The ultimate audit guide to ISO 27001 Annex A 5.29 Information security during disruption – change
Table of contents
- 1. Information Security Requirements in BC/DR Plans Verified
- 2. Crisis Management Security Roles and Authorities Confirmed
- 3. Security Control Implementation During Disruption Validated
- 4. Emergency Remote Access Security Integrity Verified
- 5. Information Security Continuity Drill Evidence Identified
- 6. Secure Recovery and Restoration Procedures Present
- 7. Evidence of Security Incident Logging During Crisis Confirmed
- 8. Critical Third-party Continuity Security Alignment Verified
- 9. Maintenance of Physical Security During Recovery Confirmed
- 10. Post-Disruption Security Review and Improvement Validated
1. Information Security Requirements in BC/DR Plans Verified
Verification Criteria: Business Continuity (BC) and Disaster Recovery (DR) plans must explicitly include information security requirements that remain applicable during a disruption.
Required Evidence: Approved BC/DR plans containing a dedicated section for “Information Security Maintenance” or “Security during Crisis.”
Pass/Fail Test: If the BC/DR plans focus solely on system availability and omit requirements for confidentiality and integrity during a crisis, mark as Non-Compliant.
2. Crisis Management Security Roles and Authorities Confirmed
Verification Criteria: Personnel responsible for maintaining security during a disruption are formally identified, with clear authorities to enforce security protocols under emergency conditions.
Required Evidence: Crisis Management Team (CMT) structure or RACI matrix specifying security-specific roles during a BC event.
Pass/Fail Test: If the organisation cannot identify a specific individual with the authority to veto an insecure “emergency” workaround, mark as Non-Compliant.
3. Security Control Implementation During Disruption Validated
Verification Criteria: Existing security controls (e.g., access control, encryption, logging) are maintained or replaced by equally effective compensatory controls during the disruption.
Required Evidence: Technical configuration standards for “Emergency Operating Mode” or logs showing active security monitoring during a previous drill.
Pass/Fail Test: If security controls (such as MFA or firewall rules) are intentionally disabled to facilitate faster recovery without a formal risk waiver, mark as Non-Compliant.
4. Emergency Remote Access Security Integrity Verified
Verification Criteria: Technical solutions for emergency remote access or “work from home” scenarios during a disruption are pre-vetted and secured to the same standard as normal operations.
Required Evidence: Provisioning records for emergency VPNs or secure remote desktop gateways used during continuity events.
Pass/Fail Test: If staff are permitted to use unmanaged personal devices or unencrypted connections for recovery tasks without prior security authorisation, mark as Non-Compliant.
5. Information Security Continuity Drill Evidence Identified
Verification Criteria: The organisation must conduct periodic tests of its security continuity capabilities to ensure they function as intended during a real event.
Required Evidence: Tabletop exercise records or functional drill reports that include a “Security Impact” or “Security Performance” assessment score.
Pass/Fail Test: If the organisation has performed BC/DR tests but failed to document or test the security aspects of the recovery, mark as Non-Compliant.
6. Secure Recovery and Restoration Procedures Present
Verification Criteria: Procedures for restoring systems to a stable state include mandatory security verification steps, such as integrity checks and vulnerability assessments.
Required Evidence: Step-by-step restoration playbooks containing “Security Validation” gates before systems are returned to production.
Pass/Fail Test: If systems are restored from backups without a recorded verification that the restored data is free from the malware that may have caused the disruption, mark as Non-Compliant.
7. Evidence of Security Incident Logging During Crisis Confirmed
Verification Criteria: The ability to detect and log security events is maintained throughout the disruption to prevent attackers from exploiting the chaos.
Required Evidence: SIEM (Security Information and Event Management) logs or manual event logs covering the duration of a recent continuity exercise.
Pass/Fail Test: If central logging is suspended during a recovery phase to “save bandwidth” or “reduce complexity,” mark as Non-Compliant.
8. Critical Third-party Continuity Security Alignment Verified
Verification Criteria: Key suppliers and cloud providers must demonstrate their ability to maintain security standards for the services they provide during their own disruptions.
Required Evidence: Supplier SOC2 reports or “Right to Audit” logs showing a review of the supplier’s continuity security capabilities.
Pass/Fail Test: If a critical SaaS vendor has no documented security continuity commitment in their Service Level Agreement (SLA), mark as Non-Compliant.
9. Maintenance of Physical Security During Recovery Confirmed
Verification Criteria: Physical access controls at primary and secondary recovery sites are maintained to prevent unauthorised entry during the recovery process.
Required Evidence: Visitor logs for the secondary recovery site or physical security audit records for the “Warm” or “Cold” site.
Pass/Fail Test: If recovery sites are found to have weaker physical access controls (e.g., shared keys or no CCTV) than the primary site, mark as Non-Compliant.
10. Post-Disruption Security Review and Improvement Validated
Verification Criteria: Following a disruption or drill, a review is conducted specifically to identify and remediate security weaknesses discovered during the event.
Required Evidence: After-Action Reports (AAR) with a dedicated “Security Lessons Learned” section and tracked corrective actions.
Pass/Fail Test: If the organisation fails to document a security post-mortem following an operational outage, mark as Non-Compliant.
About the author
