ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27001 backup is one of the few Annex A controls that fails quietly, and you find out on the worst day of the year. The control text is barely two lines long, so most teams read it as “run backups, keep the job logs.” That reading survives a vendor questionnaire and falls apart in a Stage 2 audit, because the control names three different things you have to copy, puts testing inside the requirement rather than the guidance, and points at a policy that has to be approved and reviewed like every other policy in the management system.
This guide covers what the ISO 27001 backup control asks for in the 2022 edition, the numbers the standard deliberately refuses to give you, how it differs from redundancy and continuity, and the evidence an auditor will actually ask to see.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
Annex A 8.13 Information backup sits in the technological theme of ISO/IEC 27001:2022 — Edition 3, published October 2022, with one free amendment issued in 2024. The 2022 Annex A holds 93 controls in four themes: 37 organizational, 8 people, 14 physical and 34 technological. Backup is one of the 34 technological controls.
Stripped to its obligations, the control says copies of information, software and systems are to be kept and tested regularly, in line with an agreed topic-specific policy on backup. That single sentence carries three separate duties:
One useful thing to know before you start rewriting anything: this is not a new control. Annex A 8.13 carries forward A.12.3.1 from the 2013 edition, so it is not among the eleven controls the 2022 revision introduced. If your ISMS transitioned properly, you already have something here. The common failure is not absence — it is a policy that only ever scoped the first of those three objects.
Nearly every ISO 27001 backup policy written in the last decade scopes “production data.” The control names three things, and the gap between them is where recovery time goes. A database dump restores nothing on its own if the application that reads it, and the server that runs the application, both have to be rebuilt by hand from someone’s memory.
| What the control names | What it means in practice | What a real restore needs |
|---|---|---|
| Information | Databases, file shares, mailboxes, document repositories, logs you are required to retain, SaaS tenant data | A copy that is readable without the original system, plus a documented retention period per data class |
| Software | Application binaries and packages, licence keys, build artefacts, container images, the versions that matched the data | A copy of the version that was running, not just the latest release in the registry |
| Systems | Operating system images, server and network configuration, infrastructure-as-code, directory and identity configuration | Enough to rebuild the environment from bare metal or an empty cloud account |
Auditors do not usually push on the systems object during Stage 1. They push at Stage 2, when they ask what you would do if the hypervisor cluster — or the cloud subscription — were gone rather than one file. If the answer involves a person who “knows how it was configured,” the ISO 27001 backup control has not been met for the systems object.
The control refers to an “agreed topic-specific policy on backup.” That phrase is doing more work than it looks. Annex A 5.1 requires an overarching information security policy supported by topic-specific policies, and backup is one of the standard examples. Anything carrying that label inherits the A.5.1 obligations: it has to be defined, approved by management, published, communicated to and acknowledged by the people it applies to, and reviewed at planned intervals and after any significant change.
That is why a wiki page called “Backup runbook,” last edited nineteen months ago by an engineer who left in March, is a finding even when the backups themselves are flawless. The jobs are fine; the policy is not under control. The same logic ties this back to clause 7.5 — see our guide to ISO 27001 document control for how approval, version and review evidence has to look.
An ISO 27001 backup policy that holds up names, at minimum: the scope of what is copied across all three objects, frequency per data class, retention per data class, where copies live, whether copies are encrypted and under whose keys, who owns the process, how restores are tested and how often, and what happens when a job fails.
This is the single most useful thing to understand about the ISO 27001 backup requirement. In many Annex A controls, the detail about verification sits in ISO/IEC 27002 guidance, which is advisory. Here, testing is inside the control statement, so a backup estate that has never been restored is nonconforming on its own terms — not merely weak practice. A green dashboard proves a job finished writing bytes. It does not prove the bytes come back.
The standard does not prescribe a test method, so build a ladder and record each rung. The cadences below are common industry practice, not requirements:
| Test | What it proves | What it does not prove | Typical cadence |
|---|---|---|---|
| Single file or mailbox restore | The media is readable and the process works | That a whole system can be rebuilt | Monthly |
| Database restore to a staging instance with an integrity check | Application-consistent data, not just file-consistent | That the surrounding platform exists | Quarterly |
| Full system rebuild into a clean environment | Software and systems objects are genuinely covered | That staff can do it under pressure | Annually |
| Timed recovery exercise against your stated objective | Your recovery time target is real | Nothing — this is the one auditors value most | Annually |
Record the date, who ran it, what was restored, how long it took, whether integrity checks passed and what was fixed afterwards. A test that found a problem and shows the correction is stronger evidence than a test that passed, because it demonstrates the feedback loop clause 10.1 expects.
Read the ISO 27001 backup control looking for a schedule and you will not find one. ISO 27001 states no backup frequency, no retention period, no minimum number of copies, no recovery point or recovery time objective, and no requirement for the 3-2-1 rule — which is industry convention, not a clause. It does not say backups must be offline, air-gapped or immutable either.
What the standard does is make those numbers yours, and then hold you to them. Your figures come from the business impact of losing each data class, legal and contractual retention obligations identified under A.5.31, and the expectations of interested parties captured under clause 4.2. Once they are in the policy, the auditor’s question stops being “is 24 hours enough?” and becomes “you said four hours — show me the test that met it.”
If you have not set those targets yet, start with the four recovery metrics in our guide to RTO and RPO, then write the resulting numbers into the policy rather than leaving them in a spreadsheet nobody approved. Organisations in scope of DORA have a harder floor to meet — our backup policy guide covers what Article 12 adds on top.
Two related points worth noting while you are here. Encryption of backup copies is governed by A.8.24 use of cryptography, and the key management question matters more than the algorithm — a copy encrypted under a key that only lives in the system you just lost is not a backup. See our ISO 27001 cryptography policy guide. And retention has an upper bound as well as a lower one: A.5.33 protection of records and your privacy obligations both argue against keeping copies forever, which is why disposal belongs in the same policy.
Four controls get collapsed into a single slide called “DR,” and the collapse is why Statements of Applicability so often justify three of them with the same sentence. They answer different questions.
| Control | Question it answers | 2013 origin |
|---|---|---|
| A.8.13 Information backup | Can we get the data, software and systems back after they are lost or corrupted? | A.12.3.1 |
| A.8.14 Redundancy of information processing facilities | Can we keep running when a component fails, without a restore? | A.17.2.1 |
| A.5.29 Information security during disruption | Do our security controls still hold while we are in crisis mode? | A.17.1.1–A.17.1.3 |
| A.5.30 ICT readiness for business continuity | Is our technology ready to meet the continuity objectives the business set? | New in 2022 |
Redundancy is the one most often mistaken for backup. A replicated database protects you from hardware failure and from nothing else: ransomware encryption, a bad migration script and an accidental mass delete all replicate perfectly to the secondary within seconds. If your ISO 27001 backup justification in the SoA says “covered by our high-availability cluster,” expect a finding. For the continuity side of the pair, our guide to ISO 27001 ICT readiness covers A.5.30 in depth.
The fastest-growing ISO 27001 backup finding has nothing to do with servers. It is the assumption that because your email, CRM and document storage are somebody else’s platform, somebody else is backing them up for you.
Major providers do protect their platform, and most offer a recycle bin or retention window — commonly in the range of 30 to 90 days, varying by provider and licence tier — after which deleted tenant data is genuinely gone. That window is a contract term, not a backup policy, and it rarely matches the retention periods your own policy promises. A.5.23 information security for use of cloud services expects you to have worked out exactly where the line sits, and A.5.20 expects the relevant obligations to be in the supplier agreement.
Three questions settle it for each cloud service in scope: what is the provider’s actual retention window in writing, does it cover the deletion scenarios you care about including a malicious admin, and does it reach the retention period in your own policy. Where the answer is no, you either buy third-party backup for that tenant or you write the shortfall into the risk treatment plan as an accepted risk, with a named owner. What you cannot do is leave the policy claiming seven years while the platform quietly offers ninety days.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
ISO 27001 backup sampling is predictable, so you can prepare for it. Expect the auditor to work from your own documents inward:
One more thing gets sampled that teams rarely anticipate: whether a restore has been attempted since the last significant infrastructure change. A successful test from fourteen months ago, against a platform you have since migrated, is evidence about a system that no longer exists.
For the wider picture of how this control sits alongside the other 92, see our guide to the ISO 27001 Annex A controls.
Effectively yes. The ISO 27001 backup control refers to an agreed topic-specific policy on backup, and A.5.1 sets out what a topic-specific policy must satisfy — approval, publication, communication and planned review. It is not one of the clause-level mandatory documents, but if you have applied A.8.13 in your SoA, an auditor will expect the policy to exist and to be under document control.
ISO 27001 backup testing has no stated interval — the control says only “regularly.” You choose the frequency, justify it against the criticality of each system, write it into the policy and then meet it. Annual full-restore testing with more frequent partial tests is common practice, but the requirement is to define a cadence and hold to it, not to hit a published number.
None of those three words is a requirement in the control. They are risk treatments that a competent risk assessment will usually point to — particularly against ransomware, where an attacker with production access will go for the backups first. If your risk assessment identifies that scenario and your treatment plan does not include a copy out of reach of production credentials, expect that gap to be questioned.
No. ISO 27001 backup is A.8.13 and is about being able to get information, software and systems back. Disaster recovery sits closer to A.5.30 ICT readiness for business continuity, which asks whether your technology can meet continuity objectives the business has actually set. Backup is an input to disaster recovery; it is not the whole of it, and the SoA should not justify one with the other.
Not automatically — but you do need to know what the provider retains, for how long, and whether that meets the retention your own policy commits to. Where it does not, buy third-party backup or record the shortfall as an accepted risk with an owner. The finding is never “you did not buy a tool”; it is “your policy claims a retention period your platform cannot deliver.”
Cleanly. The NIST Cybersecurity Framework 2.0, published in February 2024, carries the same obligation at PR.DS-11 — backups created, protected, maintained and tested — within the Protect function’s Data Security category. If you are running both, one set of restore test records satisfies the evidence need for each.
Most of the ISO 27001 backup work is writing one policy that scopes all three objects, states numbers you can defend, and generates test records on a schedule — then keeping the evidence tidy enough that an auditor can follow it without you narrating. If you would rather start from a drafted policy, register and test-log formats than a blank page, the ISO 27001 Toolkit includes 165 templates covering the full ISMS, Annex A 8.13 among them, for $99 as a one-time purchase.
Whatever you use, do the restore test before the auditor asks. It is the one exhibit on this control that cannot be written the week before Stage 2.
October 22, 2026
October 22, 2026
October 21, 2026
October 21, 2026
October 20, 2026