The RAID Log Explained: Risks, Assumptions, Issues and Dependencies
Four registers, four different questions, four different owners. Most RAID logs fail because they answer all four with the same list.
A RAID log is one of the few governance artefacts that repays its cost within a fortnight, and one of the most consistently misused. The failure is usually the same: a single spreadsheet with a type column, where everything is either a risk or an issue, assumptions are never recorded at all, and dependencies appear only after one has been missed.
The four are genuinely different. Keeping them separate is not bureaucratic tidiness; it is what makes each of them actionable, because the action that follows differs in every case.
What each one actually is
- A risk has not happened. It has a probability, an impact, and a response chosen from a short list: avoid it, reduce it, transfer it, or accept it deliberately. The output of a risk entry is a mitigation with an owner and a date.
- An issue has happened. Probability is no longer relevant. The output is a resolution plan and, usually, an escalation, because an issue that could be resolved by the team without help would already have been.
- An assumption is something believed to be true that has not been verified, and on which the plan depends. The output is a validation action with a date by which the belief will be confirmed or the plan will change.
- A dependency is something the engagement needs from outside its own control: a decision, a system access, a data extract, another party's deliverable. The output is a named counterpart and a date, and it belongs in the client's view rather than only in yours.
Scoring risks without pretending to precision
The standard probability by impact grid produces a number that looks like measurement and usually is not. Its value is not the arithmetic but the conversation it forces, so keep the scale coarse. Three levels on each axis is enough for almost every engagement, and five is enough for the largest.
Two disciplines make the scoring useful. First, express impact in the units the client cares about, which is generally cost, time or reputation rather than an abstract severity. Second, record the residual position as well as the inherent one: what the exposure will be once the mitigation is in place. A register that only shows inherent risk cannot tell anyone whether the mitigations are working.
The assumption register, which is the one that gets skipped
Of the four, assumptions are the least kept and the most valuable commercially. An assumption is the documented form of the thing that will later be argued about: how many entities were in scope, whether the data was expected in a particular format, how many interviews the estimate covered, how responsive the client's team was expected to be.
Every assumption should have an expiry: a date by which it will be tested. An assumption that is still unvalidated a month after that date is not an assumption any more, it is a risk, and it should be moved. This single rule does more to prevent late surprises than any amount of risk scoring.
Making the log change decisions
A register only earns its place if something depends on it. Three connections do most of the work. The status report draws its watch list from the top few risks by residual exposure, so the register is read every week. The governance meeting works the escalations and the overdue mitigations rather than reviewing every line, so attention lands where it matters. And an assumption that fails triggers a change conversation, which is the moment the register pays for itself commercially.
The counter-practice to avoid is the full review. Reading forty risks aloud in a steering meeting guarantees that nobody reads any of them, and it is how a register becomes a ritual.
Closing entries, and why it matters
Entries should be closed with a reason and a date: the risk did not materialise, the mitigation removed it, the issue was resolved, the assumption was confirmed. A register that only grows becomes unreadable within three months, and an unreadable register is the same as no register.
Closed entries also carry the firm's memory. The most useful input to the risk register of the next engagement of the same type is the closed register of the last one, which is a strong argument for keeping these records against a template rather than in a document that ends its life in an archive folder.