A risk register tracks risks in detail. A RAID log tracks risks alongside assumptions, issues, and dependencies at a higher level. They're not the same tool, they're not rivals, and on a larger project you'll often want both. The confusion comes from the fact that both deal with risk, so people assume one must replace the other.

Here's how they differ and how to decide which you need.

What each tool is

A risk register is a detailed, working document focused on one thing: risk. It's where the project team does the real analysis, scoring each risk for probability and impact, assigning an owner, and planning a response. It goes deep, and it's used by the people managing the project day to day.

A RAID log is broader and shallower. It covers four things (risks, assumptions, issues, and dependencies), which makes it a consolidated view of project health rather than a deep analytical tool. Because it pulls those four together, it's what sponsors and PMOs reach for when they want to understand where a project stands without wading through a full risk analysis. For what each of the four letters covers, see our guide to what RAID stands for.

The short version: the risk register goes deep on risk; the RAID log goes broad across four categories.

When to use which

A small or simple project: a RAID log on its own is often enough. It captures risks alongside the assumptions, issues, and dependencies that matter, and you don't need a separate detailed register for a handful of low-complexity risks.

A large or complex project: use both. Keep a full risk register for the detailed risk work (scoring, mitigation, ownership), and keep a RAID log for the wider governance picture, with the risk section of the RAID log summarising the register's headline items. The register is the working detail; the RAID log is the summary leadership sees.

The rule of thumb: if risk is complex enough to need real analysis, you want a register. If you also need to track assumptions, issues, and dependencies for governance, you want a RAID log on top. Most projects of any size end up with both.

How they work together

The two aren't parallel documents that duplicate each other. They connect. The risk register holds the detailed analysis of every risk. The RAID log's risk section summarises the significant ones, so a sponsor reading the RAID log sees the headline risks without the full workings, and can go to the register if they want the detail.

This is why running them as two disconnected files causes trouble: they drift, disagree, and confuse people about which is authoritative. Decide upfront that the register holds the detail and the RAID log holds the summary, keep the boundary clear, and make sure the RAID log's risk section is kept in step with the register.

What a risk register contains

If you're setting one up, a basic risk register tracks, for each risk: a unique ID, the risk description, the category, probability, impact, an overall rating, the owner, the response or mitigation plan, and the current status. Many teams add the date raised and a target resolution date. A simple probability-and-impact score (high/medium/low on each) is enough for most projects to prioritise; heavier quantitative scoring is worth it only on large, risk-intensive work.

A register lives wherever your team will keep it current, often a spreadsheet for a single project. As with a RAID log, spreadsheets stop coping once you're consolidating risk across many projects, at which point a portfolio platform that holds risk data centrally becomes worth the move.

Frequently asked questions

Is a RAID log the same as a risk register?
No. A risk register covers risk in detail. A RAID log covers risks alongside assumptions, issues, and dependencies at a higher, governance level. Larger projects often use both together.

Do I need both?
On a small project, a RAID log alone is usually enough. On a large or complex one, use both: a register for detailed risk management and a RAID log for the broader governance view.

Which comes first?
Start whichever fits the project. Many teams begin with a RAID log for overall governance and add a dedicated risk register once risk becomes complex enough to need detailed analysis.

Can a RAID log replace a risk register?
For simple projects, yes. For complex ones, no: the RAID log's risk section is a summary, not the detailed analysis a register provides.