Business continuity vs disaster recovery: what's the difference?

The difference at a glance

What NIST and ISO say

NIST's contingency planning guide, SP 800-34 Rev. 1, draws the line this way: continuity planning "normally applies to the mission/business itself", while contingency planning "normally applies to information systems". Its glossary defines the two plans:

• Business continuity plan: "The documentation of a predetermined set of instructions or procedures that describe how an organization’s mission/business processes will be sustained during and after a significant disruption."
• Disaster recovery plan: "A written plan for recovering one or more information systems at an alternate facility in response to a major hardware or software failure or destruction of facilities."
• Continuity of operations (COOP) plan: the government version, for sustaining mission essential functions for up to 30 days. The guide notes that nongovernment organizations typically use BCPs instead.

Read strictly, NIST's DRP is about moving to an alternate site, and the step-by-step restore of one system is an information system contingency plan (ISCP). Small teams call the combination their disaster recovery plan, and so does this guide. NIST itself notes that universally accepted definitions for these plans have not been available, so expect customers and auditors to use the words loosely.

ISO 22301:2019 is the international standard for a business continuity management system: the requirements for preparing for, responding to and recovering from disruptions, and for reviewing and improving that capability over time. Organizations can be independently audited against it. In ISO/IEC 27001:2022, two Annex A controls cover the same ground: 5.29, Information security during disruption, and 5.30, ICT readiness for business continuity. A tested DR plan is natural evidence for 5.30; 5.29 is about keeping security controls in place while you recover.

Ready.gov's guidance for small businesses says the same in plainer words: an IT disaster recovery plan "should be developed in conjunction with the business continuity plan", and "Priorities and recovery time objectives for information technology should be developed during the business impact analysis."

How the plans fit together

The BCP is the parent. It lists the processes that keep the business alive and, for each one, what people do while it is disrupted. Where a process depends on a system, it points to the DR plan for getting that system back. NIST names a few smaller plans that sit beside them:

• Crisis communications plan: who may speak to customers and the public, through which channels, with what templates. A status page hosted away from your own servers is the usual first channel.
• Cyber incident response plan: how to detect, contain and recover from an attack. NIST says it may be an appendix of the BCP; recovering a hacked server covers the technical side.

For a company of a few people, all of these can be sections of one document, as long as the restore steps stay detailed enough for someone other than their author to follow.

Business impact analysis: where both plans start

Ready.gov defines it plainly: "A business impact analysis (BIA) predicts the consequences of a disruption to your business, and gathers information needed to develop recovery strategies." NIST's guide breaks it into three steps: determine the processes and how critical their recovery is, identify the resources each needs, and set recovery priorities.

For each process, write down what stops, what that costs per hour or day, when the harm becomes unacceptable, and what it depends on. Ready.gov's list of impacts is a good prompt: lost or delayed sales, increased expenses, regulatory fines, contractual penalties, customers who leave, and delayed new business plans.

The BIA produces two kinds of target. Maximum tolerable downtime (MTD) belongs to a business process; NIST defines it as "The amount of time mission/business process can be disrupted without causing significant harm to the organization’s mission." ISO's continuity standards call it the maximum tolerable period of disruption (MTPD). RTO and RPO belong to systems: how long each can be down, and how much recent data it can lose. SP 800-34 says the RTO must normally be shorter than the MTD, because reprocessing data after a restore takes time too, and that RPO is not part of the MTD. RPO and RTO explained shows how to measure what your backups really achieve.

Worked example: a small online store

Fernhill Coffee (invented for this example) has six people, about 60 orders and $4,800 in sales a day, a WooCommerce store on one cloud server, a card payment processor, hosted email, and a fulfilment partner that ships from a daily order export. Its BIA:

From that, the systems get targets: the store database an RPO of 1 hour and an RTO of 8 hours, the store's files an RPO of 24 hours and an RTO of 8 hours, the DNS zone an RTO of 1 hour. An 8-hour RTO inside a 24-hour MTD leaves 16 hours to re-enter orders taken by hand.

The scenario: at 09:00 on a Monday the hosting provider suspends the account. The server, its snapshots and any backups kept in that account are out of reach. Here is what each plan says:

Each plan fails without the other. A perfect restore with no BCP still loses a day of sales while staff wait. A BCP with no DR plan means taking orders by phone indefinitely. Note what made recovery possible at all: backups stored outside the suspended account, as the 3-2-1 rule requires.

How to test each

A BCP is tested with a tabletop exercise: NIST SP 800-84 describes it as a discussion-based exercise in which the people named in a plan talk through their roles and responses to a scenario a facilitator presents. Bring the whole team, not just engineers, for an hour. Use the suspended-account scenario above and check: are the phone numbers current, who can log in to the payment processor, does the status page work if your own email is down, does the fulfilment partner know the fallback?

A DR plan is tested by restoring: a real backup onto a scratch server, following the written steps, timed against the RTO. How to test a backup restore has the drill and a script.

• Tabletop exercise: twice a year, and when people or suppliers change.
• Restore tests: monthly for systems like the store database, quarterly for the rest.
• Once a year, a functional exercise, which NIST describes as validating plans in a simulated operational environment: restore the store at another provider while the team takes orders by hand for an hour.

Outlines to copy

A business continuity plan for a small business fits on a few pages. Replace every ____:

# Business continuity plan: ____
Version: ____   Owner: ____   Approved by: ____   Next review: ____
Copies kept at: ____ (at least one outside our own systems)

## 1. Purpose and scope
Covers: ____ (processes, sites, teams)   Does not cover: ____

## 2. People
| Role                | Name | Phone | Deputy |
|---------------------|------|-------|--------|
| Continuity lead     |      |       |        |
| Customer comms      |      |       |        |
| Operations          |      |       |        |
| IT (owns DR plan)   |      |       |        |

## 3. Critical processes (from the BIA)
| Process | Cost of stopping | MTD | Depends on | Workaround |
|---------|------------------|-----|------------|------------|

## 4. Activation
Who may declare a disruption: ____   Triggers: ____
First hour: open incident log, call the lead, start section 5.

## 5. Workarounds, per process
Taking orders: ____   Shipping: ____   Support: ____

## 6. Communication
Status page: ____   Customer email: ____   Staff channel: ____
Fallback if our email is down: ____
Templates: first notice, updates every ____, all clear.

## 7. Suppliers and outside services
| Supplier | What we rely on | Contact | Their fallback |
|----------|-----------------|---------|----------------|

## 8. IT recovery
See the disaster recovery plan, version ____.
| System | RPO | RTO | Supports process |
|--------|-----|-----|------------------|

## 9. Back to normal
Reconcile data entered by hand; tell customers; review the incident.

## 10. Testing and review
Tabletop: every ____ months. Last run: ____  Actions: ____
Review after every incident and change of people or suppliers.

The DR plan's outline: scope; people and contacts; who declares a disaster and when; systems in restore order with RPO, RTO and dependencies; step-by-step recovery per system, with exact commands; providers and where logins are kept; returning to normal; test log; review and sign-off. The full fill-in version is the disaster recovery plan template.

Frequently asked questions

Is disaster recovery part of business continuity?

Yes. Business continuity covers the whole business; disaster recovery is the part that restores IT systems. The BCP points to the DR plan for every process that depends on a system.

Does a small business need both a BCP and a DR plan?

It needs both answers: how to keep serving customers while systems are down, and how to bring them back. For a few people, they can be two sections of one document.

What comes first, the business impact analysis or the plans?

The business impact analysis. It decides which processes matter, how long each can stop, and therefore the RTO and RPO each system needs.

What is the difference between RTO and maximum tolerable downtime?

Maximum tolerable downtime is how long a business process can be disrupted before the harm is significant. RTO is how long a system can stay down, and it must be shorter, leaving time to catch up on work after the restore.