Here’s an uncomfortable question: when did you last actually test your disaster recovery plan? Not a tabletop exercise. Not a walk-through with stakeholders. An actual failover test where you shut down production systems and brought them back from backups.

If the answer is “more than twelve months ago,” your DR plan is probably broken. And if your infrastructure has changed significantly since the plan was written — which it almost certainly has — it might be worse than broken. It might give you confidence you shouldn’t have.

I’ve audited disaster recovery capabilities for dozens of mid-size organisations over the past three years. The pattern is disturbingly consistent: the DR plan exists, it’s documented, it was approved by senior leadership, and it doesn’t reflect the current state of the organisation’s infrastructure.

How DR Plans Go Stale

The typical lifecycle works like this. An organisation experiences a scare — an outage, a ransomware attempt, a near-miss — and invests in building a proper DR plan. Consultants are engaged, systems are documented, backup procedures are defined, recovery time objectives are set. The plan gets tested, it works, everyone feels good.

Then the organisation evolves. New applications get deployed. The ERP gets migrated to the cloud. A team spins up a Kubernetes cluster. Someone moves the data warehouse to Snowflake. A SaaS CRM replaces the on-premises one. Each change makes sense individually. None of them trigger an update to the DR plan.

Within eighteen months, the documented architecture bears little resemblance to the actual architecture. The backup procedures cover systems that no longer exist and miss systems that do. The recovery sequence assumes dependencies that have changed. And nobody notices until something goes wrong.

The Specific Failures I Keep Seeing

SaaS applications aren’t covered. Most DR plans focus on infrastructure the organisation owns and operates. But critical business processes increasingly run on SaaS platforms — Salesforce, HubSpot, Xero, ServiceNow. What happens when those go down? Most DR plans say nothing. The assumption is “the vendor handles it,” which is only partially true. Your data in those platforms, your configurations, your integrations — those are your responsibility.

Cloud DR is assumed, not verified. “It’s in the cloud, so it’s redundant” is a statement I hear regularly. It’s dangerously wrong. Cloud services can fail. Regions go down. Availability zones have correlated failures. If your workloads run in a single region without cross-region replication, your cloud infrastructure is exactly as vulnerable as an on-premises server room — you’ve just outsourced the risk without eliminating it.

Data recovery granularity is insufficient. Organisations back up databases nightly and assume that’s adequate. But a ransomware attack that encrypts data at 2pm means your most recent clean backup is fourteen hours old. Fourteen hours of transactions, customer interactions, and operational data — gone. For many businesses, that’s unacceptable, but they don’t know it’s the case until they’re in the middle of a recovery.

People have moved. The DR plan names specific individuals responsible for specific recovery tasks. Half of them have changed roles or left the organisation. The people who actually understand the current systems weren’t involved in writing the plan and don’t know their role in executing it.

The Ransomware Dimension

I need to mention ransomware specifically because it’s changed the DR conversation fundamentally. Traditional DR assumed natural disasters, hardware failures, or human error. The recovery model was straightforward: restore from backup, bring systems online, resume operations.

Ransomware attacks compromise backups. Modern ransomware sits dormant in systems for weeks or months before activating, which means your backups may contain the malware. Restoring from backup restores the infection. If your DR plan doesn’t account for this — if it doesn’t include air-gapped or immutable backups and a process for validating backup integrity before restoration — it’s inadequate for the current threat landscape.

The Australian Cyber Security Centre has published updated guidance on ransomware-resilient backup strategies. If you haven’t reviewed it, you should.

What a Modern DR Plan Looks Like

A DR plan that works in 2026 needs several things most older plans lack:

Full scope coverage. Every system that supports a critical business process needs to be in the plan. That includes SaaS, cloud, on-premises, and hybrid systems. If it matters to business operations, it needs a recovery procedure.

Tested, not just documented. Quarterly failover tests for critical systems. Annual full-scope DR exercises. Every test needs to be documented with results, gaps identified, and remediation actions tracked. A DR plan that hasn’t been tested is a theory, not a plan.

Immutable backups. At least one backup copy needs to be immutable — unable to be modified or deleted, even by administrators. This is your insurance against ransomware. It’s not optional anymore.

Updated dependency maps. Modern applications have complex dependencies. Service A needs Service B, which needs Database C, which needs Network D. If your recovery sequence doesn’t reflect these dependencies accurately, you’ll bring systems online in the wrong order and create cascading failures during recovery.

Communication procedures. Who tells the board? Who talks to customers? Who contacts regulators? These aren’t technical questions, but they belong in the DR plan because they need to happen simultaneously with technical recovery.

Start With a Gap Analysis

If you suspect your DR plan is stale — and statistically, it probably is — start with a gap analysis. Compare the systems documented in your plan against your current infrastructure. I guarantee you’ll find gaps. Close them, update the plan, and schedule a test.

The cost of testing and updating is modest. The cost of discovering your DR plan doesn’t work during an actual disaster is enormous. This is one of those areas where the right time to act is before you need to.