The complete guide to RAID reporting (with examples)
A RAID report is the single most-read artefact in most project reviews — and the one project managers spend the most time re-formatting the night before a steering committee. This guide covers what a RAID log is, how to structure a RAID report that executives actually read, the mistakes that make RAID reporting fall over at scale, and how to automate the whole thing with Pocket PMO's Snapshot feature.
Table of Contents
- What is a RAID log?
- RAID report vs. RAID log: what's the difference?
- The anatomy of a board-ready RAID report
- RAID reporting best practices
- Common RAID reporting mistakes
- Automating RAID reports with Pocket PMO Snapshot
- Frequently asked questions
Key Takeaways
| Point | Details |
|---|---|
| RAID = Risks, Assumptions, Issues, Dependencies | Four categories that together give a complete picture of delivery health. |
| The log is the source; the report is the story | Maintain one live RAID log; generate reports on demand from it. |
| Executives want signal, not inventory | A good RAID report shows the top 5–10 items with owner, status and next action. |
| Automation removes the reporting tax | Pocket PMO Snapshot builds a board-ready RAID report in one click. |
What is a RAID log?
A RAID log is a single register that tracks four categories of project information:
- Risks — things that might happen and would negatively affect the project if they did.
- Assumptions — statements taken to be true for planning purposes, which need to be validated.
- Issues — things that have happened and are actively affecting delivery.
- Dependencies — internal or external items the project relies on to progress.
Some teams add Decisions instead of Dependencies (making it RAID with a different D), and some extend it to RAIDD to cover both. Whichever variant you use, the point is the same: one place where the project's live delivery signals live, with an owner, a status, and a next action against every entry.
A well-run RAID log has these fields as a minimum:
| Field | Purpose |
|---|---|
| ID | Stable reference for meetings and audit history |
| Type | Risk / Assumption / Issue / Dependency |
| Title | Short, plain-English summary |
| Description | Enough context that a new joiner understands it |
| Owner | One named person accountable |
| Status | Open, In progress, Mitigated, Closed |
| Priority / RAG | Red, Amber, Green (or High/Med/Low) |
| Impact & likelihood | For risks specifically |
| Next action & due date | The single most-skipped field, and the most important |
| Last updated | So stale items are obvious |
RAID report vs. RAID log: what's the difference?
These two terms get used interchangeably, but they are not the same thing.
- The RAID log is the live, complete register — everything, open and closed, tracked over time.
- The RAID report is a filtered, formatted view of the log, produced for a specific audience at a specific moment (weekly PM stand-up, monthly steering committee, quarterly board).
Executives do not want to read a 120-row spreadsheet. They want the top open risks, the issues currently affecting delivery, the assumptions that have been invalidated since last time, and the dependencies that are slipping. A RAID report is the log curated for the audience.
The anatomy of a board-ready RAID report
A RAID report that lands well in a steering committee usually has five sections:
- Headline RAG — one traffic light for the project overall, with a one-sentence justification. This is what the committee remembers.
- Top risks (open) — five to ten items, sorted by priority. Each row: title, owner, RAG, next action, due date.
- Active issues — issues currently affecting delivery. Fewer is better; every issue should have an owner and an action.
- Assumptions to validate or invalidated since last report — this is where governance actually happens. Assumptions that quietly stop being true are how projects fail.
- Dependencies at risk — anything the project needs from another team, supplier or programme that is slipping.
A good RAID report tells a story: what changed since last time, what's getting worse, what's getting better, and what the committee needs to decide today. If your report is just a table dump, you're doing the log's job, not the report's.
RAID reporting best practices
- One log per project, always up to date. Multiple parallel logs (one in Excel, one in email, one in a slide deck) is how RAID reporting fails at scale.
- Every item has an owner and a next action. No exceptions. "Everyone" owns nothing.
- Review weekly, not just before steer-co. Batching RAID review into the night before a board pack is the single biggest source of low-quality reports.
- Close items decisively. A log full of stale "Open" items nobody has touched in three months erodes trust in the whole report.
- Use consistent RAG criteria. Define upfront what makes a risk red vs. amber. Otherwise every PM scores differently and portfolio roll-ups become meaningless.
- Separate the log from the report. Keep the register complete; let the report be the curated view.
- Timestamp everything. "Last updated" is what tells a reader whether a row is a live signal or historical noise.
Common RAID reporting mistakes
- Confusing risks with issues. A risk hasn't happened yet. An issue has. Mixing them makes the report unreadable.
- Assumption blindness. Most teams populate assumptions once at project start and never revisit them. Half your delivery risk lives there.
- Owner = the PM for everything. If the PM owns every item, nothing is actually owned.
- No prioritisation. A flat list of 40 open risks tells a committee nothing. Rank them.
- Reporting the log instead of the story. Pasting the whole spreadsheet into a slide is not a report.
- No audit trail. When a risk closes, keep the history. Repeat patterns across projects are how portfolios learn.
Automating RAID reports with Pocket PMO Snapshot
Most of the pain in RAID reporting is not the thinking — it's the formatting. Pulling the right rows, sorting by priority, filtering to open items, laying it out for a board deck, and then doing it all again next month.
Pocket PMO's Snapshot feature removes that reporting tax entirely:
- Your team maintains one live RAID log inside Pocket PMO with owners, RAG, next actions and audit history.
- When it's time to report, one click generates a board-ready RAID report — headline RAG, top risks, active issues, invalidated assumptions and slipping dependencies — formatted, dated, and shareable as a PDF or link.
- The AI drafts a plain-English narrative for each section; you approve or edit before it goes out. Nothing is auto-sent — every Snapshot is approval-first, the same way the rest of the platform works.
- Snapshots are versioned, so you have a full history of what the RAID picture looked like at every steer-co.
For multi-project PMOs, Snapshot rolls RAID up to portfolio level with consistent RAG criteria, so senior stakeholders see one comparable view across every project — instead of five different spreadsheet dialects.
If you're spending hours every reporting cycle rebuilding the same RAID slides, try the Pocket PMO live demo and see a Snapshot render in real time.
Frequently asked questions
What does RAID stand for in project management?
RAID stands for Risks, Assumptions, Issues, Dependencies. Some organisations use the fourth D for Decisions instead, or extend it to RAIDD to cover both. All variants share the same purpose: a single register of the live delivery signals a project manager needs to control.
How often should a RAID report be produced?
The RAID log should be updated continuously as new items arise and reviewed weekly. RAID reports are produced on the cadence of your governance forums — typically weekly for internal delivery stand-ups and monthly for steering committees.
What's the difference between a risk and an issue?
A risk is something that might happen and would affect the project if it did. An issue is something that has happened and is affecting the project now. Confusing the two is the most common mistake in RAID reporting.
Can RAID reporting be automated?
Yes. Platforms like Pocket PMO maintain the live RAID log and use its Snapshot feature to generate board-ready RAID reports in one click — with an AI-drafted narrative you approve before sharing. That removes the manual re-formatting cycle that consumes most of the reporting time.
Recommended
Run delivery without the admin overhead
Pocket PMO gives PMs RAID, governance, AI reporting and stage gates out of the box. 15-day free trial. No setup required.
Keep reading
- Your first week on a project: the setup checklist that prevents rework
A day-by-day checklist for the first week of a new project: sponsor and scope, governance level, plan skeleton, RAID baseline, reporting cadence, and the traps that cause month-three rework.
- How to write a weekly project status report in five minutes
A repeatable weekly status report method: what sponsors actually read, the five-block structure, an honest RAG rule, and how to make the report a by-product of your delivery data.
- Auto-scheduling project plans: replanning without starting again
How AI auto-scheduling works in practice: ripple rescheduling, parallel-versus-sequential checks, dependency detection and safe replanning when a task slips.