ICT Continuity Within ISO 22301
ISO 22301 Clause 8.3 requires you to identify critical ICT services that support critical business activities and ensure they have continuity arrangements. ICT continuity is a subset of business continuity—necessary but not sufficient. Recovering all your systems does not mean you have recovered your business. Recovery must also address people, premises, suppliers, and processes.
ISO 27031 Overview
ISO 27031:2011 (Information and Communication Technology—Security for Business Continuity) provides the technical framework for ICT continuity planning. It introduces the IRBC (ICT Readiness for Business Continuity) concept and provides guidance on assessing and improving ICT recovery capability. While ISO 22301 defines the business requirements (what RTO and RPO you need), ISO 27031 defines the technical approaches (how to achieve them). Organizations certifying to ISO 22301 often use ISO 27031 as the technical reference for their ICT continuity plans.
ICT Continuity vs. Disaster Recovery
While the terms are sometimes used interchangeably, they have distinct purposes:
| Dimension | ICT Continuity (ISO 22301/27031) | Disaster Recovery (Traditional IT) |
|---|---|---|
| Scope | Business-critical ICT services | All IT infrastructure |
| Driver | BIA-derived RTO/RPO for critical activities | IT risk assessment |
| Documentation | ICT continuity plans linked to BCPs | DR runbooks |
| Testing | Exercise program aligned with BCM exercises | Annual DR test |
| Governance | BCMS management review | IT operations review |
Building the ICT Continuity Plan
Start by identifying which ICT services support critical business activities (from the BIA). Document each service's function, dependencies (databases, networks, third-party providers), and criticality. Derive RTO and RPO targets from the BIA. If a critical activity must resume within 4 hours, the supporting systems must be recovered within 4 hours. Design recovery procedures: backup restoration, system failover, data synchronization, and communication resumption. Document the recovery procedures step-by-step with sufficient detail that a qualified IT person could execute them under pressure without additional research.
Backup and Recovery Architecture
Backup frequency must align with your RPO (Recovery Point Objective). If you can tolerate losing one day of data, daily backup is sufficient. If you can tolerate losing one hour, you need hourly backup. Test backup integrity monthly—not just backing up, but actually restoring from backup and verifying that the restored data is complete and usable. Cloud backup adds complexity (data residency requirements in Indonesia, vendor lock-in risk) but offers geographic redundancy that on-premises backup cannot match. Document the backup strategy explicitly in the ICT continuity plan.
RTO Achievement for Technology-Dependent Activities
There is often a substantial gap between documented RTO and actual recovery capability. A business continuity plan that says "systems will be recovered within 4 hours" means nothing if the recovery architecture requires 12 hours. Test RTO achievement in exercises. Recovery time depends on multiple factors: time to detect the disruption, time to declare activation, time to execute recovery procedures, time to restore data, time to validate data integrity. A common gap: procedures are documented, but staff are unfamiliar with them, or critical recovery tools are not accessible, or documentation is incomplete.
ICT Continuity Testing
Different test types validate different aspects of your recovery capability:
| Test Type | Description | Frequency | RTO Validation |
|---|---|---|---|
| Backup Restoration Test | Restore data from backup and verify integrity | Monthly | No (data only) |
| Component Failover Test | Fail a single component and verify failover | Quarterly | Partial |
| Application Recovery Test | Restore full application stack to DR environment | Semi-annual | Yes |
| Full DR Failover | Complete failover to DR site including network | Annual | Yes |
| Cloud Provider Resilience Review | Assess cloud SLA and test recovery procedures | Annual | Partial |
| KEY IDEA | ICT recovery is a necessary component of business continuity, but recovering your systems does not mean you have recovered your business. The BCP must address people, premises, suppliers, and processes, not just technology. |
| IMPORTANT | RTO targets documented in your BIA must be achievable by your ICT recovery capability. If your BIA says a critical system must be recovered within 4 hours but your DR architecture requires 12 hours, you have a gap that must be addressed—not just documented. |
| BITLION INSIGHT | Indonesian organizations using Indonesian data center providers should verify that their providers' BCM programs align with their own RTO/RPO requirements. BSSN guidelines for critical infrastructure operators include specific requirements for data center resilience and ICT continuity that may exceed minimum ISO 22301 requirements. |