A risk register is a central record of current risks and the information needed to manage them: what the risk is, how serious it is, who owns it, what response is planned, what status it is in, and when it should be reviewed. NIST defines a risk register as a way to capture current risks, including risks that have been accepted and risks with a planned mitigation path (NIST CSRC Glossary).
The main thing to know is that a risk register is not just a spreadsheet of concerns. It is a management process for turning risk information into ownership, treatment, review, escalation, and closure. It can be used for project risks, operational risks, compliance and GRC work, security risks, supplier risks, and wider organisational risk management.
What Is a Risk Register Used For?
A risk register helps teams make risk decisions visible and follow them through. In practical terms, it is used to:
- document risks in a consistent format
- assess likelihood, impact, and priority
- assign a clear risk owner
- track existing controls and treatment actions
- record due dates, status, review activity, and decisions
- show leaders which risks need mitigation, acceptance, escalation, or closure
A maintained register can support governance discussions and risk reporting, but it should not be treated as proof that compliance, audit, or control obligations have been met on its own.
What Should a Risk Register Include?
A useful risk register should capture enough information, enough to support decisions and follow-up. NIST’s Cybersecurity Framework quick-start guidance includes fields such as risk description, category, likelihood, impact, priority, response type and description, risk owner, action owner, and status (NIST SP 1308).
A practical structure groups fields by job:
| Job | Fields to include |
|---|---|
| Identify the risk | Risk ID, risk description, category, cause or trigger |
| Assess the risk | Likelihood, impact or consequence, score, priority, residual risk |
| Assign accountability | Risk owner, action owner if different |
| Track treatment | Existing controls, treatment or mitigation action, due date, status |
| Review and govern | Review date, escalation notes, decision record, closure notes |
Not every organisation needs every field on day one. A small team may start with risk ID, description, likelihood, impact, priority, owner, action, due date, status, and review date. The register should expand only when the extra fields improve decisions or follow-up.
Residual risk means the level of risk that remains after existing controls or planned treatment actions are considered. It matters because a risk can be reduced without being eliminated.
How to Create a Risk Register
Use a simple workflow rather than starting with a large template.
- Identify risks. Gather risks from projects, incidents, control reviews, supplier reviews, operational meetings, security assessments, or leadership discussions.
- Write each risk clearly. A useful description includes the event, cause, and consequence where possible. For example: “Supplier security review is not completed before renewal, delaying contract approval” is more actionable than “Supplier risk.”
- Categorise the risk. Use broad categories such as operational, security, compliance, financial, supplier, people, or project risk.
- Assess likelihood and impact. Use a defined scoring scale so similar risks are scored consistently.
- Prioritise the risk. Convert the assessment into a score or priority band.
- Assign owners. Name the risk owner accountable for monitoring and management. If the treatment work is delegated, record a separate action owner.
- Define the response. Decide whether the risk will be treated, tolerated, transferred, terminated, or otherwise addressed. UK government grants guidance describes these as possible response types and notes that residual risk can be compared with risk appetite (Risk, Controls and Assurance).
- Set due dates and review dates. A risk without a date is hard to manage.
- Track status. Use simple statuses such as open, in treatment, overdue, escalated, accepted, or closed.
- Review, escalate, or close. Update the register when conditions change, actions are completed, or the risk decision changes.
How to Score and Prioritise Risks
Most qualitative risk registers use likelihood and impact. Likelihood estimates how probable the risk event is, impact estimates the consequence if it happens.
One simple approach is a 1–5 scale where:
| Score | Likelihood example | Impact example |
|---|---|---|
| 1 | Rare | Minor inconvenience or easily absorbed impact |
| 2 | Unlikely | Limited disruption or localised issue |
| 3 | Possible | Noticeable operational, financial, customer, compliance, or delivery impact |
| 4 | Likely | Significant disruption, cost, delay, control failure, or stakeholder impact |
| 5 | Almost certain | Severe or organisation-level impact requiring senior attention |
A common scoring method is:
Risk score = likelihood × impact
For example, likelihood 3 × impact 4 = score 12.
You can then define priority bands, such as:
| Score range | Priority |
|---|---|
| 1–4 | Low |
| 5–9 | Medium |
| 10–16 | High |
| 17–25 | Critical |
This is an example, not a universal standard. UK Department for Education guidance shows that organisations can combine likelihood and impact into a score and plot the result on a matrix, while tailoring definitions to their own risk appetite (Academy trust risk management).
Good scoring depends less on mathematical precision and more on calibration. Define what each level means, compare similar risks, avoid scoring based only on instinct, and revisit scores when conditions change. Low-likelihood, high-impact risks may also need attention even when their simple multiplied score is not the highest.
Who Owns, Reviews, Escalates, and Closes Risks?
A risk register fails when ownership is unclear. Each risk should have a named risk owner who is accountable for monitoring the risk, keeping the entry current, and ensuring decisions are made. Or, more precisely, ensuring decisions do not sit unresolved. If a mitigation task sits with someone else, add an action owner for that task.
Review frequency should reflect the severity and nature of the risk. A high-priority supplier, security, or compliance risk may need more frequent review than a low-priority operational issue. HM Treasury’s Orange Book describes effective risk management as involving clear responsibilities, identification, assessment, treatment, monitoring, reporting, and escalation, with review and escalation shaped by context and the nature of the risk (The Orange Book).
Escalation rules should be defined by the organisation. For example, escalate when:
- the risk exceeds the organisation’s tolerance
- the score or priority increases
- treatment is overdue
- ownership is unclear
- the risk affects a major decision, customer commitment, control objective, or leadership priority
Closure criteria should also be explicit. A risk may be closed when it no longer applies, when the response is complete and residual risk has been accepted, or when the risk has been otherwise resolved. If old risks remain open indefinitely, the register becomes harder to trust.
Risk Register Example: What a Good Entry Looks Like
Here is a compact example of a completed entry. The scoring and dates are illustrative and should be calibrated to the organisation’s own scale and review process.
| Risk ID | Risk description | Category | Likelihood | Impact | Score / Priority | Treatment | Owner | Due date | Status | Review date |
|---|---|---|---|---|---|---|---|---|---|---|
| SUP-014 | Critical supplier security review is not completed before contract renewal, which could delay internal approval and create uncertainty over continued use. | Supplier / security governance | 3 | 4 | 12 / High | Complete supplier review, confirm required controls, document residual risk decision before renewal. | Head of Procurement | 30 days before renewal | In treatment | Next supplier risk review |
This entry works because it is specific enough to act on. A clear risk event, a consequence, and a link between priority, likelihood, and impact. It assigns ownership, defines a treatment action, sets a deadline, and creates a review point. If the due date is missed or the review changes the score, the risk can be escalated rather than left as an open line item.
Risk Register vs Risk Matrix
A risk register and a risk matrix are related, but they are basically not the same thing.
A risk register is the record of risks, controls, owners, treatment plans, status, reviews, and decisions.
A risk matrix is a scoring or visual prioritisation tool, usually based on likelihood and impact. It can help determine the priority field in the register, but it does not replace the register. Department for Education guidance describes a matrix as a way to plot likelihood and impact scores, while the register records risks, controls, and monitoring information (Academy trust risk management).
In short: the matrix helps rank attention; the register tracks action.
Common Risk Register Mistakes
The most common problems are governance problems, not template problems.
- Treating the register as a static spreadsheet. If it is not reviewed or acted on, it stops supporting decisions.
- Writing vague risks. “Compliance risk” or “supplier issue” does not tell anyone what might happen, why, or what to do next.
- Scoring inconsistently. If one team scores cautiously and another scores aggressively, priority comparisons become unreliable.
- Leaving ownership unclear. Every material risk needs a named owner.
- Missing due dates or review dates. Without dates, treatment and monitoring drift.
- Having no escalation path. High or worsening risks need a route to the right decision-makers.
- Keeping obsolete risks open. Closed, accepted, or irrelevant risks should not clutter active management.
- Tracking too many low-value risks. A register that is too noisy can hide the risks that need attention.
- Using a template without a review process. The format matters less than whether risks are updated, challenged, treated, and closed.
A spreadsheet can be enough to start. As risk and compliance work scales, the challenge becomes keeping owners, controls, evidence, reviews, and follow-up connected. Ciphrix treats risk and compliance as live operating workflows, helping organisations maintain risk information as part of day-to-day governance rather than another document sitting off to the side.