ISO 27001 Backup Requirements (Annex A 8.13) - Complete Guide & Checklist

What Annex A 8.13 Actually Requires

Annex A 8.13 of ISO 27001:2022 is titled Information Backup. The control objective is short but demanding: backup copies of information, software, and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup.

In practice, that single sentence creates four obligations every certified organization must meet:

1. A documented backup policy that covers scope, frequency, retention, and responsibilities.
2. Backups that actually run on the schedule the policy defines, for every in-scope system.
3. Backups stored in a way that survives the failure they are meant to recover from (off-site, immutable, or air-gapped).
4. Regular restoration tests that prove the backups are usable, with evidence kept for the auditor.

If you can show all four to an ISO 27001 auditor with documentation and recent evidence, you pass this control. If any one is missing, expect a non-conformity.

What Auditors Actually Look For

Annex A 8.13 is one of the most consistently tested controls in Stage 2 audits because it is concrete and easy to evidence. Auditors usually ask for the following, in this order:

• The backup policy itself, signed and version-controlled, identifying the data and systems in scope.
• A backup schedule or runbook showing what runs, when, where it is stored, and who owns it.
• Backup job logs for the past 30 to 90 days showing successful execution and failures with remediation.
• Evidence of an off-site or logically separated copy - typically a screenshot of cloud replication, immutable storage settings, or a tape rotation log.
• At least one restoration test report from the past 12 months, with the test date, scope, outcome, and any corrective actions.
• Encryption configuration for backup data at rest and in transit, especially when backups leave the production environment.
• Retention proof that aligns with the legal, contractual, and business retention periods declared in the policy.

If your last restoration test is older than a year, or your policy says "monthly" but logs show gaps, the auditor will write it up. These are the two most common findings on this control.

ISO 27001 Backup Policy Checklist

Use this checklist as the table of contents for your backup policy. Every item should appear in the document and be traceable to evidence.

• Purpose and scope (which systems, data, and locations are covered)
• Roles and responsibilities (backup owner, restore approver, reviewer)
• Classification-driven backup frequency (e.g. critical = daily, important = weekly)
• Retention periods aligned to legal and contractual requirements
• Backup storage location, including off-site or cloud replication
• Encryption requirements for backups at rest and in transit
• Access controls and least-privilege for backup systems
• Restoration testing schedule (at minimum annual, ideally quarterly for critical systems)
• Documented restoration test procedure and evidence template
• Incident response link - how backups are used during ransomware or major incidents
• Monitoring and alerting on backup job failures
• Review and approval cycle (annual minimum)
• Reference to related controls: A.5.30 (ICT readiness), A.8.14 (redundancy), A.8.24 (cryptography)

You can download an editable backup policy and 40+ other ISO 27001 templates in the ISO 27001 Document Pack.

Backup Frequency by Data Classification

ISO 27001 does not prescribe specific frequencies. It expects you to make a risk-based decision and document it. A defensible starting point most auditors accept:

• Confidential / Critical systems: incremental backups every 4 to 24 hours, full backup weekly, retained 12 months minimum.
• Internal / Important systems: daily incremental, weekly full, retained 6 to 12 months.
• Public / Low-impact systems: weekly full, retained 90 days.

The frequency you choose must line up with your Recovery Point Objective (RPO) for each system. If your business continuity plan declares an RPO of 4 hours for a system, backing it up nightly is automatically non-conformant - you have committed in writing to losing no more than 4 hours of data. Use the free RTO/RPO Helper to set defensible objectives before you write the policy.

Off-Site, Immutable, or Air-Gapped: What Counts?

Annex A 8.13 expects backups to survive the failure they protect against. In 2026 that means surviving ransomware, not just hardware failure. Three patterns satisfy modern auditors:

• Off-site replication to a different cloud region or physical site, with separate credentials.
• Immutable storage (object lock, WORM, or vendor immutability) preventing deletion or modification for a defined retention window.
• Air-gapped copies - tape, removable media, or storage logically disconnected from the production network.

At least one of the three is the bare minimum. Mature organizations use two. If your backups live in the same cloud account, same region, and same identity boundary as your production data, an auditor will flag it - and a ransomware attacker will encrypt both.

Restoration Testing: The Item Most Organizations Fail

Running backups is easy. Proving they restore is what trips most teams up. A defensible restoration test includes:

1. A documented test plan identifying the system, dataset, and success criteria.
2. Restoration into a non-production environment (never overwrite live data).
3. Verification that the restored data is complete and usable - not just "files copied".
4. A signed test report with date, scope, outcome, anomalies, and corrective actions.
5. Retention of the report for at least one audit cycle.

At minimum, test once a year for every critical system. Quarterly is the standard for systems supporting customer-facing services. Schedule the test in your calendar the day you finish reading this article - missing this evidence is the single most common Annex A 8.13 finding.

How Annex A 8.13 Connects to Other Controls

Backup is not a standalone control. Auditors will trace it through:

• A.5.29 Information security during disruption and A.5.30 ICT readiness for business continuity - your backup policy must support your BCP.
• A.8.14 Redundancy of information processing facilities - backups support recovery; redundancy supports availability.
• A.8.24 Use of cryptography - encryption keys for backups must be managed.
• A.5.34 Privacy and protection of PII - retention and deletion of PII inside backups.
• A.5.24 to A.5.27 Incident management - backups are part of ransomware response.

Document these links in your Statement of Applicability so the auditor sees a coherent control environment, not isolated policies. The SoA Generator builds these references automatically.

Common Mistakes That Cause Non-Conformities

• Backup policy exists but lists systems that are no longer in scope, or omits new ones.
• No restoration test in the last 12 months.
• Backup logs show repeated failures with no ticket or remediation.
• Backups stored only in the same cloud account as production.
• Retention period in the policy does not match what is actually configured in the tool.
• No encryption on backups leaving the production boundary.
• SaaS data (Microsoft 365, Google Workspace, GitHub) excluded from scope on the assumption that the vendor handles it - vendors handle availability, not your retention obligations.

Fix these before your Stage 2 audit and Annex A 8.13 becomes one of your easiest controls to evidence.

Next Steps

1. Compare your current backup setup against the checklist above and log any gaps.
2. Run a restoration test on your most critical system this quarter and write the report.
3. Download the editable backup policy template inside the ISO 27001 Document Pack.
4. Map your backup decisions to your RTO/RPO targets using the free RTO/RPO Helper.
5. Add backup evidence to your audit room with the Internal Audit Checklist.

Get Annex A 8.13 right and you remove one of the most common non-conformities ISO 27001 auditors raise - and you make ransomware recovery a planned procedure instead of a crisis.