A green job is evidence of a job, not of a recovery
Backup software reports on its own activity: the snapshot completed, the target accepted the data, the retention policy ran. None of that describes whether a service can be brought back into use, which is the only question the business is actually asking.
A backup can restore into something unusable, or take longer than the recovery plan allows. A controlled test is a way to find those gaps.
Pick a service that matters and arrange the test properly
Choose something with a real owner and real dependencies rather than the easiest candidate. Agree a window, an isolated environment, and what you are allowed to touch, and tell the owner you want them present when it comes back up.
Isolation matters more than realism here. A restored domain controller or line-of-business database talking to production is a much bigger incident than the one you were rehearsing for.
Measure the thing the business feels
Start the clock when you begin and stop it when the service owner can do their work, not when the restore job reports success. Record every step that needed a human decision, every credential you had to hunt for, and anything that failed and had to be worked around.
Then put that number next to the recovery expectation the business has written down, if it has one. Where they disagree, you have found either an investment case or an assumption that needs correcting.
Close the loop while the detail is fresh
Write the findings up the same day, with the failures kept in. A sanitised test report is worth very little; the awkward detail is the part that improves the runbook.
NCSC's guidance recommends testing backups regularly rather than once. Put the next test in the diary with a named owner before the current one is forgotten.
A recovery result needs more than one number
Consider a fictional booking service. Its database restore finishes in eighteen minutes, but the application cannot start until a certificate and a configuration file have been recovered separately. The owner completes a test booking after fifty-five minutes. Record both timings and explain what happened between them.
Also check the age of the recovered information. A fast restore of yesterday’s database may miss today’s bookings. Recovery time and the amount of recent data missing are different questions. Ask the owner to judge both against the agreed business requirements; do not infer acceptable data loss from a backup schedule.
Keep a test record that supports the next attempt
Record the service, test date, backup identifier, recovery point, isolation checks, start and finish times, and the business task the owner completed. Add dependencies recovered separately, errors observed and follow-up actions. Keep sensitive evidence in the approved location and link to it from the service record.
For each failed check, name an action and an owner. If recovery cannot meet the business requirement, escalate the gap rather than quietly changing the target. Finish by removing the test environment and test access through the agreed disposal process.
Sources
Practical suggestions in this article are editorial recommendations. The source supports the guidance attributed to it.
- NCSC: Data security ↗
Checked 8 September 2026
Something needs correcting?
Get in touch to explain which claim needs attention and share the supporting source.