RAID Log
A RAID log is a single register that records risks, assumptions, issues and dependencies for a project or programme. Each entry carries an owner, a date raised, a status and an action. It is maintained continuously through delivery and reviewed at the governance meeting where entries are escalated, updated or closed.
RAID is an acronym for the four categories the log holds: Risks, Assumptions, Issues and Dependencies. The point of putting them in one place is that they are managed by the same people in the same meeting, and an entry frequently moves between categories. An assumption that turns out to be wrong becomes an issue. A dependency nobody has confirmed becomes a risk.
What it contains
A RAID log is a table. The columns vary between organisations, but the working set is small.
| Column | What it records |
|---|---|
| ID | A stable reference so an entry can be cited in a status report or a meeting without quoting the whole description |
| Type | Risk, assumption, issue or dependency |
| Description | What the entry is, written so someone outside the team can read it a month later |
| Date raised | When it entered the log, and by whom |
| Owner | The named person accountable for the entry, not the team |
| Probability and impact | Used for risks; issues normally carry a severity instead |
| Score or RAG | Derived from probability and impact, used for sorting and for the heatmap |
| Response or action | What is being done, in a form specific enough to be finished |
| Due date | When the action is expected to be complete |
| Status | Open, in progress, closed, escalated |
| Last updated | The column that shows which entries have gone stale |
Some logs add a category or workstream field, a link to a change request, and an escalation level. The RAID Log Template (Excel) uses this column set with scoring and a dashboard on top of it.
How it is used
The log has two audiences. Inside the team it is a working list: the entries with actions due this week, sorted by owner. Outside the team it is the source for the governance section of the weekly report and the steering committee pack — normally the top few risks by score, all open issues above a severity threshold, and anything being escalated.
The rhythm most delivery teams settle on is a short weekly review where each open entry is either updated or closed, and new entries are added from whatever happened that week. Entries that require a decision above the project manager go up with a named decision and a date by which it is needed. The guide to RAID log columns covers which fields survive that cycle and which ones are filled in once and never touched again.
Where it goes wrong
The common failure is not the format. It is that the log becomes an archive. Entries accumulate, nothing is closed, and the score column stops meaning anything because everything has been marked high since March. A log with 140 open entries and no last-updated column is not being used to manage anything.
The second failure is ownership at team level. An entry owned by "Infrastructure" is owned by nobody, and nobody chases it. The third is the assumption section, which in most logs is empty — assumptions are made verbally in the first weeks of the project and never written down, so when one proves false there is no record that anyone relied on it.
The fourth is duplication. If the same risk exists in the project RAID log, the programme risk register and the vendor status report with three different scores, the governance discussion becomes an argument about which number is right rather than what to do.
Related terms
See also risk register, issue log and assumption log.
Questions
What does RAID stand for?
Risks, assumptions, issues and dependencies. The four categories are kept in one register because the same people manage them in the same meeting.
Is a RAID log the same as a risk register?
No. A risk register covers risks only. A RAID log covers risks plus assumptions, issues and dependencies, so it is broader and usually less detailed per risk.
Who owns the RAID log?
The project or programme manager normally maintains it, but each entry has its own named owner who is accountable for the action against it.
How often should a RAID log be reviewed?
Most delivery teams review it weekly, in the same meeting that produces the status report, so the reporting and the log do not drift apart.