An untested disaster recovery plan is a set of assumptions, and disaster recovery plan failures show up when someone tries the restore, not in the document. Here, a plan means the written steps for bringing systems back after an outage. Two terms run through it. RTO (recovery time objective) is how long the business can wait for a system. RPO (recovery point objective) is how much recent data it can afford to lose. The runbook is the written steps, and failover is switching to the recovery copy.
Last reviewed 2026-11-02 by Manish Sharma.
This article is for an IT manager or IT head at a mid-size firm in India or the GCC who has a plan on file and a small team. It gives a reasoned order in which the plan comes apart, starting from RTO and RPO, with three primary sources. The order is Signisys’ own reading of what a restore needs. It is not a standard.
Disaster Recovery Plan Failures in Short: The Order an Untested Plan Breaks
A plan breaks in the order a restore needs things: first the targets the restore must meet, then the systems, then the people, and last the document itself. In Signisys’ view, targets come first because every other break is judged against them. Knowing the order tells you where to look this week.
An untested disaster recovery plan can look complete on paper at every row below.
| Break point | What the plan assumed | What shows on the day |
|---|---|---|
| 1. Recovery targets | Someone set the RTO and RPO once, and the restore would meet them. | If nobody timed a restore, the first real attempt can run past the RTO. |
| 2. Dependencies and restore order | Each system comes back on its own, in any order. | If the database starts after the application, the application can stall. |
| 3. Drift | The recovery site still matches production. | Changes that reached only production leave the recovery copy short of what the service needs. |
| 4. People and access | The named people are reachable and hold the access they need. | If the one person who knows a system is away, the restore waits. |
| 5. The plan copy | Someone can open the plan when the outage hits. | A copy on the failed system stays out of reach. |
Break Point 1: Disaster Recovery Plan Failures Begin With Unproven RTO and RPO
A target in a document is a promise that nobody has timed. In Signisys’ view, every later break answers to it, which is why it sits first.
What the two targets promise
The RTO says how long a system may stay down, and the RPO says how old the restored data may be. The AWS Well-Architected Reliability Pillar practice REL13-BP03 says to test failover so that the RTO and RPO are met. It rates the risk of skipping that practice as high. A plan that was never run has no evidence for either number.
How an untimed target fails
Restore time depends on the amount of data and the number of steps. A recovery point that held at the last test may not hold now, because data and systems have changed. In Signisys’ view, this failure is quiet: everything starts, but it starts later than the business can wait, or from a copy older than it can accept. Either way the recovery has missed its target, even if no step reports an error.
An untested disaster recovery plan also leaves the targets unchallenged. The person who signed off the RTO may never have seen how long the restore takes.
Key Takeaway A target that nobody has timed is an assumption, whatever the document says.
NIST SP 800-34 Rev. 1 is a US federal guide to information-system contingency planning. Its abstract says it helps personnel evaluate systems and operations to determine contingency planning requirements and priorities. It is US guidance, a reference point and not a rule for firms in India or the GCC.
Break Point 2: Disaster Recovery Plan Failures From Hidden Dependencies
A multi-tier system may need restoring in layers, and a plan can list the servers without the order. The examples here are illustrations, not findings.
Picture a database restored after the application that needs it, or an application restored before the identity service that signs users in. Parts backed up on different schedules may not agree with each other. A restore may also land in a network that differs from the original, which leaves addresses and firewall rules out of step.
Some dependencies sit outside the server. A licence server, a SaaS service, a vendor portal or one specialist may each be something the system needs to run. A plan can name the server and leave out what the server needs.
What has to be running before it will start?
The recovery details also need one home. When they sit across a configuration database, a shared drive and old tickets, nobody can read the restore order in one pass. A plan like this stays readable on paper until someone has to follow it under pressure.
The copy itself can be the problem. Dormant malware or corrupt data in the latest backup can make it unusable, which is a separate story covered in why ransomware recovery fails.
Break Point 3: Disaster Recovery Plan Failures From Configuration Drift
Drift is the slow gap that opens when changes reach production but not the recovery environment. Each change that is not passed to the recovery side widens it. A patch that reaches production but not the recovery copy is the same kind of gap.
The AWS practice REL13-BP04, “Manage configuration drift at the DR site or Region”, lists four anti-patterns, shown below. AWS rates the risk of missing the practice as high.
The service-differences point applies wherever a recovery location is not an exact copy of production. A feature, quota or setting present in one place and absent in the other changes how the restore behaves. The REL13-BP03 page makes a related point about a secondary data store, whose capacity may have been enough at the last test and may no longer carry the load.
AWS lists failing to detect drift as an anti-pattern in its own right. A recovery site can look ready without being ready, and in practice the cause is record-keeping. Ask where the firm logs a change, who passes it to the recovery side, and when that last happened. If the answer relies on someone remembering, nothing has shown that the recovery side still works.
Key Takeaway Drift is a record-keeping gap, and a log of changes to the recovery side closes it.
Break Point 4: Disaster Recovery Plan Failures in People and Access
A plan lists roles, but a restore needs people who answer the phone and hold the right access. Read the questions below against your own firm. They make no claim about what other firms do.
- Is the contact list current, and has anyone dialled it lately?
- Does one person alone know a system, leaving the restore to wait on them?
- Does a vendor own the plan, with nobody inside the firm who can read it?
- In a small team with shared on-call, does one person sit on three recovery steps?
A high-level plan may assume specialists will fill in the detail. It can fail when the incident falls outside the scenarios the author imagined.
Access is the second half. The account, key or approval needed to start a restore may sit with someone who is away, or inside the system that is down. In Signisys’ view, the incident team, described in our glossary entry on incident response, should have those permissions in place before the outage and not only during it.
What an Exercise Does Not Show
An exercise can mislead. Servers pre-staged for the day, spot checks in place of a full restore, bad news softened, no success criteria, and findings that nobody acts on each produce a pass that proves little.
In Signisys’ view, a test is worth running only if it is allowed to fail.
Choosing between exercise types is a separate topic, covered in another article in this series.
Break Point 5: A Plan Nobody Can Open During the Outage
A plan helps only if someone can open it. If the copy sits on the system that is down, it is out of reach at the moment staff need it. A paper or offline copy, and a known place to keep the contact list, can close that gap.
The plan also sits inside a wider continuity picture: the workspace staff will use, and how staff and customers hear what is happening. The article on how continuity and recovery differ covers that wider view. To check the paper plan itself, read how to score a continuity plan, part by part.
For whether a highly available design removes the need for a recovery plan, see high availability versus recovery.
Disaster Recovery Plan Failures: Why a Plan Stays Untested and What to Look At First
The break points explain what fails. The remaining question is why the plan stayed untested, and where to begin.
Why a Plan Stays Untested
In Signisys’ view, the causes are governance as much as technology. Little funding or sponsor backing, the wrong people in the planning room, recovery work missing from the agenda, no review after a test, and no definition of a failed test can each let a plan sit unrun. That is how an untested disaster recovery plan stays on the shelf.
Key Takeaway In Signisys’ view, a test that exposes a gap and gets a fix is a success, and a pass that hides a gap is the failure.
A plan that leans on specialists adds a further reason to run the restore with the people who know the systems.
Three Things to Look at First
In Signisys’ view, three questions show where to start. They are not a scored list.
- Has anyone timed a restore against the RTO?
- Has someone other than the person who knows the system written down the restore order?
- What is the date of the last change that reached the recovery side?
In Signisys’ view, if two of the three have no answer, it is time to ask for outside help. The test disaster recovery readiness use case page describes Signisys’ work in this area.
Where This Article Stops
This article explains where a plan breaks. It gives no test procedure, no checklist for scoring a test and no comparison of test types, which belong to separate articles in this series.
It makes no claim about firms’ testing or failure rates. NIST and AWS are US federal and vendor guidance, and the article gives no Indian or GCC rule. It did not read ISO 22301 and makes no claim about it.
For ownership of recovery at board level, see the CISO’s role in recovery. For backup design, see immutable backup. Signisys provides business continuity and disaster recovery planning and consulting, and that is a service, not neutral advice. Signisys suggests asking for specialist help when two of the three questions above have no answer, or when nobody has timed the restore.
Frequently Asked Questions About Disaster Recovery Plan Failures
What is an untested disaster recovery plan?
In what order does a disaster recovery plan that was never run come apart?
How do RTO and RPO relate to a plan failing?
Does a plan that passed last year’s test still hold?
Who should own the disaster recovery plan in a small IT team?
When should a firm ask for outside help?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.