A RAID log is a single tracker that captures four kinds of program entries: Risks (things that might go wrong), Assumptions (things you are treating as true without proof), Issues (problems happening right now), and Dependencies (things you need from someone else). Each entry has an owner, a due date, and a status, so nothing important lives only in someone's head.

What is the difference between a RAID log and a RACI matrix?

They answer different questions. A RACI matrix maps who is Responsible, Accountable, Consulted, and Informed for each task, so it is about ownership of work. A RAID log tracks risks, assumptions, issues, and dependencies, so it is about what could derail the program and what you are doing about it. Most programs run both at once.

When should you use a RAID log?

Start one at kickoff and keep it open for the life of the program. Review it at every status meeting. It is most valuable on cross-functional work where dependencies and assumptions pile up faster than any single person can hold in memory. The moment you hear yourself say I assumed someone had that, you needed a RAID log.

What goes in each RAID category?

Risk: something that has not happened yet but could hurt the program, so you plan a mitigation. Assumption: something you are taking as true to move forward, which becomes a risk if it turns out false. Issue: a problem that is already real and needs action now. Dependency: an input, decision, or deliverable you need from another team to keep moving.

RAID Log

Track Risks, Assumptions, Issues, and Dependencies in one place. Tag each entry by type, assign an owner and a due date, and set a status. Everything saves in your browser. No signup.

Type	Description	Owner	Due	Status

Risk might go wrong Assumption taken as true Issue already real Dependency needed from others

How to use a RAID log

A RAID log is the running memory of a program. It holds the four things that derail work but rarely fit anywhere else: the risks you are watching, the assumptions you are betting on, the issues already in front of you, and the dependencies you owe or are owed. One tracker, one owner per line, one status you can scan.

The value is in the discipline of writing things down before they bite. An assumption named out loud becomes a risk you can test. A dependency logged with a due date becomes a conversation you can have early instead of a surprise at launch. Review the log at every status meeting, close what no longer applies, and add new entries the moment they surface.

Common mistakes to avoid

Logging risks but never assumptions. The assumptions are the ones that quietly turn into the issues that sink a program.
No owner on a line. An entry owned by everyone is owned by no one. Name one person per row.
Letting dependencies sit without a date. A dependency without a due date is a wish, not a commitment.
Treating it as a setup artifact. A RAID log built once and forgotten is worse than none, because it looks like control without being it.

For more on running programs across many teams, see the Insights notes on dependency management, decision logs, and escalation paths.

Built by Arsenii Samoilov, a Senior Technical Program Manager with 19+ years at Intuit, Atlassian, Adobe, Salesforce, Roku, and Apple. If your team needs help standing up program governance, get in touch.

Read the Insights →