Risk Register
A risk register is the log of things that might happen and have not happened yet. Each entry records a description, a probability and impact assessment, a response strategy, a named owner and a review date. It is distinct from an issue log, which records events that have already occurred and are affecting delivery now.
The distinction that defines a risk register is tense. A risk is future and conditional; an issue is present and factual. The moment a risk materialises it stops being a risk and moves to the issue log, usually keeping a reference back to the risk entry so the register shows which risks were realised.
What it contains
| Field | What it records |
|---|---|
| Risk ID | Stable reference used in reports and escalations |
| Risk description | Written as cause, event and effect, so the entry says what would trigger it and what the consequence would be |
| Category | Technical, resource, vendor, commercial, regulatory, data, and so on |
| Probability | Likelihood on the organisation's scale, commonly one to five |
| Impact | Severity of the effect on cost, schedule, scope or quality |
| Score | Probability multiplied by impact, used for ranking and for the heatmap |
| Proximity | When the risk could occur, which is not the same as how large it is |
| Response strategy | Avoid, reduce, transfer or accept |
| Mitigating actions | The specific things being done, each with an owner and a date |
| Risk owner | The person accountable for the risk, often senior to the action owner |
| Residual score | The assessment after mitigation, which is what the register is really reporting |
| Status | Open, mitigated, closed, or realised with a link to the issue |
Registers used for reporting also carry a trend indicator — whether the residual score has moved since the last review — because a static register tells a governance forum nothing about whether the mitigation is working.
How it is used
Two things happen with a risk register. The first is the working review, where owners update their entries and new risks are added. The second is the reporting extract: the top risks by residual score, plotted on a probability and impact grid, taken into the steering committee. The Risk Register Template (PowerPoint) exists for that second use, where the register has to be readable on a slide rather than in a spreadsheet.
Escalation is the register's other function. A risk whose mitigation needs money, a decision or a resource the project cannot obtain is escalated with a specific ask. Without that, the register is a list of things the team is worried about, which is not the same as a governance instrument.
Where it goes wrong
Scoring inflation is the usual problem. Everything is scored high, either because scoring low feels like tempting fate or because a high score is the only way to get attention. Once the top of the register is crowded, ranking stops working and the governance forum picks by instinct.
Vague descriptions are the second. "Resource risk" is not a risk. "If the two integration developers are pulled to the billing programme in Q3, interface build slips past the test window" is one, and it can be mitigated. The third is registers that record mitigation as intent rather than action — "monitor closely" is not a mitigation and nobody can complete it.
The fourth is scope confusion with the RAID log. Running both, with the same risks in each, doubles the maintenance and guarantees they disagree. The comparison of RAID logs and risk registers sets out when each is worth keeping separately.
Related terms
See also RAID log, issue log and assumption log.
Questions
What is the difference between a risk and an issue?
A risk has not happened yet and may not; an issue has happened and is affecting the project now. When a risk materialises it moves to the issue log.
What is residual risk?
The probability and impact assessment after the planned mitigations are in place. Reporting normally uses residual scores rather than the original untreated ones.
Who should own a risk?
A named individual with the authority to act on it. Risk owners are often more senior than the person carrying out the mitigating action, who is tracked separately.
Does every project need a separate risk register?
Not necessarily. Smaller projects often keep risks inside a RAID log; a standalone register is more common where risk reporting is a formal governance requirement.