Why Most Disaster Recovery Plans Fail During Real Outages

- Sep. 24, 2026

There’s a document somewhere in your organization. Maybe it’s a 60-page PDF on SharePoint. Maybe it’s a three-ring binder on a shelf behind the IT director’s desk, printed in 2021, with a coffee ring on page four. It has an executive summary. It has an org chart. It has a section called “Recovery Procedures” with numbered steps. Everybody signed off on it. Your auditor was happy.

And it has almost certainly never been tested under conditions that resemble an actual outage.

That’s the uncomfortable truth about disaster recovery planning. The plan isn’t the hard part. Writing the plan is a project management exercise, and most companies with more than 50 employees can produce something that looks reasonable. The hard part is what happens at 2:14 a.m. on a Saturday when a production database is encrypted, the on-call engineer can’t reach the person who built the backup system, and the recovery documentation points to a server that was decommissioned eight months ago.

I’ve watched this movie more than once. The pattern is remarkably consistent. The plan fails, but not because the IT team is incompetent or because the company was too cheap to buy the right tools. It fails because the plan was built around assumptions that stopped being true a long time ago, and nobody noticed.

This article walks through the specific reasons disaster recovery plans collapse during real outages — not theoretical reasons, but the mechanical, predictable failure points that show up again and again. Then we’ll get into what a plan that actually holds up looks like, including how to test it without betting the business on the outcome.

What “Disaster Recovery” Actually Means (and What It Doesn’t)

Before we get into the failure modes, let’s clear up a definitional mess that trips up a lot of organizations.

Disaster recovery is not backup. Backup is a copy of your data. Disaster recovery is the ability to keep operating — or to resume operating within an acceptable window — after something takes your primary systems down. Those are related but very different capabilities. You can have immaculate backups and still have no disaster recovery, because you never figured out how to turn those backups back into a working business.

Disaster recovery is also not business continuity. Business continuity is the broader discipline that covers everything: where do employees work if the office is inaccessible, who talks to customers, how do you process payroll if the accounting system is gone for a week, what’s the manual fallback for the order desk. Disaster recovery is the technology slice of that. Important slice, but not the whole pie.

And finally, disaster recovery is not the same thing as high availability. High availability keeps systems running through component failure — a redundant power supply, a second node in the cluster. Disaster recovery handles the events that redundancy doesn’t: a region-wide outage, a ransomware event that spreads across your environment, a cloud provider having a very bad Tuesday.

Companies conflate all four of these constantly. Then they buy one solution to cover all of them and are surprised when it doesn’t.

Failure #1: The Backups Were Never Actually Recoverable

This is the most common failure, and it’s the most infuriating because it’s entirely avoidable.

A backup that completes successfully is not a backup. It’s a file that says the job ran. Those two things are related the way a gym membership is related to being in shape.

Here’s what typically goes wrong:

The backup captured corrupted or encrypted data. Ransomware operators figured out years ago that the fastest way to extort a company is to corrupt the backups first. If your backup chain runs nightly and the infection starts on Monday, you now have three or four nights of encrypted backups before anyone notices. Restoring them gives you a working copy of the attacker’s payload.

The backup is incomplete in ways nobody documented. Maybe the SQL database was being backed up at the file level while it was running, which produces a backup that cannot be mounted. Maybe an application stores half its state in a database and half in a local folder that wasn’t in scope. Maybe the virtual machine backup excluded the disk that holds the file shares.

The restore process only works on one person’s laptop. You’d be shocked how often the “restore procedure” is really just “call Marcus, he knows how it works.” Marcus is on vacation in Portugal, and the runbook in the binder says to use the admin console that was replaced by a different vendor’s tool last year.

The retention window is shorter than the incident. If you keep seven days of backups and the compromise sat undetected for eleven days, your oldest recovery point is already infected. Compliance frameworks love to mandate retention periods, but the real question is: how far back do you need to go to reach a clean state? For most organizations, that number is bigger than they think.

The backup infrastructure is in the blast radius. Backups stored on the same network as the production environment, using the same domain credentials, are one compromised admin account away from being deleted along with everything else. Immutability and offline copies matter here — not as buzzwords, but as architectural decisions.

The fix is conceptually simple: restore something. Not a test restore of a single file, but a genuine recovery of a real system into an isolated environment, on a schedule you actually keep. If you can’t do that, you don’t know whether you have backups. You know that you have backup jobs.

Failure #2: Nobody Planned for Ransomware

Traditional disaster recovery planning was built around a fairly narrow set of scenarios. Hurricane takes out the data center. Power grid fails. Hardware dies. Someone drives a backhoe through a fiber line. Fire, flood, earthquake, sabotage.

All of those scenarios share a characteristic that ransomware doesn’t: the primary environment is destroyed or unavailable, but the data inside it is intact. You restore from backup, and you’re back.

Ransomware inverts that. The environment is still there. It’s just been weaponized against you. And now a bunch of assumptions break at once:

You can’t trust any credential in the environment, including the ones your recovery process uses.
You can’t trust the backups until you’ve verified them forensically.
You can’t simply “fail over to the DR site” if the DR site authenticates against the compromised domain.
You may be legally or contractually obligated to determine what data was exfiltrated before you restore and resume.
The clock is different. With a hurricane, everyone knows the outage happened. With ransomware, the attacker may have been inside for weeks. Your “last known good” point could be two weeks in the past.

This is why incident response and disaster recovery have to be planned together. A disaster recovery plan that begins with “declare a disaster, activate the DR site, notify leadership” doesn’t address the ransomware case, where the first move is to isolate, preserve evidence, and figure out what’s been touched.

If your DR plan has no ransomware scenario in it, you’re planning for the last decade’s disasters.

Failure #3: Dependency Maps That Stop at the Data Center Door

Most DR plans contain a section that lists systems in priority order. ERP, email, file shares, the customer portal, the phone system. That’s a good start. It’s also drastically incomplete, because almost nothing in a modern business is self-contained.

Consider a mid-sized manufacturer’s order-to-cash process. To ship a product, you need:

The ERP system, running on a database, running on a VM, running on a host, connected to storage.
An identity provider for authentication, which might be Microsoft Entra ID, which might depend on an on-premises sync agent.
A label printing service, which runs on a print server, which talks to a third-party API.
An EDI connection to a customer’s system, which requires an outbound network path and a certificate that expires in six months.
A warehouse management tool, which is a SaaS application with its own availability guarantees and its own integration back into the ERP.

Your plan says “ERP: RTO 8 hours.” Great. Now which of those dependencies have to be up, in what order, for the ERP to actually be useful? If the identity provider is down, nobody logs in. If the EDI connection is broken, orders come in and go nowhere.

Dependency mapping is tedious. It requires talking to business process owners, not just system administrators. It means drawing lines between things that technically live in different departments. That tedium is exactly why it gets skipped, and skipping it is why the recovery takes four days instead of four hours.

A useful exercise: pick your top three business processes and trace every system, credential, network path, vendor, and person required to complete them. Then ask which of those appear in your DR plan. The gap is usually eye-opening.

Failure #4: RTO and RPO Assumptions That Nobody Validated

Recovery Time Objective (RTO) is how long you can afford to be down. Recovery Point Objective (RPO) is how much data you can afford to lose, expressed in time.

Both numbers get invented in a conference room.

A typical scene: a CIO asks the business units what their RTO should be. Nobody wants to say “24 hours” because that sounds lazy, so everyone says “four hours.” The CIO writes down four hours. The plan promises four hours. The infrastructure can deliver about thirty-six. Nobody discovers this until the outage.

Here’s the thing about RTO and RPO — they’re business decisions with cost implications, not technical preferences. A four-hour RTO for a system that generates $50,000 of revenue per hour is worth paying for. A four-hour RTO for the internal training portal is absurd.

Some practical guidance:

|—|—|—|—|

The critical step is writing down the cost of the RTO you’re promising. If a four-hour recovery requires a second data center, replicated storage, and a full-time engineer who knows the failover process, that’s a number in the budget. If leadership sees the number and decides eight hours is fine, you just saved a lot of money and eliminated a promise you couldn’t keep.

Then test it. An RTO you haven’t measured is a wish.

Failure #5: The People Who Wrote the Plan Left

DR plans have a half-life. Every reorganization, retirement, job change, and vendor swap erodes them a little.

The specific ways this bites:

The runbook references tools that no longer exist, or neglects tools that were added.
The contact list still includes the cell number of someone who left two years ago.
The escalation path routes through a role that was consolidated into another department.
The person who held the institutional knowledge — the one who knew that the DR failover requires manually updating a DNS record that isn’t documented anywhere — is gone.

The plan looked fine. It passed the annual review because the annual review was “does the document exist and does it have last year’s date replaced with this year’s.”

Combating this requires treating the DR plan as a living artifact rather than a compliance deliverable. In practice that means assigning an owner (a name, not a committee), reviewing it quarterly, and forcing a genuine review whenever a significant change happens: new critical application, new cloud provider, key staff departure, major architecture change.

Documentation rot is boring, which is exactly why it’s dangerous. It doesn’t announce itself. You find out during the outage.

Failure #6: Compliance Documentation Got Mistaken for Readiness

If you operate in a regulated industry, you have paperwork. SOC 2 reports. HIPAA risk analyses. PCI DSS attestations. ISO 27001 certificates. Regulators and auditors ask for evidence of a disaster recovery plan, and you provide it, and everyone moves on.

Here’s the trap: satisfying an auditor and surviving an outage are different goals that happen to share some artifacts. An auditor needs to see that a plan exists, that it was reviewed, that it covers the right systems, and that it includes testing evidence. An outage needs the plan to actually work.

Those diverge in a few specific ways:

Audit evidence often accepts a tabletop exercise. A tabletop exercise is people sitting in a conference room saying “then we’d fail over.” It is not a failover.
Compliance frameworks care a lot about retention and documentation. They care less about whether your restore process works when the domain controller is offline.
Auditors evaluate the plan you have. They don’t evaluate the disaster you’ll actually face, which might not be in the plan at all.

None of this means compliance is worthless — far from it. Good frameworks push organizations to do things they’d otherwise skip. But if your answer to “is our DR plan solid?” is “we passed our audit,” you’ve answered a different question.

Compliance and resilience should be the same program, not two parallel efforts with separate budgets and separate owners. When they’re separate, you get duplication, gaps between them, and a false sense that the compliance side has you covered.

What a Real Outage Actually Looks Like, Hour by Hour

Abstract failure modes are easy to nod along with. Concrete timelines are more useful. Here’s a composite scenario drawn from the kind of events that happen regularly — a ransomware attack against a 300-person professional services firm on a Thursday afternoon.

Hour 0 — 3:40 p.m. Thursday. A user reports that files in a shared folder are renamed with an unfamiliar extension. The help desk opens a ticket. Total elapsed time to “something is wrong”: about twenty minutes.

Hour 1 — 4:00 to 5:00 p.m. The IT team confirms encryption is spreading. Someone pulls the network cable on the file server. Someone else starts calling the MSP. The incident commander role is unfilled, so three people are independently making decisions. Two of them are making contradictory decisions. The backup system is still running its scheduled job against the now-encrypted primary storage.

Hour 2 — 5:00 to 6:00 p.m. Leadership is notified. Legal is notified. The cyber insurance carrier’s hotline is called and put on hold. The team attempts to identify the initial access point. They can’t, because the endpoint detection tool’s console authenticates against the domain, which is now untrusted.

Hour 3 — 6:00 to 7:00 p.m. Someone remembers the DR plan. It’s retrieved from SharePoint, which is still accessible because it’s cloud-hosted. The plan says to contact the infrastructure manager at his office extension. He’s not at his desk. His cell number in the plan is three years out of date.

Hour 4 — 7:00 to 8:00 p.m. The team decides to restore from backup. The most recent backup is from 2:00 a.m. — but the encryption started appearing at 3:40 p.m., so the 2:00 a.m. backup should be clean. Except the backup job that runs at 2:00 a.m. also captured the virtual machine’s snapshot chain, and the snapshot chain includes disks from an earlier point. Nobody is sure which recovery points are clean. The verification process is “restore it and see,” which takes four hours per attempt.

Hour 12 — Friday morning. First restore attempt fails. The database mounts but the application won’t start because it depends on a service account stored in the compromised Active Directory. The team starts rebuilding AD from scratch. Nobody has done this before. There’s no documented process.

Day 3 — Sunday. Systems are coming back online piecemeal. Email works. The file shares are partially restored. The ERP won’t talk to the bank integration because the certificate store wasn’t included in the backup scope.

Day 6. Full operations resume. The actual recovery took 132 hours. The plan said 24.

Notice what went wrong. Almost none of it was a technical failure of the backup software. It was almost entirely a failure of preparation: no incident commander, no verified clean recovery point, no offline credential store, no tested restore procedure, no current contact list, no dependency map that included service accounts and certificates.

Every one of those is a planning problem. Every one of them is fixable in advance.

How to Build a Disaster Recovery Plan That Survives Contact With Reality

If you’re rebuilding your DR capability — or building one for the first time — here’s the sequence that tends to produce plans that hold up.

Step 1: Start with business impact, not systems

Interview the people who own revenue, customer service, payroll, and regulatory obligations. Ask what they need, in what order, and what happens if it’s unavailable for a day, a week, a month. You’ll end up with a ranked list of business functions. That ranking, not the IT asset inventory, drives everything else.

Step 2: Map dependencies for the top functions only

You don’t need a dependency map for all 200 applications. You need one for the ten or fifteen functions that would actually stop the business. Trace those completely: systems, data stores, identities, network paths, third-party APIs, certificates, licenses, hardware tokens, and the humans who know how it works.

Step 3: Set RTO and RPO with a price tag attached

For each ranked function, propose an RTO and RPO, then attach the estimated annual cost of achieving it. Let leadership choose with real numbers in front of them. Document the choices and the reasoning. When the CFO asks in two years why email has an eight-hour RTO, you’ll have the answer.

Step 4: Design for the ugly scenarios

Standard DR designs assume systems fail. Modern DR has to assume systems are compromised. That means:

Immutable and offline backups. Something the attacker cannot delete, even with domain admin credentials.
Out-of-band recovery credentials. A separate identity system for recovery, stored offline, with break-glass procedures documented and rehearsed.
Isolated recovery environment. A place to restore and verify data without connecting it to production.
Clean-room capability. The ability to rebuild core infrastructure from scratch using documented procedures, not tribal knowledge.
Forensic preservation. The ability to determine what happened and what data was exposed, because you’ll need that for regulators, customers, and your insurer.

Step 5: Write runbooks at the task level

“Restore the ERP system” is not a runbook. It’s a heading. A runbook reads like this:

Log into the backup console using the recovery account from the sealed envelope stored in the CFO’s safe.
Select the recovery point labeled ERP-PROD-2026-09-24-0200.
Restore to the isolated recovery VLAN 10.50.0.0/24.
Verify database integrity by running sqlcheck -db ERP -verify.
Update the application config file app.config line 42 with the recovery environment’s DNS suffix.
Run the smoke test script erp-smoke.ps1 and confirm all 14 checks pass.
Freeze the recovery point and document the verification timestamp.

Someone who has never performed the restore should be able to follow that at 3 a.m. under stress. If your runbook requires interpretation, it’s not done.

Step 6: Assign one accountable owner

Not a committee. One name. That person is responsible for the plan’s accuracy, the testing schedule, and the budget conversation. Committees produce documents. Individuals produce working systems.

Step 7: Test on a schedule and track the results

Quarterly. At minimum. With a rotation of scenarios so you’re not rehearsing the same easy one forever. Record actual recovery times, compare them to RTO targets, and fix the gaps.

Step 8: Close the loop with a written after-action review

After each test — and after each real incident — write down what worked, what didn’t, and what changes as a result. Assign owners and dates to each change. Then verify the changes landed. Without this step, testing becomes theater.

Testing: The Step Everyone Skips, and Why It Matters Most

Let’s be honest about why testing gets skipped. It’s disruptive, it’s expensive, and there’s a real chance it surfaces problems that are embarrassing or expensive to fix. Testing a DR plan is essentially an invitation to find out that your assumptions were wrong.

That’s the point.

There are four levels of testing, roughly in order of rigor:

1. Document review. Someone reads the plan and checks it for accuracy. Useful, cheap, and almost meaningless on its own. Half of all “DR testing” is this.

2. Tabletop exercise. The team walks through a scenario and discusses decisions. Great for testing communication, escalation, and decision-making. Doesn’t test anything technical.

3. Component test. Restore a single system into an isolated environment and verify it works. This is where you find out whether your backups are actually restorable, and it should happen monthly for critical systems.

4. Full failover test. Run production from the recovery environment for a defined window. This is the only test that proves your DR capability end to end, and it’s the one most organizations never do.

If you can only do one thing, do component tests. They’re cheap, they find the most common problems, and they build the muscle memory your team will need during a real event.

A practical cadence looks like this:

Monthly: restore one critical system to an isolated environment and document the result.
Quarterly: tabletop exercise with business stakeholders, rotating scenarios.
Annually: full failover test for the highest-priority business function.
After every real incident: after-action review with documented follow-ups.

Track your actual recovery times over time. If they’re not improving, you’re not actually fixing anything.

Common Mistakes in Disaster Recovery Planning

A quick list of the patterns that show up most often. If you recognize three or more, it’s worth taking a hard look at your plan.

Treating the plan as a document instead of a capability. The PDF isn’t the point. The ability to recover is the point.
Assuming cloud services are automatically resilient. Cloud providers guarantee infrastructure availability, not your application configuration, not your data integrity, not your identity system, and not your ability to log in.
Leaving the recovery credentials in the environment being recovered. A vault that requires domain authentication is not a recovery credential. It’s a liability.
Forgetting the third-party dependencies. Your EDI partner, your bank integration, your certificate authority, your DNS registrar, your SaaS vendors. All of them can be the reason your recovery stalls.
Not testing the restore of the backup software itself. This happens more than you’d think. The backup server is a system too.
Skipping the communications plan. During a real outage, your internal teams, customers, and regulators all want updates. If nobody owns communications, everyone invents their own story.
Planning around a single scenario. Hurricanes happen in specific geographies. Cyberattacks happen everywhere. Plan for the events that are actually likely for you.
Assuming your insurance covers the gap. Cyber insurance is a financial backstop, not a recovery capability. Carriers increasingly ask detailed questions about your controls and your testing before paying out.
Letting the plan drift out of date between annual reviews. Quarterly reviews exist because annual reviews aren’t enough.
Not writing down what you learned. Every incident and every test teaches something. If you don’t capture it, you’ll learn it again next time.

The Hidden Costs of Getting This Wrong

It’s tempting to treat DR investment as insurance — money spent against something that probably won’t happen. That framing undersells the downside, because the costs of a failed recovery go well beyond the outage itself.

Direct revenue loss. Industry surveys have consistently put the hourly cost of downtime for large enterprises in the hundreds of thousands of dollars. For smaller organizations, the number is lower but the pain is sharper, because there’s less cushion to absorb it.

Customer attrition. Customers forgive outages. They don’t always forgive outages that stretch into weeks, especially when competitors can promise they won’t. The churn impact often shows up months later.

Regulatory exposure. Many frameworks require notification within set windows, plus documented evidence of your controls. A recovery that wasn’t documented can turn a survivable incident into an enforcement action.

Legal liability. If you lost data that belonged to someone else, that conversation is happening with lawyers.

Staff burnout. The people doing 20-hour recovery shifts are the same people you need to keep. Failed recoveries have a way of producing resignations.

The cost of the fix, at the worst possible time. Everything is more expensive during an incident. Emergency consulting, expedited hardware, overtime, forensic firms. The same work done proactively costs a fraction.

When you add these up, the business case for tested disaster recovery tends to be a lot stronger than the business case for most IT projects. It’s just harder to get excited about, because the return is invisible until it isn’t.

How IP Services Approaches Disaster Recovery and Business Continuity

Most organizations don’t fail at DR because they don’t care. They fail because DR requires sustained attention across a lot of disciplines — backup architecture, identity design, security operations, compliance, documentation, and testing — and no single internal team owns all of it.

IP Services has been building and running this kind of infrastructure since 2001, mostly for organizations where downtime has real consequences: financial services firms, healthcare providers, manufacturers, legal practices. The approach comes out of the VisibleOps methodology the company developed and published — practical frameworks for IT operations that have been used across a lot of environments since the first book came out.

In practical terms, the work involved usually looks something like this:

Cyber risk assessment first. Before designing recovery, it helps to know what you’re actually protecting and where the gaps are. IP Services runs assessments that cover both the security posture and the recoverability of critical systems, so the DR plan is built on real data rather than assumptions.

Managed backup and disaster recovery. Backup infrastructure with immutable copies, isolated restoration environments, and documented recovery runbooks — plus regular restore testing, which is the part most organizations never get around to. Recovery targets get validated against actual measured recovery times, not vendor claims.

Security operations feeding into recovery planning. Because ransomware is the scenario most likely to trigger a real recovery, the managed SOC and managed detection and response services aren’t separate from DR — they inform it. Knowing how a compromise propagates changes how you architect recovery.

Identity and access design that supports recovery. Out-of-band recovery credentials, break-glass procedures, and separation between production identity and recovery identity. This is one of the most commonly skipped elements, and one of the most consequential.

Compliance and resilience as one program. Compliance-as-a-service work runs alongside the DR planning, so audit evidence and recovery capability come from the same effort rather than two parallel paper trails. Frameworks like HIPAA, SOC 2, and PCI DSS get mapped onto the same controls that make recovery work.

Virtual CIO and strategy support. For organizations without a full-time CIO, vCIO services cover the planning conversation: what RTO and RPO make business sense, what the investment looks like, and how to sequence the work over a year or two instead of trying to do everything at once.

Proprietary tooling. TotalControl™ was built to surface IT issues before they turn into outages, and Visible AI combines security monitoring with compliance tracking. Both feed the same goal: fewer surprises, and better information when something does go wrong.

None of that is magic. It’s the unglamorous work of backup architecture, documented procedures, rehearsed failovers, and someone actually testing the restores. If you want to see how it would apply to your environment, the team is reachable at 866-226-5974 for sales conversations or through the client portal if you’re already a customer.

Frequently Asked Questions About Disaster Recovery Plans

How often should we test our disaster recovery plan?

At minimum, quarterly tabletop exercises and annual full failover tests. But the more useful answer is: restore at least one critical system from backup every month, in an isolated environment, and document the result. Monthly component tests catch the most common problems — corrupted backups, missing dependencies, stale documentation — long before a real outage exposes them. Annual tests alone leave you with eleven months of blind spots.

What’s the difference between RTO and RPO?

RTO (Recovery Time Objective) is how long the business can tolerate a system being unavailable. RPO (Recovery Point Objective) is how much data loss is acceptable, measured in time — an RPO of one hour means you can lose up to an hour of transactions. Both should be set by the business side with cost estimates attached, not chosen by IT because they sound good.

Can’t we just rely on our cloud provider’s disaster recovery?

Cloud providers guarantee the availability of their infrastructure, not your application. They don’t manage your configuration, your identity system, your data integrity, your integrations, or your ability to log in and operate. A misconfigured access policy or a deleted resource can take you down even when the provider’s status page is green. Cloud changes the shape of disaster recovery; it doesn’t eliminate it.

How long should we keep backups?

Long enough to reach a clean recovery point. For ransomware and other slow-burn incidents, that often means longer than the seven or thirty days most organizations retain. A reasonable starting point is 30 days of daily recovery points plus monthly archives for a year, with at least one immutable copy that can’t be deleted by compromised credentials. Check your industry’s requirements too — some mandate specific retention periods.

What’s the single most common reason DR plans fail?

Untested assumptions. Specifically: assuming backups are restorable, assuming the RTO is achievable, assuming the contact list is current, assuming the runbook matches the current environment, and assuming the recovery credentials still work. Every one of those gets verified by testing and by nothing else.

Does cyber insurance cover a failed recovery?

Insurance covers financial losses from covered events, within policy limits, subject to conditions. It does not restore your systems. Increasingly, carriers ask for evidence of backup testing, MFA, segmentation, and documented incident response before they’ll pay claims. Treat insurance as a financial backstop, not a recovery strategy.

How do we know if our DR plan is adequate?

Three questions: Have you successfully restored a critical system in the last 90 days? Do you know your actual recovery time for that system, measured? Can someone other than the person who built it follow your runbook and complete the restore? If you can answer yes to all three, you’re ahead of most organizations. If not, that’s your roadmap.

What about smaller businesses — is this overkill?

The plan scales down, but the fundamentals don’t change. A 20-person firm still needs immutable backups, a documented restore process, someone who’s tested it, and a clear idea of how long it can operate without its core systems. The tools are cheaper and simpler than they were a decade ago, and managed services make it accessible without hiring a full IT department.

Where to Start Next Week

You don’t need to rebuild everything at once. A few concrete steps will tell you more about your actual readiness than another year of planning.

Pick one critical system and restore it. Not a file, the whole system. Into an isolated environment. Time it. Write down what broke. That single exercise will surface more real problems than a month of documentation review.

Check where your backups live. If they’re on the same network, using the same credentials, and deletable by the same accounts as production, that’s the first thing to fix.

Read your runbooks out loud. Hand one to someone who’s never performed the restore and ask them to walk through it. Count how many times they have to ask a question. Each question is a gap.

Test your contact list. Call the numbers. Send emails to the addresses. See who responds. It takes an hour and it’s genuinely useful.

Ask your business leaders what an eight-hour outage costs. Then ask what they’d pay to make it four. That conversation does more to align DR investment with reality than any technical assessment.

And if the honest answer to “when did we last test this?” is “I’m not sure” or “before the pandemic,” the gap isn’t going to close on its own. Disaster recovery is one of those areas where the cost of neglect compounds quietly for years and then arrives all at once, usually on a Saturday.

The good news is that the failure modes are known, they’re predictable, and most of them are fixable with work that isn’t especially exotic. Immutable backups, tested restores, documented runbooks, out-of-band credentials, dependency maps that go all the way to the third-party APIs, and a testing cadence that actually happens. None of that requires heroics. It requires deciding it matters before you need it.

For most organizations, the plan on the shelf is a starting point, not a solution. The question is whether you find that out during a test you scheduled or during an outage someone else scheduled for you.

Posted in Compliance, Risk Management, Solutions