Business continuity plan template

A business continuity plan that cannot be picked up and followed during an actual disruption is not a plan. It is documentation. Most BCM managers know this because they have inherited one: the sections are all there, the structure looks right, but the dependencies are eighteen months out of date, the recovery sequences have never been walked through, and the contact list still names someone who left two restructures ago.

Most business continuity plans fail not because they lack content, but because nobody can follow them under pressure. A plan that sits in a shared drive collecting dust compounds disruption rather than containing it. This template gives you the structure that works in practice: each section maps to an ISO 22301 requirement, includes guidance on what to actually write, and flags the most common mistakes that make BCPs fail when they are needed.

What is a business continuity plan?

A business continuity plan documents how an organisation will maintain or restore critical operations during and after a disruption. It is the operational output of the business continuity management programme: the business impact analysis identifies what matters and how fast it must recover; the BCP documents how that recovery actually happens, who is responsible, and what resources are needed.

ISO 22301:2019 Clause 8.4 requires documented procedures for managing a disruption and restoring operations within defined timeframes. The template below maps directly to those requirements. DORA Article 11 requires financial entities to maintain ICT business continuity plans with specific recovery procedures for critical functions. The same structure serves both frameworks.

Read our full breakdown of what a business continuity plan is

Business continuity plan template: section by section

The following structure covers what a complete BCP needs to contain. Each section includes guidance on what to write and the most common gap that makes that section fail in practice. Copy this structure and fill it with your organisation's actual data, starting from BIA outputs.

1. Plan overview and scope

Define what this plan covers, what it does not cover, and when it should be activated. A BCP can cover the entire organisation or a single business unit, site, or critical process. Be explicit about boundaries so there is no ambiguity during an incident about which plan applies.

This section should cover:

• Plan name, version number, and last review date
• Scope: which business units, processes, locations, and systems this plan covers
• Activation criteria: what conditions trigger this plan (e.g. loss of primary site for >4 hours, critical system outage exceeding RTO)
• Plan owner and approval authority
• Distribution list: who has access to this plan and where it is stored

Common gap: a scope so broad that it covers everything and therefore tells nobody what to do first. Narrow the scope to what this specific plan activates. If your organisation needs multiple plans, create one per critical process or site rather than one document that tries to cover everything.

2. Roles and responsibilities

Name the people, not the positions. A plan that says "the IT Director will authorise failover" fails when that person is on leave and nobody knows who the alternate is. Every role needs a primary and an alternate with current contact details.

What to include:

• Incident commander: who declares activation and has overall authority
• Recovery team leads: one per critical process or function, with named alternates
• Communications lead: responsible for internal and external messaging
• Liaison roles: who contacts suppliers, regulators, customers
• Contact details: phone, email, and out-of-hours numbers for every named person

Common gap: listing job titles instead of names, or naming people without specifying their decision authority. The person reading this plan at 2am during an incident needs to know who to call and what that person can authorise.

3. Business impact summary

This section captures the critical data from your business impact analysis: which processes are critical, what their recovery time objectives (RTOs) and recovery point objectives (RPOs) are, and what dependencies underpin them. This is not a repeat of the full BIA. It is the operational extract that recovery teams need during an incident.

Document the following:

• List of critical processes ranked by recovery priority
• RTO and RPO for each critical process
• Maximum tolerable period of disruption (MTPD) where defined
• Key dependencies for each process: people, technology, suppliers, facilities
• Financial and operational impact if RTO is breached

Common gap: copying BIA data once and never updating it. Recovery priorities shift when the organisation restructures, launches new products, or changes suppliers. If the BIA data in this section is more than 12 months old, it is likely wrong.

4. Recovery strategies and procedures

This is the core of the plan: what to do, in what order, and how. Each critical process needs a recovery procedure that a competent person can follow without needing to improvise. Write procedures as numbered steps, not paragraphs.

What to include for each critical process:

• Recovery strategy: the approach (e.g. failover to secondary site, activate manual workaround, invoke supplier SLA)
• Step-by-step recovery procedure: numbered actions in sequence
• Resources required: systems, equipment, access credentials, physical resources
• Success criteria: how do you know recovery is complete and the process is back to normal
• Fallback if primary strategy fails: what is plan B

Common gap: writing strategies without procedures. "Failover to DR site" is a strategy. The procedure is the 15-step sequence that makes it happen, including who authorises it, what order systems come back in, and what validation checks confirm it worked. Without procedures, recovery depends on whoever happens to be available knowing what to do from memory.

5. Dependencies and resource requirements

A dedicated section mapping what each critical process depends on: technology, people, third-party suppliers, facilities, and equipment. During an incident, this section answers the question: if we have lost X, what else is affected?

This section should capture:

• Technology dependencies: systems, applications, network, data
• People dependencies: minimum staffing, specialist skills, single points of failure
• Supplier dependencies: critical third parties, their SLAs, and escalation contacts
• Facility dependencies: primary site, alternate site, minimum workspace requirements
• Upstream and downstream impacts: what feeds into this process and what it feeds

Common gap: listing dependencies without mapping the cascade. If System A goes down, what processes depend on it? If a supplier fails, which processes lose their input? Dependency mapping at scale is where most manual plans break down, particularly for organisations managing dozens of critical processes across multiple sites. This is the section where automated dependency mapping from BIA data becomes genuinely useful.

6. Communication plan

Who needs to know, what they need to know, and when. Communication failures during incidents cause more damage than the incident itself when customers, regulators, or staff find out from external sources before internal teams have a coordinated message.

What to include:

• Internal communication: who is notified at activation, how (call tree, mass notification, email), and what the initial message contains
• External communication: customers, suppliers, regulators, media. Who approves messaging and what the holding statement says
• Escalation triggers: at what point does communication escalate to the board, regulators, or public
• Communication channels: primary and backup (if email is down, what is the alternative)
• Template messages: pre-drafted holding statements for common scenarios to avoid drafting under pressure

Common gap: no pre-approved holding statements. During a real incident, legal review of external communications takes hours. A pre-approved template that covers the first 24 hours buys time without exposing the organisation to unvetted messaging.

7. Testing and exercise schedule

A plan that has never been tested is an assumption, not a capability. This section documents how and when the plan will be validated through exercises. At minimum, ISO 22301 Clause 8.5 requires an exercise programme that tests plans and identifies improvements. Map your exercise programme to the plan's critical processes and run at least one tabletop exercise annually against each major recovery scenario.

Cover the following:

• Exercise schedule: type, scope, frequency, and target date for each exercise
• Last exercise date and summary of findings
• Open corrective actions from previous exercises
• Criteria for unscheduled testing (e.g. after major organisational change)

Common gap: running the same scenario every year without escalating difficulty or acting on findings. An exercise whose after-action report produces no changes is either testing something too easy or ignoring what it finds.

8. Plan maintenance and review cycle

A BCP degrades from the moment it is published. People change roles, systems are replaced, suppliers are switched, and organisational structures shift. This section defines how and when the plan is kept current.

This section should specify:

• Review frequency: at minimum annually, plus triggered reviews after major change
• Review triggers: restructure, new system deployment, supplier change, incident, exercise findings
• Version control: how changes are tracked and who approves updates
• Distribution: how updated versions reach all stakeholders and how outdated copies are retired

Would be a full time job probably for a whole team of people to keep up to date.

That observation from a BCM manager evaluating platforms captures why most plans go stale. Manual maintenance at scale, across dozens of plans and hundreds of dependencies, requires either dedicated headcount or tooling that connects plans to live organisational data.

Whitepaper

Maturity in Exercise Governance: How BCM Programs Build Resilience

Understand why running exercises is the beginning, not the proof, and how the governance process around them determines whether your program is actually building resilience.

Get it now

BCP template mapped to ISO 22301

The table below shows how each template section satisfies specific ISO 22301:2019 requirements. Use it to verify your plan covers what an auditor will look for.

How to fill in this template

The template structure is the easy part. The hard part is populating it with accurate, current data. Every section downstream of the business impact summary depends on having a current BIA. If your BIA data is stale, the plan built on it will inherit those gaps.

Start with the BIA, not the plan

Recovery priorities, RTOs, RPOs, and dependencies all come from the BIA. Writing a BCP without a current BIA means inventing recovery priorities rather than deriving them from actual business impact data. If your last BIA was more than 12 months ago, or predates a major organisational change, refresh it before writing or updating the plan.

Write procedures as numbered steps

The most common BCP failure is strategies described as paragraphs rather than procedures written as steps. During an incident, nobody reads a paragraph. They scan for the next action. Write recovery procedures as numbered sequences that a competent person can follow without interpretation.

Test the plan before signing it off

Run at least a tabletop walkthrough with the recovery team before the plan is approved. If participants cannot follow the procedures without asking clarifying questions, the plan is incomplete. Capture those questions as gaps and fix them before formal sign-off.

Common BCP template mistakes

The failure patterns are predictable. Most BCPs that look complete on paper fail on the same points.

• Generic content copied from a template without adapting to the organisation's actual processes and risks
• No dependencies mapped: the plan names critical processes but not what they depend on or what depends on them
• Recovery procedures written as strategies: "failover to DR" with no step-by-step sequence
• Contact details out of date: people have moved roles, left, or changed numbers since the last review
• No testing evidence: the plan has never been exercised, so nobody knows if the procedures work
• Single version stored in one location: if the disruption affects access to the plan itself, nobody can read it

The reality for most BCM managers: maintaining plans across dozens of departments as a team of one or two. The template above works. Keeping it current at scale is the part that breaks without either dedicated headcount or tooling that connects plans to live data. See the full business continuity software buyer's guide for how to evaluate platforms against this requirement.