Business Continuity Plan Template: The Complete Guide to Building a BCP That Actually Works

TL;DR

• Most business continuity plans fail because they sit untested in a drawer — TSB’s 2018 IT migration proved this the hard way, resulting in a £48.65 million fine from UK regulators.
• The FFIEC’s 2019 Business Continuity Management booklet sets the bar for financial institutions — your BCP needs to be a living program, not a one-time document.
• Every BCP needs 8 core sections: scope, BIA summary, recovery strategies, communication plan, roles/responsibilities, testing schedule, vendor dependencies, and a plan maintenance process.

---

Your business continuity plan is probably broken. Not because you didn’t write one — but because you wrote it, filed it, and haven’t touched it since.

The business continuity plan template question most teams ask is: “What sections do I need?” The real question is: “How do I build a BCP that people will actually follow when everything is on fire?”

Here’s the difference between the two: one gets you a document. The other keeps your institution operational when the power goes out, a ransomware attack hits, or a vendor your entire business depends on suddenly goes dark.

TSB learned this the expensive way. In 2018, a botched IT migration locked nearly 2 million customers out of their accounts for weeks. The disruption wasn’t just bad — it was catastrophic enough that the FCA and PRA fined TSB a combined £48.65 million in December 2022. The FCA’s own words: “The disruption to continuity of service experienced by TSB during its IT migration fell below the standard we expect banks to meet.”

A better BCP might not have stopped the migration from going wrong. But it absolutely would have changed how fast they recovered, how customers were treated, and whether regulators concluded that the bank had its act together.

Let’s build the version of your BCP that doesn’t end in a regulator quote.

---

What a Business Continuity Plan Actually Is (and Isn’t)

A business continuity plan is the operational playbook for keeping critical business functions running — or restoring them quickly — when something disrupts normal operations. That something could be a cyberattack, natural disaster, power failure, key person departing, or a vendor going offline.

What it’s not: a disaster recovery plan. DRP focuses specifically on restoring IT systems and infrastructure. BCP is broader — it covers people, processes, communications, and the business itself. They’re related. They’re not the same thing. (More on that in our disaster recovery plan template guide.)

For financial institutions, the FFIEC made this distinction explicit in its November 2019 Business Continuity Management (BCM) booklet, which replaced the older Business Continuity Planning booklet. The shift in language from “planning” to “management” was intentional — the FFIEC wants to see a program, not just a plan.

---

Why Most BCPs Fail

The CrowdStrike outage in July 2024 affected an estimated 8.5 million Windows devices and cost Fortune 500 companies approximately $5.4 billion. Airlines, healthcare systems, and financial institutions were hit hardest. The organizations that recovered fastest weren’t the ones with better technology — they were the ones with better-tested continuity plans and documented manual workarounds.

The ones that struggled had the same thing in common: their BCPs existed but hadn’t been stress-tested against a scenario like this.

Here’s the pattern that kills BCPs:

1. Written once, never updated. A plan built on last year’s org chart, vendors, and systems is fiction.
2. No Business Impact Analysis driving it. If you don’t know which processes are truly critical, your recovery priorities are guesses.
3. Testing on paper only. Tabletop exercises where everyone agrees the plan would work ≠ an exercise where you prove it.
4. Vendor dependencies not mapped. Change Healthcare’s February 2024 cyberattack took down healthcare claims processing for thousands of providers across the US — organizations that had no documented continuity plan for operating without that single vendor were left scrambling.
5. Communications plan is missing. When operations go down, who calls who? In what order? Using what channel? If your team has to figure this out mid-crisis, it’s already too late.

---

The FFIEC’s Expectations (What Examiners Actually Look For)

The 2019 FFIEC BCM booklet lays out what a mature business continuity management program looks like. For financial institutions, this isn’t optional reading — it’s the framework examiners use when they walk in the door.

Key requirements from the booklet:

• Business Impact Analysis (BIA): Identify critical business functions, estimate maximum tolerable downtime (MTD), and set recovery time objectives (RTO) and recovery point objectives (RPO) for each. (Our BIA template guide covers this in depth.)
• Risk assessment: Evaluate threats and vulnerabilities across your operational environment — not just IT.
• Recovery strategies: Document how critical processes get restored, including manual workarounds for technology failures.
• Testing and exercises: Annual testing at minimum, with results documented and weaknesses tracked to remediation.
• Third-party dependencies: Map vendor relationships and confirm critical vendors have their own viable BCPs.
• Board and senior management oversight: BCM is a governance issue, not just an ops issue. The board needs to approve the program and receive testing results.

Understanding the difference between RTO and RPO is foundational to all of this — check the RTO vs. RPO guide if those terms need a deeper dive.

---

The 8 Sections Every Business Continuity Plan Template Needs

A BCP without these sections isn’t a plan — it’s a risk. Here’s what goes into each one.

Section 1: Scope and Objectives

Define what the plan covers and what it doesn’t. Be specific.

Element	What to Include
Business units covered	List every department and function in scope
Geographic locations	All offices, branches, data centers, WFH populations
Out-of-scope items	Clearly state what’s excluded and why
Objectives	Specific, measurable goals (e.g., “restore core banking within 4 hours”)
Plan owner	Name and title of the person accountable for this document

Fuzzy scope is how you end up with a plan that technically covers “all operations” but leaves entire business lines with no recovery guidance.

Section 2: Business Impact Analysis Summary

The BIA is where you discover what’s actually critical. The BCP should summarize the BIA findings — not replicate the entire analysis, but capture the key outputs:

• Top 10–15 critical business processes
• RTO and RPO for each
• Maximum tolerable downtime (MTD)
• Revenue impact per hour of downtime
• Regulatory impact (i.e., processes where failure triggers reporting obligations)

If your organization hasn’t completed a BIA, your BCP is built on assumptions. Don’t guess. Do the BIA first.

Section 3: Recovery Strategies

For each critical process in your BIA summary, document how you recover it. This is the operational heart of the plan.

Good recovery strategies include:

• Primary recovery method (fail over to secondary site, activate cloud backup, etc.)
• Manual workaround if technology isn’t available
• Minimum staffing required to execute
• Decision authority for activating the strategy
• Estimated activation time

Example: If your loan origination system goes down, your recovery strategy might be: manual loan intake forms + fax transmission to secondary processor + branch staff trained on manual intake quarterly. That’s a strategy. “Use the backup system” is not.

Section 4: Crisis Communication Plan

When things go wrong, bad communication makes everything worse. This section answers:

• Who is notified first? Activation chain from incident detection to executive leadership
• What do you tell customers? Draft holding statements for different scenarios (system outage, data breach, extended closure)
• How do you reach employees? Primary and backup channels (most teams learned during COVID that email alone doesn’t cut it)
• Regulatory notifications: Who files what with which regulator, and by when? (Many regulators have mandatory notification windows — know yours before the incident)
• Media/PR escalation: Who is authorized to speak publicly?

Assign a Communications Lead. Give them a backup. Write the templates ahead of time. Nobody drafts a good customer notification in the middle of a crisis.

Section 5: Roles and Responsibilities

“Everyone is responsible” means no one is. This section names names and assigns specific duties.

Role	Responsibility	Backup
Business Continuity Manager	Owns the plan, coordinates activation, tracks recovery	Deputy BCM
Incident Commander	Declares incidents, makes go/no-go decisions	Senior Operations Officer
IT Recovery Lead	Executes technical recovery procedures	DR Coordinator
Communications Lead	Manages internal and external communications	Marketing Director
Vendor Manager	Activates vendor SLAs, escalates third-party issues	Procurement Lead
Business Unit Recovery Leads	Execute unit-level recovery checklists	Designated backup per unit

Every role needs a primary and a backup. People take vacations. People get sick. The backup needs to be trained.

Section 6: Testing Schedule

An untested BCP is a hypothesis. Your testing schedule should include:

Test Type	Frequency	Who Participates	What Gets Tested
Tabletop exercise	Semi-annually	Leadership + BU recovery leads	Decision-making, communication flow
Functional test	Annually	IT + operations + key vendors	Actual system failover, manual workarounds
Full simulation	Every 2–3 years	All staff across all sites	End-to-end recovery from trigger to restore
Call tree test	Quarterly	All roles on the call tree	Can you reach everyone in the chain?

Each test generates a report. Each report identifies gaps. Each gap gets a remediation owner and a deadline. That loop — test, document, fix, retest — is what makes a BCP program real rather than performative.

Section 7: Vendor Dependencies

The Change Healthcare outage was a wake-up call: single-vendor dependency on a critical third party is a business continuity risk, full stop. This section maps:

• All vendors supporting critical processes
• What happens if that vendor goes down (alternate vendor, manual backup, acceptable downtime window)
• Whether you’ve reviewed the vendor’s own BCP
• SLA commitments and how you enforce them
• Escalation contacts at the vendor when normal channels fail

This isn’t just due diligence busywork. The FFIEC explicitly expects financial institutions to assess the business continuity capabilities of their critical service providers. If your vendor’s BCP is a PDF they emailed you three years ago, that’s a finding waiting to happen.

Section 8: Plan Maintenance

Plans expire. The question is whether yours expires quietly (nobody notices) or deliberately (you control it).

Maintenance requirements:

• Annual full review: Full refresh of all sections, re-validate BIA outputs
• Triggered updates: After any significant change — new vendor, system migration, org restructure, M&A activity, major incident
• Version control: Document who changed what and when
• Distribution: Confirmed that every role has the current version (and knows where to find it offline)
• Board/senior management sign-off: Approval documented in meeting minutes

TSB’s failure wasn’t that they lacked a plan — it was that their plan apparently didn’t account for the actual scope of what could go wrong during a migration of that scale. Regular, rigorous maintenance would have surfaced that gap before regulators did.

---

Business Continuity Plan Template: Quick-Reference Checklist

Section	Key Output	Common Gap
1. Scope & Objectives	Defined coverage, measurable goals, named plan owner	Too vague — “all operations” with no specifics
2. BIA Summary	RTOs, RPOs, MTDs for top 15 critical processes	BIA never completed or 3+ years stale
3. Recovery Strategies	Per-process recovery steps + manual workarounds	Strategies exist for IT; nothing for people/process
4. Communication Plan	Call trees, customer templates, regulatory notification matrix	No pre-written templates; no regulatory timelines
5. Roles & Responsibilities	Named roles with named backups	Roles defined; backups missing
6. Testing Schedule	Scheduled tests, documented results, gap remediation	Tabletop only; no functional or simulation tests
7. Vendor Dependencies	Critical vendor map, BCP reviews, SLAs, alternates	Vendor list exists; BCPs never reviewed
8. Plan Maintenance	Review schedule, version control, board approval	Approved once; never updated

---

So What? (The Part That Actually Matters)

A business continuity plan template gives you the structure. What makes the difference between a document and a functioning program is execution discipline: complete the BIA, name real owners, test against real scenarios, and treat the plan as a living document.

For financial institutions, the stakes are clear. The FFIEC’s 2019 BCM booklet signals that examiners expect to see a mature, tested, actively managed program — not a binder on a shelf. Enforcement actions like TSB’s £48.65 million penalty demonstrate that when operational resilience fails at scale, regulators don’t accept “we had a plan” as a defense. They ask what the plan looked like, when it was last tested, and whether it was followed.

The organizations that absorbed the CrowdStrike outage in 2024 with minimal disruption weren’t the ones with fancier technology — they were the ones who had tested their manual fallback procedures and knew who to call when automated systems failed.

Build the BCP that gets used, not the one that gets filed.

The Business Continuity & Disaster Recovery Kit ($79) includes pre-built templates for all 8 sections, a BIA workbook, testing documentation, and a vendor dependency tracker — everything you need to build a defensible program without starting from scratch. Need the full compliance toolkit? The Compliance Essentials Bundle ($169) bundles BCP/DR with incident response, data privacy, and more.

---

Keep Reading

This is the pillar page for our Business Continuity cluster. Dig into the supporting guides:

• Business Impact Analysis Template: How to Run a BIA That Drives Real Priorities — the analysis that tells your BCP what to prioritize
• RTO vs. RPO: What the Difference Means for Your Recovery Plan — if you’re setting recovery objectives, start here
• Disaster Recovery Plan Template: The Complete DRP Guide — IT-focused sister document to your BCP

Coming soon: business continuity testing, tabletop exercise facilitation guides, BC vs. DR explained, crisis communications, FFIEC BCM program walkthrough, ISO 22301 alignment, financial services-specific BCP requirements, and third-party business continuity oversight.

---

Frequently Asked Questions

What is a business continuity plan template?

A business continuity plan template is a pre-structured document that guides organizations through building a BCP. A good template covers all 8 core sections — scope, BIA summary, recovery strategies, communication plan, roles/responsibilities, testing schedule, vendor dependencies, and plan maintenance — so you can fill in your organization’s specifics rather than building from a blank page.

How often should a business continuity plan be updated?

At a minimum, annually. The FFIEC BCM booklet (2019) expects financial institutions to maintain current, tested plans. Triggers for an immediate update include: significant IT changes or system migrations, new critical vendors or loss of existing vendors, major org restructuring or M&A activity, and after any incident that activated the plan. A BCP that hasn’t been reviewed in two or more years is effectively outdated.

What’s the difference between a business continuity plan and a disaster recovery plan?

A business continuity plan covers the entire organization — people, processes, communications, operations, and IT. A disaster recovery plan focuses specifically on restoring IT systems and data after a disruption. DRP is a component that feeds into your broader BCP. Think of BCP as the operational playbook and DRP as the technical runbook underneath it. See our full DRP guide for a detailed breakdown.