Home · Templates · Risk register
Risk register template
A free, editable Excel risk register with probability × impact scoring, severity banding and colour-coding already built in — plus the part most templates leave out: how to actually write a risk so that someone can act on it.
Risk register template — Excel (.xlsx)
Scoring formulas, response and status dropdowns, a worked example and a how-to sheet. No email wall, no watermark. Edit and reuse freely.
What a risk register is for
A risk register is the single list of everything that could knock your project off course — each entry scored, owned by a named person, and given a response someone has agreed to carry out. That is the whole idea. Everything else is administration.
The value is not in having one. Plenty of projects have a beautifully formatted risk register that was filled in during week one and never opened again — and that register is worse than useless, because it creates the impression of control while the real risks go unwatched. The value is in it being live: risks added as they emerge, re-scored as things change, closed when they can no longer happen, and reviewed at every stage boundary.
How to write a risk that can actually be managed
This is where most registers fall down, and it has nothing to do with the spreadsheet. A risk written as a single noun — "Supplier", "Budget", "Timescales" — cannot be scored, cannot be owned, and cannot be responded to. Nobody knows what you are afraid of.
Write every risk in three parts: cause → event → effect.
| Part | What it captures | Example |
|---|---|---|
| Cause | Something that is true today. Not uncertain — a fact about your situation. | The stock system is a 16-year-old bespoke database with no documentation and no supported API. |
| Event | The uncertain thing that might happen because of that cause. | Stock data cannot be reliably synchronised with the new website. |
| Effect | What that would do to the project's objectives — time, cost, scope, quality, benefits. | Launch slips past the Christmas trading window, losing the season's revenue the business case depends on. |
The test: if you cannot say what is true today (cause) and what it would cost you (effect), you have written a worry, not a risk. Worries cannot be delegated. Risks can.
Scoring: probability × impact
Rate each risk twice, on a scale of 1 to 5. Multiply the two for a score out of 25.
| Rating | Probability — how likely is the event? | Impact — how bad if it happens? |
|---|---|---|
| 1 Very low | Would be surprising. No sign of it so far. | Absorbed without anyone outside the team noticing. |
| 2 Low | Possible, but you would not expect it. | Some rework or delay, contained within tolerance. |
| 3 Medium | A realistic chance either way. | Pushes a stage beyond its time or cost tolerance. Escalation. |
| 4 High | More likely than not, on current evidence. | Threatens a project objective or a headline benefit. |
| 5 Very high | Expect it unless something changes. | The project no longer makes sense. The business case fails. |
The score sorts the register so the things worth your attention float to the top. It is a triage tool, not a measurement — a 12 is not "50% worse" than an 8, and precision here is false comfort. What matters is that two people scoring the same risk land in roughly the same band and can argue about why.
The 5×5 matrix and the severity bands
Score 15 or more is High; 8 to 14 is Medium; 1 to 7 is Low. The template applies these automatically and colours the row.
| Probability ↓ | Impact → | ||||
|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | |
| 5 | 5 | 10 | 15 | 20 | 25 |
| 4 | 4 | 8 | 12 | 16 | 20 |
| 3 | 3 | 6 | 9 | 12 | 15 |
| 2 | 2 | 4 | 6 | 8 | 10 |
| 1 | 1 | 2 | 3 | 4 | 5 |
High (15+) — escalate; the board should know. Medium (8–14) — manage actively; the response should be in progress. Low (1–7) — monitor; re-score if anything changes.
Note the asymmetry, and keep it. A near-certain trivial problem (5 × 1 = 5) is Low. A rare catastrophe (1 × 5 = 5) scores the same — and that is the known weakness of every multiplicative matrix. If a risk would end the project, escalate it regardless of what the arithmetic says. The score serves your judgement; it does not replace it.
Using your own matrix
If your organisation already has a risk matrix, do not fight it. Map each of your axes onto the 1–5 scale, keep your own descriptors in the risk description, and if your band thresholds differ, change the two numbers in the severity formula. Nothing else in the template depends on them.
Choosing a response
Every risk above Low needs a decision, not a restatement. "Monitor closely" is not a response — it is what you say when nobody has decided anything.
| Response | What it means | Example |
|---|---|---|
| Avoid | Change the plan so the risk cannot happen at all. | Drop the live stock sync from scope; launch with a nightly export instead. |
| Reduce | Act to lower the probability, the impact, or both. | Run a two-day data spike in week one, before the build is committed. |
| Transfer | Move the financial consequence to someone else. The risk still exists. | Fixed-price contract with the integration supplier; penalty clause for late delivery. |
| Accept | Consciously decide to live with it. A legitimate answer — if it is a decision. | Accept that a niche browser renders imperfectly; not worth the cost to fix. |
| Share | Split the pain and the gain with another party. | Joint venture where both parties carry a proportion of overrun cost. |
| Contingency | Do nothing now, but have a funded, agreed plan ready if it fires. | Hold two weeks' float and a booked contractor, released only if the spike fails. |
Owner, proximity and status
- Owner — one named person. Not "the team", not "IT", not a job title with nobody in it. A risk owned by everybody is watched by nobody. The owner is accountable for watching the risk and delivering the response — which is a different job from being the person who would fix the damage.
- Proximity — how soon could it bite? Imminent, this stage, this project, or beyond the project. Proximity is why two risks with identical scores get different attention: a 9 landing next week outranks a 12 that cannot occur until next year.
- Status — open, mitigating, or closed. Close a risk when it can no longer happen, not when you get bored of it. If it has happened, close it here and open it on the issue log.
Five mistakes that make a register useless
- Written once, never reviewed. The single most common failure. If nothing on the register has been re-scored in a month, it is decoration.
- Everything scores 9. When every risk lands mid-table, nobody has actually discriminated between them, and the register cannot do its only job — telling you what to look at first.
- Risks that are really issues. "The developer left" is not a risk; it has happened. Mixing the two hides the things that are still preventable.
- Nobody owns anything. Blank owner column, or the project manager's name against all seventeen rows. Same thing.
- No closure. Risks that expired six months ago still sitting open, so the live ones are buried among the dead.
A template is a snapshot. A project moves.
The register above goes stale the day you close the spreadsheet. In Guddle it is a living view — scored the same way, exportable to a branded PDF whenever someone asks for "the document", and watched overnight by an analyst that flags the risks nobody has raised yet. It proposes; you approve. AI does the admin, you keep the governance.
Start free — first project on usOr paste a plain-English brief and Guddle drafts the whole project — stages, budget, a scored register and the business case — for you to review.
The other templates
Common questions
What is the difference between a risk and an issue?
A risk has not happened yet — it is uncertain, and you can still act to change its probability or its impact. An issue has already happened and has to be managed. When a risk occurs, close it on the register and open it on the issue log. Don't just delete it: the record that you saw it coming is worth keeping.
How often should the register be reviewed?
At every stage boundary as a minimum, and at each progress checkpoint in between. The review exists to catch two things: risks whose score has changed, and responses nobody has actioned.
Do I need a risk register on a small project?
Yes — but a proportionate one. Tailoring means shrinking the paperwork, not the thinking. Five well-written risks with named owners will serve a small project far better than thirty rows of generic entries copied from a checklist.
Is this an official PRINCE2 template?
No. It is an independent template written from scratch, aligned with the method's approach to risk. It is not affiliated with, endorsed by, or copied from PeopleCert or AXELOS materials.