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.
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.
Below is the actual schema backing the BCP module. Every column is type-validated and clause-mapped where relevant.
public.bcp_plans| Column | Type | Clause | Note |
|---|---|---|---|
| purpose | text | §8.4.4(a) | What outcome the plan is designed to achieve |
| scope_statement | text | §8.4.4(a) | Boundaries — what's in / out of the plan |
| activation_criteria | text | §8.4.4(b) | Conditions that trigger plan invocation |
| activation_authority | varchar(255) | §8.4.4(b) | Who has authority to declare activation |
| deactivation_criteria | text | §8.4.4(b) | Conditions that trigger return to BAU |
| classification | varchar(50) | §8.4.4(d) | public · internal · confidential · restricted |
| version_label | varchar(50) | §8.4.4(e) | Plan version (e.g., v1.2) |
| target_rto_hours | decimal(8,2) | §8.4.4(d) | Recovery time objective in hours |
| target_rpo_hours | decimal(8,2) | §8.4.4(d) | Recovery point objective in hours |
| department_id | uuid | FK departments — enables dept-scoped access | |
| code | varchar(50) | Human-readable plan code (e.g., BCP-PAY-001) | |
| name | varchar(255) | Plan title | |
| status | varchar(50) | draft · in_review · pending_approval · approved · archived | |
| next_review_date | date | §8.6 | When the plan is due for re-review |
public.bcp_recovery_steps| Column | Type | Clause | Note |
|---|---|---|---|
| phase | enum | §8.4.5 | respond · recover · restore — the §8.4.5 phase split |
| step_number | int | Auto-incremented per BCP regardless of phase | |
| name | varchar(255) | Step description | |
| timeframe_hours | decimal(8,2) | Expected duration in hours | |
| responsible_role | varchar(100) | Role that owns this step | |
| expected_outcome | text | What 'done' looks like for this step |
public.bcp_activations| Column | Type | Clause | Note |
|---|---|---|---|
| activated_at | timestamptz | §8.5 | When the plan was invoked |
| activated_by | uuid | §8.5 | User who declared activation |
| trigger_summary | text | §8.5 | What triggered this invocation |
| crisis_event_id | uuid | §8.5 | FK crisis_events — links real activations to the crisis log |
| deactivated_at | timestamptz | §8.5 | When the plan was deactivated (NULL while active) |
| outcome | text | §8.5 | Post-incident summary captured at deactivation |
| improvement_actions_count | int | §10.1 | Number of corrective actions raised |
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)Every clause this BCP module satisfies, with the BCMStack surface that satisfies it.
| Clause | What it asks for | BCMStack surface |
|---|---|---|
| §8.4.1 | One plan per BIA-critical service or capability | bcp_plans table — one row per plan |
| §8.4.2 | Response structure — IMT, RACI, escalation | bcp_team_members with raci enum + notify_priority |
| §8.4.3 | Warning + communication plan | bcp_stakeholder_comms (audience × trigger × template) |
| §8.4.4 | Plan content — purpose, scope, activation, deactivation, classification, RTO, RPO | Native discrete columns on bcp_plans (see data model below) |
| §8.4.5 | Phased recovery — respond / recover / restore | phase column on bcp_recovery_steps |
| §8.5 | Performance evaluation — invocation evidence | bcp_activations — first-class activation log |
| §8.6 | Periodic review of plans | next_review_date + last_reviewed_at on bcp_plans |
| §7.5 | Documented information attached to plans | bcp_documents with R2/S3 storage + soft-delete |
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.