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.
public.crisis_events| Column | Type | Clause | Note |
|---|---|---|---|
| code | varchar(50) | Auto-generated CR-YYYY-NNN per tenant per year | |
| name | varchar(255) | Crisis title | |
| severity | varchar(20) | low · medium · high · critical | |
| category | varchar(50) | operational · cyber · physical · vendor · regulatory · reputational | |
| phase | varchar(20) | declared · responding · recovering · closed | |
| event_date | timestamptz | When the event began | |
| declared_by | uuid | FK users — incident commander | |
| closed_at | timestamptz | When event was formally closed | |
| reopened_at | timestamptz | Most-recent reopen timestamp | |
| reopened_reason | text | Why it was reopened |
public.improvement_actions| Column | Type | Clause | Note |
|---|---|---|---|
| code | varchar(20) | Auto-numbered A1, A2, ... within the parent crisis | |
| crisis_event_id | uuid | FK crisis_events — parent crisis | |
| description | text | What needs to happen | |
| owner_id | uuid | FK users — accountable owner | |
| due_at | timestamptz | Target completion | |
| completed_at | timestamptz | When completed |
| 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.