Backup and restore testing

Write down what each system must recover and how fast, check every system in scope is actually backed up, then restore a real backup to an isolated place and time it. Prove the data is complete with counts or checksums and that the application works, record the result with evidence, fix the gaps, and repeat on a schedule.

When you need this

ISO 27001:2022 Annex A 8.13 expects backup copies of information, software and systems to be kept and regularly tested in line with your backup policy. SOC 2 A1.2 covers backup and recovery infrastructure, and SOC 2 A1.3 expects recovery procedures to be tested. UK GDPR Article 32(1)(c) asks for the ability to restore access to personal data in a timely manner after an incident, and Article 32(1)(d) for regular testing of security measures, which restore tests serve.

Cyber Essentials does not require backups, though the NCSC recommends them. The triggers are the scheduled test date, a new system or backup tool, and any incident that needed a restore. An engineer or IT lead runs the test; the system owner signs off the result.

This is guidance to help you understand the requirement, not legal advice.

Before you start

You need your asset or system inventory, the backup configuration for each system, a place to restore to that cannot touch production (a separate account, environment or machine), and someone who can tell whether the restored data is right. Agree recovery objectives with the system owner before the test, not after.

A file or single-database restore takes two to four hours including evidence. A full-system restore can take a day, more on the first attempt.

Steps

Inventory what is backed up and what is not, system by system, including SaaS data and laptops. Done when every system in the inventory has a backup status.
Define a recovery point objective (how much data you can lose) and a recovery time objective (how long recovery may take) for each critical system. Done when each has both, agreed with its owner.
Check the backup configuration and coverage against the inventory: schedules, retention, encryption, location and alerting on failure. Done when each gap is listed.
Choose the test type for this cycle: a file restore, a database restore, a full-system restore or a restore into another region. Done when the plan names the backup to use and the target.
Restore the backup to an isolated target. Done when the restore completes or fails, with start and end times recorded.
Measure the result: time against the recovery time objective, data age against the recovery point objective, completeness with row counts or checksums, and whether the application starts and works. Done when each measure has a value.
Record pass or fail with the evidence attached: the restore log, timestamped screenshots and the comparison output. Done when the record is complete.
Raise an action for each gap, with an owner and a date. Done when every gap has an action.
Review the backup scope once a year and after any significant change. Done when the next test and scope review dates are set.

What counts as evidence

A successful backup job proves that data was copied. It does not prove the copy can be read, that it is complete, or that you can rebuild the service from it in time. Auditors know this, and a dashboard of green ticks is the most common thing they reject.

Evidence that holds water

Good evidence shows four things: which backup was used and when it was taken, where it was restored, how long it took, and how you know the result was right. Typical items are the restore command output or console log, a timestamped screenshot of the restored system working, a table comparing row counts or file checksums with the source, and the tester’s sign-off. Keep the evidence with the test record, not in a chat thread.

Common failures

Restoring into production by mistake, testing only the newest backup when the policy promises 35 days, and testing a single file once a year while claiming a four-hour recovery for the whole service. Each test should match a claim your policy or contract makes.

Worked examples

ISO 27001, a production database restored to staging

A 15-person SaaS firm sets a recovery time objective of 4 hours and a recovery point objective of 24 hours for its production Postgres database. On 12 February 2026 an engineer restores the 02:00 snapshot into a separate staging account. The restore and application start take 52 minutes. Row counts on the 12 core tables match the source as at 02:00, and a tester signs in and opens three customer workspaces.

The coverage check finds a gap: the storage bucket holding customer file uploads has no versioning and no copy elsewhere, so deleted or overwritten files cannot be recovered. The action, owned by the lead engineer and due 28 February 2026, enables versioning and replication to a second region. The Backup and Restore Test Record is marked pass with one action, evidence attached, and the next test is set for February 2027 (Annex A 8.13).

SOC 2, an annual full-restore test as A1.3 evidence

A 60-person platform company states two controls: daily backups with alerting on failure (A1.2) and an annual full restore of the service in a second region (A1.3). For a 12-month Type II period the auditor samples 25 days of backup job history and inspects the alert handling for any failures. The annual test is a population of one, so the auditor examines it in full: the plan, the restore log, the time against the objective and the follow-up of any gaps.

UK GDPR Article 32(1)(c) follows the ISO 27001 example: the restore test is how you show you can restore access to personal data in a timely manner.

Checklist

How Sted helps

Under its Backup Policy (POL-BCK) Sted’s knowledge base holds a Backup and Restore Test Record (REC-BRR) and a Backup Scope Review Record (REC-BSR), each with a suggested annual frequency, and a Backup Configuration and Coverage Record (REC-BCR), tagged to ISO 27001 control 8.13 and, for the test and coverage records, to SOC 2 A1.3 and A1.2.
Records are part of the Full Management System plan.
33 periodic record types come with a suggested frequency, but nothing is scheduled until you pick a first due date.
Records take file attachments, scanned for malware before download.
Records follow templates with sections and, where useful, structured fields you can report on.
Records are part of the Full Management System plan.
Sted does not connect to your cloud, code or HR systems to collect evidence automatically; you record it.

Sted does not back up or restore your systems and does not run restore tests. You run the test; Sted keeps the record and its evidence.

ISO 27001 technological controls: control 8.13 in context.
SOC 2 availability: A1.2 and A1.3 and what auditors sample.
SOC 2 evidence: how auditors sample recurring controls.
Cyber Essentials five technical controls: why backups are recommended there, not required.
Testing your business continuity plan: when a restore test becomes a recovery exercise.
Repeating records: scheduling the test in Sted.

Frequently asked questions

How often should I test restoring from backup?

At least once a year for a full restore of each critical system, and more often, commonly quarterly, for a sample of files or a database. Test again after any major change to the system or the backup tool. Your backup policy should set the frequency, and the auditor checks you met it.

What evidence of a restore test does an ISO 27001 auditor want?

A dated record of what was restored, from which backup, to where, how long it took against the recovery time objective, and how you checked the data was complete. Attach the restore log or console output and the comparison results. A backup job report alone is not a restore test.

Do SaaS tools need backing up?

Often, yes. Most SaaS providers protect against their own failures, not against your deletions, a compromised account or a sync that overwrites good data. Check each provider’s terms for retention and restore options, and decide per tool whether you need your own export or a third-party backup.