How to Write a Business Continuity Plan: What to Include and Why It Matters
Most organizations have an IT recovery plan. Far fewer have a business continuity plan, which is why so many ransomware recoveries take three times longer than they should. Here's a practical guide to building a BCP that actually works when you need it.
BCP vs. DRP: Getting the Terminology Right
These terms get used interchangeably, but they're not the same thing, and understanding the difference matters when you're building documentation or responding to an insurer's questionnaire.
A Business Continuity Plan (BCP) answers the question: How does the organization keep functioning during and after a major disruption? It covers people, processes, communication, alternate work arrangements, and stakeholder management, the operational side of a crisis.
A Disaster Recovery Plan (DRP) answers the question: How do we restore IT systems and recover data? It's technical, failover procedures, backup restoration, system rebuild processes, and RTO/RPO targets for specific systems.
The DRP is typically a component of the broader BCP, or closely integrated with it. NIST SP 800-34 treats them as related plans within a broader continuity program.
Practical test: If your entire office building burned down tomorrow morning, your DRP tells you how to get your systems running from backup. Your BCP tells you where employees go, how customers get notified, how payroll runs, and how leadership makes decisions without their normal infrastructure. You need both.
The Business Impact Analysis: Start Here
Every BCP starts with a Business Impact Analysis (BIA). The BIA identifies which business functions are critical, what happens if they're unavailable, and how long the organization can survive without them. NIST SP 800-34 §3.2
For each critical business function, the BIA documents:
Recovery Time Objective (RTO), the maximum acceptable downtime before the impact becomes unacceptable
Recovery Point Objective (RPO), the maximum acceptable data loss (how far back in time can you recover from?)
Dependencies, what systems, people, vendors, and data does this function rely on?
Impact by timeframe, what are the consequences at 1 hour, 4 hours, 24 hours, 72 hours, 1 week?
The BIA output drives everything else in the BCP: your backup strategy must meet your RPOs, your recovery procedures must meet your RTOs, and your prioritization during an incident should follow BIA criticality rankings.
What a Complete BCP Must Include
Section 1, Plan Overview and Scope
Purpose statement, scope (which locations, functions, and personnel), plan activation triggers, and authority structure. Who can activate the plan? Who owns it? When does it go into effect?
Section 2, Business Impact Analysis Summary
Critical functions, RTOs, RPOs, and dependency mapping. This is the foundation, everything else is built on these priorities.
Section 3, Emergency Contact Directory
Key personnel with primary and alternate contact information, external contacts (legal counsel, cyber insurer, PR firm, key vendors), and escalation chains. Must be maintained as current, an outdated contact directory is almost as bad as no directory.
Section 4, Continuity Strategies by Function
For each critical function: what are the alternate procedures if primary systems are unavailable? Manual workarounds, alternate vendors, temporary staffing, remote work procedures. This is the operational core of the BCP.
Section 5, Communication Plan
Internal communication procedures (how do you reach all employees?), customer and partner notification procedures, regulatory and legal notification requirements, and media handling procedures. Silence during a crisis is almost always worse than communication.
Section 6, IT Recovery (Reference to DRP)
Either the full DRP or a summary with reference to the detailed technical procedures. Includes backup strategy, system recovery priorities, and vendor contact information for critical IT services.
Section 7, Testing and Maintenance
Test schedule (NIST recommends annual minimum), test types (tabletop, functional, full-scale), record-keeping requirements, and the process for updating the plan after organizational changes or after an actual activation.
Activation Triggers: When Does the BCP Go Into Effect?
One of the most overlooked elements is defining what actually triggers plan activation. Without defined triggers, organizations waste critical time during an incident debating whether "this is serious enough" to activate the BCP.
Common triggers to define explicitly:
IT system outage exceeding [X] hours for critical systems
Ransomware or destructive malware confirmed on production systems
Physical facility loss or extended inaccessibility (> [X] hours)
Loss of critical personnel affecting [X%] of a key function
Major vendor or supply chain failure affecting critical operations
Natural disaster or severe weather event affecting primary location
The plan should also specify who has authority to declare an emergency and activate the plan, ideally with a primary and at least one alternate decision-maker.
Common BCP Mistakes to Avoid
Building the plan and never testing it. An untested BCP is a guess. Annual tabletop exercises at minimum, use real scenarios like ransomware, key personnel loss, or office inaccessibility.
Contact directories that go stale. If the emergency contact list hasn't been reviewed in 18 months, half the numbers are probably wrong. Review it quarterly.
Setting RTOs without asking IT if they're achievable. The business may want a 4-hour RTO for its ERP system; IT needs to know whether that's possible given current backup infrastructure before it goes in the plan.
No alternate communication channel. If your primary communication tool is email and your email server is down, how do you reach staff? The answer should be in the BCP before the outage, not during it.
Treating the BCP as a one-time project. Every major system change, office move, acquisition, or key personnel change should trigger a BCP review.
BCP and Cyber Insurance
Cyber insurers increasingly ask about business continuity capabilities during underwriting, particularly your backup recovery capabilities (RPO/RTO), whether you've conducted recovery testing, and whether you have a documented plan for operating during an IT outage.
A written BCP that references tested, immutable backup procedures, defined RTOs, and a clear incident communication process doesn't just help you survive a disruption, it helps you get coverage at competitive rates and collect on claims without dispute. NIST SP 800-34
Ready-to-Use Incident Response Template
An IRP is your BCP's IT incident partner, together they cover both the business continuity side and the technical response side. Our template is structured for immediate use by real organizations.
A Business Continuity Plan (BCP) covers how the organization keeps functioning during a disruption, people, processes, communications, and alternate operating procedures. A Disaster Recovery Plan (DRP) focuses specifically on restoring IT systems and recovering data. The DRP answers "how do we get systems back"; the BCP answers "how does the business keep running while systems are down." Most organizations need both, with the DRP either embedded in or integrated with the BCP.
A complete BCP should include: scope and activation triggers, a Business Impact Analysis (BIA) with RTOs and RPOs, an emergency contact directory, alternate operating procedures for each critical function, a communication plan for employees/customers/regulators, IT recovery procedures or reference to a DRP, and a test and maintenance schedule. Per NIST SP 800-34, review annually and after any significant organizational change.
A Recovery Time Objective (RTO) is the maximum acceptable time a process or system can be unavailable. Determine it through a Business Impact Analysis: ask process owners what happens if each system is down for 1 hour, 4 hours, 24 hours, and 72 hours. Factor in regulatory requirements, contractual obligations, revenue impact, and reputational risk. Then validate that your IT recovery capabilities can actually meet those targets, there's no value in a 4-hour RTO if your backups take 12 hours to restore.
Many carriers ask about BCP and DRP capabilities during underwriting, particularly whether backups are tested, what your RTO targets are, and whether there's a documented communication plan. A written BCP doesn't just help you survive an incident, it strengthens your insurance application, demonstrates operational maturity, and helps prevent claim disputes by showing you followed documented procedures.
NIST SP 800-34 recommends annual testing at minimum, with tabletop exercises as the baseline. More mature programs run functional exercises (teams execute procedures without real system impact) every 1-2 years. Always update and re-review after any major organizational change, a significant system change, merger, key personnel departure, or following a real activation of the plan.
Your BCP should define explicit triggers: IT outages beyond a defined threshold, confirmed ransomware on production systems, physical facility loss, critical personnel loss, or major vendor failures. Clearly specify who has authority to activate the plan, with a primary and at least one alternate decision-maker. Undefined triggers lead to wasted time debating "is this serious enough" during an active incident.
Bottom Line
The difference between an organization that recovers from a major incident in days versus months is rarely the quality of their IT infrastructure. It's almost always the quality of their preparation, and at the center of that preparation is a documented, tested, current business continuity plan.
Start with the BIA. Document what matters most, how long you can survive without it, and what you'll do while it's unavailable. The rest of the plan flows from there.
📬
Get CMMC tips and template updates
No spam. Just practical guidance on CMMC compliance and new resources when we publish them.