A.5.30
ICT readiness for business continuity
Organizational controlsCheckpoints 6Evidence 7Cases 7
Control objective
ICT readiness for business continuity is the control for planning, implementing, maintaining, and testing the continuity and recovery capability of ICT services so that the organization can meet its predefined business continuity objectives. Based on business impact analysis (BIA) and risk assessment, it requires the organization to derive the recovery requirements (recovery time objective, recovery point objective, minimum service level) for the ICT services that support critical activities, and to put in place recovery strategies, configurations, and procedures that satisfy them. The aim is to keep ICT in a constant state of readiness and to verify it regularly, so that ICT can be restored quickly to the agreed level even during a disaster or disruption.
Key checkpoints
- Does the business impact analysis (BIA) identify critical activities and the ICT services that support them, with a recovery time objective (RTO) and recovery point objective (RPO) defined for each service?
- Are ICT continuity/recovery strategies (redundancy, backup, alternate processing facilities, cloud-based recovery, and so on) established to meet the defined RTO/RPO, with the necessary resources secured?
- Are ICT recovery procedures (fault detection, invocation criteria, recovery stages and priorities, roles/responsibilities, emergency contacts) documented and kept up to date?
- Are the ICT continuity/recovery plans tested regularly and after significant changes, with results evaluated against RTO/RPO achievement and fed into improvement?
- Are the backups, configuration information, documents, licenses, and access means needed for recovery protected and stored so that they remain usable during a disaster?
- Is ICT readiness aligned and integrated with the organization's business continuity management (BCM) and its incident/crisis management arrangements?
Implementation guidance
- Based on the BIA and risk assessment results, quantitatively define RTO/RPO/minimum service level for each critical ICT service, and confirm them as recovery targets with management approval.
- Select recovery strategies that meet the targets (system redundancy/clustering, geographically separated alternate processing facilities, data backup and offsite storage, cloud-based recovery, manual workarounds, and so on), and apply them differentially by service criticality with cost and risk in mind.
- Document the ICT continuity/recovery plan to include fault/disaster detection and invocation criteria, recovery priorities and stage-by-stage procedures, roles and responsibilities, emergency contact lists, coordination with external suppliers/telecom/cloud providers, and the procedure for returning to normal operation after recovery.
- Store the backups, system configuration/images, network diagrams, operational documents, software licenses, and credentials/access means essential to recovery in a separate secure location, and periodically verify their integrity and recoverability.
- Combine reviews, tabletop exercises, and restore/failover tests periodically and after significant changes. Use tabletop exercises to check roles and procedures; verify RTO/RPO achievement by measuring elapsed time and recovered data points in representative restore/failover tests. Record coverage limits and improvement actions.
- Secure the availability of recovery resources such as people, skills, facilities, and external contracts, and, by training staff and designating backup personnel, ensure recovery is possible even when specific individuals are absent.
- Integrate the ICT readiness plan with the organization's business continuity management system and incident/crisis management procedures, and update them together whenever changes occur to keep them consistent.
Evidence
- Business impact analysis (BIA) results and the RTO/RPO definition for each critical ICT service
- ICT continuity/recovery strategy document and architecture diagrams (redundancy, alternate processing facilities, backup architecture, and so on)
- ICT disaster recovery plan (DRP)/recovery procedures (including invocation criteria, recovery stages, roles/responsibilities, emergency contact lists)
- Recovery test plan and test result reports (RTO/RPO achievement, identified gaps, and improvement follow-up)
- Records of offsite storage of backups and configuration/documents, and recoverability verification (restore testing)
- Recovery-related training/exercise history and the designation of primary/backup personnel
- Recovery-related contracts/SLAs with external suppliers/telecom/cloud providers
Nonconformity examples
- ICT recovery targets (RTO/RPO) are not defined because no BIA was performed, so there is no basis for recovery priorities or resource allocation.
- A disaster recovery strategy/plan exists but is outdated and inconsistent with the current infrastructure/configuration, with no update history.
- Backups are performed but restore testing has never been done, so recoverability in an actual disaster is unverified.
- After the recovery plan was established, no periodic test or post-significant-change test is performed at all.
- Configuration information, documents, licenses, and access means needed for recovery exist only at the primary site, so they are inaccessible during a disaster.
- Recovery procedures depend on specific individuals, with no backup personnel or training, so recovery is impossible when the owner is absent.
- RTO/RPO shortfalls were identified in testing but were left unaddressed rather than managed as improvement items.