Auditing ISO 27001 Annex A 5.29 is a technical evaluation of an organization’s capability to maintain information security continuity during adverse situations. The Primary Implementation Requirement mandates that security controls remain operational during disruptions, providing the Business Benefit of resilient protection against opportunistic cyber-attacks during crises.
This technical verification tool is designed for lead auditors to establish whether information security remains robust throughout periods of operational instability. Use this checklist to validate compliance with ISO 27001 Annex A 5.29 (Information security during disruption) by ensuring security controls are not bypassed during business continuity events.
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.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| BC/DR Security Integration | SaaS tool confirms a “Business Continuity Plan” file is uploaded to the repository. | Auditor must read the plan to verify it covers CIA (Confidentiality, Integrity, Availability), not just Uptime. |
| Security Drills | Tool identifies a “Test Completed” flag from the previous year. | Verify the scope of the test; did it specifically stress-test security controls under load? |
| Emergency Access | GRC tool identifies “VPN” as an active asset and marks it as compliant. | Verify that the “Emergency VPN” used for continuity has the same MFA requirements as the production VPN. |
| Third-party Resilience | Tool stores a vendor’s ISO 22301 (BCM) certificate. | The auditor must verify the Statement of Applicability to ensure security is within the vendor’s continuity scope. |
| Security Logging | Platform assumes logging works because the SIEM is “Connected.” | Verify log ingestion during high-stress periods or simulated outages. |
| Restoration Integrity | Tool records that “Backups were successful” via an API. | Verify the security scan of the restored data. Backing up a virus means you will restore a virus. |
| Post-Crisis Learning | The GRC tool provides a generic “Lessons Learned” template. | Verify actual changes to the ISMS. If no policies changed after an outage, no learning occurred. |
About the author
