Continuity plans with native §8.4.4 fields as discrete columns, §8.4.5 phased recovery, and a §8.5 activation log as a first-class feature. The BCP module SAMA-regulated organisations pick when free-text plan editors stop being defensible.
Each plan carries its scope, roles, recovery steps and vendor dependencies as structured data, with a three-phase recovery sequence and an activation log that records every invocation.
Plan record: code, name, department, processes in scope, product or service covered, criticality, owner, status and next review date.
§8.4.4 fields: purpose, scope, roles, activation criteria, communication, resources, interdependencies and recovery procedures, each a discrete column rather than a heading in a document.
§8.4.5 phases: immediate response, continuity and recovery, each with ordered steps, a RACI and a target time.
Dependencies: applications, vendors with their contracted RTO, locations and the people to notify, all read from the BIA so the plan and the analysis cannot drift apart.
§8.5 activation log: who activated the plan, when, under which crisis, and the review that closed it, exportable as a branded PDF.
Every feature below is verified in our integration test suite and shipping today.
Purpose, scope, activation criteria, deactivation criteria, classification, target RTO and target RPO are discrete typed columns — diffable per field, searchable across plans, audit-trail per change.
Each recovery step belongs to one of three phases — respond, recover, restore. The UI renders steps grouped by phase with phase-specific timeframes. ISO 22301-native phasing.
Every BCP invocation captured as a structured row — activatedAt, activatedBy, triggerSummary, optional crisis-event linkage, outcome, improvement-action count. Deactivation updates in place.
Per-plan team members with RACI (Responsible · Accountable · Consulted · Informed), notify priority, internal user link or external contact, role label.
Audience × trigger × template — pre-built templates for SAMA, board, customers, regulators, media. Each communication entry links to the plan and the activation it covered.
One-click PDF in ISO 22301-shaped sections: §8.4.4 fields · §8.4.2 IMT · §8.4.3 comms · §8.4.5 phased recovery · §8.5 activation log. Branded with your tenant logo.
ISO 22301 splits recovery into three distinct phases — respond, recover, restore. Each step belongs to one phase. Most peer platforms store recovery as a flat list.
BCMStack’s phase column on bcp_recovery_steps takes one of three values: respond, recover, restore. The detail page renders steps grouped by phase. Tested end-to-end in tests/integration/bcp-activation-and-team.test.ts.
The three things a defensible BCP module has to record — and why each piece matters when an auditor pulls the file.
What outcome the plan delivers and where the boundary sits — both stated upfront so reviewers know what's in and what's out.
The explicit triggers for invoking the plan and for declaring return to BAU — no ambiguity at 3am.
The named role with authority to declare activation. Removes the 'who decides?' question during a real incident.
Public · Internal · Confidential · Restricted. Drives access control and external sharing policy.
Versioned approvals plus a hard-coded next-review date. Audit-ready evidence the plan is current.
Target RTO / RPO recorded against the plan so the recovery objectives are measurable, not aspirational.
Who owns the plan and what stage of the approval workflow it sits in (draft → review → pending approval → approved → archived).
Example
BCP-PAY-001 — Cardholder payments continuity
Respond · Recover · Restore — the §8.4.5 phase split is enforced so steps don't collapse into one big to-do.
Auto-numbered per plan so the runbook reads top-to-bottom under pressure, with reordering recorded in the audit log.
What to do, in plain language a duty officer can execute without re-interpretation.
Expected duration captured so total recovery time is the sum of step times — not a hand-wave.
Each step assigned to a named role (not an individual) so the runbook survives staff churn.
What 'done' looks like for this step — the acceptance test the duty officer runs before moving on.
Example
Step 3 of 12 — Respond phase
When the plan was invoked and by whom — the foundation of the §8.5 evidence trail.
What changed in the world that warranted invocation. Lets reviewers test whether the trigger matched the criteria.
Each activation is tied back to the crisis it served, so the BCP record and the crisis record corroborate each other.
When BAU resumed and what the post-incident summary looks like. Captured at deactivation while details are fresh.
Rolled-up count of corrective actions raised from the activation — feeds the §10.1 continual improvement loop.
Example
Activation #14 — Major acquirer outage
What a structured §8.5 invocation looks like in the database. SAMA examiners specifically sample whether plans have been invoked rather than just authored — this is that evidence.
activated_at2026-04-01 08:30:00 UTCactivated_bymohammed.alsaud@samb.com.sa (Head of Operations)trigger_summaryDC1 SAN latency spike → SOC alert → Head of Ops declares activation per §8.4.4(b) criteriacrisis_event_idevt_a87f...c0e9 (Crisis CR-2026-002)deactivated_atNULL — still activeoutcome(Pending — populated at deactivation)improvement_actions_count0 (will accumulate as actions are raised during recovery)The complete BCP lifecycle as it flows through the platform.
Author with the §8.4.4 wizard. RACI roster + comms matrix.
Submit for review. Reviewer can approve, reject, or send back.
Org admin approves. Snapshot stored in bcp_assessments.
Plan tested in annual exercise programme. AAR captured.
Real incident triggers invocation. New row in bcp_activations.
Same row updated with outcome + improvement actions.
Lessons learned land in improvement_actions register.
Annual review trigger. Loop back to draft if needed.
How the BCP module compares to peer platforms
ISO 22301:2019 §8.4.4 specifies the required content of a business continuity plan: purpose, scope, activation criteria, activation authority, deactivation criteria, classification level, target RTO and target RPO. BCMStack stores each as a discrete column with type validation and per-field audit trail. An auditor can diff them across plan versions; competing platforms typically buryeach in a single description box.
Every time a BCP is invoked — for a real incident or a tabletop — a row is inserted into bcp_activations capturing activatedAt, activatedBy, triggerSummary, optional crisisEventId linkage, optional outcome, and improvement-action count. Deactivation updates the same row in place rather than inserting a new one. SAMA auditors specifically sample whether plans have been invoked rather than just authored — the activation log is that evidence.
Yes — ISO 22301 §8.4.5 phased recovery is native via a phase column on bcp_recovery_steps with three values: respond, recover, restore. Each step belongs to one phase. The UI renders steps grouped by phase with phase-specific timeframes. Peer platforms typically store recovery as a flat checklist regardless of which phase the activity belongs to.
Yes — bcp_plan_references stores typed links to related plans: it_drp (IT-DR plan), crisis_management (corporate crisis plan), corp_resilience and others. Each reference can carry an external URL plus a label, so you can link out to corporate doc systems where those plans live. ISO 22301 §8.4.4(h) explicitly requires this.
Each plan has a bcp_team_members table with role label (Incident Commander, Comms Lead, Technical Recovery Lead, etc.), RACI assignment (R/A/C/I), notify priority, and contact info. Members can be internal users (linked to a user_id) or external (vendor / regulator / consultant) by name + email. ISO 22301 §8.4.2 (response structure) requires this and our integration tests verify the RACI rows persist in notify-priority order.
Yes. Department-scoping is enforced at the tRPC procedure layer for every dept_head user — they only see plans where bcp_plans.department_id matches their own department. Verified by integration tests that confirm cross-department access returns FORBIDDEN.
ISO 22301-shaped sections: cover page with classification + version + approval date · §8.4.4 plan content as discrete fields · §8.4.2 IMT roster + RACI · §8.4.3 stakeholder communications matrix · §8.4.5 phased recovery steps · §8.4.4(h) related plan references · §8.5 activation log · improvement actions raised. Branded with your tenant logo. Audit-ready out of the box.
We'll walk you through a live BCP authored against §8.4.4, exercised against the annual programme, and invoked into the §8.5 activation log — with the resulting PDF rendered in real time.
Book a 20-minute demoSee the full BCM lifecycle — explore BIA, BCP, Exercises, Crisis, Risk and Reporting.