Business continuity plan (BCP)

Also known as: BCP, continuity plan

A plan for keeping the most important work going during and after a crisis, even while the systems are down.

Draft - this entry has not been reviewed yet.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

Get top management to appoint an owner for business continuity and decide which services, sites and departments the plan must cover.
Run a business impact analysis with each department to find the critical activities, how long each can be disrupted before the harm is unacceptable (MTPD) and a recovery time objective inside that limit.
Map what each critical activity depends on - people, premises, IT systems, data, suppliers and equipment - and assess the likeliest disruptions, including a cyberattack that takes all IT down for weeks.
Choose a workaround for each activity, such as paper forms, pre-printed lists, another site or moving the work to another unit, and agree the minimum service level it must deliver.
Write the plan per activity with activation and stand-down criteria, roles and deputies, action cards, contact lists and a procedure for entering the manual backlog once systems return.
Hand the recovery time objectives to IT so the disaster recovery plan, backups and supplier contracts are designed to meet them.
Keep printed or offline copies where staff can reach them without the network, email or their usual login.
Exercise the plan at least once a year, from a table-top to a live trial of the manual routines, and revise it after every exercise, incident and organisational change.

Common pitfalls

Building the plan around IT systems instead of the business activities that citizens and customers depend on.
Assuming the disruption will be short and local, when ransomware can remove email, phones and the plan itself for weeks.
Forgetting the catch-up work of keying manual records into the restored systems.
Letting IT set the recovery times without the business having decided what it can tolerate.

Good guides

NIST SP 800-34 Rev. 1 - Contingency Planning Guide for Federal Information Systems(opens in a new tab) · NIST
Kontinuitetsplanlægning - fortsat drift(opens in a new tab) · Styrelsen for Samfundssikkerhed (in Danish)
Beredskabsplaner(opens in a new tab) · Styrelsen for Samfundssikkerhed (in Danish)

Technical deep dive

In ISO 22301:2019 the BCP is the output of a chain of requirements in clause 8. The business impact analysis (8.2.2) identifies prioritised activities, the impact of disrupting them over time and, for each, the maximum tolerable period of disruption (MTPD) and a recovery time objective that must fall within it; the risk assessment (8.2.3) looks at the causes. Clause 8.3 selects strategies and solutions, and clause 8.4 requires documented plans and procedures, including a response structure (8.4.2), warning and communication (8.4.3), the business continuity plans themselves (8.4.4) and recovery (8.4.5). Clause 8.5 requires an exercise programme and 8.6 an evaluation of the documentation and capabilities. ISO 22313 provides guidance on applying the requirements.

A usable BCP is organised around activities, not systems. For each prioritised activity it states the minimum business continuity objective (the reduced service level that is acceptable during disruption), the workaround used to reach it, the people, premises, information, suppliers and equipment the workaround depends on, and the criteria for invoking and standing down the plan. Typical workarounds are paper forms and pre-printed lists, relocation to an alternate site, shifting work to another unit, or accepting a backlog to be processed later. Because manual work creates data that must later be entered into restored systems, the plan also needs a catch-up procedure, which is frequently forgotten.

NIST SP 800-34 Rev. 1 distinguishes the BCP, which covers business processes, from the continuity of operations plan for mission-essential functions, the information system contingency plan for a single system and the disaster recovery plan for relocating systems to an alternate site. The practical boundary is that the BCP answers how the business keeps working, while the DRP answers how IT gets systems back; the recovery time objectives in the DRP must be derived from the BCP and BIA, not the other way round.

Regulation increasingly makes this explicit. NIS2 Article 21(2)(c) lists business continuity, such as backup management and disaster recovery, and crisis management among the minimum cybersecurity risk-management measures, and ISO/IEC 27001:2022 Annex A 5.29 and 5.30 address information security during disruption and ICT readiness for business continuity. A common weakness in plans tested against cyberattacks is the assumption that disruption is local and short, when ransomware can remove all systems, including email, telephony tied to the network and the documents holding the plan itself, for weeks. Plans should therefore be available offline and assume that identity services and communication tools are unavailable.

What to learn first

Everything this builds on, foundations first.

Relationships

Part of: Contingency plan
Consists of: Recovery objectives (RTO/RPO)
Requires: Business impact analysis (BIA)
Unlocks: Crisis management
Don't confuse with: Disaster recovery plan (DRP)
Mandated by: DORA NIS2 minimum requirements
Used with: Crisis management Backup

Sources & further reading

Standards & official texts

ISO 22301:2019
NIST SP 800-34 Rev. 1

Course material

Cyber Security Fast Track - Ordliste

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queue Suggest a correction on GitHub This term as JSON

Check yourself

Loading…