Updated 1 Nov 2026 · 7 min read
On this page
After this page you will be able to say what a business continuity plan covers that a disaster recovery plan does not, run through the three steps of a business impact analysis, and match the test types named in the CISSP, CISM and Security+ outlines to what NIST says about testing. The reference throughout is NIST SP 800-34 Rev. 1, the Contingency Planning Guide for Federal Information Systems, which is still the current revision.
Continuity versus contingency
SP 800-34 Rev. 1 draws the line early. Continuity planning normally applies to the mission or business itself: it concerns the ability to continue critical functions and processes during and after an emergency event. Contingency planning normally applies to information systems, and provides the steps needed to recover all or part of a system at an existing or new location. Business continuity is the first kind. A DRP, which NIST describes as information system focused, sits on the systems side.
NIST also admits that universally accepted definitions for these plan types have not been available, and that real plans may vary from its descriptions. That is worth remembering when two study sources draw the boundaries slightly differently.
BCP and DRP side by side
The BCP focuses on sustaining an organisation's mission and business processes during and after a disruption, such as payroll or customer service. It may cover one business unit or the whole organisation, and may be scoped to priority functions only.
The DRP applies to major, usually physical disruptions that deny access to the primary facility for an extended period. It is information system focused and designed to restore operability of the target system, application or computer facility at an alternate site. NIST adds that the DRP only addresses information system disruptions that require relocation, and that a DRP may support a BCP by recovering the systems its processes depend on.
SP 800-34 Rev. 1 places these inside a wider suite. Its Table 2-2 summarises them, and a shortened version looks like this:
| Plan | Purpose in SP 800-34 Rev. 1 |
|---|---|
| Business continuity plan (BCP) | Sustaining mission and business operations while recovering from a significant disruption |
| Continuity of operations (COOP) plan | Sustaining mission essential functions at an alternate site for up to 30 days, mandated by federal directives |
| Disaster recovery plan (DRP) | Relocating information systems operations to an alternate location |
| Information system contingency plan (ISCP) | Recovering an information system, at the current location or an alternate one |
| Cyber incident response plan | Mitigating and correcting a cyber attack such as a virus, worm or Trojan horse |
| Crisis communications plan | Internal and external communications during a disruption |
| Occupant emergency plan (OEP) | Minimising loss of life or injury and protecting property in response to a physical threat |
People often mix up a DRP and an ISCP. NIST explains that the DRP is primarily site-specific, moving systems from a damaged location to a temporary alternate one, and once that is done each affected system uses its own ISCP to restore, recover and test it.
The business impact analysis
The BIA correlates a system with the critical mission and business processes it supports and characterises the consequences of a disruption. SP 800-34 Rev. 1 says three steps are typically involved:
- Determine mission/business processes and recovery criticality. Identify the processes the system supports, the impact of a disruption, and the estimated downtime the organisation can tolerate.
- Identify resource requirements. Examples include facilities, personnel, equipment, software, data files, system components and vital records.
- Identify recovery priorities for system resources. Link resources to critical processes and set priority levels for sequencing recovery.
Three time values come out of step one. The maximum tolerable downtime (MTD) is the total time the system owner or authorising official is willing to accept for a process outage. The recovery time objective (RTO) is the maximum time a system resource can remain unavailable before there is an unacceptable impact. The recovery point objective (RPO) is the point in time, before the disruption, to which data can be recovered. NIST notes that the RTO must normally be shorter than the MTD, and that the RPO is not part of the MTD: it reflects how much data loss the process can tolerate.
The sample BIA template in Appendix B gives a worked row: for the process "Pay vendor invoice", the MTD is 72 hours, the RTO 48 hours and the RPO 12 hours (last backup). The 24-hour gap between RTO and MTD leaves room for work that still has to happen once the system is back, which NIST illustrates with reprocessing data.
The BIA is step two of NIST's seven-step contingency planning process: develop the policy, conduct the BIA, identify preventive controls, create contingency strategies, develop the ISCP, ensure testing, training and exercises, and ensure plan maintenance. Its results should also feed the organisation's COOP, BCP and DRP work.
Who owns what
SP 800-34 Rev. 1 places responsibility for the planning process with the ISCP Coordinator, typically a functional or resource manager, who also usually manages development and execution of the contingency plan. Because business processes run on information systems, the business continuity planner must coordinate with system owners so that BCP expectations match system capabilities. A crisis communications plan is often developed by the organisation responsible for public outreach, and the OEP is developed at the facility level. The MTD reflects what the system owner or authorising official is willing to accept.
Tests and exercises
NIST separates tests from exercises. Tests use quantifiable metrics to validate that a system or component works in an operational environment, for example removing power from a component. Exercises are simulations of an emergency. A tabletop exercise is discussion-based only and does not involve deploying equipment. A functional exercise has people perform their duties in a simulated operational environment, and can scale up to a full-scale exercise covering every plan element. SP 800-34 Rev. 1 suggests a tabletop for low-impact systems, a functional exercise with recovery from backup media for moderate-impact systems, and a full-scale functional exercise including failover to the alternate location for high-impact systems.
The names used for test types are not standardised. SP 800-84, NIST's guide to test, training and exercise programmes, says there are many conventions for categorising exercises and that its own definitions are not meant to be definitive. Here is how each source words it:
| Source | Test and exercise types named |
|---|---|
| NIST SP 800-53 Rev. 5, control CP-4 | Checklists, walk-through and tabletop exercises, simulations (parallel or full interrupt), comprehensive exercises |
| ISC2 CISSP objective 7.12 | Read-through/tabletop, walkthrough, simulation, parallel, full interruption |
| CompTIA SY0-701 objective 3.4 | Tabletop exercises, fail over, simulation, parallel processing |
| ISACA CISM task statement on incident management plans | Table-top exercises, checklist review, simulation testing |
Notice that SP 800-53 Rev. 5 groups parallel and full interrupt as kinds of simulation, while the CISSP outline lists them as separate items. Learn the list your own exam uses.
How this fits your exam
ISC2 CISSP. The outline, effective 15 April 2024, covers business continuity requirements in objective 1.7, including business impact analysis and external dependencies. Objective 7.11 covers implementing disaster recovery processes, 7.12 covers testing disaster recovery plans with the five test types above, and 7.13 covers participating in business continuity planning and exercises. More in our CISSP guide.
ISACA CISM. Domain 4, Incident Management, carries 30 per cent. Its readiness subtopics list the incident response plan, business impact analysis, business continuity plan and disaster recovery plan. One task statement asks you to keep the incident response plan in alignment with the BCP and DRP. ISACA says the outline will be updated effective 3 November 2026. See the CISM study guide.
CompTIA Security+ SY0-701. Objective 3.4 lists continuity of operations, hot, cold and warm sites, and the testing types above. Objective 5.1 lists business continuity and disaster recovery among policies, and 5.2 places RTO, RPO, MTTR and MTBF under business impact analysis. CompTIA expects Security+ V8 on or around 17 November 2026.
Frequently asked questions
Is a disaster recovery plan part of the business continuity plan?
They are separate plans that work together. SP 800-34 Rev. 1 describes the DRP as an information system focused plan that may support a BCP by recovering the systems that business processes rely on at an alternate location.
Why must the RTO be shorter than the MTD?
The MTD is the total outage the business can accept. Once a system is back, work such as reprocessing data still takes time, and NIST says that time must be added to the RTO to stay within the MTD.
Does a tabletop exercise involve restoring systems?
No. NIST describes a tabletop exercise as discussion-based only, with no deployment of equipment or other resources. In SP 800-34 Rev. 1, recovery from backup media is part of the functional exercise suggested for moderate-impact systems, and tests often focus on recovery and backup operations.
Sources
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
- NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities
- NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- CISSP Certification Exam Outline
- CISM Exam Content Outline
- CompTIA Security+ SY0-701 Certification Exam: Exam Objectives
Read the CISM exam guide, then try free CISM practice questions on continuity and recovery.