Risk Register Generator

What a risk register is, and the standard behind it

A risk register is a running list of what could go wrong, how much each item matters, and what is being done about it. The usual reference for managing risk is ISO 31000, published by the International Organization for Standardization. Its current edition came out in 2018, replacing the 2009 original, and ISO confirmed it again in 2023¹.

ISO 31000 is a short set of guidelines, 16 pages long. It lays out principles, a framework and a process: find risks, analyze them, weigh them, treat them, then keep monitoring and talking about them¹. It treats risk as something that can bring opportunities as well as threats¹. It is a way of working, not a form to fill in. The specific scoring methods sit in a companion standard, IEC 31010, Risk assessment techniques¹.

So a register is one tool inside that process, not the whole of it. The list above is a first draft. The rest of this guide covers what turns it into something a team can manage.

Scoring likelihood and impact, and where it goes wrong

Most registers rate each risk on likelihood and impact, then rank by the pair. It is simple, and it has a known flaw. In "What's Wrong with Risk Matrices?", published in Risk Analysis in 2008, Louis Anthony (Tony) Cox Jr. tested the math behind these grids². He found that:

• They blur very different risks together. A typical grid could correctly compare fewer than 10% of randomly chosen pairs of hazards, and it gave the same rating to risks that were very different in size².
• They can rank a smaller risk above a bigger one. When the likely risks are the small ones and the rare risks are the huge ones, a grid can do worse than picking at random².
• Different people read the same risk differently. "Medium" means one thing to the finance lead and another to the engineer, so two people can give the same risk opposite ratings².

Cox did not say to throw the grid away. He said to use it with care and explain the judgments inside it². In practice that means three habits.

• Define the words in numbers. Write down what each level means before anyone rates. For example, High likelihood is "better than 1 in 3 before launch," and High impact is "more than $50,000 or a two-week delay."
• Use the grid to sort, not to decide. It is good at separating the handful of risks worth a conversation from the long tail. It is poor at choosing between two risks that both land in the top corner.
• Look hard at rare, severe risks. These are the ones a grid most often underrates. If one would end the project, give it an owner even if it scores Low on likelihood.

Give every risk an owner and a trigger

A mitigation nobody owns does not happen. Each real risk needs four things beyond its score:

• One owner. A named person, not a team. They do not do all the work. They make sure it gets done and raise the alarm if it does not.
• A trigger. The early, visible sign that the risk is starting to happen, such as a missed test date or a supplier going quiet. A trigger turns "keep an eye on it" into something a person can check.
• A response for before. What you do now to make it less likely or less harmful.
• A response for after. What you do the day the trigger fires, agreed in advance so nobody has to invent it under pressure.

A weak entry and a stronger one

This is the migration example shown above, rewritten. The business, people and figures are invented for illustration.

The stronger entry can be checked on a date, and everyone knows who decides and what happens next. For who does what across the whole project, a RACI matrix pairs well with the register.

Finding the risks nobody wrote down: the premortem

A generated list starts from what is common for projects like yours. It cannot know your team's own worries, and people are often reluctant to voice doubts while a plan is being made. Gary Klein's premortem, described in Harvard Business Review in 2007, is built for that gap³.

• Set the scene. Tell the team to imagine the project has failed, badly, a year from now.
• Write alone. Each person spends a few minutes writing every reason they can think of, in silence.
• Go around. Take one reason from each person in turn until the list is complete.
• Add to the register. Rate the new risks, then give each serious one an owner and a trigger.

Klein cites 1989 research by Deborah Mitchell, Jay Russo and Nancy Pennington: imagining an event has already happened improved people's ability to identify reasons for an outcome by 30%³⁴. The exercise also makes it safe for the people who know a plan's weak spots to say so³. It fits well inside a planning day; see the annual planning offsite and strategy reset pages for where it goes in the agenda.

Keeping the register alive

ISO 31000 treats monitoring and review as part of the process, not an afterthought¹. A register written at kickoff and never opened again is the most common failure. Set a rhythm that matches the pace of the project, such as every two weeks for a three-month project, and ask the same five questions each time:

• Did any trigger fire? If so, the agreed response starts now.
• Did any rating change? Risks shrink as work gets done and grow as deadlines get close.
• Are the "before" actions done? A mitigation past its date is a risk of its own.
• What is new? Ask the owners and the people doing the work, not only the project lead.
• What can close? Mark risks that have passed as closed rather than deleting them, so the next project can learn from them.

A risk register answers "what could stop this plan?" It does not answer whether the plan is the right one. If the team is still choosing between options, weigh them first with a decision matrix, then set out scope and goals in a project charter before building the register.