ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27001 ICT readiness is Annex A control 5.30, and it is the only Annex A control whose own statement contains the word tested. That single word changes what an auditor can accept. For most controls, a sensible document plus consistent practice is enough. For 5.30, a plan that has never been exercised fails on the face of the control, before anyone exercises judgment about whether it is any good.
The control reads, in substance, that ICT readiness shall be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements. Four verbs, two inputs. Most ISO 27001 ICT readiness implementations deliver the first verb, partially deliver the second, skip the third and fourth, and invent the two inputs inside the IT function because nobody else produced them. That is the shape of the nonconformity, and it is remarkably consistent across organizations of every size.
This guide covers what ISO 27001 ICT readiness actually requires, why 5.30 is genuinely new rather than a renamed 2013 control, how it divides from the two controls it is constantly merged with, what changed when the supporting standard was reissued in 2025, and what the evidence looks like when a Stage 2 auditor asks to see your last recovery test.
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
Strip the control back and it asks two questions in sequence. First: what does the business need back, and how quickly? Second: can your technology deliver that, and how do you know?
The first question is not answered inside the ISMS. The control says readiness is based on business continuity objectives — which are an input the standard assumes exists, not one it requires you to create. ISO 27001 has no clause that makes you set business continuity objectives. Clause 6.2 requires information security objectives, which are a different thing entirely. So A.5.30 reaches outside the ISMS for its own starting point, and if nothing outside the ISMS has set those objectives, the control cannot be satisfied credibly no matter how good the runbooks are.
That is the single most useful thing to understand about ISO 27001 ICT readiness. It is not a technical control. It is a control that tests whether your technical recovery capability was designed against a business requirement, or designed against whatever the infrastructure team thought was reasonable.
The second question is where the four verbs bite. Planned means documented recovery arrangements exist for the services that matter. Implemented means the capability is actually in place — the replication is configured, the alternate capacity is contracted, the backups run. Maintained means the plan tracks reality, so when a system moves to a new platform the plan moves with it. Tested means you have proven it, recently, and written down what happened.
The 2022 edition reorganized 114 controls into 93 across four themes, and most of the movement was consolidation. Eleven controls, however, were genuinely new, and the ISO 27001 ICT readiness control is one of them. It appears in the published Annex A mapping with no corresponding 2013 control at all.
This matters because it is easy to assume 5.30 is simply the old A.17 section under a new number, and to carry forward a 2013-era continuity document unchanged. It is not. The three old continuity controls went somewhere else:
| 2013 control | Where it went in 2022 | What that control now asks |
|---|---|---|
| A.17.1.1 Planning information security continuity | A.5.29 Information security during disruption | Do your security controls keep working while you are degraded? |
| A.17.1.2 Implementing information security continuity | A.5.29 Information security during disruption | As above — all three merged into one control |
| A.17.1.3 Verify, review and evaluate information security continuity | A.5.29 Information security during disruption | As above |
| A.17.2.1 Availability of information processing facilities | A.8.14 Redundancy of information processing facilities | Is there spare capacity engineered in? |
| — nothing — | A.5.30 ICT readiness for business continuity | Can you get the ICT services back inside the time the business needs? |
Read that table carefully and the design intent is clear. In 2013, the standard asked whether your security survived a disruption. In 2022, it asks that question at A.5.29 — and then adds a separate requirement that the services themselves come back. Those are different obligations with different owners and different evidence, which is exactly why collapsing them into one “BCP” document causes findings.
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
Three controls sit in the ISO 27001 ICT readiness space and they are routinely treated as one. Separating them in the Statement of Applicability costs nothing and removes a whole class of audit friction.
| Control | Theme | The question it answers | Typical evidence |
|---|---|---|---|
| A.5.29 Information security during disruption | Organizational | While we are running degraded, do the controls still hold? Is access still authorized? Is logging still happening? | Degraded-mode control analysis; break-glass procedures with approval records; log continuity during the last incident |
| A.5.30 ICT readiness for business continuity | Organizational | Can we restore the ICT services inside the recovery objectives the business set? | ICT continuity plan per service; recovery objectives traced to a business input; test records with measured times |
| A.8.14 Redundancy of information processing facilities | Technological | Is there engineered spare capacity so that a single failure is absorbed rather than recovered from? | Architecture diagrams showing redundancy; failover configuration; evidence the redundant path has been exercised |
The practical test for which control you are looking at: A.8.14 prevents the outage, A.5.30 ends the outage, and A.5.29 keeps you secure while the outage is happening. An organization with excellent redundancy and no tested recovery plan is strong on A.8.14 and weak on ISO 27001 ICT readiness, and the auditor will say so.
The companion guidance standard for ISO 27001 ICT readiness is ISO/IEC 27031, and it was reissued in May 2025. This is worth knowing because a large share of the material written about 5.30 was published between 2022 and 2024 and points at an edition that no longer exists.
Two things changed in the title alone. The word Guidelines came out, and the domain label moved from “Information technology — Security techniques” to “Cybersecurity”. ISO’s own description of the 2025 edition makes the third change explicit: readiness is no longer treated as a question about internal systems only, but extends to dependencies on third-party services such as cloud providers.
That third point is the one that reshapes ISO 27001 ICT readiness for a modern organization. If your production platform is somebody else’s, your recovery capability is largely a contractual and architectural question, not an operational one — and the evidence changes accordingly.
Nearly every ISO 27001 ICT readiness plan contains an RTO and an RPO per service. Very few contain the number that makes those two meaningful: the point beyond which the business genuinely cannot cope.
NIST’s contingency planning guidance separates three figures, and the distinction is sharper than the usual “RTO/RPO” pairing suggests.
| Figure | What it measures | Who sets it | The trap |
|---|---|---|---|
| MTD — maximum tolerable downtime | The total outage the business owner is willing to accept for a process, including every knock-on effect | The business, not IT | Usually missing entirely, which leaves the RTO unanchored |
| RTO — recovery time objective | How long a system resource can be unavailable before the impact becomes unacceptable | Derived, so that the MTD is not breached | Must be shorter than the MTD, because reprocessing after recovery also consumes time |
| RPO — recovery point objective | The point before the outage to which data can be recovered, given the most recent backup | Derived from tolerable data loss | Is not part of the MTD — it measures data loss, not elapsed time |
The chain matters: the business sets a tolerance, the RTO is engineered to stay inside it, and the RPO answers a separate question about how much work you are prepared to lose. When an auditor asks where an RTO of four hours came from and the answer is “that is what the replication gives us”, the control has been satisfied backwards. We go deeper on the arithmetic in our guide to RTO and RPO.
The input that produces those numbers is a business impact analysis. ISO 27001 does not require a BIA by name anywhere in the clauses, which is why so many implementations skip it — but meeting ISO 27001 ICT readiness credibly means knowing your recovery requirements, and a BIA is the artifact that produces them. If you are unsure how it differs from the risk assessment you have already done, see BIA vs risk assessment; they answer different questions and the BIA comes first.
Free business impact analysis
How long can each activity really be down?
Rate the impact of an outage over time, set RTOs and maximum tolerable periods of disruption, map the people, systems and suppliers behind each activity, and get a recovery sequence back, free.
Run the free business impact analysis → or View premium report sample
The standard advice for 5.30 is “write a disaster recovery plan”. For a cloud-hosted company that advice is subtly wrong, and NIST’s definitions show why.
| Plan type | Scope | Triggered by | Fit for A.5.30 |
|---|---|---|---|
| Business continuity plan | Sustaining mission and business processes during and after a disruption | Any disruption to the business | Provides the objectives A.5.30 is based on, but is not itself the ICT answer |
| Disaster recovery plan | Restoring systems at an alternate site after a major, usually physical disruption | Loss of access to a primary facility for an extended period | Only addresses disruptions that require relocation — so it covers a shrinking share of real incidents |
| Information system contingency plan | Assessment and recovery of a specific system, regardless of site or location | Any disruption to that system | The closest match: one per service, which is what the control’s per-service recovery objectives imply |
| Cyber incident response plan | Identifying, containing and recovering from attacks | A security incident | Adjacent, not a substitute — it handles the cause, not the restoration of service |
A disaster recovery plan is site-specific by definition. If your estate is three SaaS platforms and a managed Kubernetes cluster in one region, there is no building to relocate from, and a document organised around “proceed to the alternate facility” will read as theatre. The plan that fits is per-system and location-independent: what is this service, what does it depend on, who decides to invoke, what are the steps, how do we verify it is really back.
This does not make disaster recovery planning obsolete. If you run your own data centre or hold material on-premise infrastructure, you need both — a site-level plan for relocation and per-system plans for restoration. The point is that ISO 27001 ICT readiness is satisfied by the per-system layer, and a site-level plan alone leaves the control half-answered.
ISO/IEC 27002’s guidance for this control is more specific than the control statement, and several of the items an ISO 27001 ICT readiness plan needs are routinely left out. A plan that covers these is defensible:
Your backup arrangements sit underneath this rather than inside it; the plan consumes the restore capability that your backup policy establishes. Keep them as separate documents, because they are reviewed on different cycles and owned by different people.
Here is where ISO 27001 ICT readiness differs from almost every other Annex A control. Testing is not a suggestion buried in ISO 27002’s implementation advice. It is one of the four verbs in the control statement itself. An untested plan does not partially satisfy 5.30 — it fails a stated element of it.
What counts as an ISO 27001 ICT readiness test is not prescribed, and that is where sensible proportionality lives. Two forms carry most of the load:
| Test type | What happens | What it proves | What it cannot prove |
|---|---|---|---|
| Tabletop exercise | A facilitated, discussion-based walkthrough of a scenario; no equipment is deployed | That roles, decision rights, escalation and sequence are understood and coherent | That the technology works, or that the RTO is achievable |
| Functional exercise | Personnel perform their actual duties in a simulated environment, from a single component up to a full failover | That the capability works and how long it really takes | Rarely the complete cross-dependency picture, unless run at full scale |
A tabletop is a legitimate test and a well-documented one will be accepted, particularly for a small organization or a first cycle. But a tabletop cannot produce a measured recovery time, and the guidance expects testing against measured metrics. If every test you have run is discussion-based, your recovery objectives are still assertions. The strongest evidence set pairs an annual functional test of the highest-criticality service with tabletops across the rest.
Write up every test the same way: scenario, participants, start and end times, the objective target, the time actually achieved, what did not work, and the corrective actions raised with owners and dates. A test report that records a clean pass with no observations is the least convincing artifact in the folder — real exercises always surface something, and an auditor knows it.
No. There is no requirement anywhere in ISO 27001 to operate a business continuity management system in order to satisfy ISO 27001 ICT readiness, and no certification body will ask for an ISO 22301 certificate as a condition of ISMS certification. What A.5.30 needs from the continuity side is narrower than a BCMS: continuity objectives for the processes your ICT services support, and enough impact analysis to turn those into recovery figures.
Small organizations can produce that in a workshop and a spreadsheet. The decision to build a full BCMS is a business one about operational resilience, not a compliance one about ISO 27001 ICT readiness — our comparison of ISO 27001 vs ISO 22301 sets out where the two management systems actually overlap.
Where this does get tighter is regulated sectors. If you are inside the scope of DORA, NIS2 or a sector resilience regime, testing expectations and reporting duties are set by that regime and are usually more demanding than anything 5.30 implies. In that case build to the regulation and let the Annex A control be satisfied as a by-product.
The ISO 27001 ICT readiness sample is predictable. Expect something close to this sequence:
If an invocation has actually happened in the period, that incident becomes the evidence and the plan becomes secondary. Expect the auditor to compare what the plan said with what people did, and to be far more interested in the post-incident review than in the document. That overlap with incident handling is worth managing deliberately — see our ISO 27001 incident response plan guide for how the two processes hand off to each other.
No specific document is mandatory. ISO 27001’s list of required documented information does not include a DR plan, and A.5.30 names a capability rather than a document. In practice you need written recovery arrangements, because “planned, implemented, maintained and tested” cannot be demonstrated from memory — but the form is yours. Per-service contingency procedures usually fit better than a single site-based DR plan.
ISO 27001:2022 sets no interval, so this is your decision to make and justify. A common and defensible pattern is an annual functional test of the highest-criticality services, tabletop exercises for the rest on the same annual cycle, and an additional test triggered by any material architectural change. State the interval and the triggers in the plan so the auditor can see a deliberate choice rather than a gap.
Yes, and arguably more sharply. The control is about restoring ICT services inside the business’s recovery objectives, and it does not care who operates the infrastructure. What changes is the evidence: contracted recovery commitments, your own configuration of the provider’s resilience features, region and account-level failover design, and tests of the parts you control — including recovery from an account or tenant-level failure, which no provider SLA covers for you.
In ISO 27001 ICT readiness terms, A.5.29 asks whether your security controls keep working while the organization is disrupted — access management, logging and monitoring under degraded conditions. A.5.30 asks whether the ICT services themselves can be restored inside the recovery objectives. One protects you during the outage, the other ends the outage. They need separate treatment in the Statement of Applicability.
Not as a named requirement — ISO 27001 never uses the term. But the control is explicitly based on business continuity objectives and ICT continuity requirements, and a BIA is how those requirements are normally produced. A proportionate BIA covering your critical processes and their ICT dependencies is the shortest route to defensible recovery objectives, and skipping it is why so many plans contain numbers nobody can account for.
ISO 27001 ICT readiness rewards structure over length. A short plan per critical service, with objectives traced to a business figure, a realistic dependency list, named invocation authority and a test report from the last twelve months, beats a sixty-page continuity manual that has never been opened in anger. The four verbs in the control are a checklist: plan it, build it, keep it current, prove it. Most organizations can close the gap in a few weeks, and the part that takes longest is getting the business to state a tolerance it has never had to articulate.
If you would rather start from drafted documents than a blank page, the ISO 27001 Toolkit includes the continuity, backup, incident and asset documentation as part of 165 templates aligned to the 2022 edition, for $149. For the control set as a whole, our guide to the ISO 27001:2022 controls maps all 93 across the four themes. The sources of record are ISO/IEC 27031:2025 on iso.org, now in its second edition and the direct companion to this control, and ISO/IEC 27001:2022 itself, currently in its third edition with one amendment.
October 12, 2026
October 12, 2026
October 12, 2026
October 12, 2026
October 12, 2026