A test that nobody can fail is a rehearsal. The point is to find the thing you did not know, which means designing the test so finding it is the success condition.
Most organisations test their disaster recovery once a year, produce a report saying it succeeded, and file it. The test is usually a tabletop walkthrough or a single file restore, both of which are worth doing and neither of which tells you whether you could actually recover.
The reason the tests are shaped like this is not laziness. It is that the test is being run to satisfy an obligation, and a test that fails creates work and a difficult conversation. So the test is scoped to pass.
Inverting that is the whole discipline. If you design the test so that a failure is the valuable outcome, you get information. If you design it to produce a tick, you get a tick.
Four kinds of test, and what each one proves
The escalation matters because people conflate them. A tabletop is frequently described as a DR test in audit responses, and it is a genuinely different activity.
A tabletop proves your plan is coherent and your contact list is current. It finds wrong phone numbers, people who left, and steps that assume knowledge nobody has. It proves nothing about technology.
A file restore proves your backup contains data and you can get some of it back. It is a monthly hygiene check and it should be automated or trivial.
A system restore proves a system comes back, and produces the number that matters: how long it actually took. This is where the gap between documented and real recovery time appears.
A live withdrawal, where you take a system away during working hours with warning, proves whether the business can operate. It is the only test that finds the dependency nobody documented, because it is the only one that involves the people who depend on it.
A year that does not need a war room
Nothing on that calendar takes more than half a day. The annual full-scale exercise has its place in larger organisations, but for most businesses it is the reason testing does not happen: it is too big to schedule, so it slips, and then it slips again.
Designing a test that can fail
Four rules.
Decide what you want to find out before you decide what to test. "We want to know whether our documented four-hour RTO for the ERP is real" is a test design. "We should test DR" is a calendar entry.
Do not let the person who built it run it. They know the undocumented steps. Hand the runbook to somebody competent who has not done it before, and watch where they stop. Every pause is a gap in the documentation, and the documentation is what you will be relying on when the person who built it is unreachable.
Time everything, including the parts that are not technical. The clock starts when the incident is noticed, not when the restore begins. Deciding, assembling and finding credentials is routinely a third of the elapsed time and is absent from most measurements.
Write down the improvisations. Every time somebody does something not in the runbook, that is a finding. They are the most valuable output of the test and they vanish if nobody is recording.
The gap you should expect
The first time an organisation measures a real restore against its documented recovery time, the measurement is longer. Typically two to four times longer.
The causes repeat: the restore worked but the application would not start because of a dependency nobody mapped; the credentials needed were in the password manager that depends on the identity system that is down; restoring at the required speed exceeded what the network or the storage could sustain; a licence needed reactivating against a server that was not reachable; the only person who had done it before was unavailable and the runbook assumed knowledge.
None of these are exotic. All of them are cheap to fix once known, and all of them are expensive to discover during the real thing.
Reporting it
The line that does the most work is "what was explicitly not tested". A report that says the ERP was restored in six hours and that email, telephony and the file server were out of scope is a useful document. One that says "DR test successful" is not, and it is actively misleading to whoever reads it in two years.
Equally important: if the measured time exceeds the target, the finding is the gap. Do not revise the target to match the measurement and call it closed. Either fix the recovery or change the target deliberately, with the business agreeing to the new number, and write down which you did.
Testing cloud services, which people skip
There is a belief that services running in a major cloud do not need recovery testing. The provider's availability is very good and the shared responsibility model is widely misunderstood.
What the provider guarantees is their infrastructure. What they do not protect you from is your own people: the deleted mailbox, the SharePoint library somebody cleared, the mass deletion in your CRM, the ransomware that encrypted files and synced the encryption everywhere.
So the test for a cloud service is not "can the provider stay up". It is: how do we recover from a deletion we caused, how long does it take, and who can do it? Run that test. The answers vary enormously between platforms and are rarely what people assume.
If you do one thing
Take your most important system, hand the recovery runbook to somebody who has never used it, and time them from a standing start in an isolated environment.
You will learn more in that half day than from any amount of planning, and whatever you learn will reorder the rest of your continuity work. If you also want the plan that sits around this, we wrote about building one that survives contact.
