By Ryan Kramer, founder of Wisegrid. Last updated July 2026.
A RAID log is a project management document that tracks four things in one place: Risks (what might go wrong), Assumptions (what you are treating as true), Issues (what has already gone wrong), and Dependencies (what you are waiting on, or who is waiting on you). It is reviewed on a regular cadence, usually weekly, so problems get owners and deadlines instead of living in someone’s head.
This guide covers what goes in each section, a complete template with a worked example you can copy, and the honest reason most RAID logs die (they go stale), along with a way to fix that.
Key takeaways – RAID stands for Risks, Assumptions, Issues, Dependencies. Some teams swap Assumptions for Actions; both variants are legitimate, pick one and be consistent. – Risks are future, issues are present. A risk might happen; an issue already has. – Every entry needs an owner and a date. An unowned RAID entry is a wish, not a plan. – The template below is a complete starting point. Columns, statuses, scoring, and a filled-in example. – Staleness is the killer. A RAID log nobody updates is worse than none at all, because it creates false confidence. The fix is making the log flag its own stale entries.
What is a RAID log?
A RAID log (sometimes called a RAID register) is a single living document where a project team records its risks, assumptions, issues, and dependencies. It usually lives as a spreadsheet or a sheet in a work management tool, with one row per entry and columns for description, owner, severity, status, and dates. Its job is to be the one place the project manager and stakeholders look to answer “what could hurt this project, and what are we doing about it?”
It gets its power from three habits: everything gets written down when it is raised (not when it becomes urgent), every entry has exactly one accountable owner, and the log is reviewed on a fixed cadence, typically at the weekly project meeting.
You will also see the variant where the A stands for Actions instead of Assumptions (a running list of agreed to-dos with owners and due dates). There is no official standard; the four-category Risks, Assumptions, Issues, Dependencies version is the most common, and it is the one this guide uses.
R is for Risks
A risk is a possible future event that would hurt the project if it happened: a key engineer might leave, a vendor might ship late, the client might delay sign-off. The cheap time to deal with a risk is before it materializes.
For each risk, capture:
- Description, written as cause and effect: “Because the vendor’s API is still in beta, integration testing may slip past March 15.”
- Likelihood (1 to 5, or Low/Medium/High): how probable is it?
- Impact (1 to 5): how bad would it be?
- Score: likelihood multiplied by impact. This is how you sort the log so the top of the list is always the scariest item.
- Mitigation: what you are doing now to make it less likely or less painful.
- Owner and a next review date.
Two pieces of hard-won guidance. First, resist logging vague worries (“the timeline is aggressive”) as risks; a risk you cannot mitigate or watch is background anxiety, not a log entry. Second, when a risk materializes, do not delete it: close it as “occurred” and open a linked issue.
A is for Assumptions
An assumption is something you are treating as true without proof because the plan depends on it: “the client will provide test data by week 2,” “the current infrastructure will handle launch traffic.”
Assumptions are the quietest project killers because nobody feels responsible for them. The discipline that works: write the assumption down the moment you hear yourself say “we’re assuming…”, then give it a validation owner and a validate-by date. An assumption is a question with a deadline. When validated, mark it confirmed; when it turns out false, that usually spawns a risk or an issue immediately, and the earlier you find out, the cheaper it is.
A good test during planning: for every major estimate, ask “what would have to be true for this number to hold?” Each answer is an assumption that belongs in the log.
I is for Issues
An issue is a problem that is happening now and needs resolution: the vendor did ship late, the environment is down, scope disagreement has stalled sign-off. Where risks are managed, issues are worked.
For each issue, capture the description and date raised, a severity (Critical / High / Medium / Low, based on impact on the project’s commitments, not on how loud the person who raised it was), an owner, the current action, and a status (Open / In progress / Resolved / Escalated).
The most useful issue-log habit is writing the current action as a real sentence with a name and a date (“Dana chasing revised delivery date from vendor, answer due July 9”) instead of a status word. When the review meeting reads the log, “In progress” invites silence; a named action with a date invites a yes/no answer.
D is for Dependencies
A dependency is anything where your work waits on someone else, or someone else waits on you: a deliverable from another team, a client decision, a compliance approval. Log both directions; forgetting outbound dependencies (things others need from you) is how you become the blocker in someone else’s RAID log.
For each dependency, capture the description and direction (inbound or outbound), the other party named specifically (“IT” is not a party; “Priya on the platform team” is), the needed-by date, a status (On track / At risk / Late / Delivered), and the owner on your team responsible for chasing it.
Anything within two weeks of its needed-by date that is not confirmed should be treated as at-risk by default.
The RAID log template
One sheet, one row per entry, these columns. A single combined log with a Type column beats four separate tabs, because the weekly review reads one list, sorted by score and date, instead of four.
| Column | What goes in it |
|---|---|
| ID | Sequential (R-01, A-01, I-01, D-01) so entries can be referenced in meetings |
| Type | Risk / Assumption / Issue / Dependency |
| Description | One or two sentences, cause and effect where possible |
| Raised by / date | Who logged it and when |
| Likelihood (1-5) | Risks only |
| Impact (1-5) | Risks and issues |
| Score | Likelihood x impact; sort the log by this |
| Severity | Issues: Critical / High / Medium / Low |
| Owner | Exactly one name |
| Action / mitigation | The current next step, as a sentence with a date |
| Needed-by / validate-by | Dependencies and assumptions |
| Status | Open / In progress / Resolved / Confirmed / Occurred / Closed |
| Next review date | When this entry must be looked at again |
A complete worked example
Here is what a healthy RAID log looks like mid-project, for a fictional website replatforming:
| ID | Type | Description | L | I | Score | Owner | Action / mitigation | Status | Next review |
|---|---|---|---|---|---|---|---|---|---|
| R-01 | Risk | Payment vendor’s new API is in beta; integration may slip past Mar 15 | 3 | 4 | 12 | Dana | Weekly checkpoint with vendor; fallback to current API scoped by Feb 20 | Open | Jul 10 |
| R-02 | Risk | Only one engineer knows the legacy CMS export format | 2 | 5 | 10 | Marcus | Pairing sessions booked; export runbook due Jul 18 | Open | Jul 14 |
| R-03 | Risk | Content migration volume may exceed the agency’s estimate | 3 | 3 | 9 | Ana | Sample audit of 10% of pages runs this week to re-baseline | Open | Jul 11 |
| A-01 | Assumption | Client provides final brand assets by Jul 21 | Ana | Confirm in Thursday’s client call; validate by Jul 17 | Open | Jul 17 | |||
| A-02 | Assumption | Current hosting tier handles launch-week traffic | Marcus | Load test scheduled Jul 25 | Open | Jul 25 | |||
| I-01 | Issue | Staging environment down since Jul 2; blocking QA | 4 | Marcus | Ticket escalated to hosting provider Jul 3; answer due Jul 8 | Escalated | Jul 8 | ||
| I-02 | Issue | Client and agency disagree on blog template scope | 3 | Ana | Scope options doc to client sponsor by Jul 9 for a decision | In progress | Jul 9 | ||
| D-01 | Dependency (in) | Legal approval of new privacy copy, needed before launch | Dana | Submitted Jun 30; legal committed to Jul 15; chase Jul 11 | On track | Jul 11 | |||
| D-02 | Dependency (out) | Analytics team needs our event schema by Jul 20 | Marcus | Draft schema in review; deliver by Jul 16 | On track | Jul 12 |
Notice what makes this log useful rather than ceremonial: every row has one named owner, every action is a sentence with a date in it, risks are sorted by score, and every single entry has a next review date. That last column is the one most templates leave out, and it is the one that decides whether the log survives.
How to run a RAID log that survives
- Review weekly, top to bottom, sorted by score and date. Ten minutes in the regular project meeting. Every open entry gets one of three outcomes: the action advanced, the action changed, or the entry closed.
- Log at the moment of mention. When someone says “one thing I’m worried about…” in a meeting, that is a risk being raised. Capture it then.
- Close aggressively. A 60-row log where 40 rows are dead is unreadable. Resolved issues, confirmed assumptions, and delivered dependencies get closed with a one-line outcome.
- Escalate by rule, not by mood. Decide up front what escalates automatically: any risk scoring 15+, any Critical issue open more than 5 days, any dependency late by more than a week.
- Make the log the source for status reporting. The status report’s “top risks and issues” section should be pulled from the log, not rewritten from memory. If the two can disagree, one of them is fiction.
And the honest failure mode: nearly every RAID log starts strong and dies around week six, when the review gets skipped twice and nobody trusts the dates anymore. The next-review-date column only works if something actually happens when the date passes.
A RAID log that maintains itself
This is the part a spreadsheet cannot do and a work management grid can. Build the same log as a Wisegrid sheet and the maintenance runs on autopilot: date-triggered automations catch every entry whose next-review date has passed and notify its owner (with a full run history showing every time it fired), a dashboard rolls up open risks and issues by score and severity so stakeholders stop asking for a summary, and cross-sheet references pull the top items straight into your status report sheet so the report can never drift from the log.
The step-by-step build, with the exact triggers, conditions, and dashboard widgets, is in the companion guide: How to build a self-maintaining RAID log in Wisegrid.
FAQ
What does RAID stand for in project management?
Risks, Assumptions, Issues, and Dependencies. A RAID log is the document that tracks all four in one place, with an owner, a status, and a review date on every entry.
What is the difference between a RAID log and a risk register?
A risk register covers only risks, usually in more depth (categories, response strategies, contingency budgets). A RAID log is broader but lighter: it adds assumptions, issues, and dependencies in the same list. Many teams run a RAID log day to day and keep a formal risk register only when the organization or contract requires one.
What is the difference between a risk and an issue?
Timing. A risk might happen; an issue is happening. When a risk materializes, close it as “occurred” and open a linked issue with an action and an owner.
Does the A stand for Assumptions or Actions?
Both variants exist and neither is wrong. Assumptions is the more common reading and the more valuable one in our experience, because actions usually already live in your task list, while assumptions live nowhere unless the RAID log holds them.
Who owns the RAID log?
The project manager owns the log itself: its completeness, cadence, and hygiene. Each entry has its own owner, and that should rarely be the PM for everything; distributed ownership keeps the review meeting from being one person reading a list at everyone else.
How often should a RAID log be reviewed?
Weekly for most projects, as a standing agenda item. High-tempo phases (launch week, a critical integration) justify a daily skim of Critical and High items.
Build a RAID log that keeps itself honest
Start free, copy the template above into a sheet, and let automations chase the review dates so you never have to.
Start free → · How to build it in Wisegrid → · Capacity planning template →
About the author Ryan Kramer is the founder of Wisegrid, a higher-capacity Smartsheet alternative built around a 1,000,000-cell-per-sheet grid, date-triggered automations with run history, and cross-sheet reporting. He writes about the project management documents teams actually keep updated. More from Ryan →