Appearance
Continuity Plans
Where to find it: Operational Resilience, then BCM & Resilience (/bcm), then Plans.
A Continuity Plan (BCP-YYYY-NNNN) is the documented response to a disruption: when to activate, who does what, and in what order.
What a plan carries
| Field | Purpose |
|---|---|
| Business reference | BCP-YYYY-NNNN |
| Business service | What it protects |
| Plan type | Business continuity, disaster recovery, or a specific scenario response |
| Version | The version identifier |
| Activation criteria | What triggers invocation, and who can invoke |
| Recovery teams | Who is involved, with roles and contacts |
| Procedures | The steps, in order |
| Owner | Who is accountable |
| Status | Its governance state |
| Historical snapshots | Immutable frozen states at approval |
Activation criteria
The most commonly weak part of a continuity plan is the trigger.
| Weak | Better |
|---|---|
| "Activate in the event of a major incident." | "Activate when the retail payments service is unavailable for more than 30 minutes with no confirmed restoration path, or immediately on confirmed loss of the primary data centre. Invocation authority: Head of Payments Operations, or in their absence the on-call COO delegate." |
The second version answers three questions the first leaves open: what threshold, on what evidence, and who decides. During an actual incident, at 3am, those are the only questions that matter.
Recovery strategies
Strategies are the catalogued approaches a plan draws on — failover to a secondary site, manual workaround, degraded-mode operation, third-party arrangement.
Each records its type, its estimated recovery time, its resource requirements and the assets or vendors it depends on.
Keeping strategies separate from plans means several plans can reference the same strategy, and a strategy whose estimated recovery time exceeds an RTO can be identified before an exercise proves it.
Governed approval
Draft and update plan, then continuity review, optionally escalating to executive approval, then approved or rejected.
Segregation of duties: the author cannot approve their own plan. Approval requires bcm.plan_approve.
On final sign-off, an immutable snapshot freezes the approved state — procedures, teams, activation criteria and the reviewer's identity.
The plan-is-not-capability rule
An approved plan is a document, not a demonstrated capability
Plan exists, is not plan approved, is not exercise scheduled, is not exercise completed, is not exercise passed, is not service resilient.
A service whose plan is approved but never exercised is reported as not tested. It is never assumed resilient.
This is the point in the domain where optimistic reporting is most tempting, because an approved plan feels like an achievement — and it is, but it is an achievement about documentation.
Versions
Plans are versioned. A revision produces a new version; the previous version and its approval snapshot remain.
During an incident review, "which version of the plan was in force at the time?" is a question with a real answer.
Keeping plans usable
Test the contact details. Recovery team contacts are the fastest-decaying part of any plan. Verify them at every review, not every exercise.
Write procedures for someone who is not you. The person executing the plan at 3am may not be the person who wrote it.
Keep procedures shorter than they want to be. A 60-page plan is not read during an incident. Put the executable steps at the front and the background behind them.
Reference, do not duplicate. A plan that restates the BIA's recovery objectives will eventually disagree with the BIA. Link instead.
Permissions
| Action | Permission |
|---|---|
| View plans | bcm.read |
| Create, version and edit plans | bcm.plan_manage |
| Approve or review plans | bcm.plan_approve |
| Generate advisory AI drafts | bcm.ai_assist |
Requires the bcm_resilience entitlement.
Example
Plan BCP-2026-0004 — Retail Payments Service Continuity Plan v2.1.
| Element | Value |
|---|---|
| Business service | Retail Payments |
| Type | Business continuity |
| BIA | BIA-2026-0003 — RTO 240 minutes, RPO 5 minutes |
| Activation criteria | Service unavailable more than 30 minutes with no confirmed restoration path, or confirmed primary site loss. Authority: Head of Payments Operations or on-call COO delegate |
| Recovery teams | 4 teams, 19 named individuals with deputies |
| Procedures | 6 sequenced procedures, primary path plus degraded-mode operation |
| Strategies referenced | Secondary-site failover, estimated 180 minutes; degraded-mode authorisation, estimated 45 minutes |
Approval: drafted by the Payments Continuity Lead, reviewed by the Head of Operational Resilience, approved by the Chief Operating Officer. Snapshot frozen.
Status in the resilience assessment: plan coverage current and approved; tested capability not tested until the next exercise.
Those two lines sitting next to each other is exactly what the module is for. The plan is in good order. Nobody has yet proved it works.
Troubleshooting
"The service still shows as not resilient with an approved plan." Approval is one of six dimensions. Tested capability is another. See Resilience Assessments.
"I cannot approve a plan I wrote." Segregation of duties.
"A strategy's estimated recovery time exceeds the RTO." That is a finding, and a useful one — it means the documented approach cannot meet the objective even in theory. Either the strategy or the objective needs to change, and both are governance decisions.