Auditors want proof that backups run and proof that you can restore from them. Keep the backup configuration, evidence of successful jobs or alerts on failure, and a dated restore test with the result and a named approver. A successful backup log without a restore test is only half the story.
Where the control fits
Backups are most often tied to the availability criteria, so check whether availability is in your scope. If it is not, backups may still be tested as part of resilience or data protection controls. Ask your auditor how they map it.
Evidence that backups run
Keep three things.
- The configuration: what is backed up, how often, where it is stored and how long it is kept.
- Job results for the period, or an export showing a success rate over time.
- Alerts for failures and the tickets that followed.
An alert rule screenshot plus one example of a failure that was handled shows the control operates.
Evidence that restores work
Pick a system, restore it into a test environment, and verify the data. Record the date, system, backup used, steps, time taken, who checked it and the outcome. If the restore failed, record the fix and a repeat test.
How often to test depends on your risk. Many teams restore at least once a year and after major changes. Choose a frequency, write it in the policy and then follow it.
Show the recovery targets
If your plan states recovery time and recovery point targets, compare your test result with them. A restore that took six hours against a four hour target is a useful finding, and it shows the test was honest.
Protect the backups
Auditors may ask about access to backups and encryption. Keep evidence that backup storage has restricted access and that data is encrypted where you say it is.
A restore test record template
Keep a simple form: system tested, date, backup timestamp used, who ran it, steps followed, time to restore, data checks performed, result, issues found and follow up actions. One page is enough. Attach screenshots or command output if helpful, with timestamps visible.
Think beyond databases
Backups also apply to configuration, infrastructure definitions, source code and secrets stores. Many teams back up databases and forget the rest. Decide what you need to rebuild the service, and list how each item is protected. Infrastructure as code in version control often serves as the backup for configuration, and a rebuild test can serve as the restore test.
Test the process on a day other than the one you are most comfortable with, and have someone other than the usual person try it. That finds documentation gaps.
Retention and deletion
Check that your stated retention matches reality. If the policy says thirty days and the console shows seven, one of them is wrong. Auditors compare configuration with the policy, so keep a current export of the retention settings next to the policy text.
Quick check
Do managed database snapshots count?
They can, if you document the setting, retention and a restore test. The provider running the job does not remove your duty to test.
Last reviewed: 19 October 2026.
