Most teams can name what might sink them, a key supplier folding, a data breach, the one engineer who holds the whole system in their head. The register is where those worries stop being corridor anxiety and become a managed list: named, sized, owned, and assigned an action. Get it right and it sharpens decisions. Get it wrong and it becomes a spreadsheet nobody opens between audits.

The quick version

  • A risk register (or risk log) is a living list of the things that could stop you hitting your objectives, each with its likelihood, its impact, an owner, and a planned response.
  • For every risk you have four honest options, often called the four Ts: tolerate it, treat it (reduce likelihood or impact), transfer it (insurance, contracts), or terminate the activity causing it.
  • You can't treat everything, so you prioritise by likelihood × impact and spend your effort where exposure is highest, set against how much risk you're willing to carry (your risk appetite).
  • The trap is the register that exists to look diligent rather than to change behaviour. If no decision moved because of it this quarter, it's filing, not risk management.

The idea in depth: a register is a decision tool

The international reference point is ISO 31000:2018, the risk-management guideline used across sectors and jurisdictions. It frames risk management as a continuous process, establish the context, then identify, analyse, evaluate and treat risks, while communicating, monitoring, reviewing and, crucially, recording and reporting. The register is the artefact that holds that record: it is where identification becomes analysis (how likely, how bad) and analysis becomes a treatment decision. ISO is deliberately a guideline, not a certifiable standard, it tells you the shape of good practice, not a single mandated template.

So build the register around the decision, not the inventory. A useful row carries more than a description: the cause, the likelihood, the impact, the current controls, the chosen response, a named owner, and a review date. The discipline that separates a real register from theatre is the owner and the date. A risk with no one accountable and no next look isn't being managed, somebody just wrote it down. The move on Monday is to open your existing register (or start one) and check a single column: does every line have a named human and a next review date? If not, that gap is your first job.

What goes in each row depends on how precisely you can size the risk. The register is described as qualitative when likelihood and impact are ranked in bands, high, medium, low, and quantitative when they're put in numbers, such as a 30% chance of a £500k loss. The Project Management Institute's PMBOK guidance treats the register as the central repository that grows through the project: risks are captured, then assessed for probability and impact, then assigned responses (PMI, project risk management). Most teams live in the qualitative world, and that's fine for prioritising, just don't mistake a colour-coded grid for a measurement.

Mitigation: the four honest responses to a risk

Once a risk is on the list, "mitigation" gets used loosely to mean anything you do about it, but the cleaner framing is that you have four distinct responses, and reducing the risk is only one of them. The version most widely taught in governance is the four Ts, set out plainly in HM Treasury's Orange Book, the UK government's risk-management guidance:

  • Tolerate, accept the risk as it stands, usually because it's low, or because the cost of acting outweighs the exposure. Often paired with a contingency plan in case it lands.
  • Treat, keep doing the activity, but add controls that cut the likelihood or the impact. This is the workhorse response, and the one people usually mean by "mitigation."
  • Transfer, shift the financial consequence to someone else, classically through insurance or a contract clause. The event can still happen; the cost lands elsewhere.
  • Terminate, stop doing the thing that creates the risk. The most decisive option, and the one organisations reach for least, because the risky activity is usually also valuable.

The Orange Book pairs each response with where a risk sits on the likelihood-and-impact grid: low/low risks you can often tolerate; high-likelihood risks you treat; high-impact-but-rare risks are candidates to transfer; and the high-likelihood, high-impact corner is where you consider terminating the activity altogether. (You'll also meet a sibling vocabulary, avoid, reduce, transfer, accept, which maps onto the same four ideas.) So the move is to make the response explicit on every material row: write down which of the four Ts you've chosen and why. A register full of risks with no named response is a list of fears; a register where each one says "treat, add an offsite backup, owner: Priya, review March" is a plan.

flowchart TD
  A(["A risk is identified
cause + consequence"]) --> B{"Likelihood × impact
vs our risk appetite"}
  B -->|"Low / low"| C(["Tolerate
accept + watch"])
  B -->|"High likelihood"| D(["Treat
add controls"])
  B -->|"High impact, rare"| E(["Transfer
insure / contract"])
  B -->|"High / high"| F(["Terminate
stop the activity"])
  C --> G(["Owner + review date
back to the register"])
  D --> G
  E --> G
  F --> G
The four Ts, chosen by where a risk sits on the likelihood-and-impact grid. Leaders Loop

None of these decisions makes sense without a sense of how much risk you're willing to carry. That's risk appetite, and the COSO Enterprise Risk Management framework (updated 2017) makes the point that appetite should be set deliberately and aligned with strategy, the line that tells you whether a given exposure is one to tolerate or one to act on. Without it, every risk looks equally urgent. With it, the same grid sorts itself: appetite is the threshold that turns "this could happen" into "and therefore we will."

An owner and a review date are what turn a row in a spreadsheet into a risk someone is actually carrying.

Where this breaks down: the comfort of a coloured grid

The honest limitation is that the most common register format, the qualitative likelihood × impact matrix, the red-amber-green heat map, has been seriously challenged on its own terms. In The Failure of Risk Management (2nd ed., 2020), Douglas Hubbard argues that scoring risks on ordinal scales, rating likelihood "3 out of 5" and impact "4 out of 5" and multiplying, has thin empirical support, can compress genuinely different risks into the same box, and risks giving teams false confidence: the look of rigour without the substance. His own remedy leans on quantitative methods (explicit probabilities, ranges, simulation) rather than colours.

You don't have to abandon the register to take the point. Treat the heat-map grid as a conversation-starter for triage, not a precise measurement, and for your handful of genuinely existential risks, push past colours toward real numbers: a defensible probability range and a financial impact estimate. The register stays; the discipline is knowing which rows deserve arithmetic and which only need a sanity check. A grid that helps you argue about priorities is doing its job; a grid you mistake for a measurement is the failure mode Hubbard warns about.

A worked example

Take a 40-person logistics-software firm, call it Cartwheel. (Illustrative figures throughout; this is a teaching example, not a real company.) Their register has drifted into theatre: forty-odd rows, mostly amber, last meaningfully reviewed at the previous audit. The new operations lead doesn't add rows, she subtracts. She asks of each line: who owns this, when do we look again, and what have we actually decided to do?

Three risks survive the cull. First, key-person dependency: one engineer holds the deployment pipeline in their head, high likelihood of disruption if they leave, high impact. You can't terminate having a pipeline, so the response is treat: document it, pair a second engineer onto it, owner the CTO, review in six weeks. Second, a customer data breach: lower likelihood, severe impact. Some of it they treat (access controls, backups); the residual financial exposure they transfer via cyber-insurance. Third, a niche compliance report that's expensive to produce and barely used: the risk of getting it wrong is real, but the activity hardly earns its keep, so they terminate it after checking no obligation requires it.

flowchart LR
  A(["Bloated register
~40 rows, mostly amber"]) --> B(["Cull to what's material
3 risks survive"])
  B --> C(["Key-person dependency
TREAT: document + pair, owner CTO"])
  B --> D(["Data breach
TREAT controls + TRANSFER residual to insurer"])
  B --> E(["Low-value compliance report
TERMINATE the activity"])
  C --> F(["A register that changes
what people do this quarter"])
  D --> F
  E --> F
Cartwheel's register stops being a list and starts being a set of decisions. Leaders Loop

Notice what changed. The register got shorter, not longer, and every surviving row names a response, an owner, and a date. The win isn't the document, it's that three real decisions got made, and the team can say exactly who is acting on each. That's the difference between a register that satisfies an auditor and one that protects the business.

Frequently asked questions

What's the difference between a risk register and risk management?

The register is one tool; risk management is the whole process around it. ISO 31000 describes that process as establishing context, then identifying, analysing, evaluating and treating risks, with ongoing monitoring and review. The register is where you record and report, it holds the decisions, but the thinking, the owners and the follow-through are what make it management rather than documentation.

What are the four mitigation strategies?

The common framing is the four Ts: tolerate (accept the risk), treat (add controls to cut likelihood or impact), transfer (shift the financial consequence, e.g. via insurance), and terminate (stop the activity creating the risk). A near-identical model uses avoid, reduce, transfer and accept. "Mitigation" in everyday use usually means the second one, treat, but a complete register considers all four for each material risk.

How do I prioritise which risks to act on?

Score each risk by likelihood and impact, then sort. The highest exposure, high likelihood and high impact, demands action first; low/low risks you can usually tolerate and watch. Crucially, set that against your risk appetite: the level of risk the organisation has decided it's willing to carry. Appetite is the threshold that turns a long flat list into a short, ordered set of things to actually do.

Are risk matrices and heat maps reliable?

They're useful for starting a triage conversation, but treat them with care. Douglas Hubbard's work argues that scoring risks on simple high/medium/low scales has weak empirical grounding and can create false confidence. The pragmatic stance: use the grid to compare and prioritise, but for your few genuinely serious risks, push toward real probability and financial estimates rather than relying on the colours alone.

How often should we review the register?

There's no universal number, but a register reviewed only at audit time has stopped being a live tool. Give every material row a named owner and a review date, and revisit the whole register on a regular cadence, quarterly is common for an organisation-level register, more often for a fast-moving project. New risks appear and old ones change; the review is what keeps the document honest.

Related in the Toolkit

A register is the operational layer of a bigger system: it only makes sense once you've decided how much risk you're willing to carry, and it's only as good as the identification and assessment that fills it.

Where to go next