Business continuity plan (BCP): method and example

A business continuity plan (BCP) is the set of measures, resources and procedures that enable an organisation to keep its essential activities running during a major crisis (cyberattack, outage, disaster, pandemic), in degraded mode if needed, and then return to normal. It is based on a business impact analysis (BIA) that sets, for each activity, a maximum tolerable period of disruption and a maximum tolerable data loss. NIS 2, DORA and the ISO 22301 standard make it an explicit requirement.

The SGDSN guide (France's General Secretariat for Defence and National Security), still the French reference, describes the BCP as the document that sets out the organisation's continuity strategy and all the arrangements for continuing and then resuming its activities after an event that seriously disrupts normal operations. In other words, the BCP answers a simple question: if tomorrow our premises, our IT or a key supplier disappear, how do we keep serving our customers, patients or users?

The BCP is therefore not limited to IT. It covers people (mass absence, loss of key skills), premises, suppliers and service providers, energy, and of course the information system. But in recent years, the scenario that shapes most plans is the ransomware attack: within hours it takes down every application, email and sometimes telephony, and rebuilding takes weeks. This is why the French cybersecurity agency, ANSSI, stresses preparing business continuity alongside the technical response.

These terms are often confused, even in tender documents. Yet they refer to complementary arrangements that come into play at different times and are owned by different people. Select them below to place them on an incident timeline.

IT continuity in the broad sense covers both the ITCP and the DRP: the part of the plan that concerns the information system. On its own it is not enough, because an organisation whose servers restart in four hours can still be paralysed if nobody knows how to process orders in the meantime. Conversely, degraded-mode business procedures only make sense if IT comes back within the promised time.

The business impact analysis (BIA) is the step that sets a real BCP apart from a binder of procedures. It involves listing the organisation's activities, identifying the essential ones, then measuring how their impacts worsen with the length of the interruption: after four hours, a day, a week. The SGDSN recommends assessing these impacts from several angles: human, financial, contractual, legal, environmental, social and reputational.

Essential activities and dependencies

For each essential activity, the BIA identifies the resources it depends on: people and skills, premises, applications and data, service providers, raw materials. These dependencies often reveal unexpected weak points, such as a single managed-services provider or business software hosted by a vendor with no fallback plan. They extend the thinking on availability needs carried out in the DICP classification.

MTPD and maximum data loss, RTO and RPO

The BIA produces two quantified targets per activity:

• the maximum tolerable period of disruption (MTPD): beyond it, the consequences become unacceptable. The recovery time objective (RTO) must stay below it;
• the maximum tolerable data loss: the amount of data, expressed as time, that can be lost. It corresponds to the recovery point objective (RPO) and determines how often backups or replication must run.

ANSSI's draft ReCyF framework, published for the French transposition of NIS 2, asks essential entities to document these two values for each activity or service. The simulator below shows what happens when actual capabilities do not meet these targets.

The SGDSN approach and the ISO 22301 standard agree on the essentials. Here is a seven-step outline that works for an SME as well as a group.

1. Frame the project. Get a mandate from management, appoint an owner, set the scope (sites, subsidiaries, activities) and the obligations to meet (contracts, NIS 2, DORA, sector requirements).
2. Carry out the BIA. Identify essential activities, their dependencies, their MTPD and maximum data loss, through interviews with each business unit.
3. Analyse the risks. Identify the scenarios that could interrupt these activities: ransomware, a provider outage, fire, staff unavailability. An existing risk analysis, for example carried out with EBIOS RM, provides a solid basis.
4. Choose the continuity strategy. For each activity, decide how to meet the targets: fallback site, remote working, IT redundancy, safety stock, a second supplier, manual procedures. Make trade-offs based on cost.
5. Write the plan and procedures. Crisis organisation, activation criteria, quick-reference sheets per business unit, ITCP, DRP, communication plan, contact lists.
6. Put the resources in place. Backup contracts, isolated backups, fallback equipment, staff training.
7. Test, then improve. Exercise the plan, learn the lessons and keep it up to date whenever the organisation or systems change.

A usable BCP consists of a steering document and a set of operational sheets. It typically includes:

• the context and objectives: scope, obligations, essential activities and their recovery targets;
• the crisis scenarios selected and the working assumptions;
• the crisis organisation: executive crisis team, operational teams, roles, deputies, activation and stand-down criteria;
• the continuity strategies and procedures for each activity, including degraded modes;
• the ITCP and DRP, with the order in which applications are restarted;
• the internal and external communication plan, which ANSSI covers in its guide on cyber crisis communication;
• the contact lists of people who can be mobilised and external contacts (insurer, providers, authorities), available on paper: a BCP stored only on the server encrypted by the ransomware is of no use;
• the testing programme and the rules for updating the plan.

An untested plan is a hypothesis. The SGDSN provides for several levels of verification: a critical review of the documents, ideally by a third party; technical tests, such as failing over to a backup site or restoring backups; and exercises that check the procedures are known and can be carried out in time.

Three exercise formats

• The tabletop exercise: the crisis team walks through a scenario around a table. Inexpensive, it quickly exposes the organisation's blind spots.
• The technical test: a full restore of an application from backups, or a site failover, measuring actual times against the RTO and RPO.
• The full-scale crisis exercise: a realistic simulation over several hours, with injected events. ANSSI's guide on organising a cyber crisis exercise explains how to prepare one.

Each exercise leads to a lessons-learned review and an improvement plan. Keeping the BCP operational also means updating it when the organisation changes: a new application, a new provider, a move, a reorganisation.

ISO 22301 specifies the requirements for a business continuity management system (BCMS). It follows the common structure of ISO management system standards, the same as ISO 27001: context, leadership, planning, support, operation, performance evaluation, improvement. The current version dates from 2019; an amendment published in 2024 adds consideration of climate change. In late 2025 ISO decided to revise the standard, and a new version is being drafted.

ISO 22301 does not say how to write a BCP, but how to manage it over time: objectives, responsibilities, BIA, testing, internal audits, management review. It comes with guidance such as ISO 22313 (guidelines) and ISO/TS 22317 (BIA). If you already run an ISMS certified to ISO 27001, whose Annex A also addresses continuity, you will reuse much of the machinery.

NIS 2

Article 21 of the NIS 2 Directive lists among the minimum risk-management measures "business continuity, such as backup management and disaster recovery, and crisis management". In France, ANSSI's draft ReCyF framework, still a working version, details what this covers: backup and restore procedures tested at least once a year, backups protected against incidents that would make them unusable, and, for essential entities, a BCP and DRP suited to cyber-originated crises and consistent with the recovery targets. For the full picture, read our article on NIS 2 and see our compliance campaigns module.

DORA and digital operational resilience

For banks, insurers and other financial entities, the DORA regulation, which has applied since 17 January 2025, is the most detailed. Its Article 11 requires an ICT business continuity policy, response and recovery plans, a BIA, a crisis management function, and tests at least yearly and after any substantive change, including cyberattack and switchover scenarios. Article 12 covers backups, restoring onto separate systems, and setting recovery time and recovery point objectives for each function. See how our vendor risk management module covers ICT third-party providers.

Healthcare

In French healthcare institutions, the CaRE programme run by the national digital health agency (ANS) devotes an entire domain to business continuity and recovery, with a formal continuity and recovery plan for critical activities and regular exercises operating in degraded digital mode. The ANS explains how the BCP exercise carried out in this framework relates to the annual cyber crisis exercise expected of institutions.

Finally, continuity increasingly depends on your suppliers: an unavailable software vendor or hosting provider can stop your activities as surely as a direct attack. Supply chain attacks are the most recent illustration.

Take a fictitious industrial SME with 180 employees that manufactures and ships parts for automotive customers. Its reference scenario: ransomware encrypts the ERP, email and file servers on a Monday morning. Here is a simplified version of its BIA and strategy.

To meet these targets, the SME opts for a daily ERP backup plus an offline copy, out of reach of an attacker who has taken over the network; a contract with a provider able to rebuild the infrastructure within 48 hours; spare workstations not joined to the domain; a five-person crisis team with deputies; and printed quick-reference sheets for shipping and production. The first tabletop exercise reveals that nobody knows whom to call at the insurer: the paper contact list is completed the same day. The restore test shows an actual RTO of 30 hours for the ERP, beyond the shipping MTPD: the company decides to print the next day's orders every evening, which makes the target achievable without heavy investment.