Published October 23, 2026
What the plan covers
NIST SP 800-34 Rev. 1 defines a disaster recovery plan (DRP) as an information system plan for major, usually physical disruptions that deny access to the primary facility for an extended period. It restores one or more systems at an alternate site. NIST says a DRP may be supported by several information system contingency plans (ISCPs), which recover individual systems once the alternate site is set up.
A lost cloud region, corrupted data and ransomware also need recovery. CISA's #StopRansomware Guide warns that many ransomware variants try to find and delete or encrypt accessible backups.
High availability does not replace the plan. AWS puts the difference this way: availability protects components of a workload, while disaster recovery maintains discrete copies of the whole workload. AWS also warns that replication can copy a deletion or corruption to the second site. Point-in-time backups are still needed.
Who sets the recovery targets
Every system needs three numbers. In NIST's business impact analysis, process owners, leadership and business managers decide the acceptable downtime. NIST defines the three:
- Maximum tolerable downtime (MTD). The total outage the system owner will accept for a business process.
- Recovery time objective (RTO). How long a system can stay down before the impact on the process becomes unacceptable. It must normally be shorter than the MTD, because reprocessing data after the restore also takes time.
- Recovery point objective (RPO). How much data loss the process can tolerate, measured back from the disruption to the last usable copy.
Shorter targets cost more. NIST describes the choice as a balance between the cost of disruption and the cost of recovery. Ask what the process loses per hour of outage, and put the price of each tier next to the answer.
Not every system needs its own recovery strategy. Consider putting systems that can be rebuilt from a build pipeline, or that the business can do without for weeks, in the lowest tier with tested backups only.
Recovery strategies
| Strategy | What is ready at the recovery site | Trade-off |
|---|---|---|
| Backup and restore | Data backups. Infrastructure, configuration and code are redeployed at recovery time. | Lowest running cost. Longest recovery. AWS says to always deploy with infrastructure as code so the infrastructure can be redeployed quickly without errors. |
| Pilot light | Data replicated and core services such as databases running. Application servers are switched off or not yet deployed. | Servers must be started and scaled before taking traffic. |
| Warm standby | A scaled-down but fully working copy of production. | Takes traffic at reduced capacity at once, then scales up. |
| Hot standby or multi-site active/active | Full production capacity in a second site or region. | Highest cost and complexity. Data corruption still needs point-in-time backups. |
The four names come from AWS's disaster recovery whitepaper. NIST uses the on-premises equivalents: cold sites with space, power and network only; warm sites with some or all hardware; hot sites fully equipped and staffed; and mirrored sites with real-time mirroring. NIST says a fixed alternate site should be in an area unlikely to be hit by the same hazard as the primary site.
The order of the work
- Write the policy. NIST's first step. It sets roles, scope, testing and maintenance schedules, and the minimum frequency of backups.
- Run the business impact analysis. NIST's three BIA steps: find the business processes each system supports and set MTD, RTO and RPO; list the resources each system needs; then rank recovery priorities.
- Map dependencies. For each system, list what must be running first: identity, DNS, network, key management, databases, integrations and outside services. These set the recovery sequence.
- Choose a strategy per tier. Match each tier to a strategy from the table, and price it.
- Write the runbooks. NIST structures each system contingency plan in three phases: activation and notification, recovery, and reconstitution, which validates the system and returns it to normal operation.
- Test. Start with a restore of one critical system from backup, then a failover of a full application.
- Maintain. Tie plan updates to change management, so a new system or a changed dependency updates the plan.
The detail plans leave out
- Verify backups before you use them. NIST CSF 2.0 outcome RC.RP-03: the integrity of backups and other restoration assets is verified before they are used. CISA warns against reinfecting clean systems during recovery and says to look for dropper malware before rebuilding from backups.
- Keep a copy out of reach. CISA recommends offline, encrypted backups of critical data, tested regularly in a disaster recovery scenario. It says some cloud vendors offer immutable storage, but to use it with caution because it does not meet compliance criteria for certain regulations.
- Golden images and infrastructure as code. CISA recommends updated golden images of critical systems and version-controlled infrastructure as code.
- Drift and quotas at the recovery site. AWS warns that capacity and service quotas in the recovery region can fall behind production. Check them as part of every test.
- Manual or automatic failover. AWS says automatic failover on health checks should be used with caution, since a false alarm costs data and availability. If failover is manual, automate the steps behind the decision.
- Where the plan lives. NIST says to keep a copy at the alternate site and with the backup media, and to train staff to carry out their roles without the document.
- When recovery ends. CSF 2.0 outcome RC.RP-06: the end of incident recovery is declared based on criteria. Write the criteria down.
Compliance, contracts and cost
HIPAA. The Security Rule at 45 CFR 164.308(a)(7) requires a contingency plan with a data backup plan, a disaster recovery plan and an emergency mode operation plan. Testing and revision, and an applications and data criticality analysis, are addressable.
HHS proposed changes in January 2025. As proposed, entities would need written procedures to restore critical systems and data within 72 hours of a loss and would test contingency plans at least once every 12 months. Business associates would report contingency plan activation to the covered entity within 24 hours. The rule is not final. The 2026 Unified Agenda lists it as a long-term action, with final action planned for July 2027.
Cloud and SaaS. AWS describes resiliency as a shared responsibility. For managed services such as Amazon S3 and DynamoDB, AWS operates the infrastructure and the customer manages backup, versioning and replication of its data. Check each SaaS contract for what the provider restores and on what terms.
Budget. NIST lists what the budget must cover: alternate site contract fees, software, hardware, travel and shipping, testing, training and awareness programs, labor hours and contracted services. Include recovery-site licenses and staff time for tests.
Skills and operations
NIST recommends training for recovery staff at least annually, and soon after someone takes on a recovery role. It matches test depth to the system's impact level: a tabletop exercise for low-impact systems, a functional exercise that includes recovery from backup media for moderate, and a full-scale exercise with failover to the alternate site for high.
NIST says contact lists need more frequent review than the rest of the plan. Give the plan one owner and a record of changes.
Settle these first
- Who signs off on each system's MTD, RTO and RPO?
- Which systems get the lowest tier, with tested backups only?
- What does recovery need first: identity, DNS, network, key management?
- Is there a backup copy that an attacker with admin credentials cannot delete?
- Who declares a disaster, and who decides when recovery is over?
- When is the first restore test, and which system goes first?
Questions
- What is the difference between RTO and RPO?
- RTO is how long a system can be down. RPO is how much data, measured in time before the disruption, the business can lose. NIST counts RTO as part of maximum tolerable downtime; RPO is separate.
- Is a disaster recovery plan the same as a business continuity plan?
- No. In NIST SP 800-34, a business continuity plan covers sustaining business processes. A disaster recovery plan covers moving information systems to an alternate site after a major disruption.
- Does replication to a second site count as a backup?
- No. Replication copies deletions and corruption to the second site. AWS and CISA both call for point-in-time or offline backups as well.
- How often should a disaster recovery plan be tested?
- NIST leaves the frequency to the organization and scales the test type to the system's impact level. Its sample policy says annually. The proposed HIPAA rule would require at least once every 12 months.
- Does HIPAA require a disaster recovery plan?
- Yes. 45 CFR 164.308(a)(7) lists a disaster recovery plan as a required implementation specification of the contingency plan standard.