The ultimate audit guide to ISO 27001 Annex A 5.30 ICT readiness for business continuity – new
Table of contents
- 1. ICT Business Continuity Strategy Alignment Verified
- 2. ICT Continuity Plan Formalisation Confirmed
- 3. ICT Recovery Team Roles and Authorities Validated
- 4. ICT Resource Redundancy and Capacity Verified
- 5. ICT Continuity Plan Testing Records Present
- 6. Data Backup and Restoration Integrity Validated
- 7. ICT Supply Chain Continuity Evidence Confirmed
- 8. Emergency Operating Mode Security Controls Verified
- 9. ICT Continuity Competence and Awareness Confirmed
- 10. Post-disruption Performance and Review Records Verified
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.
About the author
