Business Continuity Plan (BCP): 8-Step Guide for 2026

A business continuity plan (BCP) is the documented set of strategies, resources and procedures that lets an organisation keep delivering its essential activities, at a level agreed in advance, during and after a major disruption: a fire, a cyberattack, a supplier failure, mass staff absence. It answers one simple question: if we lose X tomorrow morning, what do we do, who does it, and how fast?

Most business continuity plans fail for a reason that has nothing to do with how well they are written: they are disconnected from the reality they are meant to protect. An on-call directory eighteen months out of date, a 4-hour RTO nobody has ever tested, a cloud supplier missing from the dependency map… This guide walks through the 8-step method aligned with ISO 22301, what NIS2 and DORA require in 2026, and above all how to turn a BCP into a living system rather than a binder.

The 30-second version

• A BCP keeps the business running; a disaster recovery plan (DRP) restarts IT. The DRP is part of the BCP, not a substitute for it.
• Everything starts with the BIA: without RTOs and RPOs justified by business impact, continuity strategies are guesses.
• Think in terms of unavailability (data, IT, third parties, people, premises) rather than threats: causes change, effects don't.
• NIS2 (Article 21) and DORA (Article 11) make continuity a legal obligation, and DORA requires plans to be tested at least once a year.
• A plan that has never been exercised is only a hypothesis.

What is a business continuity plan?

ISO 22301 defines a business continuity plan as documented information that guides an organisation to respond to a disruption and resume, recover and restore the delivery of its products and services consistent with its business continuity objectives. In practice, a BCP pursues three goals, in this order:

1. Protect people: employees, customers, visitors.
2. Keep priority activities running at an acceptable minimum level during the disruption (the MBCO, minimum business continuity objective).
3. Return to normal in a controlled way, without triggering a second crisis during recovery.

A BCP is not an insurance policy (insurance pays out, it doesn't keep operations running), not an IT disaster recovery plan (that covers only part of the problem), and not a 300-page document sitting in a drawer. It is a capability: decisions made in calm conditions, resources positioned in advance, and people who have rehearsed.

The international reference is ISO 22301:2019, a certifiable standard whose clause 8.4 covers business continuity plans and procedures. Practitioners also rely on the Business Continuity Institute's Good Practice Guidelines and on national guidance such as the French SGDSN guide.

BCP vs DRP vs crisis management plan: what's the difference?

This is the most common confusion, and an expensive one: many organisations believe they have a BCP when all they have is an IT disaster recovery plan.

The BCP is the umbrella: it relies on the DRP and IT continuity plan for systems, on the crisis management plan for decisions and on the communication plan for messaging. If all you have is the DRP, you know how to restore your servers, but nobody knows how to invoice, ship or answer customers during the 48 hours the restore takes. For the technical side, see our disaster recovery plan guide.

Is a business continuity plan mandatory in 2026?

For a growing number of organisations, yes. The main sources of obligation in Europe:

• NIS2: Article 21 requires essential and important entities to take risk-management measures that explicitly include "business continuity, such as backup management and disaster recovery, and crisis management". Fines can reach €10 million or 2% of worldwide turnover for an essential entity. Transposition is still incomplete in several member states (France had not finally adopted its law as of mid-October 2026), but that delay protects few: large customers already ask for this evidence in supplier questionnaires. See NIS2: essential vs important entities.
• DORA (financial sector, applicable since 17 January 2025): Article 11 requires an ICT business continuity policy, response and recovery plans, and testing of those plans at least yearly. Article 12 covers backups, Article 14 crisis communication. See our DORA guide 2026 and, for ICT providers, the DORA register of information guide.
• Insurance: Solvency II (Article 41) requires insurers to develop contingency plans.
• GDPR: Article 32 requires the ability to restore the availability of and access to personal data in a timely manner after an incident.
• ISO 22301: voluntary, but increasingly required in tenders and by cyber insurers.

Even without a regulatory obligation, continuity has become a sales question: the day a major customer asks "what is your RTO on the service you provide us?", you need an answer you can prove.

The 8 steps to build a business continuity plan

The method below follows the logic of ISO 22301 (clauses 4 to 10). It works for a 50-person company and for a multinational group alike: only the depth changes.

Step 1 — Scope it: sponsor, perimeter and policy

A BCP without an executive sponsor dies at the first budget trade-off. ISO 22301 makes leadership an explicit requirement (clause 5).

• Appoint an executive sponsor and a business continuity manager, with a correspondent in each business unit.
• Define the scope: which products and services, which entities, which sites. For a first version, start with two or three critical services rather than the whole organisation.
• Write a one- or two-page continuity policy: objectives, scope, roles, review and testing frequency.
• Set your thresholds of unacceptable impact: at what level of loss, customer delay or regulatory breach does an impact become intolerable?

Deliverable: a scoping note signed off by management, and a business continuity policy.

Step 2 — Map activities and their dependencies

For each in-scope activity, identify everything it needs to function:

• key people and skills (including the ones nobody else can cover);
• applications and IT services, and the data they handle;
• suppliers and subcontractors, including SaaS vendors and fourth parties;
• sites, equipment and stock;
• upstream and downstream processes it depends on or feeds.

This is the most underestimated step, and the one where spreadsheets hit their limits: one application supports ten processes, one supplier hosts three applications. A dependency missed here becomes a blind spot on the day. On 19 July 2024, a faulty update from security vendor CrowdStrike took down around 8.5 million Windows devices, according to Microsoft: airlines, hospitals and banks discovered within hours that a component nobody had mapped as critical could stop everything.

Step 3 — Run the business impact analysis (BIA)

The BIA measures what an interruption of each activity costs over time: after 4 hours, 24 hours, 72 hours, a week, a month. Assess impact across several dimensions (financial, customer, regulatory, reputational, health and safety), then derive the metrics that will drive the rest of the plan:

Two rules prevent most mistakes. First, interview the business, not IT: the head of invoicing knows what three days without invoicing costs. Second, compare business RTOs with technical recovery capability: an application that takes 72 hours to restore cannot support a process with a 4-hour RTO. That gap is the most valuable finding of any BIA. Fix it; don't hide it.

Go further: our BIA guide in 7 steps, RTO vs RPO explained, the free BIA template and the RTO/RPO calculator.

Step 4 — Assess risks and select scenarios

Two complementary approaches, run together.

By unavailability. Whatever the cause, an organisation can only ever lose five things. Reasoning about these effects, rather than an endless list of threats, guarantees no response is missing:

By scenario. Then use your risk assessment (ISO 31000, ISO 27005, EBIOS RM) to select a handful of severe but plausible high-risk scenarios, which often combine several unavailabilities: ransomware hits both IT and data; a flood hits premises, people and local suppliers.

The check is simple: every critical activity needs a response for every unavailability, and every selected scenario must be covered by the plan.

Step 5 — Choose continuity strategies

For each unavailability, list the options, cost them, and keep the ones that meet your RTOs at the most reasonable cost (ISO 22301, clause 8.3):

• Premises: recovery site, remote work, reciprocal agreements, moving work to another site.
• People: cross-training, named deputies, documented critical know-how, temporary staff.
• IT systems: redundancy, DR, cloud failover, manual degraded-mode procedures.
• Data: 3-2-1 rule with an immutable or offline copy, and regular restore tests (a backup you have never restored is not a backup).
• Third parties: dual sourcing, buffer stock, contract clauses (service levels, reversibility, the supplier's own continuity plan), and exit strategies for critical providers, which DORA mandates for ICT services.

Golden rule: the shorter the RTO, the more expensive the strategy. Every choice should be justified by the BIA, not by a technical preference. The recovery cost estimator helps make the trade-off objective.

Step 6 — Write plans people can actually use

An effective BCP is short and readable under stress. Recommended structure:

1. Purpose, scope, owner, version and last review date.
2. Activation criteria and alert levels: who can invoke the plan, on which signals?
3. Crisis organisation: roles, primary holders and deputies.
4. Contact directory: internal teams, critical suppliers, authorities, insurer, with numbers reachable outside company IT.
5. Procedures by unavailability and by activity: ordered actions, required resources, time objective.
6. Degraded modes and workarounds.
7. Return to normal: conditions, sequence, checks.
8. Appendices: inventories, one-page action cards per role.

Two sanity checks. The plan must be executable by a deputy woken up at 3 a.m.: action verbs, checklists, no paragraphs. And it must stay reachable when IT is down: a BCP stored only on the intranet that just went offline is useless. Keep offline and printed copies with key people.

Free templates: business continuity plan, disaster recovery plan, crisis communication plan.

Step 7 — Organise alerting and crisis management

The BCP says what to do; crisis management decides when, and in what order.

• A two-tier crisis management team: strategic (executives, trade-offs, external communication) and operational (running the actions). Essential roles: lead, scribe keeping the incident log, communications, legal, HR, IT, business representatives.
• A tested alert chain: on-call rota, call tree, multi-channel notification, and a fallback channel in case corporate email is itself compromised.
• A time-stamped incident log: every decision, action and piece of information received. It is used to steer the response, write the post-incident review and answer the regulator.
• Notification obligations prepared in advance: NIS2 requires an early warning within 24 hours, a notification within 72 hours and a final report within one month; DORA sets comparable or even shorter deadlines for major ICT incidents. Prepare the templates now. See NIS2 incident notification: 24h, 72h, 1 month.
• Pre-drafted messages for staff, customers, partners and media.

To structure decision-making, see our article on the crisis management plan and the RAPID framework.

Step 8 — Test, exercise, improve

This is the step that turns a document into a capability. ISO 22301 (clause 8.5) requires an exercise programme at planned intervals and after significant changes; DORA requires ICT business continuity plans to be tested at least yearly. Build up gradually:

Every exercise should produce a post-exercise review: gaps found, corrective actions with an owner and a deadline, plan updates, then a management review (clause 9.3). The most telling metric for an executive committee is the gap between target RTO and the recovery time actually measured.

Need ideas? See our 10 crisis exercise scenarios.

Why so many business continuity plans fail on the day

Post-incident reviews all sound alike. Six causes come up again and again:

1. The plan is asleep. Nobody owns it, and it hasn't been reviewed since the last reorganisation. Fix: one owner per plan, and reviews triggered by change (new application, new supplier, office move), not just by the calendar.
2. Dependencies are invisible. The SaaS vendor, the fourth party, the single expert. Fix: map process ↔ application ↔ supplier links once, and reuse them everywhere.
3. RTOs are declarative. Announced, never measured. Fix: test, and track the gap between target and actual capability.
4. The plan is unreachable. Stored on the system that just failed. Fix: offline copies, printed versions, a contact directory outside company IT.
5. The plan is unreadable. Two hundred pages nobody opens in a crisis. Fix: one-page action cards per role.
6. There is no evidence for the auditor. Exercises happened, but nothing proves it. Fix: keep a history of versions, approvals, exercises and corrective actions.

What these six failures share: the BCP is treated as a document, when it is really an information system in its own right, a dependency graph that changes every week. A plan that holds is one where every element (activity, application, supplier, risk, procedure, exercise) is linked to the others and updated along with them.

Spreadsheets, Word or business continuity software?

A spreadsheet and a word processor are enough for a first version in a small, single-site organisation with few IT dependencies. Beyond that, the cost of keeping them current quickly exceeds the cost of a dedicated tool:

Go further: spreadsheet vs ResiPlan and our BCM SaaS buyer's guide for SMEs.

What ResiPlan does, concretely

ResiPlan was designed around the idea this guide argues for: one data model, from the BIA to a tested plan and audit-ready evidence.

• Connected BIA: processes pre-filled for your sector, RTO and MTPD calculation, campaigns sent to process owners with an approval workflow and version history.
• Plans pre-filled from the BIA: 8 plan types (business continuity, business recovery, disaster recovery, incident response, emergency response, crisis management, crisis communication, supplier resilience). For five of them, a first draft is generated by AI, then reviewed and approved by your team.
• Linked dependencies: process ↔ IT service ↔ supplier ↔ risk, with coverage of the 5 unavailabilities and high-risk scenarios checked against your strategies.
• Exercises and reviews: tabletop exercises, with findings turned into corrective actions tracked to closure.
• Evidence: ISO 22301 clauses 4 to 10, NIS2 Article 21 and DORA mapped, a downloadable evidence pack, Word and PDF export.
• For consultants: one workspace per client to run several continuity engagements from a single interface.

Business data is hosted in the European Union. An honest caveat: software does not make anyone "compliant" and certifies no one. ResiPlan structures, links and evidences the work your teams do. Free 7-day trial, no credit card.

Checklist: is your business continuity plan ready?

• An executive sponsor and a business continuity manager are appointed.
• The continuity policy is written, approved and dated.
• Critical activities are identified and their dependencies mapped (people, applications, data, suppliers, sites).
• A BIA has set the MTPD, RTO, RPO and MBCO for each critical activity.
• Gaps between business RTOs and technical capability are identified and addressed.
• Every critical activity has a response for each of the 5 unavailabilities.
• High-risk scenarios selected by the risk assessment are covered.
• Chosen strategies are costed and justified by the BIA.
• Critical suppliers have contractual continuity commitments and a fallback option.
• The plan names primary holders and deputies for every role.
• The crisis contact directory is current and reachable outside company IT.
• Notification templates (NIS2, DORA, GDPR) and crisis messages are ready.
• Critical backups have been successfully restored within the last 12 months.
• An exercise took place within the last 12 months and its corrective actions are tracked.
• Management has reviewed the programme within the year.

For a fuller assessment: ISO 22301 checklist, NIS2 self-assessment, DORA readiness checklist.

FAQ

What is the difference between a BCP and a DRP?

A BCP aims to keep essential activities running during a disruption, across the whole organisation (business units, people, premises, suppliers, IT). A DRP aims to restart after an outage, mainly IT systems. The DRP is one component of the BCP.

How long does it take to build a business continuity plan?

For a 50-to-250-person company starting with two or three critical services, expect roughly 6 to 12 weeks for a first exercised version. For a multi-site group, several months. Writing is rarely the bottleneck: business teams' availability for the BIA is.

Who should write the business continuity plan?

The business continuity manager coordinates, but business units write their own procedures: only they know how to work in degraded mode. IT writes the DRP, and management approves the policy and the trade-offs. A plan written by a consultant alone, without the teams, will not be followed. For consultants, see how to scale business continuity engagements.

How often should a business continuity plan be tested?

At least once a year for a meaningful exercise (an obligation for ICT business continuity plans under DORA), and after every major change: a new critical application, a new supplier, an office move, a reorganisation.

Is a business continuity plan mandatory for SMEs?

It is for SMEs in scope of NIS2 (essential or important entities) or DORA, and for some regulated activities. For everyone else, it is becoming a de facto requirement from customers, insurers and public tenders.

Do you need ISO 22301 certification?

No, certification is voluntary. But following the standard's structure ensures your BCP covers what auditors, regulators and large customers expect, and makes certification straightforward later if it becomes a commercial asset: see ISO 22301 certification: steps, timeline and cost.

What should a business continuity plan contain at minimum?

A scope and an owner, activation criteria, a crisis organisation with deputies, a contact directory reachable outside company IT, procedures per critical activity and per unavailability, degraded modes, a return-to-normal procedure, and a record of the latest exercise.

Further reading

• Disaster recovery plan: complete guide
• Crisis management team: roles, structure and activation
• ISO 22301 in 10 steps: implementing a compliant BCMS
• BIA guide in 7 steps, with a free template
• ISO 22301 vs ISO 27001: differences and overlap
• DORA vs NIS2: which regulation applies to you?
• Business continuity plan generator

A business continuity plan is only worth something on the day it is used. Until then, its quality comes down to one thing: its ability to stay true while the organisation changes around it.