Auto-numbered crisis codes (CR-2026-001) and action items (A1, A2…) per crisis. BCP activation linked to the §8.5 audit log. Five structured impact types. Reopen-after-close support — because crises don't always stay closed.
Each declared event gets a unique CR-YYYY-NNN code per tenant. The number resets per year. Codes appear in the audit log, the comms tree, every PDF — they're the citation handle for an entire incident.
Action items within a crisis auto-number A1, A2, A3 onwards. Numbers reset per crisis. So 'A3 in CR-2026-001' is uniquely identifiable across the entire audit log — verified in the crisis-lifecycle integration tests.
The IMT activates one or more BCPs from inside the crisis record. Each activation creates a row in bcp_activations (§8.5 audit trail), linked back to the crisis. Closing the crisis deactivates linked plans.
Operational · financial · regulatory · reputational · staff. Each captured with timeline (start / end), magnitude, mitigation. Auditors see the impact picture across all dimensions, not just the one impact author thought to mention.
Every comms send during a crisis logged: audience, channel, sent-at, sent-by, content snapshot. Required by §8.4.3. Also serves as evidence post-incident for what was said and when.
Crises sometimes need to reopen — new evidence emerges, an impact reactivates, post-mortem triggers more actions. crisis_events has reopened_at + reopened_reason. Most peers force a new event; BCMStack treats it as continuation.
Two records carry the weight of crisis management — the event itself, and the corrective actions raised from it. Here's what's recorded for each, in business terms.
Auto-generated identifier (CR-2026-014) — every tenant gets its own yearly sequence so codes never collide between organisations.
Low / Medium / High / Critical, and Operational / Cyber / Physical / Vendor / Regulatory / Reputational. Lets reviewers slice the historical record by impact and root family.
Declared → Responding → Recovering → Closed. Same phase taxonomy every regulator expects to see.
Named incident commander and the moment the crisis began — the start of the §8.5 evidence trail.
Closure timestamp recorded; reopens captured with timestamp and reason so audit trail can't be glossed over.
Example
CR-2026-014 — Acquirer outage incident
Auto-numbered A1, A2, A3 within the parent crisis. The runbook keeps its numbering even when items are deleted and re-added.
What needs to happen — written so the assigned owner can act without re-reading the whole crisis record.
Exactly one named owner per action. No collective ownership. If the owner leaves, reassignment is recorded.
Due date set when raised; completion timestamp recorded when closed. Variance is reportable, so SLA breaches are visible.
Every action remembers the crisis it was raised against, so post-incident reviews can roll up corrective actions automatically.
Example
Action A3 — under CR-2026-014
| Clause | What it asks for | BCMStack surface |
|---|---|---|
| §8.4.2 | Response structure during a declared event | crisis_events + IMT roster from linked BCPs |
| §8.4.3 | Warning + communication during a crisis | crisis_communications log (who said what to whom, when) |
| §8.5 | BCP activation evidence — linked to real events | crisis_activated_bcps joins to bcp_activations |
| §9.1.1 | Monitoring + measurement during recovery | crisis_recovery_activities + crisis_recovery_resources |
| §10.1 | Improvement actions raised post-event | Auto-numbered A1..An action items per crisis |
How the Crisis module compares to peer platforms
Every crisis declared gets a unique code (CR-2026-001). Action items raised within that crisis auto-number from A1 onwards (A1, A2, A3...). The numbering resets per crisis. So 'A3 in CR-2026-001' is a uniquely identifiable record across the audit log. Tested in the crisis-lifecycle integration suite.
When a crisis is declared, the IMT can activate one or more BCPs. Each activation creates a row in bcp_activations linked to crisis_events.id via the crisis_activated_bcps join. Closing the crisis triggers deactivation of linked BCPs. The §8.5 audit trail captures: which crisis triggered which activation, when, by whom, with what outcome.
Crisis events sometimes need to be reopened — new evidence emerges, a closed-out impact reactivates, lessons-learned trigger additional actions. crisis_events has reopened_at, reopened_by, reopened_reason fields plus a reopen audit trail. Most peer platforms force you to create a new crisis; BCMStack treats it as continuation of the original.
Five structured impact types: (1) operational — what services are disrupted, (2) financial — quantified loss, (3) regulatory — notification obligations triggered, (4) reputational — media / customer reaction, (5) staff — safety, displacement, availability. Each captured with timeline (when impact started / ended), magnitude, mitigation in flight.