How continuity and disaster recovery fit together: ISO 22301, business impact analysis, RTO and RPO, ransomware-resistant backups and plan testing.
Business continuity is the ability of an organisation to keep delivering its critical activities during and after a disruption, while disaster recovery is the technical subset that restores IT systems and data. Both rely on the same foundation: knowing which activities matter most, how long they can be interrupted, and how much data loss is acceptable. This article explains the concepts, the reference standards and the steps to build a plan that actually works on the day it is needed.
Business continuity management (BCM) takes an organisation-wide view. It covers people, premises, suppliers, communication and processes, and asks how the organisation will continue to serve customers if a site is unavailable, a key supplier fails or a cyberattack paralyses its systems.
Disaster recovery (DR) focuses on information systems. It defines how servers, applications, networks and data will be restored, in what order and within which time frame. A DR plan without a continuity strategy often restores systems in the wrong order; a continuity plan without a tested DR capability remains a document with no technical backing.
Two references are widely used:
Sector regulations increasingly require these capabilities. In the European Union, the NIS 2 Directive lists business continuity, backup management and disaster recovery among the cybersecurity risk-management measures, and the DORA regulation sets detailed ICT continuity requirements for financial entities.
The business impact analysis (BIA) is the core of any continuity programme. For each critical activity, it identifies the consequences of an interruption over time and the resources the activity depends on. It produces a few key parameters:
The BIA must be validated by business owners, not only by IT. Otherwise, technical teams end up guessing priorities.
Once objectives are set, the organisation selects strategies that meet them at an acceptable cost. Common options include:
Ransomware deserves specific attention. An attacker who compromises administrator accounts can delete or encrypt online backups. Isolating backup infrastructure, protecting it with separate credentials and multi-factor authentication, and regularly testing restoration are now baseline measures.
Plans should be short, role-based and accessible even when normal systems are down. A typical set includes a crisis management plan for decision-makers, business continuity plans for each critical activity, and technical recovery procedures for IT. Each plan should state who activates it, who does what, how to communicate internally and externally, and how to return to normal operations.
Contact lists, network diagrams and recovery procedures must be available offline or on an independent platform. A plan stored only on the file server that has just been encrypted is of little use.
A plan that has never been tested is an assumption. ISO 22301 requires an exercise programme, which usually progresses from tabletop discussions to technical restoration tests and, for mature organisations, full failover exercises. Each exercise should produce findings, corrective actions and updates to the plans. Changes in the IT environment, such as a cloud migration or a new ERP system, should trigger a review of the BIA and the recovery procedures.
Building and auditing a continuity programme requires specific methods. The PECB ISO 22301 Lead Implementer training covers the design and operation of a BCMS, while the ISO 22301 Lead Auditor training prepares professionals to assess one. For teams that handle the technical side of recovery after a cyber incident, the E|CIH incident handler training addresses incident response and recovery procedures.
Effective continuity starts with a business impact analysis owned by the business, continues with recovery strategies sized to realistic RTO and RPO values, and is proven through regular exercises. Aligning this work with ISO 22301 and, where relevant, NIS 2 or DORA gives the programme a clear structure and makes it auditable.