When did you last restore, what did you restore, and did it work?
That is the question an ISO 27001 or SOC 2 auditor asks about backups, and most auditors work from one simple principle. If you don't have evidence, it didn't happen. The most common backup finding isn't missing backups. The jobs run, but the evidence does not.
What the auditor checks, and what the register shows
ISO 27001:2022 A.8.13 says backup copies "shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup." SOC 2 availability criteria have the same shape. The auditor tests operating effectiveness over the audit period, usually 3 to 12 months, and the most common exception they report is a plan that exists with no test results.
| The auditor asks for | The register shows |
|---|---|
| Backups actually run per policy | Coverage, meaning check-ins received against expected over the audit window, per system. |
| Failures are detected and acted on | The alert log. Silence, explicit failures and anomalies, each with timestamps and the evidence it fired on, plus recovery records. |
| Backups are regularly tested | Integrity verification records (method and result) and the restore drill log with date, scope, environment, who ran it, and measured results. |
| Restores meet your RTO | Each drill reporting a restore time gets a met or missed verdict against the objective you set. |
| Evidence covers the audit period | A 12-month evidence report per system, with full raw data as CSV. |
Why not a spreadsheet?
Auditors accept a self-maintained restore-test spreadsheet. It is today's norm. It is also backdatable by anyone with edit rights, the week before the audit. Lastcopy's register is different in one way that matters. Timestamps are assigned server-side on arrival, the record is held outside your systems, and there is no edit function. It is an independent system of record, not a document someone maintains.
A failed drill stays on the record with its remediation and its passing re-run. That is stronger evidence than a perfect page, because it proves the control operates.
If you use a compliance platform
Compliance platforms automate the checks their integrations can see. Backups configured, jobs reporting status. Restore testing is the control they cannot automate, because a human has to restore something real. Most mark the control failed until a fresh restore-test report is uploaded, and it goes stale every 12 months. That report is what Lastcopy produces. Run the drill on your infrastructure, report it with one curl line, and export the register when the control asks for it.
What Lastcopy never claims
Lastcopy is not an auditor and never says "certified", "third-party verified" or "passes your audit". Auditors decide, and evidence makes their decision easy. Restores and integrity checks run on your infrastructure, by your tools, which is what auditors expect anyway. The organisation tests its own backups. Lastcopy schedules the drills, nags weekly while one is overdue, and keeps the record. It never has access to your backup data. It stores the numbers your job sends and nothing else.
Getting the register started
- Add one curl line to each backup job. Coverage records start immediately.
- Report your integrity checks (restic check, borg check, pg_verifybackup) to /verify. One line in the same cron.
- Restore one system into a scratch environment and report the result to /drill. One drill row makes the report forwardable. The quarterly cadence keeps it current.
Watch 6 backups free See the sample report
A footnote for UK shops. Cyber Essentials treats backups as guidance rather than an assessed requirement since the 2026 update, though the NCSC still recommends backups that are "recent and can be restored". ISO 27001 and SOC 2 carry the evidence story.