How to Test Your Disaster Recovery Plan

Ask a business owner whether they have backups and most will say yes. Ask when they last proved they could actually restore from them, and the room goes quiet. A disaster recovery plan you have never tested is a promise you have not checked, and the worst possible time to discover a backup does not work is the day you need it.

This guide explains how to test your disaster recovery (DR) plan properly, in a way that fits a UK SME. It is a companion to our full cyber incident response plan guide and pairs with our business continuity and disaster recovery executive guide.

Two numbers to agree first: RTO and RPO

Before you test anything, agree what “recovered” even means for your business. Two simple ideas do most of the work:

• Recovery Time Objective (RTO): how quickly a system needs to be back. If your order system can be down for four hours but not four days, your RTO is four hours.
• Recovery Point Objective (RPO): how much data you can afford to lose, measured in time. If you back up overnight, you could lose up to a day’s work, so your RPO is one day.

These two numbers tell you whether your current backups are good enough, and they give your tests a pass or fail line. A backup that restores in three days is a failure if your RTO is four hours, however reliable it is.

The three levels of testing

You do not need to stage a full disaster to learn something useful. There are three levels, and you can build up over time.

For most SMEs, a regular partial restore test plus an occasional fuller exercise is a sensible balance. The key is that at some point you actually restore real data, not just confirm the backup job reported success.

A simple DR test checklist

• Pick a system and confirm its RTO and RPO.
• Restore it to a safe, isolated environment, not over the live system.
• Time how long the restore takes, start to finish, and compare it to the RTO.
• Check the restored data is complete and correct, not just present.
• Test the dependencies too, such as the accounts, licences and connections the system needs to actually run.
• Confirm you can reach emergency admin access and alternative communications if the main ones are down.
• Write down what worked, what did not, and what to fix, with owners and dates.

The dependency trap

The most common surprise in DR testing is not the backup itself, it is everything the restored system quietly depends on. A restored application that cannot reach its database, a server that needs an identity platform that is also down, an emergency admin account whose password is stored in a system that needs that account to open. Real testing exposes these chains before an incident does. This is also why identity and communications usually top the recovery order: almost everything else depends on them.

How often, and when

Test at a frequency that matches your risk rather than a made-up interval. For most SMEs, an annual full test plus more frequent partial restore checks is a reasonable floor. Test again after any significant change to your systems, and after any real incident. Ransomware makes DR testing especially important, because a backup taken before the attack was visible may already be compromised, so validating what you restore is part of the job. See our ransomware response checklist for more.

Frequently asked questions

Related reading: the full Cyber Incident Response Plan guide, how long ransomware recovery takes, and the Backup and Disaster Recovery Checklist.