Disaster Recovery vs Business Continuity Planning: What CISM Candidates Need to Know

What Is Business Continuity Planning (BCP)?

Business continuity planning is an organization-wide discipline that answers one question: if a disruption happens, whether that is a hurricane, a pandemic, a key vendor failure, or a prolonged power outage, how does the business keep its most critical functions operating at an acceptable level?

BCP is not an IT function. It covers people, facilities, suppliers, communications, and process, in addition to technology. A well-built BCP typically includes:

• A business impact analysis (BIA) that identifies which processes are critical and how quickly each one must be restored. If you have not read it yet, our Business Impact Analysis guide covers the full BIA methodology in depth.
• Continuity strategies for people (remote work, alternate staffing, succession plans), facilities (alternate work sites), and suppliers (backup vendors, contractual continuity clauses).
• Crisis communication plans for employees, customers, regulators, and the media.
• An incident command structure defining who declares a disruption, who leads the response, and how decisions get made under pressure.
• A dependency on IT recovery, which is where disaster recovery comes in. Almost no modern business function can continue without its underlying systems, so the BCP explicitly relies on the DR plan to restore the technology layer.

Ownership of BCP typically sits with a business continuity manager, a risk or resilience function, or in smaller organizations, the CISO or security manager wearing multiple hats. ISACA and most standards bodies treat it as a governance responsibility, not a purely technical one.

What Is Disaster Recovery (DR)?

Disaster recovery is the technical plan for restoring IT infrastructure, applications, and data after an outage, whether that outage is caused by a natural disaster, a hardware failure, a ransomware attack, or human error. DR is owned by IT and infrastructure teams, and it is almost always scoped as a subset of the broader BCP.

A DR plan typically covers:

• Recovery site strategy: hot site, warm site, cold site, or cloud-based failover, each with a different cost and recovery-speed tradeoff.
• Backup and replication architecture: how often data is backed up or replicated, and where.
• System and application recovery sequencing: which systems come back first, based on dependency mapping and business priority.
• Failover and failback procedures: the technical runbooks for switching to a recovery environment and later switching back to primary systems.
• DR testing: tabletop exercises, partial failover tests, and full failover tests conducted on a regular cadence.

Key Differences Between DR and BCP

The relationship is hierarchical, not parallel. DR sits inside BCP as one of its supporting plans, alongside crisis communication plans, facility continuity plans, and supply chain continuity plans. A mature continuity program treats the DR plan as one deliverable among several, not as a replacement for the BCP itself.

RTO, RPO, MTD, and WRT: The Metrics That Tie Them Together

Both disciplines share a common vocabulary of recovery metrics, and the exam expects you to distinguish them precisely. These metrics are derived during the BIA and then used to design the DR plan's technical targets.

A useful way to see how these fit together: MTD ≥ RTO + WRT. The maximum tolerable downtime for a business process must be greater than or equal to the time it takes IT to restore the system plus the time staff need to fully resume work. If RTO plus WRT exceeds MTD, the DR plan does not actually meet the business requirement, even if the technology recovery itself succeeds. This is a frequent scenario-based exam trap: a plan can look technically sound while still failing the business.

RPO, by contrast, is entirely about data loss tolerance and directly drives backup and replication architecture decisions. A near-zero RPO requirement (common in banking and healthcare transaction systems) forces synchronous replication and a hot site; a 24-hour RPO tolerance allows nightly backups to a cold site at far lower cost. For a deeper walkthrough of how these figures get derived during the BIA process itself, see our Business Impact Analysis (BIA) guide.

How DR and BCP Fit Together in Practice

Consider a mid-sized regional bank that loses its primary data center to a flood:

1. The BCP activates first. The crisis management team declares an incident, activates the incident command structure, and communicates with regulators, customers, and staff per the crisis communication plan.
2. Alternate facilities and staffing kick in. Branch staff shift to a business continuity site or work remotely per the facility continuity plan. This is BCP scope, not DR scope.
3. The DR plan executes in parallel. IT fails core banking systems over to the warm site, restores the transaction database to its last replicated point (meeting the defined RPO), and brings applications back online within the agreed RTO.
4. WRT closes the gap. Once systems are up, operations staff reconcile any transactions that were in flight during the failover before declaring the branch network fully operational.
5. The BCP governs the overall recovery timeline. Even after IT systems are restored, the business continuity plan continues to manage the broader recovery, including customer communication, regulatory reporting, and eventually failback to the primary data center.

Notice that the DR plan is a critical dependency of the BCP, but it is executed by a different team, measured against different targets, and does not by itself constitute a complete response. This layered relationship, where DR is necessary but not sufficient for full business continuity, is exactly what CISM scenario questions are built to test.

How ISACA Tests This in CISM Domain 4

Disaster recovery and business continuity planning fall under CISM Domain 4: Information Security Incident Management, which represents roughly 30% of the exam. ISACA does not test DR and BCP as an isolated topic; instead, it weaves them into broader incident management scenarios alongside the BIA, incident response procedures, and post-incident review.

Expect exam items that:

• Present a scenario and ask which plan, BCP or DR, should be activated first, or which team owns a specific decision.
• Give you an RTO, RPO, or MTD figure and ask you to identify a design flaw (for example, a backup frequency that violates the stated RPO).
• Ask you to distinguish the BIA (which determines requirements) from the DR plan (which implements a technical solution to meet those requirements).
• Test your understanding of testing types: tabletop exercises, walkthroughs, simulations, parallel tests, and full interruption tests, and which is appropriate for a given risk tolerance and maturity level.
• Ask about plan maintenance triggers, such as after a merger, a major system change, or a failed test, since ISACA treats BCP and DR plans as living documents requiring regular review, not one-time deliverables.

Our CISM Domain 4: Incident Management guide covers the full domain breakdown if you want the complete picture beyond DR and BCP specifically, and our Key Risk Indicators guide is useful background for how organizations monitor continuity and recovery risk on an ongoing basis.

Common Mistakes Candidates Make

1. Treating DR as a Complete Answer

On scenario questions, if the only action taken is a technical failover with no mention of communication, staffing, or business-process continuity, that answer is describing DR, not BCP. ISACA frequently uses this as a distractor: the technically correct-sounding answer that is actually incomplete from a governance perspective.

2. Confusing RPO with RTO

RPO measures data loss tolerance looking backward from the moment of failure; RTO measures downtime tolerance looking forward from the moment of failure until restoration. A quick way to keep them straight: RPO is about how much you can afford to lose, RTO is about how long you can afford to wait.

3. Ignoring Plan Maintenance and Testing Cadence

A DR or BCP plan that has never been tested is, from an audit and governance standpoint, treated as unverified and therefore unreliable, regardless of how well it reads on paper. ISACA expects candidates to know that plans require periodic testing (commonly annually at minimum for critical systems, more frequently for high-risk environments) and updates after significant organizational or technical change.

4. Assuming One Recovery Strategy Fits All Systems

Not every system needs a hot site and a near-zero RPO. Applying uniform recovery targets across all systems, regardless of criticality, wastes budget on low-priority systems and is a common wrong-answer pattern on tiered-recovery-strategy questions. Recovery investment should scale with the BIA's criticality ranking, not be applied uniformly.

Frequently Asked Questions

Is disaster recovery part of business continuity, or are they separate plans?

Disaster recovery is a subset of business continuity planning. The DR plan is one of several supporting plans (alongside crisis communication, facility continuity, and supply chain continuity plans) that together make up a complete BCP. They are documented separately in most organizations because they have different owners and audiences, but DR is scoped inside the broader BCP framework, not alongside it as an equal, independent discipline.

Who is typically responsible for DR versus BCP?

DR is typically owned by IT operations or infrastructure teams, since it deals with restoring technology. BCP is typically owned by a business continuity manager, a risk or resilience function, or in smaller organizations, the CISO or security manager. The CISM exam expects candidates to understand this ownership split, since it frequently underlies "who should make this decision" scenario questions.

What is the difference between RTO and MTD?

RTO is the target for how quickly a specific system must be restored. MTD is the outer limit for how long an entire business process can be down before the damage becomes unacceptable, considering both the technical recovery time and the additional work-recovery time needed afterward. RTO is a system-level IT target; MTD is a process-level business threshold. The relationship is generally MTD ≥ RTO + WRT.

Do small organizations need both a formal BCP and a formal DR plan?

Yes, in principle, though the documents can be far shorter than a large enterprise's. Even a small business benefits from identifying its critical functions and recovery targets (the BCP side) separately from documenting how it will actually restore its systems and data (the DR side). Skipping the BCP and relying only on backups is a common real-world failure mode: the data comes back, but nobody planned for the loss of an office, a key employee, or a critical vendor.

How does this topic relate to the business impact analysis (BIA)?

The BIA is the analytical process that produces the RTO, RPO, and MTD figures used by both the BCP and the DR plan. Think of the BIA as the input, and DR and BCP as the two outputs built to satisfy that input, DR from a technical-recovery angle and BCP from an organization-wide angle. See our full Business Impact Analysis guide for the complete 7-step methodology.

Related Guides