A.5.29 / A.5.30 / CP-4 / CIS-11.5 ISO/IEC 27001:2022 Annex A ISO 27001

A.5.29 / A.5.30 — Is information security maintained during disruption and is ICT readiness for business continuity tested? (A.5.30 NEW)

Demonstrate that information security controls remain functional during disruption scenarios and that ICT business continuity capabilities are regularly tested, validated, and improved based on exercise outcomes.

Description

What this control does

This dual control ensures that information security remains effective during disruptive incidents (A.5.29) and that ICT readiness for business continuity is periodically tested through simulations, exercises, or failover tests (A.5.30). Organizations must maintain security controls during activations of continuity arrangements—such as when operating from alternate sites, using backup systems, or invoking disaster recovery procedures. Testing verifies that security functions (authentication, encryption, logging, access control) remain operational under continuity scenarios and that recovery time objectives (RTOs) and recovery point objectives (RPOs) can be met without compromising confidentiality, integrity, or availability.

Control objective

What auditing this proves

Associated risks

Risks this control addresses

Failure of encryption, access control, or authentication mechanisms when systems are restored from backup or failover to alternate infrastructure
Unauthorized access to production systems due to weakened security controls during disaster recovery operations or use of temporary facilities
Data loss or corruption exceeding acceptable RPO thresholds because backup integrity and restore procedures were never tested under realistic conditions
Prolonged outages exceeding RTO commitments due to undiscovered incompatibilities between primary and standby ICT environments
Inadequate logging or monitoring during continuity events, preventing detection of malicious activity or insider threats during crisis response
Business continuity plans that fail in real incidents because testing was performed only in isolated labs without realistic load, network conditions, or dependencies
Compliance violations or contractual breaches arising from inability to maintain required security posture during disruption recovery phases

Testing procedure

How an auditor verifies this control

Obtain the current business continuity plan (BCP) and disaster recovery plan (DRP), identifying all ICT systems, alternate processing sites, and recovery procedures in scope.
Review the organization's BCP/DRP testing schedule and retrieve documentation of the three most recent tests, including tabletop exercises, failover simulations, and full DR invocations.
For each documented test, verify that information security controls were explicitly included in test objectives and success criteria, not limited to availability alone.
Select one recent ICT continuity test and examine logs, screenshots, or recorded outputs demonstrating that authentication, encryption-in-transit, access controls, and audit logging functioned correctly in the alternate or restored environment.
Interview business continuity and IT recovery personnel to confirm security responsibilities during activation, including incident response coordination, privileged access management, and security monitoring during recovery operations.
Compare the tested recovery time and recovery point against documented RTO/RPO targets to verify that security validation steps did not prevent meeting recovery objectives.
Review test after-action reports or lessons-learned documents to confirm that any security-related issues discovered during testing were logged as corrective actions and tracked to closure.
Verify that test results have been communicated to senior management and that security findings influenced updates to continuity plans, security architectures, or control configurations.

Evidence required The auditor collects business continuity and disaster recovery plans with testing schedules; test execution reports, tabletop exercise agendas, and failover logs from the past twelve months showing security controls were in scope; system logs, authentication records, or monitoring dashboards captured during test windows proving security functionality; and corrective action registers or change tickets demonstrating remediation of security gaps identified in tests.

Pass criteria The control passes if the organization conducts documented ICT business continuity tests at least annually, those tests explicitly validate the continued operation of key information security controls during recovery scenarios, and test findings trigger remediation actions that are tracked to closure.