RAID Log: What Goes In It and Which Columns Actually Get Used

What belongs in a RAID log — risks, assumptions, issues and dependencies — the columns worth having, and why most RAID logs are abandoned by week six.

A RAID log is a single project management document used to track Risks, Assumptions, Issues and Dependencies across the life of a project or programme. Each entry carries an owner, a status and a date, and the log is reviewed on a fixed weekly rhythm so that entries which have gone stale are visible.

RAID stands for Risks, Assumptions, Issues and Dependencies. The log is one of the few project artefacts that survives across every methodology, which is why it is also one of the most copied and least maintained.

Most RAID logs die around week six. Not because the format is wrong, but because they were built with thirty columns and nobody wants to fill in thirty columns during a status meeting.

The four categories, briefly

Risk — something that has not happened and might. Has a probability and an impact. Managed by mitigating or accepting it.

Issue — something that has already happened and is hurting you now. Has an owner and a resolution date. A risk that materialises becomes an issue; the log should let you show that transition rather than losing the history.

Assumption — something you have decided to treat as true without proof, because waiting for proof would stop the project. Has a validation date. Unvalidated assumptions are where projects quietly go wrong.

Dependency — something you need from someone outside your control, or something they need from you. Has a needed-by date and a named counterparty.

The columns worth having

Per entry, across all four types:

• ID — a stable reference you can quote in a steering committee ("we discussed R-014")
• Type — R / A / I / D, so one sheet serves all four
• Description — written as a full sentence including the consequence, not a two-word label
• Raised by / Date raised
• Owner — one named person, never a team
• Probability and Impact — for risks; a simple High/Medium/Low each is enough
• Score — derived from the two above, used only for sorting
• Response — avoid / reduce / transfer / accept, and what is actually being done
• Due date — the date the next action is expected, not the date the risk expires
• Status — Open / In progress / Closed
• Last updated — the single most useful column, because it tells you which entries have gone stale

That is eleven columns. Anything beyond this tends to be filled in once and never again.

Why RAID logs get abandoned

No named owner. Entries assigned to "IT" or "the vendor" are assigned to nobody.

No review rhythm. A RAID log is a meeting artefact. If it is not opened during a fixed weekly slot, it is not maintained. Ten minutes reviewing only the entries due in the next two weeks is enough.

Everything is a risk. Teams log fifty risks, half of which are really issues or general anxieties, and then cannot find the four that matter. If an entry has no plausible action attached to it, it does not belong in the log.

Closed items get deleted. Keep them, marked closed. The history is what protects you when someone asks in month nine why a decision was made.

Descriptions are too short. "Vendor delay" tells a reader nothing in three months. "Vendor has not confirmed the interface spec, which blocks build start and puts the September release date at risk" tells them everything.

A practical starting point

One spreadsheet, one tab for the log itself, filters on Type / Owner / Status, and a small summary view showing open items by owner and anything overdue. Add a separate tab holding the dropdown lists so the columns stay consistent — inconsistent status values are what make filtering useless later.

Build it once, reuse it on every project. The format does not need to change.