Glossary
Risk Register
A structured log of identified project risks, recording what could go wrong, how likely it is, what the impact would be, and what is being done about it.
A risk register is the central document for managing project risk. At its simplest it is a table: each row is a risk, and the columns record the risk description, the cause, the potential impact (on cost, time, or quality), the probability of occurrence, the severity of impact, and the current mitigation actions and owners. Most registers also include a risk score — probability multiplied by impact — and a residual risk score after mitigations are applied. On projects using quantitative risk analysis, each risk entry will also have quantified cost and schedule impact ranges that feed into the Monte Carlo model.
A risk register is a live document, not a one-off deliverable. It should be reviewed regularly — typically at every project board or risk workshop — and updated as risks are realised, mitigated, or new ones emerge. It is the mechanism by which the project team demonstrates that risk is being actively managed rather than just identified and filed. A risk register that has not been updated in months is a governance failure, regardless of how good the original entries were.
The most common problems with risk registers are vagueness and completeness bias. Vague risks — 'design may be delayed', 'stakeholder issues' — cannot be properly assessed or mitigated, because nobody knows exactly what the risk is or who owns it. Force each risk to be written as a cause-risk-effect statement: 'because X, Y might happen, resulting in Z.' Completeness bias means the register typically captures the obvious risks but misses the less obvious ones that cause the biggest problems. Use structured techniques — prompt lists, risk workshops with diverse participants, lessons learned from previous projects — to surface risks that a single planner sitting at a desk would miss.
Frequently asked
- What should a risk register include?
- A risk register should capture, for each risk: a unique identifier; a clear description of the risk event (cause → event → effect); probability of occurrence; impact on cost, schedule, and scope; a risk score; the risk owner; current mitigation actions; and the residual (post-mitigation) probability and impact. For a register that feeds into quantitative risk analysis, it also needs three-point estimates of cost and schedule impact (minimum, most likely, maximum) rather than single-point scores.
- What is the difference between a risk register and a risk log?
- The terms are used interchangeably in most organisations, but in formal project controls a risk log typically refers to a simple list of identified risks without the full scoring and management data that a risk register contains. A risk register is the live management document — it is reviewed regularly, risks are updated as their status changes, and it drives mitigation actions. A log is more of an audit trail. In practice, if it is used to manage risks, it is a risk register regardless of what it is called.
- How often should a risk register be updated?
- On active projects, the risk register should be formally reviewed at least monthly — more frequently during high-risk phases such as procurement, mobilisation, or transition. Between formal reviews, risk owners should update their risks as new information becomes available. The register should be reviewed and baselined ahead of any stage gate, funding submission, or quantitative risk analysis, since a stale register will produce misleading QRA results.
- What makes a risk register 'QRA-ready'?
- A QRA-ready risk register has: a clear event description for each risk (not vague labels like 'design risk'); probability of occurrence as a single percentage or range; cost impact as a three-point estimate (minimum, most likely, maximum) in £; schedule impact as a three-point estimate in days or weeks; an identified risk owner; and no double-counting of risks already included in the base cost estimate. Risks priced into the base estimate should be removed from the register before the QRA, or the analysis will overstate contingency.
Related terms
Putting these techniques into practice?
SOMA provides independent project controls consultancy for UK programmes. We can help you apply QRA, EVM, schedule risk analysis, and more.