ISO 27001 A.8.13: proving backups and restore tests to your auditor

Three weeks before the certification audit, the auditor’s sample request arrives: “Please show the backup of the production database from 12 March and the record of the last restore test.” The backup exists; the database instance’s schedule takes one every day. The last restore was during an incident 14 months ago, and nobody wrote it down. This is where things often stall: not on backups, but on evidence.

ISO/IEC 27001:2022 A.8.13 “Information backup” is the Annex A control under which an organisation creates, keeps and regularly tests backups of its information, software and systems according to an agreed backup policy. It is one of the 93 controls of the 2022 edition; in the 2013 edition its counterpart was A.12.3.1. The word that matters most is “tests”.

What does ISO 27001 require under A.8.13?

The control itself is one sentence. The guidance in ISO/IEC 27002:2022 comes down to these points, summarised in our own words:

• complete records of what is backed up, and documented restore procedures,
• scope and frequency driven by business needs – how much data loss is bearable,
• copies in a separate location, far enough away that one event cannot hit original and copy,
• protection of the copies: access, physical protection, encryption according to risk,
• regular tests of whether a restore succeeds within the planned time,
• retention periods and monitoring, so a failed run gets noticed,
• cloud services you do not run yourself included.

The auditor does not check whether you use a particular tool, but whether policy and reality match – and whether you can prove it.

What belongs in a backup policy?

One page is enough if it is concrete. Per system or type of data:

• Scope: which databases, volumes, buckets and configurations are backed up – and which deliberately are not, with the reason.
• Frequency and targets: how often backups run, how much data loss is bearable (RPO) and how quickly a restore must be done (RTO).
• Retention: how long copies are kept and when they are deleted.
• Location and protection: where the copies live, separated from what, who has access, whether they are locked or encrypted.
• Tests: how often, by which method, who checks, and where the record is filed.
• Ownership and failures: who receives alerts and what happens after a failed run.

Which evidence does the auditor want to see?

The auditor typically draws a sample and asks to see the policy at work. Have ready:

1. the approved backup policy with its version and the date of its last review,
2. an overview of which systems are backed up where, with region and project,
3. the history of backup runs in the audited period, with results,
4. alerts about failed runs and what happened next,
5. the restore test records with results and deviations,
6. proof of separation: the lock configuration, the backup key’s permissions, a separate project,
7. the audit log of who downloaded or restored backups.

For NIS2 the list looks very similar; which evidence can serve both is covered in NIS2 evidence from day-to-day operations.

What does a restore test record look like?

For the audit, a test that was not written down never happened. These fields are enough:

• date, the person who ran it, system and scope – one database, one bucket, one volume,
• the restore point used: identifier and time of the backup,
• the target: a new database or a new bucket, never running production,
• start and end, measured against the RTO, and the age of the data, measured against the RPO,
• the check: row counts, checksums, a sign-in to the application against the copy,
• the result, deviations, and actions with an owner,
• the clean-up: the restored copy deleted, with the date.

A rhythm you keep beats an ambitious one you miss – say, an automatic monthly sample and a quarterly full restore of the most important database.

Databases, volumes, object storage: what does this mean in the cloud?

• Databases: A snapshot of the whole managed database instance is quick, but covers everything at once; a logical backup of a single database can be downloaded and checked on its own. Tests restore into a new database alongside.
• Volumes: A block storage snapshot of a running service is crash-consistent – whatever the application still held in memory is missing. And it sits in the same zone and project as the volume: a copy, but not a separate one.
• Object storage: Versioning lives in the same bucket and is therefore no separate backup. Only a locked copy in another project is separate.
• Configuration: Helm values, environment variables and cluster settings belong to “software and systems” – without them, a restore takes days instead of hours.

The page Backups & recovery covers which backup suits which data.

How Clusterward produces the evidence

Clusterward certifies nothing and does not make you compliant; it provides evidence from operations. The Compliance page in the cockpit shows live checks with their Annex A control, three of them under A.8.13: bucket backups (no good backup for 36 hours?), restore tests (failed, or not yet tested this month?) and, for information, database backups. Nothing is ticked by hand; each check reads what is stored right now.

For the auditor there are CSV reports for a chosen period: backup evidence (every run, restore and restore test with time, result and who started it), an inventory of where your data lives, the audit log and the security settings in force. The compliance pack bundles the reports into one ZIP with SHA-256 checksums, and every download is itself in the audit log. Clusterward tests bucket backups automatically every month with a sample (S3 backups). You restore databases from a backup into a new database, volumes from a snapshot after a safety snapshot; those tests you record yourself, and the restores land in the audit log. BitKollegen GmbH, the company behind Clusterward, is itself ISO 27001 certified.

Conclusion

A.8.13 does not check whether you have backups, but whether you can show that they run, live apart and can be brought back. A concrete policy, a run history, alerts with a response and test records with results cover the typical sample. Testing just before the audit means testing under time pressure – often for the first time.

Is your next ISO 27001 audit coming up? Tell us what you back up today and how you prove it. We’ll show you which evidence Clusterward produces from operations. Ask a question →

Sources and further reading

• ISO: ISO/IEC 27001:2022
• ISMS.online: Annex A 8.13 explained
• High Table: Annex A 8.13 and the audit
• Wikipedia: ISO/IEC 27001
• Scaleway docs: Database Instance backups