Restore-test evidence for SOC 2 and security questionnaires
An auditor and a customer's security questionnaire ask the same thing about backups: do they restore, how often do you check, and when did you last check. A backup job that reports success answers none of it. This guide says what SOC 2 asks, what a record of a restore test has to hold, and how to keep one for every week of the audit period without anyone running the test by hand.
Nothing here makes an organization compliant. Your auditor decides what evidence satisfies a control, and tests you against your own backup policy.
1. What SOC 2 asks
Backups and restore testing sit in the Availability category of the AICPA's 2017 Trust Services Criteria (TSP section 100), in two criteria:
| Criterion | What it covers | Points of focus about backups |
|---|---|---|
| A1.2 | The backup processes and recovery infrastructure, put in place and monitored to meet your objectives. | Backing up data, watching for failed backups and correcting them, and storing backups far enough from the data that one event is unlikely to reach both. |
| A1.3 | “The entity tests recovery plan procedures supporting system recovery to meet its objectives.” | Testing the integrity and completeness of backup data on a periodic basis, beside testing the business continuity plan. |
Both apply when your SOC 2 report includes Availability. A report on Security alone does not include the A1 criteria, though a questionnaire may still ask about backups. The criteria are objectives, not procedures: they do not say how often to test or how. Your backup policy does, so write down the cadence you will keep, then keep it.
2. What a restore-test record has to hold
An auditor samples the audit period, often six or twelve months, so a test run the week before fieldwork covers one week. What holds up is a record the test writes each time it runs, with dates. For each test it should say:
- Which backup. The database or directory, and when that backup was taken.
- Where it was restored. A separate, empty database or directory, never the production one.
- What was compared. Tables and row counts, file digests, or queries with expected answers. “The restore command exited 0” is weaker than “all 41 tables and 2,180,334 rows matched the backup”.
- The result and the date. Passed or failed, and when. A failed test that was noticed and fixed is evidence the process works.
- Why it can be trusted. Who or what wrote the record, and whether it could be edited afterwards.
For A1.2, keep the backup history beside it: each backup's date, the failures, and the alert that went out for each failure.
3. Producing the records with SafeGrd
SafeGrd's Fire Drills are restore tests that run on a schedule. Each one restores a backup somewhere disposable (in memory, into a sandbox database, or into a throwaway PostgreSQL on your host), compares the tables, rows and file digests with what the backup recorded, and writes the result. Your own checks add queries with expected answers, such as “no order without a customer”, and their results go into the same record. Every plan runs drills; the pricing page says how often and how deep on each.
| What you need | Where it is |
|---|---|
| Every restore test, with what it compared and the result | The console's Fire Drills tab, or safegrd verify history --json |
| Proof the records were not edited | Each record is signed with Ed25519 and carries the hash of the one before it. safegrd verify history --file <records> --key <public key> checks the chain offline, on the auditor's machine (how) |
| One test to show a customer | A public certificate: a link to one passed drill that anyone with it can open (what it shows) |
| Backups and their failures | The Snapshots tab, and the alerts sent for a failed backup or drill |
| Backups kept apart and unchangeable | Each snapshot's Object Lock date, in the Snapshots tab or safegrd list |
| A quarter's records in one file | The Evidence Pack, on the Scale plan: drill records, retention and who holds each key, with the control each answers (sample) |
Backup controls and the records that answer them lists the same records against ISO/IEC 27001, HIPAA, CIS, DORA, NIS2 and GDPR.
4. Answering a security questionnaire
Questionnaires word it differently, but the backup questions come down to these. Answer with what your setup does, and say where the answer can be checked:
| Question | An answer, and where to read it |
|---|---|
| Are backups tested? | “Each database backup is restore-tested by an automated drill every week [or day]. Each test compares tables and rows with the backup and is recorded and signed.” Your plan’s cadence is on the pricing page. |
| When was the last successful restore test? | The date of the last passed drill, with a public certificate link if they want to see it. |
| Are backups encrypted? | “Encrypted on our host with age (X25519) before upload.” Say who holds the key: your choice of key custody is shown on each surface. |
| Can backups be deleted or changed? | Only if true for your bucket: “Stored under S3 Object Lock in compliance mode, so they cannot be deleted or changed for N days.” See immutable backups. |
| Where are backups stored? | The provider and region of the bucket, which is separate from the database's. |
| How long can a restore take, and how old can it be? | Your recovery time and recovery point, from the drills' restore times and the backup schedule (details, and RPO and RTO). |
What the records do not cover
- The rest of A1.3. Testing the business continuity plan, with its scenarios and the people involved, is yours. A drill tests that a backup restores.
- Your application. A drill restores and checks the data. Whether your service runs against the restored database is a test you run, or a check you add.
- Systems SafeGrd does not back up. Records exist for the databases, directories and mailboxes you added, nothing else.
- The policy. The records show the tests happened. The policy that says how often they must is yours to write.
Install SafeGrd on a host, or add a database SafeGrd backs up for you in the console, and the first drill runs after the first backup.