Business Continuity Plan vs Disaster Recovery Plan: Where Each Ends

Owners, and the meeting they need to have

The business owns the BCP because only the business can say how long an activity can stop. IT owns the DRP because only IT can say what recovery the environment can actually deliver, and at what cost. Neither number means much without the other.

The useful meeting goes like this. The business brings tolerances from its impact analysis. IT brings achieved recovery times from its last tests and a price for closing each gap. Where the two do not match, an executive either funds the fix or accepts the risk in writing. Skip that meeting and you get a plan promising same-day recovery on infrastructure that has never restored in under three days. The method for turning tolerances into targets is in our guide to setting RTO and RPO without guesswork.

Triggers: who declares what

Write separate invocation rules, then make each plan tell the other.

• IT can invoke disaster recovery for a single failed system without declaring a business disruption. The DRP should still say when IT must notify the continuity lead, such as any tier-1 system down for more than 30 minutes.
• The business can invoke the BCP while every system works. Closing the office is the common case. The BCP should then warn IT, because remote access load, help desk calls and laptop shortages arrive within the hour.
• A single severe event can trigger both. Decide in advance who chairs when they run together, so two teams are not giving staff conflicting instructions.

Metrics: how the numbers nest

The maximum tolerable period of disruption (MTPD) is a business figure and belongs in the BCP. NIST calls the same idea maximum tolerable downtime and describes it as including all impact considerations. Everything else has to fit inside it.

Recovery time objectives appear in both plans, at two levels. The BCP sets an RTO for each activity; the DRP sets an RTO for each system that activity needs. A system RTO plus the time people need to check data and clear the backlog must fit inside the activity RTO, which must fit inside the MTPD. NIST SP 800-34 says plainly that the RTO must normally be shorter than the maximum tolerable downtime, and that the recovery point objective is not part of that downtime calculation. The RPO, the amount of data you can afford to lose, lives in the DRP but comes from a business question: what would it take to reconstruct the missing hours?

A quick example. An order desk can stop for one ten-hour business day. Re-keying paper orders after an outage takes three hours, and the team wants two hours of margin. That leaves the ordering system an RTO of five hours at most, not the full day.

Where incident response and crisis management fit

A BCP and a DRP sit inside a wider set of response plans. Each layer has its own clock and its own people.

1. Emergency response covers life safety in the first minutes: evacuation, shelter in place, accounting for people. NIST calls this the occupant emergency plan. US employers covered by OSHA's emergency action plan rule (29 CFR 1910.38) already need much of it in writing.
2. Incident response contains and investigates a cyber incident. NIST notes that a cyber incident response plan may activate a system contingency plan or a DRP, depending on the extent of the attack.
3. Crisis management is the senior team deciding what the organization does and says: shut down or keep trading, what to tell customers and regulators, whether to pay. It directs the other plans rather than restoring anything. Our piece on executive decisions in the first hour of a crisis covers that room.
4. Business continuity keeps priority activities going with workarounds while the rest happens.
5. Disaster recovery brings the technology back, often last to finish and sometimes, in a ransomware case, only after forensic clearance.

Where the standards draw the lines

NIST SP 800-34 Rev. 1 (2010), the federal contingency planning guide, is the clearest source on the boundary. It describes eight plan types, listed alphabetically: business continuity plan, continuity of operations (COOP) plan, crisis communications plan, critical infrastructure protection plan, cyber incident response plan, disaster recovery plan, information system contingency plan (ISCP) and occupant emergency plan. Its BCP focuses on sustaining business processes during and after a disruption, and it notes that organizations outside government typically use BCPs rather than COOP plans.

Its DRP is narrower than the way most companies use the term. NIST defines it as an IT-focused plan for moving information system operations to an alternate location after a major disruption with long-term effects, which then activates the contingency plans for individual systems. Recovering one system, where it runs now or elsewhere, is the job of the ISCP. So what many small firms call a DR plan, restoring the server from backup in place, is closer to an ISCP in NIST's vocabulary. The label matters less than the lesson: cover both recovery in place and recovery somewhere else.

ISO 22301:2019 is a management system standard and does not require a document called a disaster recovery plan. It asks for a business impact analysis that sets prioritized time frames for resuming activities at a minimum acceptable capacity (clause 8.2.2), strategies and solutions to meet them (8.3), and plans and procedures covering response structure, warning and communication, business continuity and recovery (8.4.2 to 8.4.5). Technology recovery choices sit under those strategies and solutions. The companion guidance for the IT side is ISO/IEC 27031, on ICT readiness for business continuity, whose second edition was published in May 2025.

Mistakes that keep turning up

1. The DRP is filed as the BCP. It restores servers. It does not tell anyone how to take orders in the meantime.
2. Targets set in two rooms. IT tiers a system at 24 hours while the activity it supports cannot stop past noon.
3. DR tests without a business user. A server answering a ping is not a recovered service until someone completes a real transaction.
4. A DRP written only for losing a building. Ransomware, cloud and SaaS outages and faulty software updates leave the building standing, and a site-loss plan has little to say about them. Our look at cloud region outages covers designing for those.
5. A BCP that assumes IT will be back. Every priority activity needs a manual workaround and a stated limit on how long it lasts.
6. Two contact lists, neither current. Keep one shared appendix that both plans reference.

One document or two?

A small firm with one site and most of its systems in SaaS can run a single combined business continuity and disaster recovery plan, with the IT section written and owned by whoever runs IT, even an outside provider. Larger organizations usually keep separate documents, joined by one shared table of activities, systems and targets so a change in one shows up in the other. Regulated firms should expect auditors and examiners to ask for both, and for evidence that they agree.

Frequently asked questions

Is disaster recovery part of business continuity?

Yes. Disaster recovery is the technology part of a wider continuity effort: the BCP sets the targets and the DRP delivers the systems that meet them. NIST treats them as separate plans that must be coordinated.

Which should come first, the BCP or the DRP?

Start with the business impact analysis that feeds the BCP, because it tells IT which systems matter and how fast they must return. Writing the DRP first tends to produce targets that describe today's infrastructure rather than what the business needs.

Who should own the disaster recovery plan at a small business?

Whoever runs IT, even an outside managed service provider, should write and maintain it. A named person inside the business should be accountable for it, approve the targets and check that tests happen. Outsourcing the work does not outsource the accountability.

Does a business continuity plan replace an incident response plan?

No. An incident response plan deals with containing and investigating a cyber incident, while the BCP keeps the business running around it. The two need agreed hand-offs, especially on when systems may be rebuilt.