A risk register is a structured record of identified risks, analysis, ownership, controls, treatments, and review information. It should be easy to update, understand, sort, and use in meetings.
Essential fields
| Field | Purpose |
|---|---|
| ID and category | Reference and grouping |
| Objective | What could be affected |
| Risk statement | Cause, uncertain event, and consequence |
| Owner | Accountable person with authority |
| Existing controls | Measures already operating |
| Likelihood and impact | Defined assessment ratings |
| Residual rating | Exposure after controls |
| Treatment actions | Specific improvements or contingencies |
| Action owner and due date | Delivery accountability |
| Indicators and triggers | Monitoring and escalation |
| Status and review date | Current position and next check |
Write one clear risk per entry
Avoid combining unrelated causes, events, or consequences. If different owners or responses are required, use separate entries. Consolidate true duplicates to prevent inflated counts and inconsistent ratings.
Keep issues and actions distinct
An issue has already occurred. A risk is uncertain. An action is work to change exposure. The register may link to issue and action logs, but should not blur them.
Use ownership correctly
The risk owner is accountable for understanding and managing the risk. Action owners may deliver individual treatments. The owner should have enough authority and information to escalate or seek decisions.
Maintenance rules
- Review high-velocity risks more often
- Close risks with a stated rationale
- Retain important decision history
- Track overdue actions separately
- Archive obsolete entries without losing history
- Challenge scoring consistency
Write entries for future readers
A register is a working decision record, not merely a workshop output. Risk statements should be understandable months later by someone who was not in the room. Keep causes, uncertain events, and consequences distinguishable. Record current controls separately from proposed actions, and avoid using the action field to restate the problem.
Fields worth considering
Useful fields may include objective, risk statement, category, owner, causes, consequences, current controls, control effectiveness, likelihood, impact, overall rating, response strategy, actions, action owners, dates, status, indicators, escalation threshold, acceptance authority, and review date. Not every register needs every field; unnecessary complexity discourages maintenance.
Maintenance checks
- Are overdue actions visible and discussed?
- Are closed entries retained for learning where appropriate?
- Can duplicate or related risks be identified?
- Are ratings updated when evidence changes?
- Does each active entry have a next decision or review date?