BCM risk management where risks attach to what they actually affect — process, vendor, application, location, or the organisation. Inherent + residual scoring. Reusable scenario library shared with the exercise programme. Critical-asset linkage. KRI tracking.
Risks enter from the register or the scenario library, attach to a process, vendor, application or location, and carry inherent and residual scores side by side.
Risk record: code, title, category (operational · technological · regulatory · reputational · strategic · environmental), target asset, accountable owner, scenario link and next review date.
Scoring: inherent and residual likelihood × impact (1–5 each), with the gap between gross and net drawn on the heatmap so auditors see what the treatments bought.
Treatments: accept · transfer · mitigate · avoid, each with its own owner, due date, lifecycle status and a verification record; overdue treatments roll up to the committee dashboard.
Scenario library: reusable archetypes such as “Ransomware on Core Banking” or “SAN failure DC1”, referenced by risks and reused by the exercise programme.
Critical assets: information assets, infrastructure and key staff linked to risks, so the register can be pivoted by asset: “what does Core Banking carry?”
A SAN-failure risk targets a location · a vendor-outage risk targets a vendor · a regulatory-breach risk targets a process. Each renders contextually with the right cross-links.
Each risk carries inherent and residual likelihood × impact (1-5). The treatments register tracks what moved the residual. The heatmap shows both side-by-side — auditors see the gap between gross and net.
Scenarios = risk archetypes. 'Ransomware on Core Banking' · 'SAN failure DC1' · 'Critical-vendor SWIFT outage'. Risks reference scenarios. Exercise programmes use scenarios. One source of truth across modules.
Information assets, infrastructure, key staff. Each linked to risks via critical_asset_risk_links. The asset-centric view answers 'what risks does my Core Banking system carry?'
Each treatment has type (accept · transfer · mitigate · avoid), owner, due date, status, verification. Linked to the risk it addresses; the verified_at timestamp is the audit-evidence anchor.
Top-N risks by residual · risks by category · treatments overdue · scenario coverage across the exercise programme. Rolls up to the cross-module reporting dashboard.
A register that earns its keep records each risk with both its 'gross' and 'net' position, and each treatment with the verification that closes the loop. Here's what BCMStack records for each, in plain terms.
Human-readable identifier (RISK-CYBER-001) plus a one-line title — the same handle you'd use in a steering committee paper.
Operational · Technological · Regulatory · Reputational · Strategic · Environmental. Lets the register slice by family for committee reporting.
Every risk attaches to something concrete — a process, vendor, application, location or the organisation as a whole. No abstract orphan risks floating in the register.
Likelihood × Impact (1–5 each) before any treatment. The 'gross' position auditors need to see.
Likelihood × Impact (1–5 each) after planned/implemented treatments. The 'net' position management lives with. Difference between the two quantifies treatment value.
Optional link to a reusable scenario archetype — the connective tissue between the risk register and the exercise programme.
One named owner per risk. Not a team mailbox. Re-assignments are recorded.
Example
RISK-CYBER-001 — Ransomware on payments stack
Accept · Transfer · Mitigate · Avoid. The four ISO 31000 options, recorded explicitly so reviewers see the rationale, not just the activity.
What the treatment actually does — written so a reviewer can connect the action to the risk it's addressing.
Planned → In progress → Implemented → Verified. Verification is its own state because 'implemented' is not the same as 'works'.
Often differs from the risk owner — engineering may own a control while risk-management owns the position. Both named, both accountable.
Target completion. Overdue treatments roll up automatically into the BCM steering committee dashboard.
When effectiveness was confirmed and by whom. The evidence the residual rating is defensible.
Example
Mitigate · 'Immutable backup tier'
How the Risk module compares to peer platforms
Most risk registers force you to pick one 'attached to' field — usually a process. BCMStack's risks table has a polymorphic target_type + target_id that can point to a process, vendor, application, location, or the organisation as a whole. A SAN-failure risk targets a location; a third-party-outage risk targets a vendor; a regulatory-breach risk targets a process. Each renders contextually.
Each risk has inherent_likelihood, inherent_impact, residual_likelihood, residual_impact (each 1-5) plus the calculated inherent_score and residual_score. The treatments table tracks what's been done to move from inherent to residual. The heatmap renders both — auditors can see the gap between gross and net.
Scenarios are reusable risk archetypes — 'Ransomware on Core Banking', 'SAN failure DC1', 'Critical-vendor SWIFT outage'. Each scenario carries typical_likelihood, typical_impact, scenario_type, coverage_tags. Risks reference scenarios. Exercise programmes also use scenarios. One source of truth across modules.
Top-N risks by residual score · risks by category · treatments overdue · risks past target review date · scenario coverage across the exercise programme. The reporting dashboard rolls these up across the organisation; the risk module's own dashboard shows them per-tenant.