Building a Business Continuity Plan (BCP)

In brief:

1. A business continuity plan (BCP) describes the procedures and resources a company mobilises to keep its essential activities running during and after a major crisis.
2. Its scope starts with a business impact analysis (BIA), which identifies critical activities and the acceptable recovery time for each one.
3. It covers a range of crisis scenarios, cyberattack, physical disaster, prolonged outage or staff unavailability, each with its own response strategy.
4. A BCP is tested at least once a year and updated after every significant change, or it risks becoming inoperative on the day it is actually needed.

A business continuity plan organises a company’s response to an event that could interrupt its operations: a cyberattack, fire, flood, a prolonged outage at a supplier, or the unavailability of part of its staff. Rather than improvising during the crisis, the company works from a document that sets out which activities to maintain first, with what resources and under what procedures. This article details the scope to cover, the scenarios to anticipate, and the concrete steps to build and test a BCP.

What is a business continuity plan (BCP)?

A business continuity plan records the procedures, staff and technical resources a company mobilises to maintain its essential activities, or restore them within a defined timeframe, after an event that disrupts its normal operation. It answers a precise question: if a given system, site or team became unavailable tomorrow, how would the company keep running.

A BCP differs from a simple IT fallback procedure in its scope. It covers human dimensions (who replaces whom, who decides, how to communicate), organisational dimensions (which backup premises or sites, which alternative suppliers) and technical dimensions (which information systems take priority, with what recovery times), whereas an isolated technical plan often addresses only the IT dimension. A complete BCP covers three phases: immediate emergency measures, operating in degraded mode while the situation stabilises, and the gradual return to normal activity. This cross-functional approach, which goes beyond the IT perimeter alone, fits within a broader Enterprise Service Management logic, where the continuity of services delivered to the business matters more than the mere availability of tools.

Why set up a BCP?

Formalising a BCP addresses several needs that overlap in practice.

The first is protecting vital activities and, in some sectors, people’s safety: a hospital, an energy operator or a public administration cannot suspend certain functions, even temporarily, without serious consequences. The second is limiting financial loss and reputational damage: every hour a critical service is unavailable has a direct cost, in lost revenue or contractual penalties, and an indirect cost to customer and partner trust.

Finally, a BCP addresses regulatory obligations that apply across many sectors: financial institutions supervised by regulators such as France’s ACPR, healthcare providers, public administrations and operators of vital importance must demonstrate they have a formalised, tested continuity setup. Recent European frameworks, such as the NIS 2 directive on cybersecurity or the DORA regulation for the financial sector, reinforce these requirements by mandating regular testing and traceability of continuity arrangements. A company that falls under none of these regulated categories still has a direct interest in having a BCP, whenever an outage of its systems or operations would pose a significant risk to its business. This prioritisation of risk is, in practice, a matter of IT governance: governance is what arbitrates how much investment continuity receives relative to the company’s other priorities.

Defining the scope of a BCP: essential activities and the BIA

An effective BCP does not try to cover every single activity in the company with the same level of rigour: it concentrates resources on what is genuinely critical. This prioritisation relies on a business impact analysis (BIA), the starting point of any continuity approach.

A BIA involves listing the company’s processes, then assessing, for each one, the consequences of an interruption over time: financial loss, customer impact, contractual or regulatory obligations, or risk to people’s safety. This analysis distinguishes essential activities, whose interruption is unacceptable beyond a few hours, from secondary activities that can wait several days without major consequence.

For each essential activity, the BIA sets two indicators that shape the rest of the approach:

• RTO (Recovery Time Objective): the maximum time an activity can remain down before the consequences become unacceptable.
• RPO (Recovery Point Objective): the maximum amount of data, measured in time, a company can afford to lose between the last backup and the incident.

These two indicators directly drive the plan’s technical and organisational choices: an RTO of two hours on a payment service calls for backup infrastructure that is almost immediately available, while an RTO of two days on an administrative process leaves more room for a manual recovery. This prioritisation echoes the logic of governance frameworks such as COBIT, which likewise recommend calibrating risk-management effort to the actual criticality of each activity, rather than applying the same level of rigour everywhere.

Identifying the crisis scenarios to cover

Once the scope is defined, a BCP must anticipate the events likely to trigger its activation. These scenarios generally fall into several families, which are worth treating separately since they call for different responses.

Physical disasters affect premises or infrastructure: fire, flood, water damage, a prolonged power outage or a major site failure. IT-related crises cover cyberattacks, ransomware in particular, technical failures and failures at a hosting provider or cloud service provider. A poorly controlled IT perimeter, of the kind revealed by shadow IT, widens exposure to this type of scenario, since tools adopted outside the managed perimeter often escape the security and backup measures built into the BCP. Health or social crises make part of the workforce unavailable, through illness, a strike or travel restrictions. Finally, supply chain failures interrupt the supply of goods or services essential to the business, even when the company itself is not directly affected.

For each family of scenarios, the BCP specifies the signals that trigger its activation, the first actions to take and who is responsible for taking them. An unanticipated scenario does not mean a total lack of response: a well-designed crisis management structure, with clear roles and a fast decision chain, remains able to react to an unforeseen event, even one the plan did not explicitly detail.

Steps to build a BCP

Building a BCP follows a structured approach, based on the scope and scenarios defined in the previous steps.

1. Conduct the business impact analysis

This first step, described above, lists the company’s processes, assesses their criticality and sets recovery objectives (RTO, RPO) for each essential activity. It involves the managers of each department, who are best placed to accurately assess the real impact of an interruption within their area.

2. Define continuity strategies

For each essential activity, the company chooses a maintenance or recovery strategy: a backup site, widespread remote work, switching to redundant IT infrastructure, temporary reliance on an external provider, or a manual degraded procedure. The choice depends on the RTO set by the BIA and the cost of each option: a near-instant technical failover is generally more expensive to maintain than a manual recovery spread over several days.

3. Write the plan and its procedures

The plan formalises, for each scenario, the actions to take in order, who is responsible for each action, internal and external communication channels, and contact details for key parties: the crisis management team, critical suppliers, and the relevant authorities depending on the sector. A typical BCP template includes a crisis unit and its roles, an alert procedure, response sheets per scenario and activity, and a communication plan for customers, employees and, where required, regulators.

4. Roll out and share the plan

A BCP only has value if the people expected to apply it actually know it. Rolling it out comes with training for the teams involved, especially members of the crisis unit, and guaranteed access to the document even if the usual systems are unavailable (a printed copy or hosting outside the area affected by the disruption).

Testing and maintaining the BCP in working order

A BCP that is written but never tested carries a high risk of failing exactly when it is needed: outdated procedures, contacts who have changed roles, undersized backup infrastructure. Testing in working conditions is an integral part of the approach, just as much as writing the plan itself.

Exercises take several forms, best combined according to the stakes involved: the tabletop exercise, which brings the crisis unit together around a fictional scenario without mobilising real infrastructure; the technical test, which verifies the actual failover of a system to its backup setup; and the full-scale exercise, which simulates a real interruption of an activity for a limited period. Most frameworks recommend testing the setup at least once a year, and reviewing it after any significant change: a new organisation, a new information system, a new site, or a notable shift in the risks identified during the last BIA. This principle of continuous improvement echoes the one behind service management standards such as ISO 20000, which likewise make periodic review a condition of certification.

Each exercise produces a report listing the gaps found between the plan and the situation observed, followed by an update to the document. A BCP that never changes, while the organisation keeps evolving, quickly loses relevance and becomes a box-ticking document rather than an operational tool.

BCP and DRP: two complementary plans

The business continuity plan is often confused with the disaster recovery plan (DRP), even though the two cover different but complementary scopes. The BCP covers the whole organisation: it defines how essential activities, both human and material, continue during and after a crisis, whether that means relocating a team, running a service in degraded mode, or communicating with customers. The DRP, more technical in nature, focuses on restoring information systems and IT infrastructure after a disruption, with its own recovery time and data loss objectives.

In practice, the DRP sits inside the BCP as one of its components, the one that specifically addresses the IT dimension. A BCP without a solid technical component remains vulnerable as soon as a crisis hits the information systems, while a standalone DRP, without any thought given to business continuity, does not guarantee the company’s actual recovery.

Frequently asked questions