ISO 27001 Annex A 8.13: information backup that survives audit

The Stage 2 auditor asks for your last restore test. Your backups have run every night for three years, and nobody has ever restored from them. That gap is what ISO 27001 Annex A 8.13 exposes, and it stalls certifications and enterprise security reviews alike.

This guide is for security, IT operations and DevOps leads at UK regulated firms and B2B SaaS teams. It covers what A.8.13 requires, how to scope cloud and SaaS estates, how to build copies that ransomware cannot reach, and how to automate the evidence.

What does ISO 27001:2022 Annex A 8.13 information backup require?

ISO 27001:2022 Annex A 8.13 requires a deliberate backup regime, not a scheduled job. That means a written policy covering what is copied, how often and for how long. Copies are protected like the originals and kept apart from them, and regular tests prove they restore. Frequency and restore speed take their targets from continuity objectives under A.5.30.

The 2013 edition carried this requirement as A.12.3.1, and the 2022 revision moved it into the technological controls as 8.13. The control protects integrity, because you need a clean copy when the live one is corrupted or encrypted. It also protects availability, because service has to return within a tolerable time.

In practice, the ISO 27001 backup requirements an auditor tests come down to four things:

• A written backup policy. It names the data and systems in scope, the frequency and the retention period.
• Targets per system. The recovery point objective (RPO) is how much data you can afford to lose. The recovery time objective (RTO) is how long you can be down.
• Protected, separated copies. Backups get the same protection as the originals and sit far enough away that one disaster cannot take both.
• Proven restores. Tests run regularly, into somewhere safe.

The ISO 27001 backup policy that satisfies this can be short. One page naming systems, frequency, retention and an owner beats a long document that nobody has checked against the configured schedule. When retention ends, the copies are deleted too, which is where A.8.10 takes over.

Ransomware made backups the survival variable. Firms with isolated, tested copies have a bad week, and firms without them negotiate with criminals. For regulated firms, lost client records can also be a reportable breach, not just an operational problem. Insurers and enterprise customers now ask pointedly about immutable copies and your last successful restore test.

If your firm is in scope of the FCA's operational resilience rules, set each RTO inside the impact tolerance of the important business service that system supports. In-scope firms had until 31 March 2025 to show they could stay within those tolerances. A backup that takes days to restore cannot support a tolerance measured in hours.

What should your backup scope include, and does your SaaS vendor already cover it?

Scope covers more than the production database: configurations, infrastructure-as-code state, and every SaaS platform such as Microsoft 365, Google Workspace and your CRM. Cloud providers keep their platform running, but recovering data deleted from their service is usually the customer's problem, so check what each contract actually promises.

Scope the estate honestly, system by system:

• Databases and application data, with the RPO deciding how often.
• System state and configuration: server images, identity and network settings, and the dependencies an application needs to start. File-level copies without them turn a planned four-hour recovery into a week of rebuilding.
• Infrastructure-as-code state, along with the repositories and pipeline definitions that rebuild your environment.
• The SaaS estate: Microsoft 365 or Google Workspace, the CRM and the finance system.
• Endpoints that hold data existing nowhere else.

Vendor redundancy protects the vendor's service from hardware failure and outages. It does not protect you from deletion, ransomware-driven sync corruption or a retention mistake on your side. Read each contract for how long deleted items stay recoverable and whether the vendor offers any restore at all. Where the answer is thin, add a copy held outside the vendor's own platform.

SaaS is among the most common backup gaps we find, and it is the auditor's favourite place to look.

How do you implement ISO 27001 Annex A information backup that ransomware can't reach?

Follow the 3-2-1 rule, translated for cloud: three copies on two storage types, with one in a separate region and security boundary. That way production credentials cannot reach the backup store. Make at least one copy immutable with object lock, and give backup administration its own MFA-protected credentials.

The architecture comes together in five moves:

1. Keep three copies on two kinds of storage. Production data, a local or snapshot backup, and a copy in a different service.
2. Hold one copy in another region and another security boundary. In practice that means a separate cloud account, subscription or project that production roles cannot assume.
3. Lock one copy. With object lock, even an administrator, or an attacker holding admin credentials, cannot rewrite history inside the retention window. Pick the strict mode where the platform offers one. In Amazon S3, compliance mode stops every user, including the root user, from deleting a locked version early, while governance mode can be overridden by anyone granted a bypass permission.
4. Separate the credentials. The account that runs backups should not be the account that falls to a phishing email, so keep it apart from general IT admin and behind MFA.
5. Disconnect logically. Restrict the paths into the backup store so a compromised production client cannot overwrite or delete anything.

The NCSC guidance on mitigating malware and ransomware attacks is blunt that ransomware actors go after backups, and it advises keeping backups separate from your network and systems. The NCSC cloud backup security recommendations add the cloud twist: you cannot unplug cloud storage, so the disconnection has to be logical: backup clients should hold no valid credentials while the store is not in use, and access controls should refuse connections.

A copy that shares a tenant and credentials with production is a second victim, not a backup.

Run the auditor's separation question yourself before they do. List every identity that can reach the backup store, then every identity that can delete from it. If the first list includes your general admins, the architecture has a hole.

How should backups be encrypted and keys kept separate?

Encrypt every backup copy at rest and in transit, and store the encryption keys apart from the data they protect. UK GDPR requires you to be able to restore personal data in a timely manner after an incident. The ICO suggests encrypting backups to protect them, with key management good enough to open them when needed.

The ICO encryption scenarios guidance calls backup a key part of disaster recovery. For encrypted backups it asks for good key management. For long-term copies, it also asks you to check that the data is still readable and the encryption still appropriate. Four habits cover the ground:

• Encrypt at rest on every copy, including the immutable one and any SaaS exports.
• Encrypt on the wire between the source and the backup store.
• Keep keys in a separate key-management service or account, with its own access list, so whoever reaches the data cannot also read it.
• Document key recovery. An encrypted backup whose key has been lost is a lost backup.

The auditor wants configuration evidence: encryption switched on, and key custody that is independent of the backup store. Use current, widely reviewed algorithms such as AES, and let the key-management service handle rotation rather than a spreadsheet.

How often should you test restores under ISO 27001 Annex A 8.13?

Test restores quarterly for systems the business cannot operate without, at least annually for everything else, and again after any significant infrastructure change. Each test recovers into an isolated environment and is timed against the RTO. The write-up records what was restored, how long it took and who verified it.

Each test follows the same sequence:

1. Choose the system and restore point, rotating so every critical system is covered over time.
2. Restore into an isolated environment, never over production.
3. Start the clock and record the elapsed time against the RTO.
4. Have someone other than the operator verify that the data is intact and the application works.
5. Write it up and raise tickets for anything that broke, so the next test checks the fix.

"We back up nightly" describes a schedule. It says nothing about recovery.

A common pitfall is a recovery procedure that lives in one engineer's head, discoverable only by their absence. Ask a second engineer to run the restore from the written procedure alone, and fix every gap they hit.

Treat a failed test as a good result. A restore that fails in staging, followed by a ticket and a fix, is the strongest exhibit you can hand an auditor.

How do you automate continuous backup verification?

Wire backup job telemetry into alerting so failures open tickets automatically. Run scripted restores into an isolated environment on a schedule. Check immutability and key separation with scheduled configuration checks, and compare backup scope with the asset register. Evidence then becomes a by-product of operations rather than a quarterly scramble.

Silent failure is the standard horror story: a job stops completing in March and the gap surfaces during an incident. Sending every completion and failure into your monitoring stack, with failures raising tickets, removes that failure mode. It also produces the failed-job-to-fix trail that auditors sample.

A scheduled pipeline makes the restore test happen because a timer fires, not because someone remembers. The script restores into an isolated environment, checks the result and writes duration and outcome to an evidence store you can export on request.

Add an integrity check before each job runs. Otherwise the regime faithfully copies corrupted or already-infected data every night, and the first sign is a restore that succeeds technically and returns garbage.

Configuration checks catch the quiet regressions: a lock switched from compliance to governance mode, a production role newly allowed into the backup account, a key policy widened during an incident. A reconciliation job against the asset register turns a new SaaS tool missing from the regime into a ticket within days.

How long can you keep backups under UK GDPR?

Keep backups only as long as the retention schedule says, then delete them. UK GDPR does not stop applying because data sits on a backup tier, so a 'keep forever' default on cheap storage quietly builds up liability. Tie each system's retention to business need and recovery objectives, and connect expiry to the deletion duties of A.8.10.

Set the schedule in four steps:

• Decide retention per system, from business need and the RPO and RTO you set earlier.
• Record it in the backup policy, so the auditor can compare policy against configuration.
• Automate expiry with lifecycle rules that delete copies when the period ends.
• Align object-lock periods with retention. A lock longer than the retention period leaves you unable to delete on schedule.

Cheap storage makes "forever" look free, which is why the default persists. Decide in advance how erasure requests under Article 17 treat data held on backups, and record the answer in the policy. The retention schedule is what makes that answer defensible.

What will an auditor ask during an ISO 27001 Annex A 8.13 audit, and how is it graded?

An A.8.13 auditor picks a critical system and walks the chain. They check the policy entry, recent job logs and the last restore test record, then trace a failed job to a ticket and a fix. Expect questions on separation, SaaS coverage and who can delete a backup. A never-tested restore programme grades major.

Expect these questions in the room:

• Show me your backup policy, then show me that the configured schedule matches it.
• When did you last restore something, and how do I know it worked?
• If ransomware took your production environment and its credentials tonight, why would the backups survive?
• Is your Microsoft 365 or CRM data backed up outside the vendor's own platform?
• Who can delete a backup, and what stops them?

Beyond the chain, the auditor compares backup coverage with the asset register, looking for systems that appear in one list and are missing from the other.

Bring this evidence:

• The backup policy and per-system schedule, with frequency and retention tied to stated objectives.
• Job logs or dashboard exports showing scheduled runs completing across servers, cloud and SaaS.
• Restore test write-ups: what was recovered, into where, how long it took and who verified it.
• Configuration evidence for immutability or separation, and for encryption with independent key handling.
• The list of who can administer backups, with MFA enforcement shown.
• Tickets showing failed jobs caught and fixed.

Grading follows certification-body practice. A critical system with no working backup, or a programme whose restores have never been tested, is an absent requirement and grades major. A lapsed test cadence, one unremediated failed job or retention drifting past policy grades minor, though a pattern of minors can add up to a major.

With the verification loop running, the evidence already exists, and the auditor's sample becomes an export you run on the day.

Frequently asked questions