How to Test a Disaster Recovery Plan and How Often

A disaster recovery plan that has never been tested is a set of assumptions. Tests find the missing password, the undocumented dependency, the backup that does not restore and the restore that takes three times longer than the plan says. Finding these in a planned exercise costs a few hours. Finding them in a real incident costs far more.

A document review checks the plan for gaps, out-of-date contacts and missing systems. A tabletop exercise walks the team through a scenario in discussion, without touching any systems, to check roles and decisions. A component test restores a single system from backup into an isolated environment and checks that it works. A simulation exercises several systems together under a realistic scenario. A failover test switches real services to the recovery environment, and it is the most realistic and the riskiest, so it should be planned carefully.

The most useful early test is to restore an important system from backup into an isolated network and time it. Then check whether the data is complete, whether the application works, and whether the time taken matches the recovery time objective. It exposes backup and documentation problems quickly, without any risk to production.

Useful scenarios include ransomware that affects production and connected backups, loss of a site or data centre, failure of the identity or directory service, an outage at a cloud provider, and the unavailability of the one person who knows a system. Each one tests different parts of the plan, and the ransomware scenario in particular tests whether an uncompromised copy of the data exists.

There is no single right answer. A common approach is a full exercise at least once a year, smaller restore tests more often for the most critical systems, and a test after any major change to systems or suppliers. Some regulations and standards set expectations for testing, so check what applies to your sector. Frequency should follow risk, meaning that the systems that matter most are tested most.

Every test should record what was tested, the times achieved against the objectives, what went wrong, who owns each fix and by when. Then retest the fixes. A test whose findings are not acted on has produced a report and nothing else. Over time, the record also shows whether recovery is getting faster and more reliable.

The findings that come up again and again are credentials or keys that nobody can find, systems missing from the inventory, dependencies no one had documented, backups that do not restore, restores that are too slow, and contact lists that are out of date. None of these is dramatic, and every one of them is much easier to fix before an incident than during it.

Announce the exercise to the people who will be affected, agree a way to stop it, and never test in production without a tested way back. Keep test restores away from live networks, so that a recovered copy cannot conflict with the real system. Then treat the exercise as routine rather than as a special event.