RAID Log vs Risk Register: What's the Difference?

A RAID log tracks four things; a risk register tracks one. Which you need, when you need both, and how they relate to the issue log and dependency tracker.

A risk register records risks only: things that have not happened and might, each with a probability, an impact and a response. A RAID log records four categories in one artefact — Risks, Assumptions, Issues and Dependencies — and is therefore a superset of the risk register.

Both are legitimate. Which one you should run depends less on preference than on how many artefacts your governance already demands, and whether anyone is going to maintain a fifth spreadsheet.

The four RAID categories

A risk register holds only the first row. Everything else lives elsewhere — usually in an issue log, an assumptions list nobody kept, and a dependency tracker.

When a risk register is the right choice

• Your organisation has a formal risk function with a prescribed register format that feeds a corporate risk report. Do not fight this; feed it.
• The project is small enough that issues are handled in the actions list and dependencies fit on one slide.
• Risk is genuinely the dominant concern — a regulatory programme, a safety-critical change.

When a RAID log is the right choice

• You want one artefact reviewed in one weekly slot. Four separate logs means three of them are always stale.
• You need to see the transition — a risk that materialises becomes an issue, and keeping both in one log preserves the history rather than losing it in a copy-paste.
• Assumptions matter. They almost always do, and they are the category most likely to be dropped entirely when there is no obvious home for them.
• Dependencies are the main threat to the date, which is true of most programmes.

Running both without duplicating work

Many programmes have to do this: corporate risk wants a register in their format, and the delivery team needs the full RAID picture.

The workable arrangement is one source and one export. Keep the RAID log as the working artefact, filter to type = Risk, and produce the corporate register from it. What does not work is maintaining both by hand — within a month they disagree, and the disagreement is discovered in a governance meeting.

Where the issue log fits

An issue log is the “I” of RAID kept separately. There is one good reason to split it out: if issues are being raised by a service desk or a test team at a volume the RAID log cannot absorb — dozens a week during UAT or hypercare, for example — they need their own tracker.

In that case the rule is to keep project-level issues in the RAID log and defect-level issues in the test or incident tracker, and to promote an issue upward only when it needs project attention. Without that rule the RAID log fills with defects and the four items that matter become invisible.

Where the dependency tracker fits

Dependencies outgrow a RAID log faster than any other category, because a dependency needs fields the other three do not: direction (inbound or outbound), the counterparty's committed date as distinct from your needed-by date, and a confidence rating. Once you have more than about fifteen live dependencies, a dedicated dependency tracker earns its place — and the RAID log then carries only the ones being escalated.

The practical answer

For most IT projects and programmes: run a RAID log as the working artefact, split out dependencies once there are enough to need their own fields, split out defects during test and hypercare phases, and export the risk view in whatever format corporate risk requires. One place where work happens, several places where it is reported.