ICT readiness for business continuity
Purpose
Plan, implement, maintain and test ICT readiness so technology can support business continuity objectives.
How to meet this control
In short: Plan, implement, maintain and test ICT readiness based on continuity objectives.
- Step 01Derive ICT continuity requirements from a business impact analysis and set RTO and RPO per critical system
- Step 02Select continuity strategies covering before, during and after disruption (redundancy, backups, failover)
- Step 03Document ICT continuity plans specifying recovery procedures for each prioritised service
- Step 04Have management approve the plans and ensure the recovery team has the right authority and competence
- Step 05Test ICT recovery at least annually through exercises and record the results and improvements
Tip: Define RTO/RPO per critical system and test recovery at least annually.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Derive ICT continuity requirements from the business impact analysis
- ›Use the BIA to assign recovery time objectives to prioritised activities and supporting resources
- ›Define performance and capacity needs plus recovery point objectives for the information involved
- ›Select ICT continuity strategies covering before, during and after disruption
- ›Ensure an adequate organisational structure with the right authority and competence is in place
- ›Have management approve ICT continuity plans and test them regularly through exercises
- ›Document continuity plans that specify RTOs, RPOs and procedures for restoring each prioritised ICT service
Audit evidence to keep
- - Business impact analysis defining RTO and RPO for critical systems
- - Documented ICT continuity and recovery plans per prioritised service
- - Management approval of the ICT continuity plans
- - Recovery test or DR exercise records with outcomes and remediation
Common mistakes
- - Testing that backups exist but not that restore works
- - Setting recovery targets that the architecture cannot meet
- - Leaving backup access wider than production access
Owner, cadence, and proof
Assign one accountable owner for A.5.30. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.