What is a risk register?
A risk register is the backbone of risk management. It's where risks live, grow, are treated, and are reviewed. Here's a complete guide to what should be in it, how to build one, and how to keep it alive over time.
By Kim Borg, Founder, RiskNote · Last updated
What is a risk register?
A risk register is a structured list of all identified risks in an organisation or project, along with assessment, ownership, actions, and status. It's operational, it should be read, updated, and reviewed regularly.
The register is not a risk report. The report is a snapshot (PDF to board) drawn from the register. The register is the living data.
In ISO 27001 the risk register is a mandatory part of the ISMS (clauses 6.1.2 and 8.2). In ISO 31000 it's the standard output of the process. In NIS2 Art. 21 it's the prerequisite for risk-based cybersecurity.
Which fields should be included?
A complete risk register typically has these fields per risk:
ID
Unique number or code (R-001, R-002...). Makes it possible to reference the risk without writing the whole description.
Description
What is the risk? Write 1–2 sentences. Avoid vague phrasing (“risk of IT problems”), be specific (“downtime in the invoicing system over 4 hours”).
Category/domain
Operational, financial, strategic, compliance, cyber, project. Makes filtering and reporting easy.
Likelihood (1–5)
How probable it is that the risk occurs. Use a defined scale.
Consequence (1–5)
How serious it is if the risk occurs. Can be assessed separately for financial, operational, reputational, compliance.
Score / severity
L × C = 1–25. Translates to low/medium/high/critical.
Owner
Named person accountable for the risk. Without an owner nothing gets done.
Action
What's being done about the risk? Accept, reduce, transfer, or avoid. Concrete action plan if reducing.
Status
Open, in treatment, treated, closed. Changes over time.
Dates
When was the risk identified? When last reviewed? When next?
Residual risk
Likelihood and consequence after treatment. Shows whether the action is enough.
Gross, net, and residual risk
A mature risk register distinguishes three risk measures per row. These are the terms ISO 27001 auditors and boards expect to see:
Gross risk (inherent risk)
The risk without any controls or treatments. How bad could it get at worst? Essential for justifying security investments.
Net risk / residual risk
The risk after existing controls are factored in. This is the value compared against your risk tolerance. Also called residual risk.
Target risk
The risk level you aim to reach after planned treatments. The gap between net and target risk shows whether planned actions are enough.
Why does it matter? A risk with high gross risk but low net risk (thanks to strong controls) needs control maintenance, not new treatments. A low-gross-risk item rarely needs dedicated actions at all. Without the distinction, everything becomes one pile.
How many risks should the register have?
For an SME (15–50 people): 10–30 risks is typical. Fewer and you likely miss important things. More and the register becomes hard to manage.
For a mid-sized organisation (100–500 people): 30–80 risks across domains.
For large organisations: 100+ risks, often split by business area or domain.
A project: 10–20 risks, updated per sprint or steering meeting.
Common mistakes with risk registers
The register is never updated
Created for ISO certification, then sits still. Value lost within 6 months.
No owner per risk
Without an owner the risk is theoretical. Named person with mandate.
Risks with no action
Documenting a risk with no plan is documenting failure. Every risk should have a chosen response (accept/reduce/transfer/avoid).
Too abstract phrasing
“Risk of IT incidents” is not a risk. “Ransomware attack that makes the invoicing system unavailable for over 4 hours” is a risk.
Nobody in management reads it
If nobody in management actively uses the register, the process hasn't been anchored. Fix that first, not the format.
Excel vs dedicated tool
Excel works for small registers (under ~15 risks) but quickly becomes problematic: version drift, broken formulas, no audit trail, hard to share with control, no role-based access.
A dedicated tool like RiskNote gives you version history per risk, sharing via link with roles, AI suggestions for identification, and PDF export directly from data, rather than manual report assembly.
See our guide to Excel alternatives for risk registers.
Frequently asked questions about risk registers
Are the risk register and risk assessment the same?
No. The risk assessment is the process (identify, analyse, evaluate). The risk register is the output, the list of all risks with their assessment. The register is maintained; the assessment is a recurring activity.
How often should the register be reviewed?
Operational risks: quarterly. Strategic: annually. Project risks: per sprint or steering meeting. On major events (regulatory change, major contract, system switch): always.
Must every risk be documented in the register?
Every material risk, yes. Routine day-to-day items (solve them directly) don't need to be in. The line: if the risk can materially affect your objectives, document it.
Who should see the register?
Internally: management team, relevant department heads, risk owners. Externally: auditors, regulators on review, insurers on renewal. Not public.
How do I export the register for a board presentation?
In RiskNote: one click gives you a PDF with matrix, register, and AI disclosure. In Excel: manually assemble table and screenshot of the matrix.
More guides
Build your risk register in RiskNote
Version history, AI suggestions, 5x5 matrix, and PDF export built in. Start a 7-day free trial.