Recovery Testing and Rehearsal

Recovery testing and rehearsal means practising the return of a service before an incident forces it, under conditions realistic enough to reveal where the plan breaks. A test that only restores a file to an empty environment proves that a tool works. A rehearsal that restores a service, with its dependencies, its providers, its decision makers, and its communication, proves something far more valuable: whether the firm, as a whole, can recover. The difference is between testing a component and rehearsing a capability, and only the second prepares a firm for a real outage.

The purpose of rehearsal is to find failure while failure is cheap. A plan that has never been exercised contains assumptions about dependencies, access, data, and decisions that may all be wrong, and a real incident will test those assumptions at the worst possible time. A rehearsal that finds those assumptions, records them, and leads to a changed plan has succeeded, even if the rehearsal itself was messy. A rehearsal that runs smoothly because it avoided every difficulty has taught the firm little, however tidy it looked.

Different kinds of testing answer different questions, and a sensible programme uses several. A discussion exercise, where the service owner and colleagues talk through a scenario, can surface gaps in decisions, roles, and communication without touching live systems. A technical restore test can show whether a backup is usable and how long restoration takes in practice. A fuller rehearsal, restoring a service in an isolated environment and walking its journeys through, can show whether the parts work together and whether the sequence holds.

Realism should be high enough to stress the plan, without creating risk to live customers. That balance is the art of rehearsal design. Restoring into an isolated environment, using recovery credentials, involving the actual decision makers, and including provider coordination all add realism that matters. Simulating incomplete information, such as a scope that is not yet fully known, adds realism of a different kind, because real incidents rarely arrive with complete facts. A rehearsal that hands participants perfect information from the start has removed one of the hardest parts of recovery.

Scenarios should reflect the disruptions the service actually faces, not generic disasters. For a service that depends heavily on a provider, a scenario where the provider itself is affected is worth rehearsing. For a service with complex data, a scenario where restored data proves corrupted is worth rehearsing. For a service where customer pressure is high, a scenario where the return must be limited is worth rehearsing. Scenarios chosen because they are plausible for that service teach more than scenarios chosen because they are dramatic in general.

A rehearsal turns into learning through a structured review held soon afterwards, while memories are fresh. The review should ask what worked, what failed, what was assumed and proved wrong, and what will change as a result. Each change should have an owner and a date, because a lesson without an owner is a note, not a change. The review should also record what the rehearsal did not test, so that untested areas are not mistaken for proven ones in later assurance.

Testing proves that a recovery approach worked under the conditions tested, on the day tested, for the scope tested. It does not prove that recovery will work under different conditions, at a different scale, or after the service has changed. Services change constantly: new providers, new data stores, new journeys, and new dependencies all alter the recovery picture. A test result therefore ages, and a firm should know how old its evidence is and what has changed since it was produced.

That ageing is why testing should be regular and tied to change. When a service changes materially, its recovery plan and its testing should be revisited, not left to a fixed calendar that may miss the change. Under DORA, which applies from 17 January 2025, the EU frame is labelled separately from the UK regime under FCA PS21/3 and PRA PS6/21, with their own dates. In either frame, the practical expectation is the same: recovery capability should be demonstrated, not merely documented, and demonstration should keep pace with the service it protects. A plan that was proven for a service that no longer exists in that form is a historical document, not a capability.