For consultants keeping a project on track
RAID Log Template With Scales and Examples
One document and five sheets: risks, assumptions, issues, dependencies and decisions, with scoring scales, owners and dates, plus worked example entries.
| Entry | Owner | Rating or date | Next step |
|---|---|---|---|
| R-02 · Depot 3 go-live lands in peak season | Operations director | 4 × 5 = 20 · Critical | Steering committee decides on 26 Aug |
| A-01 · Two super-users per depot from 1 Sep | Operations director | Validate by 15 Aug | Confirm with the three depot managers |
| I-01 · Test environment arrived 9 days late | Project manager | High | Two weekend build days; escalated |
| DEP-01 · Carrier label connection (external) | Client IT lead | Needed by 29 Aug | At risk: sponsor to call the carrier |
| DEC-03 · Move Depot 3 go-live to January? | Steering committee | Needed by 26 Aug | Recommended: move to 12 Jan |
Example entries from an invented warehouse system rollout.
What you'll get
Five RAID sheets with scoring scales and worked example entries
- A sheet each for risks, assumptions, issues, dependencies and decisions
- Likelihood and impact scales from 1 to 5, with what each score means
- Worked example entries, or a first pass sorted from your own notes
Before and after
Your notes in. A sorted RAID log out.
Vendor's test environment came 9 days late, so sprint 2 started late. Depot 3 go-live is 20 Oct and peak starts 1 Nov, worried. Still no label connection details from the carrier after three emails. Planning on two super-users per depot from September.
Risks R-01 · Because peak starts on 1 Nov, any slip in Depot 3's 20 Oct go-live would put go-live support in peak. Owner: [owner]. 4 × 5 = 20, Critical (proposed). Assumptions A-01 · Two super-users per depot from September. Validate by: [date]. Issues I-01 · The vendor's test environment arrived nine days late, so sprint 2 started late. High (proposed). Dependencies DEP-01 · Carrier label connection details. External, we need. Needed by: [date]. At risk.
Scores are marked proposed, and owners and dates your notes don't give stay in brackets.
Why it works
What is a RAID log, and what goes in it?
A RAID log is one place to track a project's risks, assumptions, issues and dependencies, and most teams record decisions there too. The UK government's gate review guidance asks for the same set of registers, with decisions and constraints alongside. This template is one document and five sheets. Each type gets a sheet with its own columns, and the guide covers the rules, the scoring scales and a 30-minute weekly review.
Every entry gets an ID, a named owner, the date it was raised and the next date that matters. Risks are scored from 1 to 5 for likelihood and impact, and the guide says what each number means in weeks of delay and share of budget. The UK government's risk management guidance says the matrix should be tailored to the work, and the guide shows how. Assumptions carry a validate-by date. Dependencies are marked internal or external; for work split across several workstreams, the programme management template checks every handoff between them.
Each sheet opens with worked example entries from an invented warehouse system rollout, so you can see what a good entry looks like before you write your own. Paste your latest status update or meeting notes, and River replaces the examples with your own entries, proposed scores and bracketed gaps. When the log is current, the status report generator turns it into your weekly update. The weekly status report template puts your Critical risks and the decisions you need from the sponsor in front of the client.
What lands in your doc
What's inside the RAID log template
- Risks
Cause, event and effect, scored 1 to 25, with a trigger, a mitigation and a contingency. - Assumptions
Each one with a validate-by date, who confirms it, and what changes if it proves false. - Issues
Priority from Critical to Low, the action, a target date and who it was escalated to. - Dependencies
Internal or external, which way it runs, who provides it and the date you need it. - Decisions
What was decided, by whom and when, the options considered and why. Superseded, never edited. - The RAID log guide
Scales with definitions, rules for every entry, a weekly review, what to report and a worked example.
How it works
From scattered notes to a RAID log
Open the template
Click Edit with AI. The guide and the five sheets open in River, with worked example entries in place.
Paste your notes
Optional. Paste a status update, meeting notes or an old risk list, and River sorts every point onto the right sheet.
Check the first pass
Confirm or change each proposed score, then fill in the owners and dates River left in brackets.
Review it every week
Run the 30-minute review in the guide, then ask River to turn the log into your status update.
Questions consultants ask
Common questions
What is a RAID log, and what does RAID stand for?
A RAID log tracks a project's risks, assumptions, issues and dependencies (RAID) in one place. A risk might happen, and an issue is happening now. An assumption is what you're planning on without proof, and a dependency is something you need from someone else by a date. Some teams read the D as decisions, which get their own sheet here.
What's the difference between a risk and an issue?
A risk hasn't happened yet, and an issue has. The UK government's issue management guidance defines an issue as an event that has happened, was not planned and needs management action. When a risk happens, close it as "Happened, see I-03" and open the issue, so the history stays linked.
How do you score likelihood and impact?
Score each from 1 to 5 using the definitions in the guide, then multiply them for a score from 1 to 25. In this template, 20 to 25 is Critical and goes to the steering committee, and 10 to 16 is High and goes in the weekly status report. Agree what each impact number means in weeks and dollars with your sponsor at kickoff.
How often should a RAID log be updated?
Review it every week, before the weekly status report goes out. The guide sets out a 30-minute routine. Add new entries, re-score open risks and check assumptions past their validate-by date. Then chase dependencies due in the next four weeks, and list the decisions the next steering committee needs.
Should I share the RAID log with my client?
Usually, yes. A log the client can see gets acted on, and most entries need a client owner anyway, because only the client can supply its data, people and decisions. Keep concerns about your own firm, such as staffing or margin, in a separate internal note rather than a hidden column that could be shared by mistake.
Is a RAID log the same as a risk register?
No. A risk register holds only risks. A RAID log puts risks next to the assumptions, issues, dependencies and decisions that feed them. That's how you catch an assumption turning into a risk, or a late dependency turning into an issue. On a smaller project, the RAID log can replace a separate risk register.
What happens to the RAID log when the project ends?
Close every entry, or hand it to a named owner who stays after your team leaves. Open risks and issues go to the client, and the decisions sheet becomes the record of who agreed what. The project closure report template has a section for exactly this handover.
Your next step
More for your project
Give every risk an owner and a date
Open the five sheets with worked examples in place, or paste your latest notes and River sorts them into the log.