What a RAID log is, and how to keep one that gets used
What each letter in RAID means, how risks differ from issues, how to score a risk, and why most RAID logs quietly stop being maintained.
A RAID log is the single register where a delivery team tracks the things that could go wrong, the things that already have, the things being taken on trust, and the things being waited on. It is one of the most useful artefacts in delivery and one of the most reliably abandoned.
The four letters
- Risks are things that might happen. They have a probability and an impact, and they get mitigation actions.
- Assumptions are things being treated as true without proof. They are dangerous precisely because nobody is watching them.
- Issues are things that have already happened. They have an owner and a resolution, not a probability.
- Dependencies are things you need from someone outside your control, with a date attached.
Some teams read the D as Decisions and track dependencies separately. Either convention works. What does not work is having nowhere to record decisions at all, because six months later nobody remembers why the integration approach changed.
Risks and issues are not the same thing
This is the distinction people get wrong most often, and it matters because the two need different handling.
A risk has not happened. It is managed with probability, impact, and mitigation: reduce the likelihood, reduce the damage, or accept it deliberately.
An issue has happened. Probability is now 100% and irrelevant. It needs an owner, a resolution, and a date.
When a risk materialises it should be closed as a risk and opened as an issue, with the link preserved. A register where realised risks quietly stay open as risks is a register that has stopped describing reality.
Scoring a risk
The standard approach scores probability and impact from 1 to 5 and multiplies them, giving a score from 1 to 25 that sorts the register.
| Score | Band | Typical response |
|---|---|---|
| 15–25 | High | Escalate, mitigate actively, review weekly |
| 8–14 | Medium | Mitigation owner named, review fortnightly |
| 1–7 | Low | Accept and monitor, review monthly |
A heat map of the same data (probability on one axis, impact on the other) is worth more than the table in a governance meeting, because it makes the top-right corner impossible to look away from.
The scores are relative, not absolute. Their job is to rank the register so attention goes to the right rows, not to produce a number anyone should believe to two decimal places.
Why most RAID logs die
Almost always the same three reasons, and all three are structural rather than about discipline.
- Nothing has an owner, so nothing gets updated, so the register is stale, so nobody reads it, so nothing gets updated.
- It lives apart from the plan. A risk in a separate spreadsheet, unconnected to the tasks it threatens, cannot show you that it sits on your critical path.
- It is only reviewed at a monthly governance meeting, which makes it a reporting artefact rather than a working one.
The fixes follow directly: every row gets a named person and a review date, the register lives next to the plan and links to the tasks involved, and it is reviewed in the weekly delivery meeting rather than saved up for governance.
Link risks to tasks
The single change that makes a register useful is connecting each risk to the work it threatens.
Once a risk names its tasks, questions that were previously guesswork become answerable: which of our high-scoring risks sit on the critical path, what is the cost exposure of the delayed workstream, and which risks became more likely when that dependency slipped. A register that cannot answer those is a list, not a control.
How this works in Depentra
Depentra's RAID register holds risks, issues, assumptions, dependencies, decisions, and actions in one place, with probability and impact scoring, a heat map, cost impact, due dates, and links from a risk to the tasks it threatens.