The RAID log, done properly
A RAID log is the simplest discipline in project management and the easiest to let rot. Here's a clean structure for each register, the columns that actually earn their place, and an honest look at where the spreadsheet version stops being enough.
What a RAID log is — and what RAID stands for
A RAID log is the running record of everything a project carries that isn't on the schedule: the things that could go wrong, the things you're taking on faith, the things already going wrong, and the handoffs you depend on. The plan says what's supposed to happen. The RAID log says what's really going on around it.
The acronym has two common readings, and the ambiguity is real enough that it's worth settling for your team:
- Risks, Assumptions, Issues, Dependencies — the most widely used reading, and the one this template follows.
- Risks, Actions, Issues, Decisions — common in delivery teams that want actions and decisions in the same place.
Neither is more correct. Pick one, write the definition down, and hold everyone to it — a log that three people read three ways isn't a shared record any more.
The template
Below is a working structure for each register. Copy the columns straight into a spreadsheet and you have a RAID log you can run today. The sample rows use a fictional Mobile Banking App v3.0 project so you can see the shape of a real entry.
Risks — what could go wrong
| ID | Risk | Owner | Prob. | Impact | Score | Response | Status |
|---|---|---|---|---|---|---|---|
| R-014 | Third-party KYC vendor may not certify before the release gate | A. Okafor | Med | High | 12 | Mitigate — start certification 6 weeks early; line up fallback vendor | Open |
| R-021 | Peak-load testing slips into the freeze window | J. Reyes | Low | High | 8 | Monitor; pre-book the test environment | Open |
Score is just probability × impact on whatever scale you choose (1–5 each is common). The number matters less than using the same scale every time so risks sort honestly against each other.
Assumptions — what you're relying on
| ID | Assumption | Owner | Validated? | Validate by | Status |
|---|---|---|---|---|---|
| A-007 | Existing customer auth service can handle the new SSO flow without rework | P. Nair | No | End of discovery | Open |
| A-011 | Compliance sign-off needed only once, at the release gate | A. Okafor | Partially | Gate 2 | Open |
An assumption with no validation date is just a hope. The most useful column here is Validate by — every assumption should have a moment where it's either confirmed or it becomes a risk.
Issues — what's going wrong now
| ID | Issue | Owner | Severity | Raised | Action & target | Status |
|---|---|---|---|---|---|---|
| I-009 | Staging environment unavailable, blocking integration testing | J. Reyes | High | 12 Mar | Platform team rebuilding env — target 18 Mar | Open |
| I-012 | Two conflicting requirements for transaction limits | P. Nair | Med | 14 Mar | Decision needed from product — target 19 Mar | Open |
Dependencies — what you owe and are owed
| ID | Dependency | Direction | With | Needed by | Status |
|---|---|---|---|---|---|
| D-003 | Final fraud-rules spec from the risk team | Inbound | Fraud & Risk | Start of build | At risk |
| D-005 | API contract delivered to the partner integration team | Outbound | Partner Eng | Gate 2 | On track |
Direction is the column teams most often skip and most often regret. An inbound dependency is something you're waiting on; an outbound one is something others are waiting on from you. Both can sink a date.
How to run a RAID log so it doesn't rot
The template is the easy part. A RAID log earns its keep only if it's a living record, and most aren't. Four habits make the difference:
- One owner per item, always. "The team" owns nothing. Every row names a person.
- Review on a fixed cadence. Walk the log in your regular project review — weekly for active work. Items with no movement for two reviews are either done, dead, or being ignored.
- Close things out loud. Resolved issues and retired risks stay in the log, marked closed, with a note on how. That record is where your lessons come from later.
- Follow the migrations. Watch assumptions turn into risks and risks turn into issues. The same threat wearing three labels over its life is the single most useful pattern a RAID log can show you — if you can see the link.
Where the spreadsheet RAID log breaks down
For a small, single project, a spreadsheet RAID log is genuinely fine — don't let anyone sell you software you don't need. But on complex, long-running, or multi-project work, the same limits show up every time:
- Items don't connect. The risk that became an issue that forced a decision that changed a deliverable now lives in four rows across four tabs, with nothing linking them. The story is there; you just can't follow it.
- There's no Deliverables or Lessons. RAID stops at the four registers. The things the project actually owes, and what it learned, live in yet more documents elsewhere.
- Version sprawl. "RAID_log_v7_FINAL_JR.xlsx" in someone's inbox is not a system of record.
- No portfolio view. Running five projects means five spreadsheets and no way to see, at a glance, which one is on fire.
- It dies at handover. When the project closes or the PM changes, the reasoning evaporates. The log survives; the why doesn't.
From a RAID log to a system of record
DARIL grew out of exactly this problem on live engineering projects. It keeps the disciplines a RAID log gets right — Risks and Issues — and folds them into a fuller record that holds the parts a RAID log leaves scattered: what the project owes, the actions in motion, the decisions and the reasoning behind them, and the lessons, all in one place with the connections between them intact.
DARIL is not a scheduler. It doesn't compute critical paths, dependencies, or resource leveling, and doesn't pretend to. Build your schedule in the tool that does that best and attach it — DARIL is the record that governs the work the schedule depicts. It's a professional instrument for seasoned PMs, not a to-do app, and it asks more of you than a spreadsheet. On genuinely complex work, that's the point.
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.
RAID log FAQ
What does RAID stand for?
RAID is an acronym for the four registers a project keeps alongside its plan. The most common reading is Risks, Assumptions, Issues, Dependencies. Some teams use Risks, Actions, Issues, Decisions instead. Neither is wrong — what matters is that your team agrees on one reading and defines each term, because a log everyone interprets differently stops being a shared record.
Is a RAID log the same as a risk register?
No. A risk register is only the R — the things that could go wrong but haven't yet. A RAID log adds the assumptions you're relying on, the issues already biting you, and the dependencies you owe or are owed. The risk register is one column of a RAID log.
What's the difference between a risk and an issue?
A risk is a future possibility you can still prevent or prepare for; it has a probability. An issue is happening now and needs managing, not forecasting. The same item often migrates from risk to issue when it materialises — which is exactly why it helps to track both in one place and keep the link between them.
Should assumptions and dependencies live in the same log as risks?
Yes — that's the whole point of RAID. Keeping them separate is how a dependency quietly slips while everyone's watching the risk register. One log, reviewed on one cadence, surfaces the connections: an unvalidated assumption is usually a risk in waiting, and a late dependency is usually tomorrow's issue.
Can I keep a RAID log offline?
Absolutely, and many regulated or security-conscious teams have to. A spreadsheet on your own machine is offline by default. If you outgrow the spreadsheet, a purpose-built offline tracker keeps the same local-first ownership while adding the structure a RAID log eventually needs.