Risk Register
Track risks as owned decisions (treat, accept, mitigate) with review cadence.
Risk Register
Risk Register in the app is /risk/register.
Use the risk register for management decisions: what could go wrong, what you’re doing about it, who owns it, and when it gets reviewed next.
Use this when…
- you need a small set of “top risks” leadership can review
- you’re tracking accepted risks and their review dates
- you want to connect risks to assets, controls, vendors, and findings
Recommended workflow
- Write risks as scenarios (not labels): “Unauthorized access to prod via compromised service account”.
- Assign an owner and a next review date.
- Choose a treatment path: mitigate, transfer, accept (with rationale).
- Link it to the relevant asset(s), control(s), and any findings that support it.
Directory and matrix (/risk/register)
The directory shows risk ID/source, title, category, owner, inherent risk, treatments, residual risk, and status. Use the table for record-level work and the inherent/residual matrices to understand concentration across likelihood and impact. Search and filters help isolate owner, status, category, or risk level.
The matrix visualizes current scoring; it does not normalize different owners' scoring assumptions. Define likelihood and impact criteria in your risk methodology and apply them consistently.
Create and edit (/risk/register/create, /risk/register/[id])
Record:
- a scenario-based title and description
- category, owner, assignee, status, and due date
- inherent likelihood and impact before treatment
- affected asset and linked controls/policies
- one or more treatment actions with owner/status and target likelihood/impact
- mitigation strategy, contingency plan, notes, and relevant framework/control reference
- residual likelihood and impact after the credited treatments
Where a risk originated from a security finding or integration, preserve source/external references. Do not overwrite an observed finding with a broad risk narrative; link them so both provenance and management decision remain visible.
Risk treatment and acceptance
Treatment can reduce, avoid, transfer, or consciously accept exposure depending on your methodology. Each action should state what changes, who owns it, when it is due, and what evidence will demonstrate completion. Residual risk is the post-treatment estimate, not the desired score.
Accepted risk needs an authorized rationale and review date. “Accepted” is not a permanent terminal state; revisit it when systems, threats, business impact, contracts, or legal obligations change.
Compliance relevance
Risk-based planning is central to ISO 27001 and supports SOC 2 risk assessment, vendor management, privacy assessments, and control selection. Framework mapping does not replace your organization's risk criteria, management acceptance, or documented treatment evidence.