A disaster recovery plan is proven by a dated restore test with a measured result, not by the plan itself. Show the recovery targets you committed to, the last test, what you measured against them, and what you fixed afterward. A customer can trust a number you measured more than a policy you wrote.
Plan versus proof
A plan describes intent. A test describes fact. NIST SP 800-34 Rev. 1, the contingency planning guide for federal information systems, describes the purpose, process and format of contingency planning, and is a reasonable reference for what a plan should cover. It is a federal guide written in 2010, so use it as a structure, not as something you can claim to be certified against.
When a reviewer asks "do you test your recovery plan?", they want to read a sentence like this: "We restored production data into a separate environment on a stated date, it took a stated time, and the data matched a stated check."
The four items to show
| Item | Example of what to keep | Why it matters |
|---|---|---|
| Recovery targets | Written time and data loss limits per service | Shows you decided, not hoped |
| Backup record | Job logs showing success and retention | Proves backups exist |
| Restore test | Date, who ran it, duration, result | Proves backups are usable |
| Follow-up | Tickets for each gap found | Proves learning |
How to run a small restore test
- Pick one important data store and one date.
- Restore the most recent backup into an isolated environment, never over production.
- Record the start and end times.
- Check the restored data with a defined test, such as row counts and a sample of known records.
- Compare the elapsed time and data age against your written targets.
- Open a ticket for every miss and set an owner and due date.
- Save the log, the notes and the tickets in your evidence folder with the date in the file name.
What not to claim
Do not state recovery times you have never measured. If you have only tested a database restore, say so, and do not describe the result as a full site recovery. If a service depends on a cloud provider's region, say which dependencies you have and what you do about them. Customers forgive limits that are stated. They do not forgive surprises found during an outage.
Avoid terms such as "guaranteed" and "zero downtime" unless a contract you are willing to show says so. A plan that has never been run end to end should be described as such, with a date for the first full exercise.
How often
Test at least yearly, and after major architecture changes. For the most critical service, quarterly restore checks are easy to automate and make the evidence fresher. Record the owner by role, so the record survives staff changes.
Where Safeguard fits
Safeguard's compliance and evidence automation can store dated artefacts like restore logs against the control they support, and the free scan at https://gold.safeguard.sh/scan helps you check the software side of what you are recovering.
Quick check
Is a backup success log enough evidence?
No. It shows a job ran, not that the data can be restored. Pair it with a dated restore test.
What if our first restore test fails?
Keep the record anyway, fix the gap, and retest. A failed test with a fix is better evidence than no test.
Sources
Last reviewed: 19 October 2026.
