Direct answer
A restore test should prove that an authorized operator can select a known recovery point, restore it into a controlled target, validate integrity and application behavior, and document elapsed time and exceptions. Rotate workloads and recovery paths so a passing sample does not conceal systemic gaps.
How to frame the decision
Operational confidence comes from repeatable evidence: logs, timestamps, restored-object counts and application checks. A successful backup job is an input to testing, not proof of recoverability.
For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.
Decision table
| Factor | Practical guidance | Evidence to retain |
|---|---|---|
| Test scope | Include file, application, identity and infrastructure dependencies appropriate to the service. | A scope record tied to the service recovery requirement. |
| Pass criteria | Define expected object counts, checksums, application transactions and elapsed-time limits before the test. | Pre-approved pass/fail assertions and actual results. |
| Evidence | Capture logs, timestamps, screenshots, commands, approvers and exception tickets. | An evidence package another operator can reproduce. |
Validation procedure
Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.
- Collect machine-readable evidence rather than relying on a green dashboard.
- Translate the requirement into a pass/fail test for a restore test checklist that produces audit-ready evidence.
- Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
- Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.
A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.
Common failure modes
- A single file restore is used to certify an entire service.
- Pass criteria are invented after results are known.
- Failures are recorded but never assigned or retested.
Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.
Evidence checklist
- Assign an owner and closure date to every failed assertion.
- A tested requirement exists for: Test scope.
- A tested requirement exists for: Pass criteria.
- A tested requirement exists for: Evidence.
- Evidence includes a date, environment, operator and reproducible procedure.
- The exception path identifies who can accept residual risk.
Questions this guide answers
- What should a backup restore test include?
- How do you document restore testing for audits?
- How often should applications be restored?