# Risk Register

> 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.

1. **Movement** — which scores changed since last time, and what caused the change.
2. **Additions** — anything arising from new dependencies, commitments or information.
3. **Retirements** — risks that can no longer occur. Close them here, not "later".
4. **Overdue mitigations** — actions past their date. Work this list first; it is the one that
   most often goes unread.
5. **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 | | |