Most disaster recovery tests prove one thing: that infrastructure can be brought back in a planned window, with the right people available and plenty of notice. Real failures are rarely like that. A useful DR plan is tested against the failures the business is most likely to face, measured by whether the business can operate again, not by whether servers are running.

I have designed DR programmes and sat through a lot of DR tests. The tests usually pass. That is part of the problem.

Why DR tests pass and real recoveries fail

A typical test is scheduled weeks ahead. The team knows the scenario, the runbook has been updated, and the systems in scope are the ones that recover cleanly. Everyone is awake and in the room. The test passes, the report goes to the board and the plan is considered proven.

Then a real incident happens at a bad time, affects something that was not in scope, or depends on a person who is on leave. The plan exists. The recovery still takes far longer than anyone expected.

What failures should DR be tested against?

Start from what is most likely and most damaging for your business, not from what is easiest to test:

  • Losing a critical application, not a whole site. Many outages are a single service, a corrupted database or a failed change.
  • Ransomware. Recovery from clean backups you can trust, with systems you must assume are compromised.
  • Losing a key supplier. A cloud region, a network provider or a managed service partner.
  • Losing people. The two engineers who know how the recovery works are unavailable.
  • Losing data integrity. The systems are up, but the data is wrong and you do not know since when.

How should you measure a DR test?

Measure the business, not the infrastructure.

  1. Can the business process run again? Orders taken, payments made, customers served. A server that is up but unusable has not recovered.
  2. How long did it take, end to end? Including detection, decisions and communication, not only the technical steps.
  3. How much data was lost? Compared with what the business agreed it could tolerate.
  4. Who made the decisions? Was it clear who could declare a disaster and switch over?
  5. What did not work? A test that finds nothing has probably not tested much.

Start with ownership

The hardest part of DR is usually not technical. It is agreeing which services matter most, who owns each one and how long the business can live without it. When those answers are missing, the infrastructure team fills the gap by protecting servers. That is how plans end up tested against the wrong failure.

Agree recovery tiers with named application owners first. Then design, and then test against the scenarios that would hurt. The tests will fail more often. That is the point. Each failure in a test is one you will not discover during a real incident.

This is the same pattern I described in the contract is the architecture document nobody reads: the decisions that shape the outcome are usually made outside the technical design.