Risk register vs RAID log: what's the difference?
They overlap, so the terms get used interchangeably — but they're not the same tool. One tracks a single thing in depth; the other tracks four things at a glance. Here's where each fits, with a working risk register you can download.
The short answer
A risk register tracks one thing — risks — in depth. A RAID log tracks four registers side by side: Risks, Assumptions, Issues, and Dependencies (some teams read the D as Decisions). The risk register is the R of RAID. The difference is depth versus breadth: a risk register goes deeper on a single discipline, while a RAID log keeps four disciplines visible in one place so the connections between them don't get lost.
Put plainly: every RAID log contains a risk register, but a risk register is not a RAID log. Which one you reach for depends on whether risk is the thing you most need to manage closely, or just one of several.
A risk register: one discipline, in depth
A risk register is the running record of things that might go wrong but haven't yet. What makes a register more than a list is that it scores and tracks each risk over its life. A good one rates the likelihood and impact of each risk, combines them into a severity, names an owner, records the mitigating action, and — the part most spreadsheets skip — rates the risk again after mitigation to show the residual exposure.
That last step is the whole point. A mitigation you never re-score is a mitigation you're taking on faith. Here's the shape of a register that captures it, using a fictional Mobile Banking App v3.0 project:
| ID | Risk | Owner | Likelihood | Impact | Severity | Mitigating action | Residual |
|---|---|---|---|---|---|---|---|
| R-014 | KYC vendor may not certify before the release gate | A. Okafor | Med | High | High | Start certification 6 weeks early; line up a fallback vendor | Medium |
| R-038 | Core-banking API rate limits throttle launch-day traffic | J. Reyes | High | High | High | Negotiate a higher quota; add client-side backoff and caching | High |
| R-027 | New biometric login fails the accessibility review | P. Andersson | Med | Med | Medium | Run an accessibility audit in beta; keep the PIN fallback | Low |
Notice R-038: the residual stays High even after mitigation. That's not a failure of the register — it's the register doing its job, telling you a risk is still live and needs a contingency, not just a hopeful action.
How severity is scored
Severity isn't a separate guess — it falls out of likelihood and impact. The cleanest approach is a 3×3 matrix: rate each on Low / Med / High, and read the severity off the grid. Using the same grid every time is what lets risks sort honestly against each other.
| Likelihood ↓ / Impact → | Low | Med | High |
|---|---|---|---|
| High | Medium | High | High |
| Med | Low | Medium | High |
| Low | Low | Low | Medium |
A RAID log: four registers, one view
A RAID log widens the lens. Instead of risks alone, it keeps four columns of project reality side by side:
- Risks — what might go wrong (the risk register lives here).
- Assumptions — what you're taking on faith until proven.
- Issues — what's already going wrong and needs managing now.
- Dependencies — the handoffs you owe or are owed.
The value of a RAID log is exactly the thing a standalone risk register can't show you: the migrations between registers. An unvalidated assumption is usually a risk in waiting; a risk that materialises becomes an issue; a late dependency becomes tomorrow's issue. Seeing all four on one cadence surfaces those links. If you want the full structure, see the RAID log template.
Side by side
| Risk register | RAID log | |
|---|---|---|
| Scope | One discipline: risks | Four: risks, assumptions, issues, dependencies |
| Depth per item | High — scoring, owner, mitigation, residual | Lower — a row per item across four registers |
| Best at | Managing risk closely over its whole life | Keeping the wider picture visible at a glance |
| Blind spot | Everything that isn't a risk | Depth — the risk column is often just a list |
| Reach for it when | Risk is your biggest exposure | You need breadth across the whole project |
So which should you use?
It isn't really either/or, and it isn't necessarily two files. Three honest cases:
- Risk is your dominant exposure — regulated delivery, safety-critical work, anything where a single risk can sink the project. A dedicated register, scored and re-scored, earns its place.
- You need the wider picture — most projects, most of the time. A RAID log keeps risks next to the assumptions, issues, and dependencies they interact with.
- You're outgrowing both spreadsheets — when items stop connecting, versions multiply, and the reasoning evaporates at handover, the answer isn't a third spreadsheet. It's a record that holds the depth of a risk register and the breadth of a RAID log in one place.
Where DARIL fits
DARIL grew out of running exactly this trade-off on live engineering projects. It keeps a full risk register — likelihood × impact, owner, mitigating action, and the pre- and post-mitigation severity shown above — and folds it into a record that also holds what the project owes, the actions in motion, the decisions and their reasoning, and the lessons. The depth and the breadth, with the connections between them kept intact.
DARIL's risk register is qualitative — likelihood, impact, and a severity you can read at a glance. It is not a quantitative risk-analysis workbench: no Monte Carlo, no probabilistic cost or schedule modelling. And it's not a scheduler — bring your own Gantt and attach it. DARIL is the record that governs the work, built for seasoned PMs on genuinely complex projects.
See whether DARIL fits the way you actually work
One offline file. No install, no account, no cloud. Try it on a real project, or read how the method holds a project together.
Risk register vs RAID log FAQ
What's the difference between a risk register and a RAID log?
A risk register tracks one thing — risks — in depth, scoring each by likelihood and impact and tracking it to a residual rating after mitigation. A RAID log tracks four registers at once: Risks, Assumptions, Issues, and Dependencies (some teams read the D as Decisions). The risk register is the R of RAID, usually kept in more detail than a single RAID column allows.
Is a risk register part of a RAID log?
Conceptually, yes — it's the R. But a standalone risk register normally goes deeper than the risk column of a RAID log: it adds a likelihood × impact severity, a named owner, the mitigating action, and a post-mitigation (residual) rating. A RAID log trades that depth for breadth across all four registers.
What columns should a risk register have?
At minimum: an ID, the date raised, a description, likelihood and impact, a severity derived from the two, an owner, and the mitigating action. A strong register adds a post-mitigation likelihood, impact, and severity so you can see the residual risk once your action is in place.
What is residual risk?
Residual risk is what remains after your mitigating action is working. You re-rate likelihood and impact post-mitigation to check whether the action actually reduced the exposure. If the residual severity is still high, the risk needs a contingency plan, not just a hopeful action.
Do I need both a risk register and a RAID log?
Not necessarily as two separate files. If risk is your biggest exposure, a dedicated register is worth keeping. If you need the wider picture, a RAID log holds risks alongside assumptions, issues, and dependencies. When you outgrow both, a purpose-built offline record can hold the depth of a register and the breadth of a RAID log together.