"Business continuity" and "disaster recovery" get used interchangeably in casual conversation, in vendor marketing, and unfortunately sometimes in programme documents. They are not the same thing. The distinction is operationally meaningful: it determines who owns the programme, what artefacts it produces, and what scenarios it covers. This article walks through the difference and the integration pattern that actually works.
The parent topic is our crisis management playbook.
The basic distinction
Disaster Recovery (DR) is about restoring IT systems and infrastructure after a technical failure. Its scope is technology: servers, networks, databases, applications, the data centre. Its objectives are technical (RTO, RPO at the system level). Its owner is typically the CIO or Head of Infrastructure. Its main artefact is the DR runbook — a step-by-step procedure for restoring a specific system, usually in a specific failover sequence.
Business Continuity Management (BCM) is about keeping the business running during any kind of disruption. Its scope is the whole business process: people, location, vendors, processes, data, and IT. Its objectives are business outcomes (MTPD at the process level, customer impact, regulatory standing). Its owner is typically the CRO or a dedicated BCM lead. Its main artefacts are the BIA, the BCP and the exercise programme — all framed around business processes, not systems.
DR is a subset of BCM. Every well-designed BCP references the relevant DR runbooks; the DR plan tells the BCP "here is how IT recovers when its piece fails." But BCM covers many scenarios where IT is not the failure point — a key vendor going bankrupt, a regional weather event, a regulatory shutdown, a critical staff cohort being unavailable. DR has nothing to say about those scenarios; BCM does.
Concrete examples
Scenario 1: Database server fails. IT-DR territory. The runbook says: fail over to the replica, restore writes, validate data integrity, return to primary when fixed. BCM exists in the background — if the failover takes longer than the BCP's RTO, the process owner needs to invoke degraded-mode operation. But the recovery itself is DR work.
Scenario 2: Key payment-processing vendor has a major outage. BCM territory. There is no IT to restore — the IT is the vendor's, not yours. The BCP's role is to invoke the manual workaround (e.g. fallback to a secondary processor, increased manual review), notify customers, manage the regulatory reporting, and coordinate the response across operations, comms and compliance. DR has nothing to say here.
Scenario 3: Regional power outage affecting the primary data centre. Joint territory. DR runbooks fail over IT systems to the secondary site. BCPs cover the business-level response — branch staff working from home, call centre redirected, customer communications, treasury/liquidity actions. Both must run in parallel and reference each other.
Scenario 4: Ransomware encrypts production systems. Joint and cyber-incident-response territory. DR is critical (clean-room recovery, data restoration from immutable backups). BCM is critical (extended manual operations, regulatory notifications, customer communications, potential ransom-payment decisions). Cyber-incident response is critical (forensics, containment, root-cause analysis).
In modern incidents, the most-damaging events are rarely pure DR. They involve cyber, vendor concentration, regulatory exposure and customer impact simultaneously. A programme built only on DR foundations cannot respond.
Where the confusion comes from
Several reasons the terminology blurs:
Historical. Twenty years ago, BCM in many organisations effectively was DR. The internal customer was IT. The "business" side of continuity was a thin wrapper around "is the data centre running?" Organisations that haven't modernised their programme structure since may still operate this way.
Vendor language. Some platform vendors market DR products as "business continuity" because BCM sells better than DR. The product still focuses on technical failover, regardless of the labelling.
Audit and regulator language. Some regulatory frameworks use "business continuity" to mean "you must have a DR programme" and don't distinguish further. Mature regulators (SAMA, FCA, MAS) explicitly distinguish.
Programme reporting. When a CIO reports BCM status to the board and the report is dominated by data-centre failover testing, the implicit framing is DR-as-BCM. The board should expect coverage of business-level scenarios as well.
The integration pattern
A working programme has both BCM and DR, and they reference each other explicitly.
BCM produces the BIA, the BCPs and the exercise programme. The BCPs are organised by business process. Each BCP names the DR plans it depends on.
DR produces the IT-DR runbooks. The runbooks are organised by system. Each runbook references its target RTO and RPO, which derive from the BIAs of the business processes that use the system.
The two artefact sets share data. The system inventory feeds both the BIA dependency map and the DR runbook catalogue. The RTO/RPO commitments flow from BIA → BCP → DR runbook. The exercise programme covers both BCM scenarios and DR-failover tests.
The two functions report jointly. The CIO owns DR; the CRO owns BCM. Both report to the BCM committee on different aspects of the same resilience surface. Conflict between them — which is to be expected — surfaces explicitly rather than being hidden inside one combined function.
In SAMA and ISO 22301 contexts
ISO 22301 explicitly addresses BCM as a management system covering all kinds of disruption. IT-DR is not separately certified under ISO 22301 — it sits inside the BCM scope as one of the recovery strategies the BCMS coordinates. SAMA likewise treats BCM as the umbrella programme and IT-DR as an integrated component. See the ISO 22301 implementation pillar for the standard's scope and the SAMA BCM Framework pillar for the regulatory context.
ISO 27031 (Information and Communication Technology Readiness for Business Continuity) is the standard most directly aligned with IT-DR. It is non-certifiable and complements ISO 22301 — most organisations that pursue ISO 22301 also informally align IT-DR with ISO 27031.
Where to start
If you have a DR programme but not a coherent BCM programme:
- Read the BIA pillar guide. Run BIA workshops on your top critical processes. Notice how often the dependencies are non-IT.
- Build BCPs for each critical process. Reference your existing DR runbooks as components, not as the plan itself.
- Expand the exercise programme to cover non-IT scenarios — vendor failure, key-person unavailability, regulatory event, regional disruption.
- Bring DR into the BCM governance structure rather than running it separately.
If you have a BCM programme but it never references DR specifically:
- Inventory the IT systems that critical BCPs depend on.
- For each, link the BCP to the relevant DR runbook explicitly.
- Cross-validate RTO/RPO commitments — does the DR capability actually support the BCP's commitment?
- Run a joint BCM/DR exercise.
The two functions work best in tension. DR thinks "how do we restore?" BCM thinks "how do we continue?" Both questions matter. Neither answers the other.
For the broader crisis-management context, return to the crisis management playbook.