Auditing ISO 27001 Annex A 5.30 is the technical verification of an organization’s resilient infrastructure to ensure continuous operations during crises. The Primary Implementation Requirement is the rigorous testing of failover mechanisms, which yields the Business Benefit of maintained service integrity and regulatory compliance.
This technical verification tool is designed for lead auditors to confirm the readiness and redundancy of information processing facilities. Use this checklist to validate compliance with ISO 27001 Annex A 5.30 (ICT readiness for business continuity).
1. ICT Business Continuity Strategy Alignment Verified
Verification Criteria: The ICT continuity strategy is explicitly derived from business continuity requirements and prioritises systems based on a formal Business Impact Analysis (BIA).
Required Evidence: Business Impact Analysis (BIA) report showing Maximum Tolerable Period of Disruption (MTPD) for ICT services.
Pass/Fail Test: If the ICT recovery priorities are not aligned with the RTOs (Recovery Time Objectives) defined in the business-level BIA, mark as Non-Compliant.
2. ICT Continuity Plan Formalisation Confirmed
Verification Criteria: Documented ICT continuity plans exist that detail the specific technical steps required to restore information processing facilities during a disruption.
Required Evidence: Approved ICT Continuity Plan (ICTCP) or Disaster Recovery Plan (DRP) with current version control and owner sign-off.
Pass/Fail Test: If the plan describes generic goals but lacks step-by-step technical restoration procedures for specific server/cloud environments, mark as Non-Compliant.
3. ICT Recovery Team Roles and Authorities Validated
Verification Criteria: Specific technical personnel are appointed to the recovery team, with defined authorities to activate failover systems and manage emergency configurations.
Required Evidence: ICT Recovery Team structure, contact directory, and “Emergency Authority” delegation memos.
Pass/Fail Test: If the organisation cannot identify a specific technical lead with the authority to trigger a site failover without board-level approval during a crisis, mark as Non-Compliant.
4. ICT Resource Redundancy and Capacity Verified
Verification Criteria: Sufficient technical resources (e.g. secondary data centres, cloud instances, bandwidth) are provisioned to meet the defined recovery objectives.
Required Evidence: Infrastructure architecture diagrams showing secondary sites or High Availability (HA) configurations across distinct geographic regions.
Pass/Fail Test: If critical ICT services lack a secondary, independent infrastructure path (Single Point of Failure), mark as Non-Compliant.
5. ICT Continuity Plan Testing Records Present
Verification Criteria: The ICT continuity plans are tested at planned intervals (at least annually) or upon significant changes to the technical environment.
Required Evidence: Post-test reports from a recent technical failover drill, including a log of successful and unsuccessful recovery actions.
Pass/Fail Test: If the organisation has not conducted a technical failover or data restoration test within the last 12 months, mark as Non-Compliant.
6. Data Backup and Restoration Integrity Validated
Verification Criteria: Backup data is stored in a location physically or logically separated from the primary site and is subjected to regular restoration testing.
Required Evidence: Backup success logs and restoration test receipts confirming that data is recoverable and intact.
Pass/Fail Test: If backups are stored in the same physical rack or the same cloud account without “Immutable” locks or air-gapping, mark as Non-Compliant.
7. ICT Supply Chain Continuity Evidence Confirmed
Verification Criteria: Critical ICT suppliers and managed service providers have demonstrated their own readiness to support the organisation during a disruption.
Required Evidence: Supplier BC/DR attestation letters, SOC 2 Type II reports, or results of joint continuity exercises with the vendor.
Pass/Fail Test: If a critical SaaS/IaaS provider does not have a contractually guaranteed RTO/RPO aligned with the organisation’s requirements, mark as Non-Compliant.
8. Emergency Operating Mode Security Controls Verified
Verification Criteria: Security controls (e.g. logging, MFA, encryption) remain active or are replaced by equivalent measures when ICT systems are in recovery/failover mode.
Required Evidence: Security configuration documentation for the DR site and logs from the SIEM showing ingestion from failover systems.
Pass/Fail Test: If security protocols (like MFA or Firewall inspection) are disabled to “speed up” the recovery process without a recorded risk waiver, mark as Non-Compliant.
9. ICT Continuity Competence and Awareness Confirmed
Verification Criteria: Technical staff are trained in their recovery roles, and general staff are aware of the temporary procedures for accessing ICT services during disruption.
Required Evidence: Training records for the ICT Recovery Team and evidence of general “Security Continuity” awareness briefings for staff.
Pass/Fail Test: If the primary technical responder for a critical system is unaware of their specific role in the Disaster Recovery Plan, mark as Non-Compliant.
10. Post-disruption Performance and Review Records Verified
Verification Criteria: Following any continuity test or actual event, a formal review is conducted to identify and address deficiencies in ICT readiness.
Required Evidence: After-Action Reports (AAR) and a tracked Corrective Action Plan (CAP) showing remediation of failed recovery steps.
Pass/Fail Test: If the most recent continuity test identified a failure that has not been added to a tracked remediation log, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| BIA Alignment | GRC tool shows a “Green Tick” because a BIA document was uploaded. | An auditor must verify that the Technical RTO in the system settings actually matches the Business RTO in the PDF. |
| Failover Verification | Tool records that “Cloud Failover” is enabled in the cloud console. | Verify a manual test. Auto-failover often fails due to DNS propagation delays or expired SSL certificates at the DR site. |
| Supplier Readiness | SaaS tool verifies the vendor has an ISO 27001 certificate. | A generic ISO certificate does not guarantee a specific RTO. Demand the SLA or SOC 2 report covering availability. |
| Recovery Capacity | Tool checks if a “Recovery Site” is defined. | Verify Resource Contention. If a cloud region goes down, can the organisation actually provision the required nodes in the secondary region? |
| Backup Integrity | Platform reports “100% Backup Success” via API. | Verify Restoration. A success log for an “upload” does not prove the data is readable. Demand a signed restore-test log. |
| Security During Crisis | Tool assumes production security policies apply to DR. | Check the DR Firewall. Often, DR sites have laxer rules to ensure connectivity, creating a massive security hole during a crisis. |
| Role Accountability | Tool lists the “CISO” as the recovery lead. | Verify Depth. If the CISO is unavailable, does the plan name a technical deputy who has the administrative keys to the DR vault? |
About the author
