RAID Log Template Permalink

Use this template to run a RAID log in Quire: keep risks, assumptions, issues and dependencies in one place, rank them by impact in Table view, and hold a weekly review that actually closes things.

You can visit the RAID Log project and duplicate it to your workspace, so you don’t need to build everything from scratch.

You can also explore more ready-to-use templates to speed up your workflow.

Understand RAID Logs

RAID stands for Risks, Assumptions, Issues and Dependencies. A RAID log is the running record of all four: what could go wrong, what you are betting on without having checked, what has already gone wrong, and what you need from people outside your team.

Most teams track some of this somewhere. Very few keep all four in one place, and that is where the value sits. A missing budget code looks like a small administrative issue right up until you notice it is why the vendor will not release credentials, which is why the launch-week agreement is still unsigned. One root cause, three separate lists, nobody joining them up.

The log is laid out as five sections, with a milestone pinned at the top so every date below it is read against the deadline that matters.

Four sections hold the categories themselves. The fifth, RAID governance, holds the review cadence, which is the part that decides whether the log survives past month two. Twenty-one worked sample entries come filled in, so you can read the shape of a good write-up before replacing them with your own.

RAID Log or Risk Register

Quire ships both, and they answer different questions. A risk register is a deep instrument for one category: a 5x5 matrix, numeric risk scores, five formal response strategies and a governance cadence, all pointed at risk alone. A RAID log is a shallower instrument for four categories, scoring risk with just probability and impact, but covering the assumptions and dependencies a register has no place for.

Use the log when you want one place for everything that could derail the project. Use the register when risk management is the whole job and the scoring has to be defensible. Running both is common, with the log as the working record and the register as the formal artifact.

The template ships with a document covering setup, the category rules and the failure modes worth avoiding.

A second document holds the weekly review agenda, so whoever runs the meeting is not inventing the running order on the morning.

Tell the Four Categories Apart

The categories get confused constantly, and an argument about where something belongs is a good way to waste the first ten minutes of a review. Four tests settle almost all of it.

Three rules resolve the rest.

1. A risk that materializes is no longer a risk. Move it to Issues and close the risk with a note saying where it went, rather than leaving it open in both places.
2. An assumption that turns out false is not just wrong, it has a consequence. Close the assumption and raise that consequence as a risk or an issue.
3. A dependency you have stopped chasing is a risk. Re-score it at the monthly clean-up.

The sample entry A-01 in the template is the worked example of rule two, wired to the issue it produced.

Read the Log in Table View

Table view is only available in the Professional, Premium, Enterprise plans. More information can be found on our pricing page.

Table view is the RAID log proper. It puts every custom field beside the entry, and sorting by Impact turns the top of the list into your meeting agenda.

Seven fields carry the log.

Raised On and Last Reviewed only look like bookkeeping. An entry raised in March, reviewed in April and still open in September is not being managed, and those two dates are the only way that fact shows up without someone noticing it by accident.

Note: If you find yourself filling in Probability on an issue, it is probably a risk that has not been reclassified. Issues have already happened, so their probability is one hundred percent.

Eight tags cut across all four categories: Budget, Schedule, Technical, Scope, Client, Vendor, People and Compliance. They answer a different question from Type, which is where the entry came from rather than what kind of thing it is.

Write an Entry Worth Keeping

The difference between a useful RAID log and a compliance artifact is almost entirely in how the entries are written. Every sample entry in the template follows the same four-part shape.

The description opens with an if X, then Y statement, then states the impact if it happens in units somebody cares about, then names the response, then gives the trigger to watch. Mitigation work hangs off the entry as subtasks, so the plan and the record stay in the same place.

Five rules make the difference.

• Write risks as cause and effect. “Vendor delay” is a worry. “If the vendor misses 6 August, then authentication testing starts without production credentials and testing slips two weeks” is something a team can act on.
• Give every risk a trigger. The observable point at which it stops being hypothetical. Without one, escalation happens late and by feel.
• Name the response. Avoid, mitigate, transfer or accept. “Monitor” is not a response, it is a way of writing “we have not decided”.
• Write 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.

Assign one named person to every entry. A team never chases anything, because nobody in it believes the chasing is specifically theirs.

Track Flow in Board View

Board view grouped by status shows movement rather than inventory, which is a different and more honest picture.

Six statuses run the log.

Awaiting response is the one that earns its place. Without it, In progress has to cover both “I am working on this” and “I sent an email nine days ago”, and those two need completely different follow-up.

Tip: Watch the Escalated column over a few weeks rather than reading it once. If it fills faster than it empties, that is a more reliable health signal than any status report.

Pull Cross-Cutting Views with Sublists

In the Free Subscription plan, you can create two sublists for each project, and this template ships with 4. Keep the two your team opens most after duplicating, or upgrade your subscription plan to use all four. More information can be found on our pricing page.

The sections answer “what kind of thing is this”. Four sublists answer questions that cut across all four categories at once, which is where keeping one log instead of four starts paying off.

• Escalate now is every Critical-impact entry still open, regardless of category. This is the steering committee pack. If it runs past about six items, the project is being watched rather than managed.
• 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 a worked example rather than a filter.

That last one is worth opening first, because it shows the whole argument for a single log in four entries.

An unraised purchase order is an issue. It blocks finance approving the order, which is a dependency. That blocks the vendor delivering production credentials, another dependency. And that is the reason the launch-week agreement is still unsigned, which is logged as a risk. Three categories, one root cause, visible only because they live in the same log. The entries are wired together with real task dependencies, so the chain is enforced rather than described.

Keep the Log Honest

A log without a review is a document, not a process. The governance section holds four recurring tasks so the rhythm lands on the schedule instead of depending on someone remembering.

Three failure modes account for most dead RAID logs, and it is worth naming them because they arrive quietly.

1. It becomes a graveyard. Fifty open entries, most of them stale, so people stop opening it. An entry nobody has touched in two months is either not real or not owned.
2. Everything is high impact. If the whole log is red, it has stopped ranking anything. Four Critical entries out of twenty is a plausible project. Fourteen is a project nobody has thought about.
3. It is only updated before the steering meeting. At that point it has turned from a management tool into a reporting one.

All three have the same unglamorous fix: a short weekly review, and closing entries aggressively.

Read more on our blog about how to score risks and keep a register alive.

Frequently Asked Questions

What is a RAID log?

A RAID log is a single running record of what could go wrong, what you are betting on without having checked, what has already gone wrong, and what you need from people outside your team. Keeping all four in one place is what lets you see that separate-looking problems share a root cause.

What does RAID stand for?

Risks, Assumptions, Issues and Dependencies. You will also see it expanded as Risks, Actions, Issues and Decisions, which is more common in program work. The Quire template uses the first version because assumptions and dependencies are the two categories teams are least likely to be tracking anywhere else.

What is the difference between a risk and an issue?

Tense and certainty. A risk is future and uncertain, written as “if X, then Y”. An issue is present and certain, because it has already happened. When a risk materializes it stops being a risk, so move it to Issues and close the risk with a note saying where it went.

What is the difference between a RAID log and a risk register?

A risk register is a deep instrument for one category, with a 5x5 matrix and formal response strategies. A RAID log is a shallower instrument for four, and it covers the assumptions and dependencies a register has no place for. Many teams run both.

Who owns the RAID log?

The project manager owns the log itself, meaning the review cadence, the closing of stale entries and the escalations. Every individual entry needs one named person, never a team, because a team never chases anything.

How often should a RAID log be reviewed?

Weekly for the whole log, about 30 minutes sorted by impact. Monthly to close stale entries and re-score open risks. Quarterly to re-validate assumptions. The template holds all three as recurring tasks so they land on the schedule by themselves.

What should a RAID log entry contain?

A stable ID such as R-01, the category, an impact rating, one named owner, a due date and a written response. Risks also need a probability and a trigger, which is the observable point at which the risk stops being hypothetical and someone has to act.

Why do RAID logs stop being useful?

Three failure modes: the log becomes a graveyard of stale entries, everything gets marked high impact so nothing is ranked, or it only gets updated before the steering meeting. The fix for all three is a short weekly review and closing entries aggressively.

Is there a ready-made RAID log template in Quire?

Yes. Visit the RAID Log project and duplicate it to your workspace to get the four category sections plus governance, seven custom fields, six statuses, eight tags, four cross-cutting sublists and twenty-one worked sample entries already set up.