RAID Log vs Risk Register: When to Use Which

This is the most common question I get from PMs who are setting up program governance for the first time: "Do I need a RAID log or a risk register? Aren't they the same thing?"

Short answer: most enterprise programs need both. They look similar, they overlap heavily on risks, and you can muddle through with just one. But they serve different cadences, different audiences, and different jobs. Conflating them is how teams end up with one bloated artifact that nobody reviews and a steering committee that has no governance instrument.

Here's how I think about the split, and how to decide what your program actually needs.

The short version

• A RAID log is a working document. Weekly, owned by the program team, simple scoring, action-oriented. The artifact you open on Tuesday afternoon when something's wrong.
• A risk register is a governance document. Quarterly, owned by the steering committee or program board, deeper scoring, audit-ready. The artifact you open before a board review.

If you only have one, you're either flying blind on weekly operations (no RAID) or skipping governance rigor (no register). Most teams need both. They feed each other.

What a RAID log is for

RAID stands for Risks, Assumptions, Issues, Dependencies. The acronym is unimportant. What matters is the cadence: weekly review, named owners, simple scoring, fast updates, integrated into your status report.

The RAID log lives in a single spreadsheet (or web app, or Notion page) that the whole program team can see. It's structured around action, not analysis. When a risk shows up, you log it, score it 1-5 on probability and impact, name an owner, set a review date. When that risk materializes, you promote it to an issue. When the issue resolves, you close it.

It's the operating system for how the program is run between governance meetings. If your RAID log is alive, your weekly status reports practically write themselves: the top 3 risks, the top issues, the dependency that just slipped, the assumption that just turned out to be wrong. All right there.

Who reviews a RAID log

The program team. Workstream leads. Sometimes the program manager runs it solo. The 15-minute weekly review I keep talking about is a working session, not a presentation. People come to update, not to be informed.

I've never run a RAID log as an executive-facing artifact. Once you start formatting it for leadership, it stops being a working tool and starts being a status update. Different artifact. Different cadence.

What a risk register is for

A risk register serves a different job: defensible, deeply scored, governance-grade documentation of the risks that could derail the program at the strategic level. It's the artifact you reference in a steering committee, hand to an auditor, or share with legal when there's a regulatory dimension.

Where the RAID log uses simple 1-5 scoring, the register typically uses:

• Probability and impact, scored on anchored rubrics (not vibes)
• Inherent risk (before mitigation) and residual risk (after mitigation)
• Mitigation cost and effectiveness
• Risk owner at the program-leader level (not workstream level)
• Acceptance criteria for which risks the program is willing to carry
• Quarterly review history that shows the register has been actively maintained

The register isn't where you log every dependency slip. It's where the top 10-15 strategic risks live with deep documentation. It's the artifact the CFO, CRO, or external auditor expects to see when they ask "how is your program managing risk?"

Who reviews a risk register

The steering committee, program board, or the equivalent governance forum. Reviewed quarterly at minimum. The audience expects depth, not breadth: 10-15 well-documented risks, not 50 thinly logged ones.

The honest comparison table

How they feed each other

The two artifacts aren't independent. They feed each other in a specific direction.

RAID log feeds the risk register. The strategic risks that surface in the weekly RAID review get promoted up. Not every RAID risk goes to the register. The ones that warrant board-level visibility do. This is the move most teams skip: they treat the RAID log as the only place risks live, and then nothing makes it to governance.

Risk register feeds the RAID log. When the steering committee makes a decision about a registered risk (accept it, mitigate it, escalate it), that decision becomes an action in the RAID log. The register is where the strategy lives; the RAID log is where the strategy executes.

If you only have one, half this loop is missing.

When you can get away with just one

Some programs really only need a RAID log:

• Internal product or feature programs with no regulatory or financial governance requirement. The steering committee is your director and a peer. A simple RAID log is enough.
• Programs under 6 months where quarterly governance doesn't fit the timeline. Run the RAID log weekly; do a single closeout risk summary instead of an ongoing register.
• Small programs (under 5 workstreams) where the RAID log itself is small enough to serve double duty. The top 5-10 risks in the RAID log can be your governance view.

And some programs really need both:

• Regulated industries. Financial services, healthcare, aerospace, anything with external audit. The risk register is non-negotiable governance documentation.
• Multi-year programs. The strategic risks shift over time, and the register is where you track that drift. The weekly RAID log won't show you that pattern.
• Programs with a formal steering committee or program board. They expect a register. They will not accept a RAID log dressed up.
• Programs with significant financial exposure. $10M+ budgets, contractual penalty clauses, or revenue-at-risk dependencies. The register's depth is what defends the program in a board review.

The most common failure mode

The pattern I see most often is the same artifact pretending to be both.

It looks like a RAID log: spreadsheet, simple scoring, weekly review. But the team is also using it for steering committee reviews because nobody built a separate register. So the artifact accretes columns: inherent risk, residual risk, mitigation cost, control owner, regulatory citation. By month four it has 24 columns and 80 rows, and nobody reviews it weekly anymore because the format is too heavy. By month seven it's stale, and there's no governance artifact either.

The fix is not to merge them better. The fix is to acknowledge they're different jobs and build two artifacts. The RAID log stays light, weekly, action-focused. The register sits separately, gets the deep treatment, gets reviewed quarterly. They cross-reference each other but don't try to be each other.

Practical setup for a new program

If you're standing up a new program and trying to decide what to build, here's the order I run:

1. Week 1: stand up the RAID log. Spreadsheet, four sections, named owners. Run the first weekly review by the end of week 2. Don't worry about a register yet.
2. Week 4: assess governance need. Do you have a steering committee or program board? Quarterly governance forum? Audit or regulatory exposure? If yes, you need a register. If no, the RAID log alone may suffice.
3. Week 6-8: stand up the risk register. Take your top 10-15 risks from the RAID log and document them deeply. This becomes your first quarterly review artifact.
4. Ongoing: run the cycle. Weekly RAID review. Quarterly register review. Promote risks up, push decisions down.

The first quarterly register review is uncomfortable. You'll have gaps. The mitigation costs will be guesses. The residual risk math will feel arbitrary. That's normal. By the second review, the gaps fill in. By the fourth, the register is genuinely useful.

The bottom line

RAID log: weekly working tool. Risk register: quarterly governance artifact. Most enterprise programs need both. They're not competing tools, they're different cadences serving different audiences, and they feed each other when you set them up that way.

If you're forced to start with one, start with the RAID log. The discipline of weekly review is the most important habit for a program manager to build, and the RAID log is the artifact that institutionalizes it. The register can come later as governance demand emerges. The opposite path (register first, RAID log later) almost never works because the register without weekly working rhythms goes stale fast.