When Change Healthcare's payment processing network went dark in February 2024 after a ransomware attack, thousands of pharmacies found themselves unable to process prescriptions for days. Many had continuity plans. Few had plans that accounted for a single third-party processor going offline at that scale. The gap between having a plan and having a *tested, current* plan is where organizations get hurt.
This guide covers how to build a business continuity plan that closes that gap, step by step, in the order it matters.
TL;DR
- A BCP is only as strong as the analysis behind it, starting with a thorough BIA.
- Most plans fail not because they're wrong, but because they're outdated or untested by the time an incident hits.
- The CrowdStrike outage (July 2024) and Change Healthcare ransomware attack (February 2024) both exposed gaps that a well-exercised BCP should have caught.
- This guide covers eight structured steps, from scoping through exercising, with specific actions at each stage.
What is a business continuity plan?
A business continuity plan (BCP) is a documented set of procedures and resources that enables an organization to maintain or rapidly restore critical business functions during and after a disruptive event. A complete BCP defines which functions are critical, who owns recovery, what resources are needed, and how success is measured, typically against pre-agreed recovery time objectives.
For a deeper look at what goes inside a plan, see What Is a Business Continuity Plan? Definition, Examples, and Key Components.
Step 1: Establish scope and governance
Before anything gets documented, someone needs to own this. That sounds obvious, but in most organizations we've seen, the first failure point is ambiguous ownership: BCM sits between IT, risk, and operations with no clear authority structure.
Define:
- Programme owner. A named senior sponsor, ideally at C-suite or board level, who can compel business units to participate.
- Scope boundaries. Which sites, subsidiaries, business lines, and third parties are in scope for this planning cycle?
- Policy anchor. The BCP should flow from an overarching business continuity policy that states management's commitment and minimum requirements.
ISO 22301:2019 Clause 4.3 requires organizations to determine the scope of the BCMS explicitly. If you're targeting certification or regulatory compliance under frameworks like DORA, getting scope right at this stage saves painful rework later.
Document the scope in a single page. Keep it version-controlled.
Step 2: Conduct a business impact analysis
The business impact analysis (BIA) is the analytical foundation of every BCP. Skip it, and you're writing fiction.
The BIA answers three questions:
- Which processes are critical to the organization's survival or regulatory obligations?
- What is the maximum tolerable period of disruption (MTPD) for each?
- What resources, people, systems, suppliers, facilities, does each process depend on?
In practice, BIA data collection is where programs stall. Sending spreadsheets to 40 department heads and chasing returns for six weeks is the default; it's also why BIA data is often 18 months stale by the time it's used. Purpose-built tooling with automated data collection and reminder workflows changes this materially.
Output from the BIA: a prioritized list of critical processes with recovery time objectives (RTOs) and recovery point objectives (RPOs). For a primer on those metrics, see RTO vs RPO Explained.
If you need a starting structure, the Business Impact Analysis Template covers the standard fields across process, financial, and operational impact dimensions.
Step 3: Identify and map dependencies
A process doesn't fail in isolation. When CrowdStrike's Falcon sensor update (Channel File 291) caused Windows systems to blue-screen in July 2024, the cascading effect hit airlines, hospitals, and broadcasters simultaneously, because their critical processes shared a common technology dependency nobody had mapped as a single point of failure.
Dependency mapping means tracing each critical process to:
- Internal IT systems and infrastructure
- People and teams (including key-person dependencies)
- Physical locations
- Third-party vendors and suppliers
For organizations with complex supplier chains, this step is increasingly where regulators focus. The FCA's operational resilience rules (PS21/3) require firms to map dependencies for important business services explicitly. DORA Article 11 extends this obligation across the ICT supply chain for financial entities in the EU.
Step 4: Identify threats and assess risk
With critical processes and dependencies mapped, run a scenario-based threat assessment. The goal is not to predict every possible incident, it's to identify which threat categories would trigger plan activation and which scenarios should drive your recovery strategy choices.
Common threat categories to assess:
| Threat category | Example scenario | Typical BCP trigger? |
|---|---|---|
| Cyber incident | Ransomware encrypts core systems | Yes |
| Technology failure | Cloud provider outage, ISP failure | Yes |
| Third-party failure | Critical supplier goes offline | Yes |
| Physical damage | Fire, flood at primary site | Yes |
| People unavailability | Pandemic, key-person departure | Yes |
| Regulatory action | Enforcement closes a business line | Sometimes |
Each scenario gets a likelihood/impact score. High-impact scenarios that affect your top-tier critical processes become the design basis for recovery strategies in the next step.
Step 5: Define recovery strategies
A recovery strategy is the documented approach for restoring a critical process within its RTO when a threat scenario occurs. One process may need multiple strategies depending on the threat type.
Strategies fall into a few categories:
| Strategy type | Typical use case | Cost indicator |
|---|---|---|
| Work-from-home / remote activation | People-unavailability scenarios | Low |
| Alternate site (warm) | Primary site loss, 4–24 hour RTO | Medium |
| Alternate site (hot) | Sub-4-hour RTO requirements | High |
| Manual workaround | System failure with tolerant RTO | Low |
| Third-party reciprocal agreement | Specialist function, shared risk | Variable |
| Cloud failover | IT systems with near-zero RPO | Medium–High |
A common mistake practitioners make is writing recovery strategies in the abstract without confirming that the resources exist. If your strategy says "invoke the warm recovery site," someone needs to have verified that the site has sufficient desks, bandwidth, and licensed software for the team size specified.
For a broader view of the options, business continuity strategies: types, examples, and how to build one covers the trade-offs in more depth.
Step 6: Write the plan documents
With analysis complete and strategies confirmed, you can write the actual plan. A BCP is not a single document, most mature programmes maintain a hierarchy:
- Programme-level BCP: Governance, activation criteria, escalation contacts, and cross-functional coordination
- Business unit recovery plans: Process-specific procedures, resource lists, and contact trees
- IT disaster recovery plan: Technical recovery of systems and infrastructure (see How to Build an IT Disaster Recovery Plan for that scope)
- Crisis communications plan: Stakeholder messaging during an active incident (links to the crisis management plan)
Each plan should include:
- Activation triggers and decision authority
- Step-by-step recovery tasks, with named owners
- Resource requirements (people, systems, alternate facilities)
- Communication protocols
- Escalation paths and decision trees
- Recovery milestones and stand-down criteria
Keep procedures short and action-oriented. A plan that requires 20 minutes of reading before the first action is taken will not be followed under pressure.
Step 7: Test and exercise the plan
A plan that has never been tested is a hypothesis. The BCI Good Practice Guidelines 2023 found that organizations that exercise annually or more frequently recover faster from incidents than those that exercise less often, yet most programmes still run one tabletop per year at best.
There are three main exercise types:
| Exercise type | Format | Tests |
|---|---|---|
| Tabletop | Discussion-based, no live systems | Decision-making, plan logic |
| Functional | Partial activation with some live elements | Coordination, communications |
| Full-scale simulation | Live activation of recovery procedures | End-to-end recovery capability |
For guidance on running effective discussions, Tabletop Exercise: Definition, Examples, and How to Run One covers scenario design and facilitation.
A critical trap: treating exercise volume as a proxy for readiness. Running six tabletops a year while never doing a functional exercise means you've tested conversations, not capability. The article Why Most BCM Exercise Programs Measure Activity, Not Readiness addresses this directly.
AI-assisted testing is changing what's possible here. Automated scenario injection and real-time scoring can surface gaps in plan logic without requiring a full-day facilitated exercise for every test cycle. See How to Automate Business Continuity Testing with AI.
Step 8: Maintain and improve the plan
Plans become obsolete the moment the organization changes, new systems, new vendors, restructured teams, regulatory updates. The Change Healthcare attack exposed how many healthcare organizations hadn't updated their third-party dependency registers after consolidation in the clearinghouse market. The plan existed; the data in it did not reflect 2024 reality.
Maintenance requires a formal review trigger list:
- Annual scheduled review (minimum, per ISO 22301:2019 Clause 8.4)
- Post-incident review after any activation or near-miss
- Triggered review after material organizational change (M&A, new system, new vendor, site closure)
- Post-exercise review after each test cycle
Every review should produce a version increment, a change log entry, and re-sign-off from the plan owner. Tracking this manually across dozens of plan documents is where most programmes lose discipline. Plan lifecycle management within a purpose-built BCM platform keeps version history, owner attestation, and review schedules in one place.
For a benchmark on where most enterprise programmes currently sit across these dimensions, the BCM Maturity Benchmark 2026 gives specific scoring data across six capability areas.
What good looks like: a summary comparison
| Maturity level | BIA approach | Plan maintenance | Exercise frequency |
|---|---|---|---|
| Ad hoc | Spreadsheet, annual | Manual, inconsistent | Annual tabletop only |
| Managed | Structured collection, annual | Tracked reviews, version control | Tabletop + occasional functional |
| Advanced | Automated, continuous | Triggered by change events | Mixed types, quarterly cycle |
| Leading | Real-time dependency data | Always current, integrated with change mgmt | Continuous simulation, post-incident review |
Most organizations we've worked with land somewhere between ad hoc and managed. The gap to advanced is usually a process gap, not a budget one. See Business Continuity Plan Best Practices for specific improvements at each level.
Sources
- ISO 22301:2019, *Security and resilience, Business continuity management systems, Requirements*, Clauses 4.3, 8.4. iso.org
- FCA PS21/3, *Building operational resilience*, Financial Conduct Authority, March 2021. fca.org.uk
- DORA (EU) 2022/2554, Article 11, *ICT business continuity policy*, in force January 2025. eur-lex.europa.eu
- BCI Good Practice Guidelines, 7th Edition, 2023. thebci.org
- Reuters, *Change Healthcare cyberattack disrupts US pharmacies*, February 2024. reuters.com
- Reuters, *CrowdStrike update causes global IT outage*, July 2024. reuters.com
