Disaster Recovery Best Practices: 2026 Checklist

Most disaster recovery programs look healthy on paper. A signed plan, a stated RTO target, a binder auditors can flip through. Then a real outage hits, and none of it was ever tested against how the enterprise actually runs today.

That gap between a compliant document and a tested capability is the whole problem. The rest of this guide unpacks why documented plans fail when it matters, what hybrid and cloud environments change about recovery, and the five disaster recovery best practices that turn a plan on paper into something you can trust under pressure.

Why documented DR plans fail when it atters

Enterprises rarely lack a disaster recovery plan. What they lack is proof it works. The distance between a document that satisfies an examiner and a capability that recovers critical systems on time is where most programs quietly fail.

The compliance-vs-capability gap

A plan can pass an audit and still miss its recovery time objective by hours in a live incident. The audit checks that a document exists and covers the required topics. It does not check whether the failover actually completes, whether the runbook matches the current environment, or whether the team executing it has ever done so under load.

The cost of that assumption compounds fast. According to the ITIC 2024 Hourly Cost of Downtime Survey, more than 90% of mid-size and large enterprises lose over $300,000 per hour of IT downtime, and 41% lose between $1 million and $5 million or more per hour. Every untested assumption in your plan is a bet against those numbers.

Static documents also drift. Infrastructure changes weekly; the DR plan gets reviewed annually, if that. By the time you need it, the diagram describes a network that no longer exists.

Real example where the plan meets reality: delta after crowdStrike

On 19 July 2024, a faulty Channel File 291 content update to CrowdStrike's Falcon sensor pushed Windows endpoints into boot loops worldwide. The U.S. Government Accountability Office put the reach at roughly 8.5 million Microsoft Windows devices. CrowdStrike reverted the update quickly, but recovery required booting each affected machine into safe mode and deleting the offending file by hand.

Most airlines recovered within days. Delta took nearly a week, cancelling over 7,000 flights and stranding around 1.3 million passengers, and later filed a $500 million lawsuit against CrowdStrike and Microsoft. The failure point was not the update. It was that manual remediation at that scale, plus a critical crew-scheduling dependency, had never been rehearsed. Peers with tested recovery procedures were selling seats while Delta was still rebooting machines.

What are disaster recovery best practices?

Before the practices themselves, it helps to fix what the term actually means, because too many programs treat "best practice" as a synonym for "documented."

Disaster recovery best practices, defined

Disaster recovery best practices are the tested, current, and validated capabilities that let an enterprise restore critical systems and data within defined recovery objectives after an outage. They cover recovery objectives, dependency mapping, realistic testing, plan maintenance, and human readiness. A signed document that has never been exercised is not a best practice. It is an assumption.

DR is the IT execution layer inside a broader continuity effort. The NIST SP 800-34 Rev. 1 Contingency Planning Guide lays out a seven-step process across Sections 3.1 to 3.7, from policy and business impact analysis through recovery strategy, testing, and maintenance. The business impact analysis (BIA) remains the foundation. It tells you which systems matter, how long they can be down, and therefore where recovery investment should go first.

How DR fits within business continuity

Business continuity is a holistic process that starts with a business impact analysis, informs the development of business continuity plans (BCPs) and recovery strategies, and helps an organization keep critical operations running during and after an incident. Disaster recovery is the technical subset that restores the systems those plans depend on.

ISO 22301:2019, at Clause 8.4, treats business continuity plans and recovery strategies as living requirements that must be exercised and maintained. Written once and shelved is not the model the standard describes. For a fuller walk-through of how these pieces connect, the disaster recovery planning guide covers the end-to-end program, and this piece on what a disaster recovery plan is covers the document itself.

What the modern enterprise changes about DR

Static DR plans were built for data centers you controlled from the loading dock to the last rack. Hybrid and cloud environments broke that assumption. Recovery now depends on systems you don't own, in regions you don't manage, run by vendors whose recovery posture you may never have tested.

Hybrid and cloud dependencies static plans never accounted for

Single-site restore has given way to multi-region and multi-cloud failover patterns. SaaS dependencies mean parts of your recovery are executed by someone else, on their timeline. A runbook that assumes you can log into a console and rebuild a server does not help when the failure is in a managed service upstream of you.

Practitioners have noticed. The BCI Horizon Scan Report 2025 ranks cyber threats the highest concern for both the year ahead and the next five to ten years, and flags complex interdependencies and third-party failure as rising anxieties. Mapping those dependencies is now a core recovery task, which is why dependency visibility has moved from nice-to-have to prerequisite.

Third-party failure as a first-party outage

In March 2024, McDonald's suffered a roughly 12-hour global point-of-sale outage across markets in the Far East, Europe, the US, and Australia. The cause was a third-party configuration change during a system update, not a security incident. Per CIO's roundup of 2024 IT disasters, the change knocked out card and kiosk payments, and franchisees closed tills while the vendor sorted it out.

To the customer standing at the counter, the vendor's mistake was McDonald's outage. That is the point. Your DR scope has to reach into your critical suppliers, because their recovery time becomes your recovery time whether your contract says so or not.

The core disaster recovery best practices

These five practices form the operational spine of a DR program that actually recovers. Each one addresses a specific way documented plans break in real incidents, and each moves DR from paper assertion toward demonstrated capability.

Set and validate realistic RTO and RPO targets

Tier your recovery objectives by application criticality, drawn from the business impact analysis, not from wishful round numbers. A tier-one payment system and a tier-three internal wiki should not share an RTO. The relationship between recovery time objective and recovery point objective drives your entire architecture, from replication frequency to standby capacity.

An aggressive RTO that has never been tested is a guess wearing a commitment's clothes. Track recovery time actual against target after every test, not just the number you wrote down. The stakes are long: IBM's research found that 76% of organizations took more than 100 days to fully recover from a data breach. A four-hour RTO on paper means nothing next to that.

Map dependencies so you recover in the right order

Runbooks fail in the wrong sequence. Restore an application before the identity service, database, or message queue it depends on, and it comes up broken while you burn recovery time chasing the reason. Sequence is capability. Foundational services first, dependent apps after.

Regulators now expect this explicitly. The PRA's SS1/21 requires firms to map the resources underpinning important business services and set impact tolerances against them. You cannot demonstrate you will stay within tolerance if you cannot show the dependency chain. That mapping is also what tells you where a single supplier failure cascades.

Test with realistic scenarios, not check-the-box tabletops

A tabletop walkthrough validates awareness. A live failover validates capability. Both have their place, but confusing the first for the second is how programs build false confidence. Severe-but-plausible scenarios, including third-party outages and ransomware, belong in the rotation, and this is where structured disaster recovery testing earns its keep.

Change Healthcare shows the cost of skipping it. In February 2024, the BlackCat/ALPHV group entered through a Citrix remote-access portal that had no multi-factor authentication, dwelt for around nine days, then deployed ransomware. The attack affected roughly 190 million individuals, the largest US healthcare data breach on record, and disrupted claims for 900,000 physicians and 5,500 hospitals for weeks. For regulated financial entities, DORA Article 11 makes documented response and recovery testing a requirement, not a courtesy.

Keep plans current as the environment changes

Plans go stale the moment infrastructure changes and the document doesn't. Tie DR review to change management and to your infrastructure-as-code pipeline so the plan updates when the environment does, not on an annual calendar reminder. ISO 22301:2019 Clause 8 frames operation and maintenance as continuous, and there is a good reason for that.

Immutable, air-gapped backups deserve the same discipline. A backup you have never restored is a hope, not a control. Test the restore, verify the data, and confirm the recovery environment is clean, because ransomware that also encrypts your backups turns a bad day into an extinction event.

Prepare the people, not just the systems

Runbooks are only useful in the hands of people who have rehearsed them. Design out key-person dependencies with decision trees and cross-trained roles, so recovery does not hinge on one engineer answering their phone at 3am. Delta's crew-scheduling bottleneck was, at bottom, a human-process failure as much as a technical one.

Crisis communication protocols matter too. Knowing who decides, who informs regulators, and who talks to customers keeps the recovery moving while the technical work happens. The DRII Professional Practices place training and testing at the center of a credible program because rehearsal is what turns documentation into muscle memory.

Industry-specific disaster recovery considerations

Regulated and operations-heavy sectors face DR expectations that go well beyond general good practice. Two are worth flagging: financial services, where testing is mandated and evidenced, and manufacturing, where recovery means restoring physical processes, not just data.

Financial services: impact tolerances and mandated testing

UK firms must set impact tolerances at the point of intolerable client harm and evidence that they can stay within them, per FCA PS21/3 and SYSC 15A.2. In Australia, APRA CPS 230 at paragraphs 27 to 28 requires credible business continuity plans and annual testing against severe-but-plausible scenarios. These regimes converge on the same demand: prove it, don't assert it. Firms working through this often start with operational resilience for financial services.

Manufacturing and operations: recovering physical processes

When OT and IT converge, DR has to cover production systems, not just databases. A recovered ERP does not help if the line is still down. Manual fallback procedures matter here, and the February 2024 AT&T Mobility outage shows why. Per CIO's disaster roundup, the interruption hit around 125 million devices for more than 12 hours, blocked roughly 92 million calls, and disrupted about 25,000 emergency 911 calls. When the automated channel dies, the fallback has to exist and have been practiced.

How to know your DR program is genuinely resilient

Resilience is measurable. It shows up in test results and actuals, not in the existence of a plan. To pressure-test your own program, work through these five checks:

1. Pull your last three DR test results and compare recovery time actual against RTO target.
2. Ask which tests were live failovers versus tabletops, and what share of critical systems have had a live test in the past twelve months.
3. Confirm your dependency map matches current production, not last year's architecture.
4. Verify at least one restore from immutable backup into a clean environment has been completed and documented.
5. Check whether the people executing the runbook have rehearsed it, or only read it.

Metrics that prove capability, not paperwork

Track the actuals, not just the targets. The metrics that tell you something real are the ones that come out of tests and incidents.

Detection speed matters more than most programs admit. IBM's 2025 research put the average breach lifecycle at 241 days to identify and contain, the lowest in nine years, and found that organizations using AI extensively in security cut that lifecycle by 80 days and saved nearly $1.9 million on average. Faster detection shrinks the whole recovery problem.

Closing the test-and-validate gap

The move that separates the compliant from the resilient is unglamorous: go from the annual tabletop to recurring, scenario-based exercises and simulations that stress the plan against how the enterprise actually runs. Not to generate more paper, but to find the broken dependency and the stale runbook before an incident does.

Proof beats paperwork. A program that can show its recovery time actuals, its test success rate, and its dependency map has something an auditor's binder never will: evidence.

Discover how Fortiv's exercise and simulation solutions help teams prove their disaster recovery plans actually work →

Disaster recovery best practices checklist for 2026

Use this checklist as a quick reference for your annual DR programme review. Each item corresponds to a practice detailed in the sections above.

1. 1. Derive all recovery objectives (RTO, RPO) from a current business impact analysis, not from infrastructure defaults.
2. 2. Classify systems into criticality tiers and assign DR strategies proportional to each tier's impact profile.
3. 3. Map all dependencies (upstream, downstream, third-party, internal) for every Tier 1 and Tier 2 system.
4. 4. Test DR plans at least annually for every tier, quarterly for Tier 1 systems with tight RTOs.
5. 5. Run at least one full failover test per year, not just tabletop walkthroughs.
6. 6. Validate backup integrity independently of the backup vendor's own reporting.
7. 7. Protect backups against ransomware with immutable storage, air-gapped copies, or both.
8. 8. Document and rehearse manual workarounds for the period between system failure and DR activation.
9. 9. Keep DR runbooks updated within 30 days of any infrastructure change.
10. 10. Capture every test result, remediation action, and closure in an auditable improvement log.
11. 11. Assign each remediation a named owner and deadline. Unfixed findings from previous tests void the assurance of the next one.
12. 12. Review and refresh third-party DR SLAs annually, verifying that contracted RTOs still match your business requirements.

Treating this as a living checklist rather than a one-time audit is what separates programs that recover from programs that have a plan.

For detailed guidance on test types and frequency, see the companion guide on disaster recovery testing. Organizations running recovery infrastructure in the cloud should also review cloud disaster recovery architecture and strategy considerations specific to multi-region and hybrid environments.

The five core disaster recovery strategies

Most enterprises choose from five recognized DR strategies. Each sits at a different point on the cost-vs-recovery-speed spectrum, and each carries different infrastructure requirements. Understanding what each actually involves is the prerequisite to matching one to your RTO and RPO targets.

Backup and restore

Backup and restore is the simplest strategy: data is backed up on a schedule (hourly, daily, or weekly), and recovery means restoring from the most recent clean backup. No parallel infrastructure runs. Cost is low; recovery time is high. RTOs measured in hours or days are typical, and RPO equals whatever interval sits between your last backup and the incident.

This strategy is appropriate for non-critical systems where several hours or days of downtime is tolerable, or as a baseline layer beneath a more capable primary strategy. It is not appropriate for systems with sub-four-hour RTO requirements.

Pilot light

Pilot light keeps a minimal version of core infrastructure always running in a secondary environment, usually cloud. The database replicates continuously; compute resources sit idle or at minimum capacity. When a disaster occurs, you scale up the compute layer and redirect traffic. Recovery typically takes thirty minutes to two hours depending on how much provisioning is automated.

RPO can be near-zero if replication is synchronous. RTO depends on how much of the scale-up process is pre-scripted and automated. Pilot light costs more than backup-and-restore (you are paying for the idle database instance and replication) but far less than a fully active standby.

Warm standby

Warm standby runs a scaled-down but functional version of the production environment in the secondary site. Traffic is not actively routed there, but all components are live. Recovery involves scaling up and promoting the standby to production, typically within fifteen to sixty minutes.

This strategy suits systems where an RTO under one hour is required but continuous dual-site load is not financially justified. RPO depends on replication lag, which should be monitored continuously as a KPI, not just reviewed during tests.

Active-active (multi-site active)

Active-active distributes live traffic across two or more sites simultaneously. If one site fails, traffic shifts to the remaining sites with minimal or no disruption. RTO can be measured in seconds; RPO is effectively zero if data writes are synchronous.

The trade-off is cost and operational complexity. You pay for full capacity in multiple locations. Application architecture must handle distributed state, session management, and data consistency. Active-active is appropriate for systems where any material downtime has direct revenue or safety consequences: payment processing, trading platforms, real-time manufacturing control.

Multi-site (cloud or on-premises failover)

Multi-site failover keeps a full duplicate environment ready in a secondary geographic location. Unlike active-active, the secondary site is passive until needed. Unlike warm standby, it runs at full production capacity. Failover is pre-tested and typically executes in under fifteen minutes.

Multi-site is common in regulated industries where documented failover to a geographically separated facility is a compliance requirement (UK FCA operational resilience rules, DORA, FFIEC guidance). Cost is high; it is essentially paying for two production environments.

---

How to match a DR strategy to your RTO and RPO targets

Strategy selection starts with two numbers: your RTO (maximum tolerable downtime before the business impact exceeds an acceptable threshold) and your RPO (maximum tolerable data loss measured in time). These should come from a completed business impact analysis, not executive intuition.

A rough mapping:

Two practical cautions:

First, RTO and RPO targets are often set aspirationally rather than based on what recovery infrastructure actually delivers. Before committing to a strategy, run a failover test and measure actual recovery time. The result is frequently longer than the stated RTO. If your pilot light environment takes ninety minutes to scale and your stated RTO is sixty minutes, you do not have a compliant strategy regardless of what the policy document says.

Second, a single organization will have multiple tiers of systems with different RTO/RPO requirements. A tiered approach is normal: active-active for payment processing, warm standby for order management, backup-and-restore for internal reporting. Applying one strategy across all systems wastes money on low-criticality systems and under-protects high-criticality ones.

---

Cost vs. recovery speed: a trade-off framework

Every increase in recovery speed requires a corresponding increase in infrastructure cost. The relationship is roughly exponential, not linear. Moving from backup-and-restore to pilot light is a moderate cost increase. Moving from warm standby to active-active is a step change.

A practical way to frame the trade-off:

Quantify the cost of downtime first. If an hour of downtime for a given system costs $500,000 in lost revenue, regulatory exposure, and remediation, then paying $200,000 annually for warm standby infrastructure protecting that system is straightforward to justify. If an hour of downtime costs $2,000, backup-and-restore is likely sufficient.

Include hidden costs in the comparison. Active-active architectures require significant engineering investment to handle distributed data consistency. Warm standby requires continuous replication monitoring. Multi-site requires periodic full failover tests to remain credible. These operational costs are real and often underestimated in initial budget comparisons.

Distinguish recovery infrastructure cost from testing cost. A strategy is only as good as your confidence it works. Factor in the cost of realistic DR testing (including downtime risk during tests) when comparing options. An untested warm standby is not functionally different from a warm standby that fails when you need it.

Tier by business impact. Rather than selecting one strategy enterprise-wide, map each application tier to a cost-appropriate strategy based on its RTO/RPO and revenue or operational impact. Most mature DR programs use three or four tiers with different strategies and different recovery infrastructure.

---

On-premises vs. cloud DR strategy considerations

Cloud has changed the economics of DR significantly. Strategies that previously required a second physical data center with owned hardware can now be implemented on-demand, paying only for active replication and scaling up compute only when needed.

Cloud DR advantages:

• Pilot light and warm standby become substantially cheaper because idle compute can be provisioned on-demand rather than sitting powered on
• Geographic distribution across regions is easier to implement without owning facilities
• Infrastructure-as-code makes environment provisioning faster and more consistent during recovery
• Managed replication services (AWS Database Migration Service, Azure Site Recovery, GCP Backup and DR) reduce operational overhead

Cloud DR risks to account for:

• Recovery time depends on provisioning speed, which varies and should be tested, not assumed
• Cloud region outages do occur; single-cloud, single-region DR does not address provider-level failure
• Egress costs for large data volumes during recovery can be material and should be modeled in advance
• Compliance requirements in some industries (financial services, healthcare, government) restrict where data can be stored and processed; cloud region selection must account for data residency rules

On-premises DR still applies when:

• Latency requirements for real-time replication make cloud secondary sites impractical
• Air-gapped or classified environments prevent cloud connectivity
• Existing contractual commitments make on-premises secondary sites more economical than transition costs

For most enterprises, a hybrid approach is realistic: cloud DR for the majority of workloads, on-premises secondary capacity for specific high-sensitivity or latency-critical systems. Document the rationale for each tier. Auditors and regulators increasingly expect to see evidence of the decision process, not just the outcome.

---

Industry-specific strategy selection examples

RTO and RPO requirements do not exist in isolation; they are shaped by regulatory obligations, operational dependencies, and the nature of failure consequences. Three sectors illustrate how these factors push strategy selection in specific directions.

Financial services

Financial regulators in most major jurisdictions set explicit expectations around operational resilience and recovery. UK FCA PS21/3 and the EU's Digital Operational Resilience Act (DORA) both require financial institutions to define impact tolerances for important business services and demonstrate they can recover within those tolerances under realistic disruption scenarios.

In practice, this means:

• Payment processing and trading systems typically require active-active or multi-site strategies, with RTO targets measured in seconds to minutes
• Customer-facing banking applications generally require warm standby or multi-site with RTO under one hour
• Regulatory reporting systems may tolerate longer RTOs but carry strict RPO requirements because reconstructing transaction data is costly and sometimes impossible
• Documented, tested failover evidence is mandatory for regulatory examination; passing a tabletop exercise does not satisfy DORA's requirement for testing under realistic conditions

Manufacturing and industrial operations

Manufacturing DR planning must account for operational technology (OT) alongside IT systems. SCADA, MES, and industrial control systems often cannot be recovered with the same techniques as enterprise IT.

Key considerations:

• OT systems may have vendor-specific recovery requirements that preclude standard cloud DR approaches
• A five-minute IT RTO is meaningless if the production line requires a two-hour manual restart procedure after a control system recovery
• Supply chain dependencies mean that recovery of internal systems does not equal recovery of operations; DR planning must extend to supplier notification and logistics rerouting
• Backup and restore may be acceptable for internal ERP systems; operational control systems almost always require warm standby or higher to meet production continuity requirements

Healthcare

Healthcare DR is shaped by patient safety obligations and regulatory requirements including HIPAA in the United States and equivalent frameworks internationally.

• Electronic health record (EHR) systems directly affect patient care; RTOs over four hours are generally not acceptable for active clinical facilities
• Medical imaging systems (PACS) carry large data volumes that affect both RPO targets and the practical feasibility of different replication strategies
• HIPAA requires that backup and recovery processes maintain the privacy and security of protected health information; encryption in transit and at rest must be verified in the DR environment, not just production
• Downtime procedures (paper-based fallback workflows) must be documented, trained, and exercised alongside technical recovery; clinical staff need to operate during IT recovery windows

---

How to document and test your chosen DR strategy

Selecting a strategy is the planning work. Making it a reliable capability requires documentation that reflects how the environment actually operates, and testing that proves recovery works at the required scale and speed.

What DR strategy documentation should contain

A DR strategy document is not a runbook. It should answer:

• Which systems are in scope and their tier classification (RTO/RPO per tier)
• Which recovery strategy applies to each tier and why
• What infrastructure underpins the recovery capability (replication targets, secondary site or cloud region, provisioning approach)
• Who owns activation decisions and what triggers failover
• How data integrity is verified post-recovery before systems return to production use
• How the strategy is maintained as the environment changes

Runbooks that document step-by-step recovery procedures should exist separately and link back to the strategy document. They need to be updated every time the underlying infrastructure changes. Runbooks describing a network topology that no longer exists are a common failure point, particularly in organizations where infrastructure change management and DR documentation are maintained by different teams.

Testing requirements by strategy type

Each strategy type has a corresponding minimum test rigor:

Backup and restore: Regular restore tests from backup are mandatory. Testing that a backup completed successfully is not the same as testing that you can restore from it. At minimum, quarterly restore tests to a non-production environment should validate that backup data is recoverable and complete.

Pilot light and warm standby: Annual live failover tests are baseline. Testing should validate actual RTO, not estimated RTO. Measure the time from failover trigger to systems-available confirmation. Compare against targets. If actual RTO exceeds target RTO, the strategy requires adjustment before the next test cycle.

Active-active and multi-site: Chaos engineering and simulated region failure tests are appropriate. If traffic load-balancing across sites has never been tested under production-level load, it cannot be treated as a reliable failover mechanism. Game day exercises that simulate site loss while teams respond in real time give more reliable evidence than scheduled maintenance window tests.

Integrating DR testing with change management

Test results become stale quickly if infrastructure changes are not tracked against DR documentation. A practical control: require DR impact assessment as part of the change approval process for any change affecting systems in the DR scope. This is the mechanism that prevents runbooks from drifting out of sync with the environment they describe.

For more detail on structuring tests that produce reliable evidence of capability rather than checkbox completion, see disaster recovery testing.

Fortiv connects DR documentation to live system data, so when infrastructure changes, affected runbooks and recovery procedures are flagged for review automatically rather than drifting silently until the next annual review cycle.