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.
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'
| Clause | What it asks for | BCMStack surface |
|---|---|---|
| §6.1 | Risks and opportunities — formal register | risks table with polymorphic targets |
| §6.1.2 | Risk treatment options | risk_treatments — 4 treatment types |
| ISO 31000 | Risk-management process alignment | Inherent + residual scoring; full risk lifecycle |
| §8.2 | Risk feeds into BIA | scenario_bia_process_links — risks attached to BIA processes |
| §8.3 | Strategies derived from risk treatments | Treatments inform BCP plan strategy types |
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.