How_to_use_this_RAID_log
📖 How to use this template
A RAID log is one running record of four things teams usually keep in four places: Risks, Assumptions, Issues and Dependencies. Keeping them apart is why the connections get missed. This one has twenty-one sample entries across the four sections, so you can see the shape before you replace them.
- Duplicate this project into your own organization (dropdown next to the project name, then
Duplicate) - Replace the 🚀 Customer Portal v2 go-live milestone with your real deadline. Every date below it should be read against that one
- Read two or three sample entries in each section, then delete the rest. They exist to show you the shape of a good entry, not to be kept
- Add your first five real entries. Start with what is already going wrong, because Issues are the easiest to write and they get people used to the log
- Put the Weekly RAID review in the calendar and invite the owners. A log without a review is a document, not a process
- Read the RAID playbook below for how to tell the four categories apart
RAID playbook
The four categories, and how to tell them apart
The categories get confused constantly. Here is the short version.
| Tense | Question it answers | Test | |
|---|---|---|---|
| 🔴 Risk | Future, uncertain | What could go wrong? | Can you write it as "if X, then Y"? |
| 🟡 Assumption | Present, unverified | What are we betting on? | Would you be surprised if it turned out false? |
| 🟠 Issue | Present, certain | What is going wrong now? | Has it already happened? |
| 🔵 Dependency | Future, someone else's | What do we need from others? | Is the next action outside your team? |
Three rules that resolve almost every argument about where something goes:
- A risk that materialises is no longer a risk. Move it to Issues and close the risk with a note saying so
- An assumption that turns out false is not just wrong, it has a consequence. Close the assumption and raise the consequence as a Risk or an Issue. A-01 in this template is the worked example
- A dependency you have stopped chasing is a risk. Re-score it at the monthly clean-up
Writing entries that are worth keeping
The difference between a useful RAID log and a compliance artefact is almost entirely in how the entries are written.
Write risks as cause and effect. "Vendor delay" is a worry. "If Northbridge misses 6 August, then authentication testing starts without production credentials and UAT slips two weeks" is something you can act on and argue about.
Give every risk a trigger. The point at which it stops being hypothetical. Without one, nobody knows when to escalate, so escalation happens late and by feel.
Name the response. Avoid it, mitigate it, transfer it, or accept it. "Monitor" is not a response, it is a way of writing "we have not decided".
Write the impact in units someone cares about. Weeks, money, customers, reputation. "High impact" tells a sponsor nothing.
Put a date on everything. An entry with no due date will never be worked.
Three ways this goes wrong
It becomes a graveyard. Fifty open entries, most of them stale, and people stop opening it. Close aggressively. An entry nobody has touched in two months is either not real or not owned.
Everything is high impact. If the whole log is red, the log has stopped ranking anything. Force a spread. Four Critical entries out of twenty is a plausible project. Fourteen is a project that has not been thought about.
It is only updated before the steering meeting. Then it stops being a management tool and becomes a reporting one. The weekly review is what keeps it real, and it takes twenty minutes.
RAID log or Risk Register?
They overlap, and Quire has both.
Use this RAID log when you want one place for everything that could go wrong across a project, including the things a risk register does not cover: assumptions and dependencies. Risk scoring here is deliberately light, just Probability and Impact.
Use the Risk Register template when risk is the whole job, and you need a 5×5 scoring matrix, risk scores, response strategies and a formal review cadence. It is the deeper instrument for one of these four categories.
Plenty of teams run both, with the RAID log as the working record and the register as the formal artefact.
What's set up for you
The fields
RAID ID gives every entry a stable handle (R-01, A-03, I-02, D-05) so people can refer to it in a meeting without reading the whole title out. Number sequentially within each letter and never reuse a number, even after an entry is closed.
Type duplicates the section, on purpose. Sections organise the list. The Type field is what lets you filter and group in Table view, or pull a single category out across a whole portfolio.
Probability applies to risks only. Issues have already happened, so their probability is 100% and the column stays empty. If you find yourself filling in Probability on an issue, it is probably a risk.
Impact applies to everything. It is the column you sort by, and the one that decides what gets escalated.
Raised On and Last Reviewed are the two dates that expose neglect. An entry raised in March, reviewed in April, still open in September is not being managed. Sort by Last Reviewed at the monthly clean-up and work upward from the oldest.
Depends On names the team, vendor or person on the hook. Mostly used on dependencies, but useful on any entry that is stuck outside your control.
Assignee is the single person accountable, not the team. "Engineering" never chases anything.
The statuses
| Status | Use it when |
|---|---|
| Open | Logged, owned, nothing happening yet |
| In progress | Someone is actively working it |
| Escalated | It has outgrown the project team and needs a decision above you |
| Awaiting response | The ball is genuinely in someone else's court |
| Closed | Resolved, retired, or no longer relevant |
| Validated | An assumption checked and confirmed true |
Awaiting response earns its place. Without it, "In progress" covers both "I am working on this" and "I sent an email nine days ago", and those need very different follow-up.
The views
Table view is the RAID log proper. Show RAID ID, Type, Probability, Impact, Status, Assignee, Due and Last Reviewed, then sort by Impact. The top of that list is your meeting agenda.
List view is for working inside an entry, where the description, subtasks and comments live. Entries with real mitigation work have subtasks. R-01 and I-04 show the pattern.
Board view grouped by status shows you flow. If the Escalated column is filling up faster than it empties, that is your project's actual health indicator.
Calendar view shows the due dates. Useful for spotting the week where four dependencies all land together.
The sublists
Sublists cut across the four sections, which is where a single log starts paying off.
- 🔥 Escalate now is every Critical-impact entry still open, regardless of category. This is your steering committee pack
- ⏳ Waiting on someone else is everything whose next move is not yours. Open it before every status call and chase the top three
- ❓ Unvalidated assumptions is the list nobody reads until it is too late. Read it out loud once a quarter
- 🔗 The vendor chain is the worked example: one missing budget code, traced through four entries in three different categories