Risk Register Template
A register that changes decisions — cause-event-effect risks, scales you define yourself, a named owner per risk, responses with dates, and the five-question review.
Markdown. No sign-up, no email.
Ten risks that are genuinely managed beat sixty that are catalogued. If a row cannot be acted on, it is a condition, not a project risk.
Issues go in a different list. A risk might happen; an issue has happened. Mixing them lets today's problems crowd out tomorrow's, which is the failure this register exists to prevent.
Project: _______________ Owner: _______________ Last reviewed: _______ Next review: _______
Define the scales first#
Undefined scales produce scores that vary by author and cannot be compared. Fill these in for this project before scoring anything.
| Score | Likelihood | Impact — cost | Impact — schedule | Impact — other |
|---|---|---|---|---|
| 5 | almost certain | over ___ | over ___ | regulatory breach / customer-visible outage |
| 4 | likely | |||
| 3 | possible | |||
| 2 | unlikely | |||
| 1 | rare |
The register#
Write each risk as cause → event → effect. It forces you to name the cause, which is usually the only part you can act on.
| ID | Risk (because… there is a risk that… resulting in…) | L | I | Score | Owner (person) | Response | Action | Due | Status |
|---|---|---|---|---|---|---|---|---|---|
| R1 | avoid / reduce / transfer / accept | open | |||||||
| R2 |
Response definitions:
| Response | Means | Note |
|---|---|---|
| Avoid | Change the plan so it cannot occur | Usually cheapest, least considered |
| Reduce | Lower likelihood or impact | Needs a specific action, owner and date |
| Transfer | Contract, insurance, supplier obligation | Transfers cost, not operational consequence |
| Accept | Live with it, deliberately, on the record | Needs a trigger for reconsidering |
🔴 A risk owned by "the project" or by the project manager for all thirty rows gets reported on rather than acted on. The owner must be someone who can actually influence it.
Accepted risks#
| ID | Risk | Accepted by | Date | Trigger to reconsider |
|---|---|---|---|---|
Accepting a risk explicitly is a legitimate and underused decision. Accepting it silently is not.
Closed risks#
| ID | Risk | Why closed | Date |
|---|---|---|---|
| passed / mitigated / became issue ___ |
A register that only grows stops being read. Close things.
The review — five questions, fifteen minutes#
Not a read-through of the same twenty rows.
- Movement — which scores changed since last time, and what caused the change.
- Additions — anything arising from new dependencies, commitments or information.
- Retirements — risks that can no longer occur. Close them here, not "later".
- Overdue mitigations — actions past their date. Work this list first; it is the one that most often goes unread.
- Realised risks — anything that became an issue, plus a note on what this register said about it in advance. Comparing the two is how the team's scoring gets better.
Health check#
| Risks scored medium | ___ of ___ |
| Risks owned by the project manager | ___ of ___ |
| Mitigations with no date | ___ |
| Mitigations overdue | ___ |
| Risks closed since last review | ___ |
If the first two are most of the register, it is being maintained rather than used.
Sign-off#
| Name | Date | |
|---|---|---|
| Project manager | ||
| Sponsor reviewed |