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:
- Pull your last three DR test results and compare recovery time actual against RTO target.
- Ask which tests were live failovers versus tabletops, and what share of critical systems have had a live test in the past twelve months.
- Confirm your dependency map matches current production, not last year's architecture.
- Verify at least one restore from immutable backup into a clean environment has been completed and documented.
- 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.
| Metric | What it measures | What it tells you |
|---|---|---|
| Recovery time actual | Time to restore a service in a real test | Whether your RTO is a commitment or a wish |
| Recovery point actual | Data lost between last good backup and failure | Whether your RPO survives contact with reality |
| Test success rate | Share of DR tests meeting objectives | Trend of capability over time |
| Mean time to detect | Time from failure to detection | How much of your recovery window is spent unaware |
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 →
