Interactive tool
RAID Log Template
A working log for the four things that knock delivery off course — risks, assumptions, issues and dependencies. Every entry gets an owner, a due date and a next action, because an entry without those is decoration. It's the template behind the RAID log guide.
# RAID log ## Risks | Description | Owner | Due | Next action | Status | | --- | --- | --- | --- | --- | | — | — | — | — | Open | ## Assumptions _None logged._ ## Issues _None logged._ ## Dependencies _None logged._
Five fields per entry. The test of a RAID log isn't whether it's complete — it's whether anything on it changed since last week. Nothing you type here leaves your browser.
Worked example
Four entries from a treasury-system implementation — one per letter. Illustrative values to show what a working entry looks like, not a template answer to copy.
Risk — might happen, gets a mitigation
- Descriptionvendor may miss connectivity date
- Ownerprogramme lead (named)
- Duechase by Friday
- Next actionwritten commitment from vendor PM
Assumption — treated as true, unconfirmed
- Descriptionbank supports camt.053 v8
- Ownerconnectivity lead
- Duebefore build starts
- Next actionconfirm format with the bank
Issue — already true, gets a resolution
- Descriptionmigration rejecting 4% of records
- Ownerdata lead
- Duethis week
- Next actionroot-cause the reject reasons
Dependency — someone else's timeline
- Descriptiontest environment from IT
- Ownerdelivery manager
- Duetwo weeks before UAT
- Next actionescalate ticket at steering
Read the four side by side and the distinctions do the teaching: the risk is conditional and gets a mitigation; the assumption is a belief with a confirmation date; the issue is already true and gets worked this week; the dependency is a chase on somebody else's calendar. Notice that every next action names a concrete step — "chase the vendor PM", not "monitor the risk". That's the difference between a log that manages a programme and one that watches it.
How this works
Methodology
It structures every entry — risk, assumption, issue or dependency — around the three fields that make an entry real: one named owner, a due date, and a specific next action. The export groups entries by letter so the log reads as the steering agenda it should be.
Assumptions
- Each entry is owned by one person, not a team.
- The log is reviewed and worked on a regular cadence, not updated the night before steering.
- A next action is a concrete step someone will take, not the entry restated.
Limitations
- It is a working template, not a tracker — it does not send reminders or chase owners for you.
- It does not score probability or impact; if you need quantified risk ratings, add them in the spreadsheet after the CSV export.
- It cannot log the risks nobody says out loud — the ones that sink programmes are usually those.
Frequently asked questions
What columns does the RAID log template use?
Every entry — risk, assumption, issue or dependency — carries the same five working fields: a description, one named owner, a due date, the specific next action, and an Open or Closed status. That deliberately mirrors the discipline in the guide behind this tool: an entry without an owner, a date and a next action is decoration, so the template gives those fields equal weight with the description instead of treating them as optional extras.
How do I get the log out of this page?
Three ways. Copy puts the whole document on your clipboard as markdown, grouped into Risks, Assumptions, Issues and Dependencies with one table per section. Download .md saves the same document as raid-log.md for a wiki or repo. Export CSV downloads raid-log.csv — one row per entry with its type, description, owner, due date, next action and status — which opens straight in Excel or Google Sheets if the log's long-term home is a spreadsheet.
Where does my RAID log data live?
No. Programme risks and issues are internal and often sensitive, so the tool deliberately has no share link — there is no URL that could carry your entries, and nothing is posted to a server. The log is held in this browser's local storage only. Consent-gated analytics records that the tool was used, copied or exported, never the text of any entry.
Will my entries survive if I navigate away?
Yes — every entry is written to this browser's storage moments after you stop typing and restored on your next visit, because a RAID log is kept over weeks, not filled in once. A notice tells you when a saved log was restored, and Start fresh clears it down to a single empty risk row. Nothing syncs to an account or another device, so the log lives in the browser you started it in.
How big should the log be before it stops working?
Smaller than most programmes keep it. A log where every entry has a real owner and a live next action tends to stay in the dozens; a log in the hundreds is usually a filing cabinet, not an instrument. If a section grows past what the team can actually review on its cadence, that's the signal to close what's resolved, promote stale risks that have quietly become issues, and delete what nobody would chase — not to add more rows.
These answers are about the template. What a RAID log is, the risk-versus-issue distinction and why dependencies sink finance programmes are covered in the RAID log guide.