Backup restore testing evidence for ISO 27001, SOC 2 and NIS2

What the frameworks ask for, what auditors look at, and a record template you can copy.

Every major security framework expects you to test your backups, not just take them. The wording is short and leaves a lot open, so teams often find out what "tested" means during the audit itself. This guide covers what the requirements say, what evidence usually satisfies them, and the mistakes that turn a restore test into an audit finding.

This is practical guidance, not legal or audit advice. Your auditor and your own policies have the final word.

What the frameworks say

What auditors usually ask for

1. A policy that says what is backed up, how often, how long it's kept, and how often restores are tested (for example: "production databases: automated restore test daily; full disaster recovery exercise yearly").
2. Evidence that tests happened as the policy says, spread across the whole audit period. For SOC 2 Type II, the auditor typically samples dates and asks for the matching records.
3. Evidence that the test proved something: what was restored, from which backup, whether it succeeded, how long it took and how you checked the result.
4. What happened when a test failed: the ticket, the fix and the date of the next successful test. A failed test that was handled well is good evidence; a failure nobody noticed is a finding.
5. Recovery objectives backed by measurements: if your continuity plan promises a 4-hour recovery time, your measured restore times should support it.

A restore test record template

Whatever tool or script you use, each test should leave a record with these fields. A spreadsheet works; a generated log or report is better because it can't be filled in after the fact.

Common mistakes that become findings

• "Restore succeeded" as the only check. A restore can finish without errors and still contain last week's data or an empty table. Record how you verified the content.
• One test the week before the audit. Type II periods cover months. Tests should be spread across the period as your policy states.
• Testing a different backup than production uses. Test the actual backups your recovery plan relies on, from the actual storage location.
• No record of failures. If tests can fail silently, nobody can show that failures were handled.
• Policy and practice disagree. If the policy says "monthly" and you tested twice a year, that's a finding even if both tests passed. Write a policy you can keep.
• Restored data left lying around. Test restores contain production data. Restore into an isolated environment and delete it afterwards, and say so in your records.

How often should you test?

The frameworks don't prescribe a frequency; your policy does. A common pattern:

• Automated restore test of each production database: daily or weekly. Cheap once automated, and it catches silent backup failures within a day.
• Full disaster recovery exercise (restoring a whole environment, with people following the runbook): once or twice a year.

Automation makes the frequent tests nearly free and gives you a continuous evidence trail, which is exactly what a Type II audit samples from. If you want to build it yourself, our guide How to test PostgreSQL backup restores automatically includes a working script.