Key takeaways
- A business continuity plan (BCP) sets out how an organisation keeps delivering its products and services at an agreed level during a disruption, and who does what.
- Disaster recovery is part of business continuity: it restores information systems, while the BCP covers processes, people, sites and suppliers.
- A BCP rests on a business impact analysis, recovery objectives (RTO and RPO), roles and activation conditions, recovery procedures and resources, and regular testing.
- NIS2 Article 21(2)(c) lists business continuity, backup management, disaster recovery and crisis management among the risk-management measures; Implementing Regulation (EU) 2024/2690 details the plan's contents for certain digital providers.
- DORA Article 11 requires financial entities to have an ICT business continuity policy and to test their plans at least yearly.
- ISO 22301 is the voluntary, certifiable standard for business continuity management systems: its specific requirements sit almost entirely in clause 8.
A business continuity plan (BCP) is the document that says how your organisation keeps delivering its products and services, at a level agreed in advance, while something stops it: ransomware, a data centre failure, a fire, a supplier that goes down. It names who decides, which activities come back first and within what time, what resources are needed and how the plan is tested.
For a mid-market company it is no longer only good practice. The NIS2 Directive lists business continuity among the cybersecurity risk-management measures, the DORA Regulation requires it of financial entities, and ISO 22301 makes it certifiable. Below: what a BCP is, how it differs from a disaster recovery plan, what it contains, how to test it and what each framework asks.
What a business continuity plan is
NIST Special Publication 800-34 Rev. 1, the contingency planning guide of the US National Institute of Standards and Technology, defines a BCP as "The documentation of a predetermined set of instructions or procedures that describe how an organization’s mission/business processes will be sustained during and after a significant disruption." The key word is processes: a BCP starts from the business, not from the servers.
Three terms tend to overlap, so it helps to separate them:
- Business continuity: the outcome. The company keeps working through a disruption, possibly at reduced capacity, and returns to normal within agreed times.
- Business continuity management (BCM): the process that produces that outcome and keeps it current: impact analysis, strategies, plans, exercises and review.
- Business continuity plan (BCP): the written output that people follow when the disruption happens.
When BCM is organised so that an external body can audit it, it becomes a business continuity management system (BCMS), the subject of ISO 22301.
BCP and disaster recovery plan: the difference
This is the most common confusion, and it has practical consequences: a company with a solid disaster recovery plan often assumes it also has business continuity.
- The business continuity plan looks at processes: how you keep taking orders, shipping, invoicing and paying staff while something is not working. It covers manual workarounds, backup people, an alternative site and replacement suppliers.
- The disaster recovery plan (DRP) looks at information systems. NIST SP 800-34 describes it as a plan focused on information systems, designed to restore the target system, application or computer facility at an alternate site after an emergency.
In short, disaster recovery is one part of business continuity, not a synonym for it. The NIS2 Directive reflects the same logic: Article 21(2)(c) names "business continuity, such as backup management and disaster recovery, and crisis management", with disaster recovery inside business continuity and crisis management alongside it.
What a business continuity plan contains
The most concrete EU reference is Commission Implementing Regulation (EU) 2024/2690. It applies to a defined group of digital providers (among them cloud computing, data centre, managed service and managed security service providers) and sets the technical requirements of the NIS2 Article 21 measures for them. Point 4.1.2 of its Annex lists what the business continuity and disaster recovery plan includes, where appropriate:
- purpose, scope and audience;
- roles and responsibilities;
- key contacts and internal and external communication channels;
- conditions for activating and deactivating the plan;
- order of recovery for operations;
- recovery plans for specific operations, including recovery objectives;
- required resources, including backups and redundancies;
- how activities are restored and resumed from temporary measures.
Even if your company is not one of those providers, the list works as a checklist, because it maps onto the building blocks every BCP needs. Here they are in practice.
Business impact analysis (BIA)
The BIA is where the plan starts. For each activity, it asks what damage a stoppage causes as hours and days pass, and how much downtime is tolerable. The same Implementing Regulation (point 4.1.3) requires a BIA to assess the potential impact of severe disruptions and to set continuity requirements for network and information systems on that basis. A BIA done well tells you which three or four activities really carry revenue and obligations, and which can wait a week.
Recovery objectives: RTO and RPO
From the BIA come the two numbers the IT side works with. NIST SP 800-34 defines them as follows (our summary):
- Recovery time objective (RTO): the maximum time a system resource can stay unavailable before the impact on the processes it supports becomes unacceptable.
- Recovery point objective (RPO): the point in time before the disruption to which data can be recovered, in other words how much data loss the process can tolerate.
NIST also uses maximum tolerable downtime (MTD) for the business process as a whole: the RTO of each system is set so that the process stays within its MTD. These values are agreed with the owners of each process, not set by IT alone, and they then drive the choice of backup frequency, replication and alternative sites.
Roles, activation and communication
A plan nobody knows how to start is not a plan. It names who can declare a disruption and activate the plan, who leads the response, who deputises when that person is unavailable, and who talks to staff, customers, suppliers and authorities. Contact details belong in the plan itself, on channels that still work when email and the directory are down.
Recovery procedures and resources
For each critical activity: the order in which things come back, the step-by-step procedure, the people, sites, systems, data and suppliers it depends on, and the temporary arrangements used in the meantime. The last point in the list above is often forgotten: how you move back from the workaround to normal operations, including the data entered manually during the outage.
Testing and review
Point 4.1.4 of the Implementing Regulation asks that the plans be tested, reviewed and, where appropriate, updated at planned intervals and after significant incidents or significant changes to operations or risks, incorporating lessons learnt from the tests. A plan that has never been exercised is a hypothesis.
How to build a BCP, step by step
- Scope and mandate from management. Which products, services and sites are in, and who owns the programme. Without a mandate from the top, the choices that cost money (redundancy, an alternative site, supplier contracts) do not get made.
- Business impact analysis. Critical activities, tolerable downtime, dependencies.
- Risk assessment. Which threats can hit the critical activities, and how likely they are.
- Objectives and strategies. RTO and RPO system by system, and the means to meet them: backups, replication, secondary site, manual procedures, alternative suppliers.
- Plans. Business continuity, disaster recovery and crisis management, with roles, contacts and activation conditions.
- Exercises and review. Tabletop exercises and recovery tests, a record of what did not work, an updated plan.
A practical tip: plan for effects rather than causes. Causes are too many to list, effects are few: systems unavailable, site inaccessible, key people unavailable, a supplier down. A plan that covers those four effects also covers causes nobody had imagined.
What NIS2, DORA and ISO 22301 ask
NIS2
Directive (EU) 2022/2555 asks essential and important entities to adopt cybersecurity risk-management measures based on an all-hazards approach, and Article 21(2)(c) includes business continuity, backup management, disaster recovery and crisis management among them. Under Article 20 the management bodies approve these measures and oversee their implementation. How the measure is detailed depends on each Member State's transposing law and, for the digital providers covered by Implementing Regulation (EU) 2024/2690, on its Annex, quoted above. Our NIS2 page explains how a readiness programme is organised.
DORA
For credit institutions, payment institutions, insurance undertakings and the other financial entities listed in Article 2, Article 11 of Regulation (EU) 2022/2554 requires a comprehensive ICT business continuity policy, implemented through documented arrangements, plans, procedures and mechanisms. Among the points that shape a BCP:
- a business impact analysis of exposures to severe business disruptions (Article 11(5));
- tests of the ICT business continuity plans and the ICT response and recovery plans at least yearly, and after substantive changes to ICT systems supporting critical or important functions (Article 11(6)); for entities other than microenterprises, the test scenarios include cyber-attacks and switchovers between primary infrastructure and redundant capacity;
- plans that pay specific attention to critical or important functions outsourced to ICT third-party service providers (Article 11(4));
- a crisis management function for entities other than microenterprises (Article 11(7)).
Article 12(6) adds that recovery time and recovery point objectives are set for each function, taking into account whether it is critical or important and the potential overall impact on market efficiency. Entities under the simplified ICT risk management framework of Article 16 are outside Articles 5 to 15, but Article 16(1) still requires them to ensure the continuity of critical or important functions through business continuity plans and to test those plans on a regular basis. More on our DORA page.
ISO 22301
ISO 22301:2019, amended in 2024 and adopted in Europe as EN ISO 22301, specifies the requirements of a business continuity management system. Its introduction explains that it applies the Plan-Do-Check-Act cycle, which keeps it consistent with other management system standards such as ISO/IEC 27001, and organises the requirements in clauses 4 to 10: context of the organisation, leadership, planning, support, operation, performance evaluation and improvement.
The foreword states that the requirements specific to business continuity now sit almost entirely in clause 8. That is where the BCP lives: business impact analysis and risk assessment (8.2), business continuity strategies (8.3), plans and procedures (8.4), the exercise programme (8.5) and the evaluation of business continuity documentation and capabilities (8.6).
The standard is voluntary. Its introduction lists several ways to demonstrate conformity, from self-declaration to certification by an external body. For a company that answers to NIS2 or DORA, certification produces orderly evidence of plans, tests and management approvals. The path is on our ISO 22301 page.
How to test a business continuity plan
- Tabletop exercise. The people named in the plan walk through a scenario around a table. It costs little and quickly shows unclear roles and missing contacts.
- Recovery test. Restore a system or a data set from backup and time it against the RTO and RPO. This is where the real recovery times emerge.
- Switchover test. Move a service to the secondary site or redundant capacity and back. DORA names this explicitly for entities other than microenterprises.
- Cyber scenario. A ransomware scenario tests the plan where it is most often weak: systems, backups and communication channels hit at the same time. Detection matters here too, because the plan starts only when someone notices the incident; this is the role of a 24/7 SOC.
After each test, record what did not work, assign the fixes and update the plan.
The mistakes that empty a BCP
- Leaving it to IT alone. The result is a good disaster recovery plan and no answer on how to ship or invoice while systems are down.
- Forgetting suppliers. If your ERP is in the cloud or outsourced, continuity also depends on the contract: promised recovery times, exit terms, alternatives.
- A plan stored on the systems it is meant to restore. If the only copy sits on the network encrypted by ransomware, there is no plan. Keep a copy outside the corporate network.
- Writing it for the auditor. The plan is read under pressure by people who are tired and worried: short steps, names, phone numbers.
- Never testing it. Real recovery times come out either in an exercise or during an outage. The first is cheaper.
Where to start
If your business continuity today still means having backups and little else, start with a BIA on the activities that carry revenue, then write a plan with roles and activation conditions, then run a first exercise. If you want to know where your plan stands against NIS2, DORA or ISO 22301, talk to our team.