SOC 2: evidence that your backups restore

SOC 2's availability criteria ask you to back up data and to test the recovery plan procedures that support system recovery (Trust Services Criteria A1.2 and A1.3). Auditors want to see that a restore was tried, on a schedule, and what the result was. A backup job that "succeeded" isn't evidence that the data comes back.

What Verestore gives your auditor

• A restore test on a schedule. Daily, weekly or monthly, of your newest PostgreSQL backup, into a disposable database that's deleted when the run ends.
• What was checked. Every table restored, row counts against the previous run, checksums of the tables you choose, and your own SQL checks against a baseline.
• Evidence you can't edit. Each result is signed by the run and countersigned by Verestore. Anyone can check a report at /verify; changing one number breaks the signature.
• An evidence pack per period. A ZIP with the reports, the signed results and a summary for the audit window, plus the coverage sentence on every target ("restore-tested N times in the last 90 days with F failures").

How to use it in your audit

1. Connect the backup location with a read-only key (how access works) and choose a schedule.
2. Map the control "backups are tested for recoverability" to the Verestore target in your control matrix.
3. At audit time, download the evidence pack for the period and attach it. Point the auditor to /verify for any report.

Verestore produces evidence for this control; it doesn't certify your organisation. Your auditor decides what is sufficient.