Backups exist, restore never tested: the ISO 27001 evidence gap

The backup job runs nightly. The confirmation email arrives each morning. The IT team knows the files are there. And then an auditor asks: "Can you show me a record of the last time you tested a restore?" - and the room goes quiet.

This is one of the most common evidence gaps in ISO 27001 Stage 2 audits. Backups and restore testing are separate controls, and the existence of one does not prove the other. Understanding that distinction - and building the right records - is what separates a passing programme from a finding.

Why "we have backups" fails as evidence

ISO 27001 Annex A control 8.13 covers information backup. The standard requires that backups are taken, stored appropriately, and - critically - tested for restore. Most organisations can produce logs showing backups completed. Far fewer can produce records showing that a restore was actually performed and verified.

An auditor looking at this control is asking a practical question: "If you lost your production database at 3am, do you have evidence that your restore process works, that it meets the time targets you have documented, and that someone has verified the recovered data is intact?" Backup logs answer none of that.

Common failure patterns include:

• Backup completion logs exist but are never reviewed by a named person.
• Restores have been performed informally as part of incidents but were never documented as restore tests.
• The restore procedure exists as a runbook but has not been executed against a current backup.
• Partial restores of individual files have been done, but no full-system or full-database restore has been tested.
• Cloud snapshot capabilities are assumed to work but have never been exercised in a recovery scenario.

Each of these represents a claim the organisation cannot substantiate under audit.

What RTO and RPO evidence actually requires

Your Information Security Management System will typically reference Recovery Time Objectives and Recovery Point Objectives, either in a Business Continuity Plan, a Disaster Recovery Plan, or both. Simply writing those targets down is not sufficient. An auditor will look for evidence that the targets are achievable - which means restore tests need to be connected to those numbers.

A tested restore record that supports RTO/RPO evidence should include:

• Date and time the test was initiated, and the time at which the recovered system or data was confirmed usable.
• Scope - exactly what was restored: which system, which dataset, from which backup.
• Recovery Point - the timestamp of the backup used, so the gap between that point and the test can be calculated and compared to the documented RPO.
• Recovery Time - elapsed time from initiating the restore to verified completion, compared explicitly to the documented RTO.
• Verification method - how integrity was confirmed. Spot-checking records, running application smoke tests, or comparing checksums are all valid; "it looked fine" is not.
• Named person who performed the test and who signed off on the result.
• Outcome - pass or fail relative to the targets, and if fail, what follow-up action was raised.

Without the comparison to documented targets, restore logs are still just backup logs with extra steps.

Building a restore test programme

A defensible restore testing programme does not require elaborate infrastructure. It requires regularity, documentation, and a connection to the targets in your ISMS.

A practical structure for most organisations looks like this:

• Full restore test of the most critical system or database at least quarterly. Some programmes run monthly for high-criticality assets.
• Partial restores of individual services or file groups monthly or as part of change activity where relevant.
• An annual full-scenario drill that covers the narrative in the DR plan, not just the technical steps.
• An owner responsible for scheduling tests, recording results, and escalating failures.

The frequency should match the criticality of the data and the RPO. If your RPO for a core database is four hours, running one restore test per year is not proportionate evidence that your programme is effective.

What a restore test record looks like in practice

An illustrative example: a SaaS business running on AWS RDS has a documented RPO of one hour and an RTO of four hours for its application database. Their restore test record for a quarterly test would include:

• Test date and start time.
• Source backup timestamp (confirming the backup is no more than one hour old at time of test, validating RPO).
• Name of the engineer who ran the restore.
• Steps taken: snapshot selected, restore initiated to a test environment, application connection verified, five representative records spot-checked against production values.
• Total elapsed time from initiation to verification: logged as, for example, two hours and seventeen minutes, clearly within the four-hour RTO.
• A tick-box or written sign-off from a second person confirming the result.
• Any issues noted - even minor ones - with a linked ticket if follow-up was required.

This kind of record is not complicated to produce. What it requires is treating each restore as a formal activity, not a background task.

The evidence trail an auditor follows

When an auditor examines backup and restore evidence during Stage 2, they will typically trace from the policy to the procedure, from the procedure to the schedule, from the schedule to the test records, and from the test records to the RTO/RPO documented in your continuity plan. A gap at any point in that chain is a potential finding.

Organisations that present only backup logs will typically receive either a nonconformity or an observation asking for restore evidence. Organisations that present restore logs without comparison to RTO/RPO targets may satisfy the backup control but still receive an observation against business continuity planning. The full picture requires both halves connected.

Fixing a gap before audit

If restore testing has been informally done but never documented, the window before a Stage 2 audit is the right time to run a documented test and create the record. A belated test with a clean record is far better than relying on an undocumented one.

What an auditor cannot accept is a verbal assurance that restores have worked historically. What they can accept is a dated record signed by the person who ran the test, showing the result against your targets.

Run the test. Write down what happened. Compare it to your documented objectives. Have someone countersign. That is the evidence.

Where Kellwick fits

If you are not sure whether your backup and restore evidence will hold up in a Stage 2 audit, a focused gap review will identify exactly what is missing and what needs to be documented before your certification window. Kellwick provides independent advisory, with no certification body relationship. Request a mini gap review to see where your evidence stands.