How to Build a Risk Register That Actually Gets Used (And What Most Teams Get Wrong)

Most teams have a risk register. Almost nobody uses it properly.

It starts well. Someone creates a spreadsheet, adds a few columns — risk title, probability, impact, owner, status — and the team dutifully fills it in at project kick-off. For a few weeks, it gets updated. Then it becomes a quarterly exercise. Then it becomes the thing the PM hastily refreshes the night before a steering committee meeting.

By the time an auditor asks "who approved this escalation and when?", the answer is buried in an email thread from six months ago, or it doesn't exist at all.

This isn't a discipline problem. It's a design problem. The way most risk registers are built makes them impossible to maintain. They're logs, not management systems. And there is a meaningful difference between the two.

A Risk Log Versus a Risk Register

The terms are used interchangeably, but they describe very different things.

A risk log is a record of what you wrote down. It captures risks as they occur to someone, usually at the start of a project, and stores them in a flat list. There is no mechanism to update scores consistently, no trigger to escalate when something becomes critical, and no way to see risk across multiple projects at once. It exists so you can say you have one.

A risk register is a live management tool. Every risk has a named owner. Scores are proposed consistently and reviewed by a human before they are recorded. When a risk crosses a severity threshold, something happens automatically: the right person is notified, a decision is required, and that decision is recorded. The register is not a snapshot of how things looked at kick-off. It reflects how things look right now.

The difference matters enormously when something goes wrong. A log tells you that someone once wrote "supplier delivery delay — probability 3, impact 4" six months ago. A register tells you who scored it, when, what was proposed versus what the human approved, whether it was escalated, who reviewed the escalation, and what action was taken.

What a Working Risk Register Requires

Before getting into what goes wrong, it helps to be precise about what a properly functioning register needs to do. There are five things.

• Every risk needs a single named owner. Not a team. Not a programme. One person who is responsible for monitoring the risk, updating the score when circumstances change, and escalating when necessary. Without a named owner, diffuse ownership produces diffuse accountability.
• Scores need to be set consistently. The biggest problem with probability and impact scoring is not that people get it wrong — it is that two people looking at the same risk will score it differently. AI scoring removes that variation by applying the same reasoning to the same description every time.
• Scoring must be human-approved. AI can propose consistently, but it does not know your context. The PM reviews the AI's proposed scores, adjusts if their situation warrants it, and approves. That decision is recorded with their name and a timestamp.
• Escalation must be automatic. A register that depends on someone noticing a threshold has been crossed, deciding to escalate, and remembering to send an email will fail consistently. Effective escalation is triggered by the system when a risk score crosses the threshold — not by individual vigilance.
• The register must span the hierarchy. A risk that sits only at project level is invisible to the programme manager. A working register operates at project, programme, and portfolio levels simultaneously, with risks rolling up automatically.

Where Most Teams Go Wrong

Given those five requirements, here is where the gaps typically appear.

• Scoring by gut feel. When there is no consistent reference point, scoring degrades into guesswork. A senior PM and a junior PM scoring the same risk will arrive at very different numbers. When scores are inconsistent, the register becomes useless as a decision-making tool.
• Escalation that depends on email. The standard workflow: the risk owner notices the score has crossed a threshold, sends an email, the programme manager forwards it to the PMO lead, and the board reviews it three weeks later. By that point the risk has often already materialised.
• No ownership enforcement. Creating a risk owner column and actually enforcing ownership are different things. In a spreadsheet, the owner field is just text — there is no mechanism to ensure the named person knows they own it, receives alerts when their risk escalates, or is the one whose approval is recorded.
• Siloed visibility. A team running multiple projects in parallel almost certainly has risk overlap. When risks live in separate spreadsheets, nobody sees the connections. The programme manager has no aggregate view. The portfolio owner has no systemic picture.
• The register as a snapshot. Perhaps the most common failure: the register gets created at the start of a project, reviewed quarterly at best, and consulted when governance requires it. In between, real risks accumulate in email threads and conversations that never make it back to the register.

What a Working Register Looks Like in Practice

Here is what the workflow looks like when all five requirements are met.

When you create a project, you give it a one-line description. That description feeds directly into the AI scoring engine — it provides the context the AI needs to produce domain-relevant probability and impact assessments, rather than generic scores that could apply to any project in any industry.

When you log a risk, you give it a title, a description, and assign it to an owner. Once you have a description of at least 20 characters, you trigger AI analysis. The AI considers your risk description, your project description, and up to ten other open risks in the same project — using all of that context to propose a probability score from 1 to 5, an impact score from 1 to 5, and a plain-language reasoning summary.

On Starter and Team plans, the AI also generates a full mitigation plan: a set of suggested actions, each with a recommended owner role. This is tailored to the specific risk and project context — not a generic checklist.

You then review everything the AI has proposed. You can accept the scores as suggested, or adjust them if your context warrants it. When you approve, that decision is recorded — the approved scores, the AI's original proposal, and any adjustments you made are all stored as part of the risk's history.

If the approved score reaches 15 or above — probability multiplied by impact — the risk is automatically escalated. On Starter and Team plans, this triggers an email notification to the project owner within two minutes, naming the risk and its score. On the Team plan, the escalated risk also appears in a reviewer queue, where it requires a formal human sign-off before it can be closed — creating the governance record that audit requires. Full audit trail records are available on the Team plan (£25/month).

At programme level, your Programme Manager sees all escalated risks rolled up across every project in the programme. At portfolio level, the Portfolio Owner sees a heatmap of risk concentration and can trigger an AI cluster analysis — grouping open risks by theme across the entire portfolio to surface systemic issues that would be invisible at project level.

The register also surfaces linked risks. When the AI detects meaningful interdependencies with other open risks in the same project, it shows you those connections with a brief explanation of how they are related. When you need to report upward, the board narrative feature generates a 2–4 paragraph executive summary of your project's risk posture with a single click — ready to copy directly into a steering committee pack. Every risk can be exported to CSV at any time.

What This Means for Your Team

A register built this way does three things that most registers do not.

It removes the dependency on individual memory and discipline. Escalation does not require someone to notice a threshold has been crossed. AI consistency does not require everyone to share the same intuitive calibration. The system enforces the process so your team does not have to.

It creates an evidence trail without additional effort. Every approval, every escalation, every adjustment to a score is recorded as it happens. When an auditor asks who approved a risk decision and on what basis, the answer is already there — no email archaeology required.

And it scales naturally. A PM managing one project gets immediate value from consistent AI scoring. A programme manager overseeing eight projects gets aggregate visibility without manual consolidation. A portfolio owner with multiple programmes gets systemic theme detection across hundreds of risks. The same register model serves all three levels.

Getting Started

KinetiRisk is free to start — one project, five AI analyses, no credit card required. That is enough to see exactly how the scoring and approval workflow operates before committing to anything.

When you are managing more than one project, or when you need escalation alerts and full mitigation planning, Starter is £5 per month. When governance matters — audit trails, compliance records, and formal review workflows for your team — Team is £25 per month for up to ten seats.

You do not need to migrate your existing risk register to get started. Create a project, describe it, log your highest-priority risks, and run the AI analysis on the first one. The workflow will be immediately familiar if you have ever maintained a RAID log or a risk register — this is the same practice, with the manual and inconsistent parts replaced.

Key Takeaways

• A risk register only works if maintained in real time — the design determines whether maintenance is sustainable, and most designs make it unsustainable
• Every risk needs a single named owner — one person accountable for monitoring, updating, and escalating, not a team or a programme
• Consistent scoring requires a calibrated reference point. AI scoring gives every team the same baseline, removing the variation that comes from different people applying different intuitions
• Human approval of AI scores is not optional. It is the governance step that makes scores defensible and records who decided what and why
• Automatic escalation is not a convenience feature. It is the mechanism that ensures critical risks reach the right people without depending on someone remembering to act
• Portfolio and programme visibility is not a reporting exercise. It is how risk management produces value at an organisational level rather than a project level