BCM-001 Business Continuity Plan
Description
A documented Business Continuity Plan identifies the organisation's critical services, recovery priorities and the procedures required to maintain or restore operations during a disruption. The plan includes recovery roles, communication protocols and escalation paths. It states which security controls remain in force during degraded, failover and recovery operation and how each is maintained, and for any control deliberately suspended it names the compensating measure and the approver. It names the related response plans it interlocks with, including the incident response plan and the disaster recovery plan, records the owner of each and the points at which control passes between them, and its development and its exercises are scheduled with those owners. It is reviewed and updated at least annually.
Rationale
Without a tested plan, disruption response is improvised and slow, and a maintained plan is the document all continuity activity references. Security controls are the part most often dropped under pressure: failover to a secondary region regularly loses centralised logging or breaks a break-glass boundary, so writing down which controls hold and which are suspended turns a surprise into a decision. Interlocking with the other response plans matters because a real disruption invokes several at once and the handover points are where they fail.
Applicability (9 profiles)
Art. 30(3)(c) makes the contingency plan a contract term for any service supporting a critical or important function. RTS 2025/532 Art. 4(1), point (h), pushes the same requirement into the provider's contracts with its own subcontractors, with service levels attached.
164.308(a)(7)(ii)(C) makes the emergency mode operation plan a required specification, and its object is the security of the data during degraded operation rather than the availability of the service. BCM-001's clause naming which controls stay in force, and the compensating measure for any suspended, is what answers it.
Annex point 4.3 adds a crisis management process with two outward limbs the plan does not carry: communication means with the competent authorities covering both obligatory communications such as incident reports and their timelines and non-obligatory ones, and a process for managing and using information received from the CSIRTs or competent authorities about incidents, vulnerabilities, threats or mitigations. Point 4.3.2(a) extends the role allocation to suppliers and service providers.
Framework Mappings (24)
| BCR-01 | Business Continuity Management Policy and Procedures | full |
| BCR-03 | Business Continuity Strategy | full |
| BCR-04 | Business Continuity Planning | full |
| BCR-05 | Documentation | full |
| DCS-18 | Datacenter Operations Resilience | partial |
| BCR-01 | Business Continuity Management Policy and Procedures | full |
| BCR-03 | Business Continuity Strategy | full |
| BCR-04 | Business Continuity Planning | full |
| BCR-05 | Documentation | full |
| DCS-18 | Datacenter Operations Resilience | partial |
| DORA-Art.30.3.c | Business contingency plans and ICT security measures | informative |
| DORA-RTS-2024/1773-Art.6.2 | Required level of assurance on the provider's risk management | informative |
| HIPAA-164.308.a.7.i | Contingency Plan | full |
| HIPAA-164.308.a.7.ii.C | Emergency Mode Operation Plan | full |
| HIPAA-164.312.a.2.ii | Emergency Access Procedure | informative |
| 5.29 | Information security during disruption | full |
| NIS2-Art.21.2.c | Business Continuity and Crisis Management | partial |
| NIS2-CIR-4.1 | Business Continuity and Disaster Recovery Plan | partial |
| NIS2-CIR-4.3 | Crisis Management | partial |
| CP-1 | Policy and Procedures | partial |
| CP-2 | Contingency Plan | full |
| CP-2(1) | Contingency Plan | Coordinate with Related Plans | full |
| CP-4(1) | Contingency Plan Testing | Coordinate with Related Plans | full |
| RA-9 | Criticality Analysis | partial |
Evidence (3)
Documented Business Continuity Plan identifying critical services, recovery priorities, roles, communication protocols, and escalation paths.
Example: Business Continuity Plan document (version-controlled, formally approved by senior management or board, dated within the last 12 months) with named roles, escalation contact list, and critical service register
Test: Request the current continuity plan. Verify: (1) critical services are identified and prioritised, (2) recovery roles and responsibilities are named with current contact information, (3) communication and escalation protocols are documented, (4) the document has been reviewed and approved within the last 12 months, (5) the document was updated following the last exercise or significant incident, (6) the related plans it interlocks with are named with the owner of each and the points at which control passes between them.
BCP review record showing the plan was formally reviewed and updated within the last 12 months.
Example: BCP review sign-off record or document version history showing the last review date, reviewer name, change summary, and approver sign-off
Test: Request the BCP version history and most recent review record. Verify: (1) a formal review was conducted within the last 12 months; (2) a named approver signed off the current version; (3) any changes from the prior review are documented.
Security-during-disruption schedule held with the continuity plan, listing the controls that stay in force in degraded, failover and recovery operation and the mechanism that maintains each.
Example: BCP annex C, security control posture under failover, v4 dated 2026-07-11
Test: Request the security-during-disruption schedule. Verify: (1) it names the controls that stay in force and the controls deliberately suspended rather than covering only the first group, (2) each suspended control carries a compensating measure and a named approver, (3) logging, access control and encryption each appear with a stated mechanism for failover operation, (4) the most recent continuity exercise record shows the schedule was applied and names any control that failed to hold, (5) a control that failed in the exercise resolves to a plan change or a recorded acceptance.
Questions (3)
Does your organisation have a documented business continuity plan?
The BCP should be formally approved by senior management, version-controlled, and updated following any significant incident or organisational change.
When was the Business Continuity Plan last formally reviewed and approved?
Annual review is the minimum requirement. A review triggered by a significant incident or major organisational change within the review period also satisfies this requirement.
Which of the following does your business continuity plan record?
Options run from the most commonly present to the least. Failover regularly costs centralised logging or a break-glass boundary, so the security posture under disruption is worth writing down before it is discovered during one. The handover points between plans are where multi-plan incidents fail.