Documents · Glossary

What is a risk register?

A risk register is the working list of things that could go wrong on a project or in a business, each one written as a cause and an effect, rated for likelihood and consequence, assigned to a named owner, given a planned response, and reviewed on a schedule. It is updated continuously rather than written once.

A register is only worth the time it takes if somebody reopens it. Most of them are built in week one, presented at the kick off, and never touched again, which turns a control into decoration.

Indunil Asanka · Co-founder

5 min read · Published 12 September 2026

What each column in a register carries
Column	What goes in it	Common mistake
Risk statement	A cause, an uncertain event and an effect	Writing a problem that has already happened
Category	Delivery, financial, people, vendor, compliance	Categories nobody filters by
Likelihood	The agreed scale, applied consistently	Every risk rated medium
Consequence	The effect if it happens, on the agreed scale	Rating the worst imaginable case
Owner	One named person, not a team	A committee, so nobody acts
Response	Avoid, reduce, transfer or accept, with an action	A treatment with no due date
Residual rating	The rating after the treatment works	Left blank, so the treatment is never judged
Review date	When it is next looked at	Reviewed only when something goes wrong

Writing a risk so it can be acted on

The single biggest improvement to most registers is the sentence structure. Write each entry as because of a cause, an event may occur, which would lead to an effect. Because the vendor has committed only two engineers, the data migration may not finish in the test window, which would delay user acceptance testing by four weeks. That shape forces three things into the open: what you could change, what you are uncertain about, and what it would cost. Compare it to the version most registers contain, which is simply migration delay. Nobody can own migration delay, nobody can treat it, and nobody can tell when it has stopped being a risk. If an entry cannot be written in the cause and effect form, it is usually an issue that has already happened, and it belongs on the issues log instead.

Register against matrix

The matrix is not a rival document; it is one view of the register. A matrix plots likelihood against consequence on a grid and colours the cells, which is useful for a board paper because it shows the shape of the portfolio at a glance. It holds no owners, no treatments and no dates, so it cannot be worked from. Problems appear when the matrix becomes the artefact that gets maintained: risks are dragged between cells in a slide while the register behind it goes stale, and the ratings drift because there is nowhere to record why a risk moved. Keep the register as the source and generate the matrix from it, not the other way around.

Ratings only mean something if the scale is written down

Likelihood and consequence scales are worthless unless the levels are defined in the document itself. Likely should mean something like more than a fifty per cent chance within the project window, not a feeling. Major consequence should be pinned to a number, a duration or a named outcome: more than two hundred thousand dollars, more than a month of delay, a reportable breach. Once the scales are written down, two people rating the same risk usually land within one level of each other, and the register becomes comparable across projects. Without them, every risk drifts to the middle of the grid, because medium is what people choose when they are not sure and do not want to be wrong.

Keeping it alive

A register works when it has a standing slot in an existing meeting, not a meeting of its own. Ten minutes on the top five, the newly raised and anything whose treatment is overdue is enough, and the register should be updated in the meeting rather than afterwards. Close risks explicitly, with a date and a reason, rather than deleting rows, because the history of what was worried about and what actually happened is the only way a team improves its judgement. Expect the register to shrink as a project matures. A register that keeps growing to the last week usually means new risks are being added while old ones are neither treated nor closed.

Building a register as a document

A risk register is mostly a table, so it suits a document with a tabular structure and a landscape friendly layout. Tables are one of the forty five component types, and a register with twelve rows and eight columns is readable if the risk statement column carries the sentence and the rest carry short codes. Callouts come in four variants, which is enough to flag the risks above appetite without inventing a colour system. Input fields are not used in documents, so ratings and owners are written as content rather than collected. If the register runs past three pages with a review history, it becomes a long document and can carry a contents list whose headings match the sections exactly.

Questions people ask

How many risks should a register hold?

For a project of a few months, fifteen to twenty five active entries is a normal working range. Fewer usually means the team has only recorded the obvious ones; many more means issues, tasks and assumptions have been swept in. If the list is long, split it by category and give each category an owner rather than trying to review everything every fortnight.

What is the difference between a risk and an issue?

A risk has not happened yet and carries uncertainty; an issue is happening now and needs a decision rather than a treatment. When a risk occurs it should be closed on the register with a note, and opened on the issues log. Keeping the two in one list is how live problems get buried among things that might never occur.

Who owns a risk?

One named person who can actually influence the cause or absorb the effect, which is usually not the project manager. The manager owns the register; the individual risks belong to the people with the levers. A risk owned by the project manager by default is a sign that nobody senior has accepted responsibility for it.

What does risk appetite mean in practice?

It is the line above which a risk has to be escalated rather than managed in the team. Writing it as a rating threshold makes it operational: anything rated high consequence goes to the sponsor regardless of likelihood. Without a stated line, escalation becomes a matter of nerve, and quiet managers escalate less than loud ones.

Should opportunities go in the register?

Some frameworks treat upside uncertainty as a risk with a positive effect, and recording them alongside threats can work well. The practical caution is that opportunities compete for attention with threats and usually lose. If you include them, give them their own section and their own review time, or they become a column nobody reads.

How often should the register be reviewed?

Fortnightly for an active project, monthly for business as usual, and immediately after any significant change in scope, funding or vendor. Set the next review date per risk rather than for the whole document, so a stable low rated risk is not rediscussed every fortnight while a volatile one waits for the cycle.

Make one with documents

The button opens the generator with this use case already described. Change the wording to match your own.

Create a document with OneCraft

Sources

Written and checked by the OneCraft team. Last checked 12 September 2026.