What is the difference between a risk register and a risk log?

A risk log is usually a chronological record of risk events that have happened (also known as a risk event log or incident log). A risk register is a forward-looking list of risks that could happen, with the controls and actions in place to manage them. Some organisations use the terms interchangeably, but the distinction matters because they answer different questions: what has gone wrong vs. what could go wrong.

What fields should a risk register contain?

At minimum: a unique ID, a risk description (cause/event/consequence), a category, an owner (a named person, not a team), gross/inherent score, the controls in place, the net/residual score, the risk appetite or target score, the date last reviewed, and any open actions with owners and due dates. Additional fields commonly added: business unit, risk taxonomy code, linked policies, linked obligations, KRI (key risk indicator) thresholds.

How often should a risk register be reviewed?

Top-of-house principal risks are typically reviewed monthly or quarterly. Operational risks owned by the first line are typically reviewed as part of an annual or six-monthly RCSA cycle. Material change events (a new product, a regulatory change, a significant incident) should trigger an out-of-cycle review.

Why do most risk registers stop being useful?

They turn into static spreadsheets that nobody opens between board meetings, ownership drifts onto generic team names, scores stop reflecting reality, and the controls column becomes aspirational rather than evidenced. The fix is not a better template - it is making the register the live operating system the first line actually uses, with controls and assessments connected to it rather than parallel to it.

Back to Articles and Learning

Risk Management8 min read

What Is a Risk Register? Definition, Structure & Examples (2026)

Elliot Poublan

Apr 18, 2026

What Is a Risk Register? Definition, Structure & Examples (2026)

In short

A risk register is the canonical list of risks an organisation faces, recorded in a structured format. Each entry captures the risk, its owner, its inherent (gross) and residual (net) score, the controls in place, and any open actions to bring exposure within appetite.

Purpose - the single source of truth for what could prevent the organisation from achieving its objectives.
Risk register vs risk log - register is forward-looking (what could happen); log is backward-looking (what has happened).
Minimum fields - ID, description (cause / event / consequence), owner, gross score, controls, residual score, target / appetite, last review date, open actions.
Why most fail - they become static spreadsheets opened only at board meetings; ownership drifts, scores stop reflecting reality and controls become aspirational.

A risk register is the canonical list of risks an organisation faces, recorded in a structured format. It is the foundation of any Enterprise Risk Management (ERM) or GRC framework - the single source of truth for what could prevent the organisation from achieving its objectives, who owns each of those risks, and what is being done about them.

Every regulated firm has one. Most do not work. This article explains what a risk register actually is, what it should contain, how it should be structured, where it tends to break down, and what good looks like.

Risk Register vs Risk Log: What Is the Difference?

The two terms are often used interchangeably, but they answer different questions:

Risk register - forward-looking. A list of risks that could happen, with their owners, scores, controls and actions. Lives at the heart of the ERM framework.
Risk log (or risk event log, incident log) - backward-looking. A chronological record of events that have happened - operational losses, near-misses, breaches - typically used to feed the risk register and to track remediation.

The two are connected: events on the risk log should prompt re-scoring or re-articulating risks on the register; risks on the register should be testable against what shows up on the log over time.

What a Risk Register Should Contain

There is no single "correct" risk register template, but a usable register typically contains the following fields per risk:

Unique ID - a stable reference (e.g. R-014) that is used in board papers, policies and incident reports so the same risk is talked about consistently.
Risk description - written as cause, event, consequence ("If X, then Y, leading to Z"), not as a vague theme.
Risk category / taxonomy - operational, financial, regulatory, strategic, technology, conduct, etc. Aligned to the firm's risk taxonomy.
Owner - a named individual, not a team or a job title without a person in it.
Inherent score - what the risk would look like with no controls. Usually likelihood × impact on a 5×5 risk matrix. See our piece on inherent vs residual risk vs appetite.
Controls - the controls currently in place that reduce likelihood or impact. Each linked to a control owner and a testing cadence.
Net / residual score - the score after controls operate. The number that gets reported to the board.
Risk appetite / target - where the organisation has decided this risk should sit. Drives the action question.
Open actions - what is being done to bring the residual score within appetite, with owner and due date.
Date last reviewed - so stale entries are visible.

Many registers also link risks to policies, regulatory obligations, KRIs (key risk indicators), and to the entries in the RCSA - which is what turns the register from a list into a connected operating system.

Where Risk Registers Break Down

Almost every organisation has a risk register. Most of them have stopped being useful. The patterns are remarkably consistent:

Common Failure Modes

Static spreadsheet syndrome - the register is a workbook nobody opens between board meetings.
Generic ownership - "Operations" or "IT Team" rather than a named individual; nobody actually accountable.
Aspirational controls - the controls column lists what should exist, not what is evidenced to operate.
Score drift - net scores set two years ago that have not been re-tested against incidents that have happened since.
Disconnected from RCSA - the first line runs RCSAs that never feed the register; the register reflects the second line's view, not the operators' reality.
Action graveyard - actions added years ago, never closed, never reviewed.

The fix for any of these is not a better Excel template. It is making the register the live operating layer the first line actually uses - which is why most organisations eventually move from spreadsheets to dedicated risk register software or a fuller modern risk management platform. See our piece on Excel vs GRC tools: when to make the switch.

What Separates a Working Register From One That Just Exists

Every regulated firm has a register. The difference between one that earns its keep and one that simply exists is usually not the tooling, the template or the column count. It is whether the register changes any decision the business makes.

A useful test: in the last six months, has any executive decision - a hire, a contract, a system change, a new product, a client onboarding - been adjusted because of what was on the register? If the honest answer is no, the register is reporting infrastructure, not a management instrument. Boards may sign it off; nobody is using it.

Working register

Risk owners can describe their top three risks unprompted.
Scores move when reality moves - incidents, near-misses, new exposures.
Actions have owners, dates and visible momentum.
Controls in the register match controls in the business.
The board pack derives from the register, not the other way round.

The risk team can describe the register; the owners cannot.
Scores are last year's scores, lightly refreshed for the meeting.
Actions are open indefinitely, with no clear next step.
Controls are aspirational - written, not evidenced.
The board pack is reverse-engineered each quarter to match a narrative.

A Note on Risk Taxonomy

Most failed registers fail upstream of the register itself - in the taxonomy. If the categories are too granular, the register grows to hundreds of entries and nobody can hold the picture in their head. If the categories are too broad, single entries cover risks with completely different owners, controls and treatment paths.

A workable mid-market taxonomy typically has six to ten level-one categories (operational, technology, financial, regulatory, conduct, strategic, people, third party, etc.) and a controlled list of level-two sub-categories beneath each. Anything more elaborate than that becomes a categorisation exercise rather than a risk management exercise. The taxonomy should serve the register, not the other way around.

When the Register Stops Being Optional

For very small organisations, an informal list of concerns held by the leadership team is genuinely sufficient. The register stops being optional - and starts needing structure - at recognisable points:

When ownership cannot be held in one head. The moment risks span multiple business units, the only way to keep accountability legible is to write it down with named owners.
When the regulator expects to see one. FCA, PRA, ICO, OfS, CQC and most sector regulators expect a documented risk register and will ask to see how it is reviewed.
When the board needs a consistent view. The day non-executive directors start asking "what are our top risks and what changed this quarter?", a structured register becomes the only credible answer.
When customers or investors start asking. Tier-1 customer due diligence, insurance underwriters, investors and acquirers all expect a register to exist - and treat its absence as a maturity signal.
After the first material incident. The post-incident review almost always concludes that the risk was knowable - it just was not held anywhere that anyone was accountable for reviewing.

Practitioner View

The strongest registers we see are not the most detailed ones - they are the ones with the shortest distance between an entry on the page and a person who can speak to it without notes. Length is not maturity. Ownership is.

How the Register Connects to the Rest of the Framework

A risk register on its own is just a list. It earns its keep when it is connected to:

RCSA campaigns - the periodic exercise where the first line confirms each risk and re-scores controls. See what an RCSA is and why most programmes fail.
Control library - controls referenced from the register should also exist in a control library with owners, tests, and effectiveness ratings.
Risk event log - incidents and losses linked back to the relevant register entries.
KRIs - leading indicators (e.g. system downtime, complaint volume, training completion) tied to specific risks so movement is visible between reviews.
Three Lines of Defence - first line owners on each register entry, second line oversight on the framework, third line independent assurance. See our guide to the three lines of defence in risk management.
Board reporting - the register is the source feed for the principal risk pages in the board pack. See board-ready risk reporting.

Takeaway

A risk register is the foundation document of any GRC framework. Its quality determines the quality of everything built on top of it - the RCSA, the control assessments, the board pack, the regulator's view of how seriously you take risk.

If your register is a static workbook, generic ownership, aspirational controls and stale scores, the problem is not the document. It is that the register is not connected to the way the first line actually works. If you want to see what a connected register looks like in practice, book a conversation.

Related reading: for the four ways to score the risks on your register, see how to assess enterprise risk. For the inherent vs residual scoring layer, read inherent vs residual risk vs appetite explained. And for the broader operating model, start with how to build an ERM framework.

Frequently asked questions

What is a risk register?: A risk register is the canonical list of risks an organisation faces, recorded in a structured format. Each entry typically captures the risk description, its owner, its gross (inherent) and net (residual) score, the controls in place to mitigate it, and any open actions to bring it within appetite.
What is the difference between a risk register and a risk log?: A risk log is usually a chronological record of risk events that have happened (also known as a risk event log or incident log). A risk register is a forward-looking list of risks that could happen, with the controls and actions in place to manage them. Some organisations use the terms interchangeably, but the distinction matters because they answer different questions: what has gone wrong vs. what could go wrong.
What fields should a risk register contain?: At minimum: a unique ID, a risk description (cause/event/consequence), a category, an owner (a named person, not a team), gross/inherent score, the controls in place, the net/residual score, the risk appetite or target score, the date last reviewed, and any open actions with owners and due dates. Additional fields commonly added: business unit, risk taxonomy code, linked policies, linked obligations, KRI (key risk indicator) thresholds.
How often should a risk register be reviewed?: Top-of-house principal risks are typically reviewed monthly or quarterly. Operational risks owned by the first line are typically reviewed as part of an annual or six-monthly RCSA cycle. Material change events (a new product, a regulatory change, a significant incident) should trigger an out-of-cycle review.
Why do most risk registers stop being useful?: They turn into static spreadsheets that nobody opens between board meetings, ownership drifts onto generic team names, scores stop reflecting reality, and the controls column becomes aspirational rather than evidenced. The fix is not a better template - it is making the register the live operating system the first line actually uses, with controls and assessments connected to it rather than parallel to it.