RAID log template
A RAID log is one list of everything that could stop delivery: risks, assumptions, issues and dependencies. Kept up to date, it's the fastest way to see what needs attention this week.
Updated
The short answer
A RAID log tracks Risks, Assumptions, Issues and Dependencies for a project or product in one table. Each entry has a type, an owner, an impact rating, a status and a next action. Review it weekly and close items as soon as they're resolved.
Pastes with formatting into Google Docs, Word, Notion and Confluence.
RAID log: [product or project]
Last reviewed: [date] | Owner: [name]
| ID | Type (R/A/I/D) | Description | Owner | Impact (H/M/L) | Likelihood (H/M/L) | Status | Next action | Due |
|---|---|---|---|---|---|---|---|---|
| R-01 | Risk | Open | ||||||
| A-01 | Assumption | To validate | ||||||
| I-01 | Issue | Open | ||||||
| D-01 | Dependency | Waiting |
Example: fictional Meridian Labs data
RAID log: Pulse Analytics
Last reviewed: 26 Sep 2026 | Owner: Avery Nolan
| ID | Type (R/A/I/D) | Description | Owner | Impact (H/M/L) | Likelihood (H/M/L) | Status | Next action | Due |
|---|---|---|---|---|---|---|---|---|
| R-01 | Risk | Metric ownership unclear: dashboards may ship with disputed numbers | Avery Nolan | H | H | Open | Agree owners for the top 20 metrics | 3 Oct |
| A-01 | Assumption | Teams will build their own dashboards if templates exist | Noor Haddad | H | M | To validate | Test the first templates with customer team leads | 10 Oct |
| I-01 | Issue | Streaming aggregation is behind (55%) and putting Self-serve dashboards at risk | Mila Karlsen | H | - | Open | Add a second engineer for two sprints | 7 Oct |
| D-01 | Dependency | Dashboard builder -> Event schema contract from the data platform team | Avery Nolan | H | - | Overdue 4 days | Escalate at Thursday's PI sync | 22 Sep |
New to RAID logs? Start here
What it is
A RAID log is one running list of everything that could stop delivery: Risks, Assumptions, Issues and Dependencies. It's reviewed every week so nothing surprises the team.
Use it when
- Several teams or suppliers are involved
- Work depends on things outside your control
- You run weekly delivery or PI reviews
Who writes it
The product manager, delivery lead or release train engineer
Who reads it
Team leads, stakeholders and anyone who owns an item
What goes in each type
- 1Risk: something that might happen and would hurt delivery. Example: metric ownership is unclear, so the dashboard may ship with disputed numbers.
- 2Assumption: something you're treating as true without proof. Example: teams will build their own dashboards if templates exist.
- 3Issue: a risk that has already happened. Example: duplicate events on consumer restart are corrupting counts.
- 4Dependency: work you need from another team before you can finish. Example: the event schema contract from the data platform team.
Some teams use A for Actions and D for Decisions instead. Pick one meaning and write it at the top of the log.
How to run it
Review the log in the same meeting every week. Sort by impact, then due date. Every open item needs an owner and a next action with a date. Promote assumptions to issues or close them as soon as you learn the answer.
Why RAID logs get ignored
A RAID log in a spreadsheet is separate from the work, so it goes stale and people stop opening it. In Ondule, risks, issues and dependencies are records on the product itself. Overdue dependencies and at-risk milestones surface automatically in a Needs attention list.
Questions
- What does RAID stand for?
- Risks, Assumptions, Issues and Dependencies. Some teams use Actions and Decisions for A and D.
- What is the difference between a risk and an issue?
- A risk might happen. An issue already has. When a risk happens, move it to issues.
- How often should a RAID log be updated?
- Review it weekly, and update individual entries as soon as anything changes.