ISO 27001: the green tick doesn't pass the audit

Control A.8.13 (Information backup) of ISO/IEC 27001:2022 fits in one sentence: maintain backup copies of information, software and systems, and test them regularly in line with a backup policy aligned with business requirements.

Everyone does the first half. It's the second half that fails audits.

What the auditor actually asks for

Audit guidance for control A.8.13 is explicit about the evidence expected:

• a documented and approved backup policy: frequencies, retention, responsibilities, scope cross-checked against the asset register;
• RPOs and RTOs defined per asset on the basis of a business impact analysis — a single objective for the whole estate is a classic mistake;
• execution logs showing that jobs run and that failures trigger alerts (a silently failing job = a finding);
• and above all: timestamped restore test reports, usually less than 6 to 12 months old, comparing actual restore time against the target RTO.

On that last point the guidance is unambiguous: a "Job Successful" screenshot from the backup console is insufficient. Restoring a single file is not a recovery test. And if the measured restore time significantly exceeds the RTO defined in the continuity plan, that's a non-conformity — even if the restore worked.

Why this control is so often a finding

Because a real restore test is expensive in human time: provision an isolated environment, fetch the archive, restore, validate data integrity, measure duration, document, clean up. Done by hand, that's half an engineer-day per critical system. The predictable result: the test happens once before the audit, in a rush, and the evidence produced is fragile.

The other obstacle is confidentiality: testing a restore of a production database means handling real data. Shipping it off to a third-party cloud tool creates a GDPR problem where you were trying to solve an ISO one.

The RestoreProof approach: continuous evidence, data stays with you

RestoreProof turns the restore test into a scheduled task that natively produces audit evidence:

1. Real, automated restore: the runner, deployed on your infrastructure, downloads the backup (S3 or compatible, HTTP, local), unpacks it, starts an ephemeral containerised database (PostgreSQL, MySQL) and restores the dump into it.
2. Functional validation: probes verify archive integrity, check for canary files, run SQL queries against expected thresholds ("the users table must contain at least N rows"), and test HTTP endpoints.
3. Signed report: every run produces a timestamped JSON report — artefact tested, SHA-256 hash, per-probe results, measured durations — signed with Ed25519 by a private key that never leaves your runner. The evidence is verifiable and tamper-proof.
4. Audit history: PASS/WARN/FAIL verdicts retained according to your retention plan, browsable and exportable when the audit comes.

And the point that changes everything for a CISO: backup data and credentials never transit through the SaaS. Secrets are resolved locally (environment variables, files, Vault, SOPS). The control plane only ever sees metadata and signed verdicts.

FAQ

How often does ISO 27001 require restore testing? The standard requires "regular" testing without naming a frequency — it's up to the organisation to define and justify one. In practice, auditors expect recent evidence (often less than 6 to 12 months old) and a frequency consistent with asset criticality. A daily or weekly automated test comfortably exceeds that expectation.

What is the difference between a backup log and restore evidence? The backup log proves a copy was written. Restore evidence demonstrates that this copy allows a usable system to be rebuilt, within a measured timeframe. A.8.13 requires both.

Does a cryptographically signed report carry weight in an audit? An Ed25519 signature guarantees that the report hasn't been modified since it was generated and that it genuinely originates from the runner holding the key. That's a stronger integrity guarantee than a PDF or a screenshot, and it strengthens the reliability of the audit trail.

Sources to link: ISO/IEC 27001:2022, Annex A 8.13; A.8.13 implementation guides and audit checklists.