A recovery test should produce four things: a measured recovery time for each workload tested, a record of what was in scope, a record of what failed and what was done about it, and evidence that can be handed to someone outside the team without being assembled first. A test that produces none of these has confirmed something, but not anything that can be shown.
The distinction matters because recovery capability is increasingly something organisations are asked to demonstrate rather than assert. An insurer at renewal, an auditor working through a framework, an executive after a news story. In each case the question is not whether recovery was tested. It is what the test showed.
A measured recovery time, per workload
The most useful output is also the simplest: how long it actually took. Not an estimate, not a recovery time objective set during a planning exercise, but a figure measured during the test itself.
This matters because most RTOs have never been validated. They were defined once, against an environment that has since changed, and nothing has tested them since. A measured figure either confirms the objective is realistic or shows the gap, and both are worth knowing before an incident makes the comparison for you.
Per workload matters as much as the number. Critical systems rarely recover at the same rate, and an average across the environment hides the ones that would hold everything else up.
A record of what was in scope
A test result means little without knowing what it covered. Restoring a single file and restoring an interdependent set of production systems are different exercises, and a report that says only “recovery tested successfully” does not distinguish between them.
Scope should record which systems were included, whether dependencies between them were part of the test, and what conditions the test ran under. A test conducted during business hours with full team availability and complete access to the production environment is a valid exercise, but it is not the same as one run under constrained conditions, and the record should say which it was.
A record of what failed, and what happened next
A test where nothing goes wrong is usually a test that was not demanding enough. Real tests surface problems: a sequence that was wrong, a dependency nobody had documented, a step that took far longer than expected.
Those findings are the most valuable output, provided they are recorded and acted on. A remediation trail, what was found, what was changed, and whether a retest confirmed it, is what separates testing as a practice from testing as an event. It is also what an auditor is most interested in, because it shows the process improves rather than simply repeats.
Evidence someone outside the team can read
The final output is the one most often missing. Documentation that exists only as knowledge within the infrastructure team cannot be produced on request, and the requests tend to arrive with little notice.
Evidence that works outside the team is written in terms of what was tested, what it showed, and what it means for the organisation, rather than in terms of the platform used. It should be current, retrievable, and complete enough that someone can understand it without a conversation.
What it means if a test produces nothing
Many organisations test recovery and keep no record of it. That is not evidence of poor practice, it usually reflects testing treated as an operational task rather than a governance one. But it does mean the organisation cannot demonstrate a capability it may genuinely have.
The practical question is not whether recovery has been tested. It is what could be produced tomorrow if someone asked for proof.
FAQs
What should a recovery test document contain?
At minimum: the scope of systems tested, the conditions under which the test ran, measured time to recovery for each workload, any failures encountered, and the remediation actions taken afterwards.
Is an annual restore test sufficient?
It depends what it covered. Restoring a single file or machine annually confirms the backup technology works. It does not establish recovery time across interdependent systems or produce evidence that would satisfy an insurer or auditor.
Why do insurers ask for evidence of recovery testing?
Because recovery capability affects their exposure. Confirmation that testing occurs is not the same as a record showing what was tested, how long it took, and what was done about any failures.
What is the difference between an RTO and a measured recovery time?
An RTO is an objective, usually set during planning. A measured recovery time is what the test actually recorded. Organisations frequently have the first without ever having validated it against the second.
