A.5.30 — ICT readiness for business continuity

Plan, implement, maintain and test ICT readiness to ensure information availability during disruption.

Also written as A5.30, Annex A 5.30, ISO 27001:2022 A.5.30, ISO27001 A.5.30.

Written by Jett N. · Last reviewed 22 July 2026

What ISO 27001 A.5.30 requires

ICT readiness for business continuity is one of 37 Organisational Controls in ISO/IEC 27001:2022 Annex A. Plan, implement, maintain and test ICT readiness to ensure information availability during disruption. Organisational controls are judged on governance rather than tooling: an auditor wants a named owner, an approval trail, and evidence the control is exercised on a defined cadence rather than written once and filed.

Audit evidence assessors look for

When preparing your Statement of Applicability (SoA) for A.5.30, gather artefacts such as:

How to implement A.5.30

1. Derive RTO and RPO from a business impact analysisRecovery targets invented by IT are the classic finding. They have to trace back to a BIA that says what the business can tolerate, per service. Without that link, the numbers are unfalsifiable and the control cannot be assessed.
2. Plan for ICT specifically, not just the businessA.5.30 is the ICT-readiness control sitting under the broader continuity requirements. A business continuity plan that says "IT will restore systems" does not satisfy it. What is needed is the technical detail: dependencies, restoration order, who executes, and what they need access to when the primary environment is unavailable.
3. Test restoration, not backupA backup job reporting success is not recovery evidence. Restore something real, time it against the RTO, and record the gap. The organisations that discover their restore takes four days are always the ones who had green backup dashboards.
4. Cover the dependency chainRecovery plans routinely omit the things needed to run the recovery: identity provider, DNS, certificate authority, the password vault, and the runbook itself if it lives only in the system being restored. Test the plan assuming the primary environment is gone.
5. Record the test outcome honestlyA test that found problems and led to fixes is better evidence than a test that passed cleanly, because it demonstrates the process improving. Keep the findings and the remediation.

Common audit findings for A.5.30

What actually gets raised against A.5.30, in rough order of how often it comes up:

• RTO and RPO stated in the plan but never tested, so nobody knows whether they are achievable.
• Backup verification presented as recovery testing.
• Recovery plans that depend on systems inside the failure scope, most commonly the identity provider or the documentation itself.
• A plan last tested more than a year ago, or last tested against an architecture that has since changed.

Scoping A.5.30

A.5.30 is new in ISO 27001:2022. Cloud-hosted organisations sometimes argue the provider handles it — that is only partly true. Provider redundancy covers infrastructure failure; it does not cover your own misconfiguration, ransomware, or account loss, and the exit and recovery responsibility for your data remains yours.

How A.5.30 maps to SOC 2 and NIST CSF

If you run more than one framework, the same evidence usually satisfies all of them. A.5.30 aligns with:

SOC 2: CC9.1 Business disruption risk mitigation, A1.2 Environmental protections, backup and recovery infrastructure, A1.3 Recovery plan testing

NIST CSF 2.0: PR.IR-03 Resilience mechanisms, PR.IR-04 Adequate resource capacity, RC.RP-01 Recovery plan execution

ISO 27001:2013 mapping

A.5.30 is a new control introduced in the 2022 revision with no direct 2013 equivalent. Treat it as a fresh requirement when transitioning from ISO 27001:2013.

Related Annex A controls

See all 37 Organisational Controls →