Skip to content
compliancebase
ISO 27001A.5 — ICT readiness for business continuity

A.5.30

ICT readiness for business continuity

ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026

Objective

Plan, implement, maintain, and test ICT continuity so it stays aligned to business continuity and information security objectives.

Points of focus

  • RTO/RPO defined per service or data tier based on business impact, not a single blanket number
  • Backup and restore, or failover, is tested on a defined cadence with recorded pass/fail results
  • Continuity plan distinguishes what the cloud provider's resilience covers from what remains the organization's responsibility
  • Continuity plan is reviewed after architecture changes, such as a new region or a new critical dependency

Implementation notes

Set RTO/RPO per service tier based on actual business impact — a marketing site and the primary application database don't need the same numbers — and validate them with a real or simulated restore or failover, not just a policy statement. Record test dates, scope, duration, and whether the result met the target; treat a missed target as a finding to remediate, not a reason to quietly lower the target. Document explicitly what the cloud provider's own resilience covers, such as regional redundancy or managed database failover, versus what remains your responsibility, such as application-level failover logic, DNS cutover, or restoring data from your own backups. Revisit the plan whenever the architecture changes materially, including a new region, a new critical dependency, or a move from single-instance to managed or clustered infrastructure.

Audit tip: Ask for the most recent restore test result, including what was restored, how long it took, and whether that matched the stated RTO. 'We have backups' without a timed restore test is not evidence.

Evidence auditors typically request:

  • RTO/RPO definitions per service tier, tied to the business impact analysis
  • Backup restore test log with dates, scope, and pass/fail outcome
  • DR or failover exercise report, even if tabletop-level, with a dated result
  • Architecture notes showing single points of failure and mitigations, such as multi-AZ or cross-region replication

Common gaps

  • Backups run automatically and are never restored to verify they actually work
  • RTO/RPO is stated as a target in the policy but has never been tested against a real or simulated failure
  • Single-region deployment with no failover plan, despite an SoA line claiming continuity readiness
  • Continuity plan doesn't address dependency on a single third-party API or auth provider with no fallback

Cross-Framework Mapping

FrameworkRequirementImplementation note
ISO 27001A.5.30This control
SOC 2A1.2, CC7.5If Availability is in scope for your Trust Services Criteria, A1.2's backup and recovery testing expectation lines up closely with this control — one test can support both.

Primary sources

Frequently Asked Questions

No. A tested, documented manual failover or restore process is acceptable if it meets your stated RTO/RPO and has evidence that it works.

At least annually for most SaaS businesses, more often for the data stores with the tightest RPO. The cadence should be in your policy and actually followed.

Partially. Provider-level redundancy handles infrastructure failure; it doesn't cover application bugs, bad deploys, or accidental data deletion — you still need your own backup and restore process tested independently.

State them as targets under review and show a plan to validate them. Presenting untested targets as a proven capability is the more serious finding in an audit.

Framework versions referenced in this page:

  • ISO/IEC 27001 — ISO/IEC 27001:2022

Last verified: July 2026 · Primary sources linked above