What is a risk register? Definition, example and how to build one
Most risk registers are written once for an audit and never opened again. Here is what a register is for, what to put in it, and how to build one that people actually keep up to date.
A risk register is a living list of the risks that could affect an organisation’s or project’s objectives. For each risk it records what could happen and why, how likely and how serious it is, who owns it, which controls are already in place and what further action is planned — and it is reviewed regularly as things change.
What a risk register is for
A register is not the goal. The goal is to make better decisions under uncertainty, and the register is the shared memory that makes this possible. A good one does four jobs:
- One agreed picture. Leadership, managers and the board look at the same list, scored on the same scale, instead of each person carrying their own worries.
- Clear ownership. Every risk has a named person who is expected to act. Risks without an owner are the ones nobody acts on.
- Prioritisation. Scoring separates the handful of risks that need money and attention now from the long tail you can simply monitor.
- Evidence. Auditors, investors, insurers, funders and regulators increasingly ask how you manage risk. A maintained register — with dates, owners and review history — is the simplest proof.
Frameworks such as ISO 31000 and COSO ERM describe this as recording and reporting the risk management process. You do not need to adopt either framework formally to benefit from the same discipline.
What to include in a risk register
You can start with fewer columns, but these are the fields that make a register useful rather than decorative:
| Field | What it records | Why it matters |
|---|---|---|
| ID | A short unique code, e.g. R-014 | Lets you refer to a risk in meetings and reports without ambiguity |
| Risk title | A short name: “Loss of main payment provider” | Scannable in a long list |
| Description | Cause → event → consequence | Forces a specific risk instead of a vague worry (see below) |
| Category | Strategic, operational, financial, compliance, technology, people… | Shows where risk concentrates; supports reporting |
| Owner | One named person, not a team | Accountability for action and review |
| Inherent score | Likelihood × impact before controls | Shows how much you rely on your controls |
| Existing controls | What already reduces the risk today | Avoids planning actions you already have |
| Residual score | Likelihood × impact with current controls | The score you actually prioritise on |
| Response | Treat, tolerate, transfer or terminate | Makes the decision explicit, including acceptance |
| Actions | What will be done, by whom, by when | Turns the register into a plan |
| Target score | Where the score should land after the actions | Tells you whether the actions are enough |
| Status & review date | Open, in treatment, monitoring, closed; next review | Keeps the register alive |
The difference between inherent, residual and target scores trips many people up — our guide to the 5×5 risk matrix explains how each is scored. If you just want the columns ready to fill in, download our free risk register template.
How to write a risk so it is useful
The most common weakness of real registers is not scoring — it is wording. “Cyber security” or “Brexit” is a topic, not a risk. Use the cause → event → consequence pattern:
Because our online shop runs on a single payment provider (cause), an outage or account freeze (event) would stop all sales until it is resolved, costing roughly £18k per day of peak trading (consequence).
Written this way, the risk practically suggests its own controls: a second provider, an outage runbook, a cash buffer.
Risk register example
Below is an extract from a register for a 40-person UK e-commerce business. Scores use a 5×5 risk matrix: likelihood and impact are each rated 1–5 and multiplied.
| ID | Risk | Owner | Inherent | Existing controls | Residual | Response & next action |
|---|---|---|---|---|---|---|
| R-01 | Single payment provider freezes account or suffers outage; sales stop | COO | 4×5 = 20 | Provider SLA; status alerts | 3×5 = 15 | Treat — onboard a backup provider by 31 Jan |
| R-02 | Ransomware encrypts order and stock systems | Head of IT | 3×5 = 15 | MFA, daily off-site backups, EDR | 2×5 = 10 | Treat — test a full restore each quarter |
| R-03 | Key supplier in one country cannot ship for 4+ weeks | Buying lead | 3×4 = 12 | 6 weeks of safety stock on top 20 lines | 2×4 = 8 | Tolerate — review stock levels monthly |
| R-04 | Founder-only knowledge of supplier terms and pricing | CEO | 3×4 = 12 | None | 3×4 = 12 | Treat — document terms, add second signatory |
| R-05 | Customer data breach triggers ICO investigation and fine | DPO | 2×5 = 10 | Access reviews, privacy training | 2×4 = 8 | Transfer — cyber insurance renewal in March |
| R-06 | Peak-season courier capacity shortfall delays orders | Ops manager | 3×3 = 9 | Two couriers contracted | 2×2 = 4 | Tolerate — monitor in November |
Two things to notice. First, R-04 has no controls, so its inherent and residual scores are the same — a register makes that gap visible. Second, the response for R-03 and R-06 is to tolerate: accepting a risk is a legitimate decision as long as it is deliberate, recorded and within your risk appetite.
How to create a risk register in 7 steps
- Start from objectives. List the three to five things the business or project must achieve this year. A risk is anything uncertain that could help or hurt those objectives — this keeps the register focused.
- Agree your scales first. Define what “likely” and “major impact” mean in your context, ideally with numbers: a major impact might be “£250k loss or one week of lost trading”. Without anchors, scores are opinions.
- Identify risks with the people who know. Run a 60-minute workshop per area, review incidents and near misses, and look at what peers report. Write each one as cause → event → consequence.
- Score inherent risk, then record controls. Rate likelihood and impact as if nothing were in place, then list the controls that genuinely operate today.
- Score residual risk and decide the response. Rate again with controls in place. Anything above your appetite needs a decision: treat, tolerate (with a reason), transfer or terminate.
- Assign owners and actions. One owner per risk, and every action with an owner and a due date. If nobody will own it, it is not really in your register.
- Set the review rhythm. Put review dates in the register and in calendars. Report the top risks and overdue actions to leadership every month.
A first version for a small or mid-sized business usually holds 15–40 risks. Many more than that and nobody reads it; many fewer and you are probably grouping several risks together.
Risk register vs risk assessment vs issue log
| Risk assessment | Risk register | Issue log | |
|---|---|---|---|
| What it is | The activity of identifying, analysing and evaluating risks | The record of risks and how they are managed over time | A record of problems that have already happened |
| Time frame | A point in time | Ongoing | Now |
| Key question | “What could go wrong, and how bad is it?” | “Who is doing what about it, and is it working?” | “How do we fix this?” |
When a risk materialises it becomes an issue or incident. Keep the link: a risk that keeps turning into incidents is scored too low, or its controls are not working.
Project risk register vs corporate risk register
A project risk register covers risks to a single project’s scope, schedule, budget and quality, and closes when the project does. It often adds fields such as the affected milestone, schedule impact in days and cost impact, which allow an expected monetary value (probability × cost) to be calculated for contingency planning.
A corporate (enterprise) risk register covers risks to the organisation’s objectives as a whole and never “finishes”. Large project risks should be escalated to it, so leadership sees them alongside operational and strategic risks.
Common mistakes
- Topics instead of risks. “IT”, “Competition”, “People” — no one can score or act on these.
- Owners that are teams or committees. “Finance” owns nothing. Name a person.
- Only residual scores. Without the inherent score you cannot see which controls are critical and must be tested.
- Controls that exist on paper. A policy nobody follows is not a control. Record only what operates, and test the important ones.
- Everything is amber. If most risks score 9–12, your scales lack anchors. Recalibrate with numbers.
- A register that never changes. If the scores in March match the scores in October, nobody is reviewing it.
How often to review a risk register
A practical rhythm for most organisations:
- Critical and significant risks — monthly, by the owner, with a short update to leadership.
- The full register — at least quarterly.
- Immediately after a major change: new product or market, a key supplier or system change, new regulation, or an incident.
Spreadsheet or software?
A spreadsheet is the right place to start: it is free, flexible and everyone can open it. It starts to hurt when several people edit it, when you need a history of who changed which score and why, when actions slip without anyone being reminded, or when the board wants a matrix and a trend rather than a 300-row file.
That is the point to move to dedicated risk register software — ideally one that imports your existing spreadsheet rather than making you start again.
Frequently asked questions
What is the purpose of a risk register?
To give one agreed view of the risks that could affect your objectives, who owns each risk, how serious it is and what is being done about it — so that decisions and follow-up do not depend on memory or scattered emails.
Who owns the risk register?
The register as a whole is usually maintained by a risk manager, finance lead or project manager. Every individual risk needs its own named owner: the person with the authority and budget to act on it.
How often should a risk register be reviewed?
High and critical risks monthly, the whole register at least quarterly, and immediately after a major change or incident.
What is the difference between a risk register and a risk assessment?
A risk assessment is the activity of identifying, analysing and evaluating risks. The register is where the results are recorded and then tracked over time.
Is a risk register required by law?
Not usually by name. But many regulators, funders, auditors and standards such as ISO 31000 expect you to show how risks are identified and managed, and a risk register is the most common way to evidence it. In regulated sectors — for example Australian banks and insurers under APRA CPS 230 — the expectations are explicit.
Skip the blank spreadsheet
Describe your business or paste your website, and Risk Samurai drafts a scored, ISO 31000-aligned risk register in minutes. You review, edit and approve every risk.
Get early access