Business Continuity
What business continuity is, and how it differs from DR
A fire knocks out your main office, but the call center keeps taking orders from a backup site and customers barely notice. That is business continuity working as intended: the organization keeps its critical functions running during and after a disruption instead of grinding to a halt. The plan that makes this possible is the business continuity plan (BCP), defined by NIST SP 800-34 Rev. 1[1] as the plan focused on sustaining an organization's mission and business processes during and after a disruption.
The single most tested point in this topic is the difference between business continuity (BC) and disaster recovery (DR), and it is easy to keep straight once you anchor on two words: operating versus restoring. BC is about keeping the business operating, the people, the processes, the service to customers. DR is the information-system-focused effort to restore the technology, the servers, applications, and facilities, often at an alternate site after an emergency. NIST puts it plainly: the DR plan recovers the systems that the business processes depend on, so the DR plan supports the BCP. They are partners, not rivals: DR brings the systems back, BC keeps the mission running in the meantime and once they return.
A simple way to remember the order in time: business continuity covers the whole disruption, from the moment something breaks through to full normal operation, because the business must keep functioning the entire time. Disaster recovery is the slice of that timeline where the technical team rebuilds the IT capability. If an exam question describes keeping payroll, shipping, or customer service going while systems are down, the answer is business continuity. If it describes bringing the servers, the data center, or the applications back online, the answer is disaster recovery.
The BIA comes first: it tells the plan what to protect
Before you can write a continuity plan you have to know what you are protecting and how fast it must come back. That is the job of the business impact analysis (BIA): the study that identifies the organization's critical business processes, estimates the impact of each one being disrupted, and ranks them so recovery effort goes to the most urgent first. NIST SP 800-34 Rev. 1[1] describes the BIA in three ordered steps: determine the mission and business processes and how critical each is, identify the resources each process needs to resume along with its dependencies, and identify recovery priorities. The BIA is the foundation, and the BCP is the plan you build on top of it.
The most important thing the BIA produces is a recovery target for each critical process, the maximum tolerable downtime (MTD). NIST defines MTD as the total amount of time the system owner or authorizing official is willing to accept for a process being unavailable. The key word is willing: MTD is a business tolerance set by leadership, not a number IT picks. A process whose MTD is measured in minutes, like accepting card payments, justifies fast and costly recovery such as a standby site; a process with an MTD of days, like refreshing a public catalog, can rely on simpler, cheaper recovery. Ranking processes by MTD is what lets a continuity plan recover the most critical work first instead of treating everything as equally urgent.
The BIA also surfaces dependencies, including outside ones. A critical process often relies on a vendor or partner, and NIST notes that those external continuity dependencies are governed by service level agreements (SLAs) that say how quickly the provider must respond, aligned to the process's own recovery needs. Missing a dependency in the BIA means the plan can be perfect on paper and still stall because a supplier was never asked to commit to a recovery time.
What a business continuity plan contains
A continuity plan is only as good as the parts that make it usable under pressure, so it pairs each critical process with the people, steps, and resources needed to keep that process running in a degraded state. Drawing on the NIST SP 800-34 Rev. 1[1] view of continuity planning, a usable BCP brings together a handful of components, and an exam item often turns on recognizing one of them.
Critical functions
These are the processes the BIA flagged as essential, the work the organization cannot stop doing for long without serious harm. The plan focuses its attention here rather than trying to protect everything equally.
Recovery priorities and targets
The plan carries the BIA's ranking and each process's maximum tolerable downtime, so responders know what to bring back first and how much time they have. This is the bridge from analysis to action.
People and roles
A plan names who is responsible for keeping each critical function going, who can declare an emergency, and who their backup is. A plan that lists technology but no clear owners fails the moment a decision has to be made.
Communication plan
During a crisis, staff, customers, partners, and sometimes the public all need information, and they need it to be consistent. NIST's crisis-communications guidance is that the plan documents internal and external communication procedures and typically designates specific individuals as the only authority for speaking to the public, so the organization speaks with one voice instead of leaking conflicting messages. The plan also covers how people will be reached when normal channels like office email and desk phones are unavailable.
A plan that is tested and maintained
A continuity plan that sits in a drawer is a liability. Plans are exercised and updated so that contact lists are current and staff know their roles before a real disruption, not during one.
Exam-pattern recognition: spotting the right answer
Most CC questions on this topic test one of three things: telling business continuity apart from its neighbors, knowing the order in which the pieces are built, and knowing who owns a decision.
Continuity vs disaster recovery vs incident response
This is the highest-yield distinction. Read the stem for the verb. Keep operating or keep serving customers during the outage points to business continuity. Restore the systems or bring the data center back points to disaster recovery. Detect, contain, and respond to an attack or breach points to incident response, which is triggered by a security event rather than a broad disruption. A common trap answer offers disaster recovery when the scenario is really about keeping the business running, because both involve an outage; the tie-breaker is whether the focus is the business process (BC) or the technology (DR).
Order: the BIA comes before the plan
If a question asks what you do first, or what the continuity plan is based on, the answer is the business impact analysis. The BIA identifies and ranks critical processes and sets their recovery targets, and the BCP is written from those results. Choosing the plan before the analysis reverses the dependency, you cannot prioritize recovery without first knowing what is critical and how much downtime each process can tolerate.
Who sets the maximum tolerable downtime
Watch for stems where the wrong answer is an IT or technical role choosing the MTD. MTD is a business tolerance, so it is set by leadership or the process owner, recorded in the BIA, and only then handed to IT to meet. The technical recovery target derived to meet the MTD is a separate idea covered under disaster recovery, so do not confuse the business-set tolerance with the technical timeline built to satisfy it.
Business continuity vs disaster recovery vs incident response
| Aspect | Business continuity (BC) | Disaster recovery (DR) | Incident response (IR) |
|---|---|---|---|
| Core question | How do we keep critical functions running? | How do we restore IT systems and facilities? | How do we detect, contain, and recover from an attack? |
| Focus | Business processes and the people running them | Technology: systems, data, sites | A specific security event |
| Timing | During and after a disruption | After a disruption, to rebuild capability | When an incident is detected |
| Triggered by | Any major operational disruption | A disaster that disrupts systems or a site | A confirmed or suspected security incident |
| Key artifact | BCP, driven by the BIA | DR plan, with RTO and RPO targets | Incident response plan |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Business continuity keeps critical functions operating during a disruption
A business continuity plan (BCP) is the plan for sustaining the organization's mission and critical business processes during and after a disruption, so the business keeps serving customers even while its normal setup is broken. Its goal is to keep operating, not to fix the broken systems. Per NIST SP 800-34 Rev. 1 the BCP focuses on the business processes, while the technical restoration of the systems those processes depend on is handled separately by disaster recovery.
- BC keeps the business running; DR restores the IT systems
The most tested point on this topic is the difference between business continuity and disaster recovery (DR). BC is about keeping the business operating (people, processes, customer service) during and after a disruption; DR is the information-system-focused work to restore the technology, servers, applications, and facilities, often at an alternate site. NIST SP 800-34 Rev. 1 frames the DR plan as supporting the BCP, since it recovers the systems the business processes rely on. The tie-breaker on an exam: focus on the business process means BC, focus on the technology means DR.
Trap Choosing disaster recovery when the scenario is about keeping the business running during the outage; both involve an outage, but DR is the technical restore of systems, not keeping the mission going.
- The BIA comes before the continuity plan
The business impact analysis (BIA) is done first, because it tells the plan what to protect and how fast. The BIA identifies the critical business processes, estimates the impact of each one being disrupted, and ranks them; the BCP is then written from those results. Asking what you do first, or what the continuity plan is based on, points to the BIA.
Trap Writing or selecting the continuity plan before the BIA; you cannot prioritize recovery without first knowing which processes are critical and how much downtime each can tolerate.
3 questions test this
- The BIA runs three ordered steps
NIST SP 800-34 Rev. 1 structures the BIA as three ordered steps: first determine the mission and business processes and how critical each is, then identify the resources each process needs to resume along with its dependencies, and finally identify recovery priorities. The output of these steps, especially each process's recovery target, is what the continuity plan is built around.
- Maximum tolerable downtime is the longest a process can be down before unacceptable harm
Maximum tolerable downtime (MTD) is the total amount of time a critical process can be unavailable before the damage becomes unacceptable, per NIST SP 800-34 Rev. 1. It is the recovery target the BIA produces for each critical process, and it drives how much to invest in recovery: a short MTD justifies fast, costly recovery while a long MTD can rely on simpler, cheaper measures.
- MTD is a business tolerance set by leadership, not by IT
MTD is set by the business, the leadership or process owner, and recorded in the BIA, because only the business can say how much outage it can survive. IT then designs recovery to meet that target. Watch for stems where the wrong answer has a technical or IT role choosing the MTD; the business sets the tolerance and hands it to IT to satisfy.
Trap Treating MTD as a number IT or the technical team picks; it is a business-set tolerance recorded in the BIA, separate from the technical recovery timeline built to meet it.
- MTD ranking decides which processes recover first
Because the BIA ranks processes and sets each one's MTD, the continuity effort recovers the most time-critical work first instead of treating everything as equally urgent. A process whose MTD is minutes, like card payments, justifies a standby capability, while one whose MTD is days, like refreshing a public catalog, can wait. This ranking is what turns limited recovery resources toward the work that cannot wait.
- A continuity plan needs people and named roles, not just technology
A usable BCP assigns the people and roles who keep each critical function running, names who can declare an emergency, and identifies their backups. A plan that lists technology but no clear owners fails the moment a decision has to be made under pressure. The plan ties each critical process to who is responsible for keeping it going.
Trap Assuming a continuity plan is mainly a technology document; without named owners and decision authority it stalls in the real disruption it was written for.
- The communication plan keeps one consistent message in a crisis
A BCP includes a communication plan so staff, customers, and partners get consistent information during a disruption. NIST SP 800-34 Rev. 1 crisis-communications guidance is to document internal and external communication procedures and typically designate specific individuals as the only authority for speaking to the public, so the organization speaks with one voice. The plan also covers how people will be reached when normal channels like office email and desk phones are down.
Trap Letting any employee answer public or media questions during a crisis; the plan designates a single authorized spokesperson so the organization speaks with one voice and avoids conflicting messages.
- Continuity dependencies on outside vendors are bound by SLAs
A critical process often depends on a vendor or partner, and the BIA must surface those external dependencies. NIST SP 800-34 Rev. 1 notes that external continuity dependencies are governed by service level agreements (SLAs) stating how quickly the provider must respond, aligned to the dependent process's recovery needs. Miss a dependency in the BIA and the plan can look complete yet stall because a supplier never committed to a recovery time.
- A continuity plan is exercised and kept current, not filed away
A BCP that sits unread is a liability: contact lists go stale and staff forget their roles. Plans are tested and updated so people know what to do and information is current before a real disruption rather than during one. Testing is part of having a continuity capability, not an optional extra.
- Incident response handles a security event; business continuity handles a broad disruption
Incident response (IR) is the plan for detecting, containing, and recovering from a security attack or breach, and it is triggered by a security event. Business continuity is broader, covering any major operational disruption and keeping critical functions running. When the stem describes an attack or breach the answer is IR; when it describes keeping operations going through an outage it is BC.
Trap Reaching for business continuity when the trigger is specifically a confirmed or suspected attack or breach; that security event is what incident response is for.