A usable RAID log template has seven shared columns and a small number of fields that vary by row type. You can build it in a spreadsheet in about ten minutes, and you should, because a template you assembled yourself is one you understand well enough to prune. The templates that fail are the twenty-column ones downloaded intact, where sixteen columns are blank by week three and the team quietly stops opening the file.
This page is the artifact. If you need the underlying concepts first, what each letter means and why the A and the D are contested, start with the RAID log pillar and come back.
Key takeaways
- Seven shared columns: ID, type, description, owner, raised date, next action with due date, and status.
- Only three status values. Open, closed, escalated. More values means slower reviews and no more information.
- Each row type earns one extra field: risks get probability and impact, assumptions get a validation date, issues get an impact statement, dependencies get needed-by and committed-by dates.
- Prefix IDs by type (R-01, A-01, I-01, D-01) so a row can be referenced in minutes without ambiguity.
- Never delete a closed row. Change its status. The closed rows are where the organizational learning is.
- One tab, filtered by type, beats four tabs. Four tabs hides the transitions between the four registers, which is the reason a RAID log exists at all.
The RAID log template columns
Start with these seven for every row, whatever its type.
| Column | Format | Rule |
|---|---|---|
| ID | R-01, A-01, I-01, D-01 | Type-prefixed and never reused, even after a row closes. |
| Type | Risk / Assumption / Issue / Dependency | A dropdown, so it can be filtered and counted. |
| Description | One sentence | State the condition and the consequence. "If X, then Y." |
| Owner | A person's name | Never a team. Never blank. Never the project manager by default. |
| Raised | Date | Enables aging, which is the most useful number in the log. |
| Next action / due | Text + date | If there is no next action, the row should be closed. |
| Status | Open / Closed / Escalated | Three values only. |
Swipe to see more →
Then add exactly one type-specific field per row type. Put them in the same columns and leave them blank where they do not apply, rather than building four separate tables.
| Row type | Extra field | Why this one and not others |
|---|---|---|
| Risk | Probability and impact (High / Medium / Low each) | Enough to sort by. If you need a quantified exposure figure, the row belongs in a risk register, not here. |
| Assumption | Validation date | The date by which this must be confirmed or converted to a risk. The single most valuable field in the whole template. |
| Issue | Impact now | What it is costing today, in days, dollars, or scope. Forces honesty about whether it is really an issue. |
| Dependency | Needed by / committed by (two dates) | The gap between them is your schedule exposure. One date hides it. |
Swipe to see more →
Worked example rows
Illustrative rows, written the way they should read. Note that each description states a consequence, and each owner is a person.
| ID | Description | Owner | Extra field | Next action | Status |
|---|---|---|---|---|---|
| R-04 | If the security review is not booked by Aug 1, the go-live date slips by at least three weeks. | D. Okafor | Prob: Medium / Impact: High | Book the review slot. Due Jul 24. | Open |
| A-02 | We assume the incumbent vendor can export historical records in CSV. | M. Reyes | Validate by Jul 31 | Request a 100-row sample export. Due Jul 22. | Open |
| I-01 | The staging environment has been unavailable for six working days, halting integration testing. | S. Brandt | Impact: 6 days lost, 2 testers idle | Escalate to platform team lead. Due Jul 18. | Escalated |
| D-03 | We need the payments team's API v2 endpoint before we can build checkout. | L. Chen | Needed Sep 1 / Committed Oct 15 | Take the 6-week gap to the portfolio board. Due Jul 25. | Escalated |
Swipe to see more →
Read D-03 again. A six-week gap between the date one project needs something and the date another project has committed to deliver it is not a project problem, because neither project manager can fix it. It is a portfolio problem, and it is exactly the kind of row that should surface in dependency management and get resolved at the portfolio review meeting.
How do I create a RAID log in Excel?
Build it as one sheet, not four. The transitions between types are the information, and four tabs conceal them.
- Row 1: the seven shared headers, then the type-specific headers to their right. Freeze row 1.
- Column B (Type): data validation, list source Risk, Assumption, Issue, Dependency. Do the same for Status with Open, Closed, Escalated.
- Turn the range into a table (Ctrl+T on Windows). You get filter dropdowns and the formatting extends automatically as rows are added, which is the one thing that keeps a shared file tidy.
- Add a conditional format on the due date column: highlight red where the date is in the past and status is Open. This is the whole review meeting, done for you.
- Add a second conditional format on the assumption validation date, same rule. Overdue assumptions are the rows most worth an argument.
- Sort by status then by raised date, so the escalated rows and the oldest rows sit at the top where they will actually be read.
Google Sheets works identically. What does not work is a Word document, because you cannot filter it, and a slide, because it will be rewritten each month and the aging data will be lost.
The three formulas worth adding
Conditional formatting shows you a color. These three columns give you something you can sort, filter, and count, which is what turns the file into a review agenda. They use Excel structured references, so they assume you did step 3 and turned the range into a table.
| Column | Formula | What it gives you |
|---|---|---|
| Age (days) | =IF([@Status]="Closed","",TODAY()-[@Raised]) | Days since the row was raised. Blank once closed, so your average age is not dragged down by history. |
| Overdue | =IF(AND([@Status]="Open",[@[Action due]]<TODAY()),"OVERDUE","") | A filterable flag. Filter to OVERDUE and you have the first half of the weekly review. |
| Breached | =IF(AND([@Type]="Assumption",[@[Validate by]]<TODAY(),[@Status]="Open"),"BREACHED","") | Assumptions past their validation date. This is the second half of the review, and usually the uncomfortable half. |
Swipe to see more →
Sorting by age descending once a month is worth more than any report you could build on top of the file. The oldest open row in a RAID log is almost never the one people are talking about, and there is usually a reason for that.
How long should a RAID log row stay open?
Measure age from the raised date, not from the last time somebody touched the row. Most rows should reach a decision inside two to four weeks. Past that, the row is usually not being worked, it is being carried, and the log is quietly turning into the archive this template is meant to avoid.
These are calibration bands to argue with, not standards. Set your own from your own closed rows: export six months of history, look at how long the rows that closed cleanly actually took, and use that as your chase point. What matters is that a number exists, because a row with no age threshold never becomes anyone's problem on a specific day.
| Row type | Typical time to close | Chase at | Escalate at | What an old row usually means |
|---|---|---|---|---|
| Issue | Days to 2 weeks | 10 days | 15 days | Nobody owns the fix. An issue is already happening, so age here is pure accumulated damage. |
| Assumption | To the validation date | Validation date | Validation date plus 5 days | The answer is inconvenient. Assumptions rarely age because they are hard to check; they age because somebody suspects the answer. |
| Dependency | 2 to 6 weeks | 3 weeks | When the needed-by date enters your remaining float | The other side never actually agreed. A dependency you logged is not a dependency they accepted. |
| Risk | Weeks to months | 30 days with no action change | 60 days, or when probability moves up | Legitimately long-lived, which is why risks are where dead rows hide. Age the action, not the risk. |
Swipe to see more →
The distinction in that last row is the one worth keeping. A risk can sit open for a year and be perfectly healthy, because the condition it describes has not resolved. What cannot sit for a year is its next action. If the next action has not changed in two months, the row is not being managed, and the aging column will show you that even when the status column says Open and the review says fine.
What triggers an escalation?
Escalate when the owner has run out of authority, not when the row looks bad. The test is a single question: is there a decision or a resource that this owner cannot obtain? If yes, escalate today. If no, the row stays open and gets chased. Escalating for visibility teaches everyone above you to ignore the log.
The other half of the rule is that the owner escalates, not the project manager on the owner's behalf. The moment the PM starts escalating other people's rows, ownership evaporates and the log reverts to being one person's list.
| Trigger | Row type | Goes to | The specific ask |
|---|---|---|---|
| Committed-by date sits past needed-by, and the other team will not move | Dependency | Portfolio board or the shared resource owner | Resequence one of the two projects, or accept the slip in writing. |
| Assumption came back false and the plan depends on it | Assumption | Project sponsor | Approve the replan, or fund the workaround. |
| Issue needs money, people, or a scope cut beyond the owner's authority | Issue | Sponsor, then the steering committee | A named decision, with the options and their costs already written. |
| Risk probability rises and the mitigation is unfunded | Risk | Sponsor | Fund the mitigation now, or accept the exposure on the record. |
| Row has been chased twice with no owner response | Any | The owner's line manager | Confirm the person still owns this, or reassign it. |
Swipe to see more →
Notice that every ask in that table is a thing somebody can say yes or no to in one meeting. An escalation that arrives as a description of a problem gets discussed and returned. An escalation that arrives with two priced options and a recommendation gets decided, and the row closes. The same discipline applies further up the chain when these rows land in front of the steering committee, which exists to remove obstacles rather than to receive updates.
How do you close a RAID log row?
Change the status to Closed, add a close date, and write one line of evidence. Never delete the row. Closure means different things for each type, and conflating them is how logs fill up with rows that are marked closed but were only abandoned.
| Row type | Closed means | Evidence to record | The false close to watch for |
|---|---|---|---|
| Risk | The condition can no longer occur, or it occurred and is now an issue | What changed, or the ID of the issue it became | Closing because the date passed. A risk whose window has closed is genuinely closed; a risk nobody has thought about is not. |
| Assumption | Confirmed true with evidence, or proven false and converted to a risk or issue | Who confirmed it and how | Marking it confirmed because nobody objected. Silence is not validation. |
| Issue | The impact has stopped, not just the ticket | The date the impact ended and what the total cost was | Closing when the fix ships rather than when the effect ends. |
| Dependency | The thing was delivered and accepted by your team | Delivery date against the needed-by date | Closing on their promise date instead of on receipt. |
Swipe to see more →
Recording the ID a row converted into is the small habit that makes the whole file worth keeping. Six months later you can count how many of your assumptions turned into issues, and that ratio tells you more about your planning than any maturity assessment will. Teams that log it consistently usually find the number is higher than they expected, which is uncomfortable and useful in roughly equal measure.
Which extra columns are worth adding?
Two are worth adding to almost every log: a close date and a response column. The rest usually cost more attention than they return, because every column you add is a cell somebody has to fill in every week for every row, forever. Judge each against that price rather than against whether the data would be nice to have.
| Column | Verdict | Reasoning |
|---|---|---|
| Date closed | Add it | Free to fill, and it is what makes cycle time and the aging bands above computable at all. |
| Response or mitigation | Add it for risks | Distinct from the next action: the action is this week, the response is the strategy. Without it, risk rows drift into a list of worries. |
| Raised by | Add if the team is above about fifteen people | You will need to go back and ask what the person meant. Below that size you already know. |
| Escalated to | Add only if you escalate often | Useful for chasing decisions that were requested and never made, which is a real failure mode. |
| Category or workstream | Skip unless the project has real subteams | Filtering by owner usually achieves the same thing without a taxonomy nobody agrees on. |
| Cost impact | Skip here | The moment you want quantified exposure, the row belongs in a risk register. Half-quantifying it in a RAID log produces numbers people cite and cannot defend. |
| RAG status per row | Skip | You already have status and aging. A per-row color is a third overlapping signal, and it will be the one that gets managed. |
| Probability multiplied by impact score | Skip | Multiplying two three-point scales produces a number with false precision and a lot of ties. Sort by the two columns instead. |
| Last reviewed date | Skip | It measures whether you held the meeting, not whether the row moved. Aging already covers the real question. |
Swipe to see more →
The pattern in the skip column is worth naming: every one of them is a field that reports on the log rather than on the work. Those are the columns that survive audits and kill files. A template stays alive exactly as long as filling it in tells the team something they did not already know.
Four mistakes that turn the template into an archive
Every one of these is a template problem masquerading as a discipline problem.
- No owner column, or a team in it. Teams do not chase actions. When a row says "Engineering," nobody in engineering has agreed to anything.
- Deleting closed rows to keep the file clean. The closed rows carry the pattern: which risks became issues, which assumptions were wrong, how long escalations took. Delete them and you throw away the only thing the log produces that a future project can use.
- A severity scale with five values. People spend the review arguing between a 3 and a 4. Use three, or use none and rely on escalation status.
- No validation date on assumptions. This is the mistake that costs the most. An assumption with no date is a sentence in a file. An assumption with a date is somebody's job, and it will either be confirmed or it will become a risk on a day you chose rather than a day chosen for you.
When to graduate from a template to a register
A RAID log scales further than most people expect, and then stops abruptly. The signal to graduate is not the number of rows. It is the moment somebody asks a question the log cannot answer: what is our total risk exposure in dollars, or which mitigation actions have we funded, or what is the residual risk after mitigation. Those questions need a quantified project risk register, and at portfolio level they need portfolio risk management.
Keep the RAID log anyway. The register is for analysis, which happens monthly at best. The RAID log is for attention, which has to happen weekly, and a fifteen-page register will not get read on a Tuesday morning. The two artifacts serve different meetings, and mature PMOs run both without confusing them. Where each one is reviewed, and who is permitted to close a row, is a matter for the project governance framework.
Frequently asked questions
What columns should a RAID log template have?
Seven shared columns: ID, type, description, owner, raised date, next action with due date, and status. Then one extra field per type: probability and impact for risks, a validation date for assumptions, a current impact statement for issues, and needed-by and committed-by dates for dependencies. Resist adding more.
What is a good RAID log example?
A good row states a condition and its consequence in one sentence, names a person as owner, and carries a dated next action. "If the security review is not booked by Aug 1, go-live slips three weeks. Owner: D. Okafor. Next action: book the slot by Jul 24." A bad row reads "Security review risk. Owner: Engineering."
Should a RAID log have one tab or four?
One tab, filtered by type. Four tabs hide the transitions that make the log valuable: an assumption failing into an issue, a risk materializing, a dependency slipping into a risk. On one sheet those movements are visible in the raised dates and the ID cross-references. On four sheets nobody ever notices.
Can I use a RAID log template for a program or portfolio?
Use it at project level and roll up only three things: escalated rows, cross-project dependencies, and assumptions past their validation date. Aggregating every row from every project produces a document nobody opens. The roll-up belongs on the portfolio dashboard, not in an appendix.
How often should the RAID log template be updated?
Rows are updated as things change, which in practice means continuously. The log is reviewed weekly as a standing agenda item, run on exceptions: new rows, overdue rows, and rows whose status changed. A full line-by-line pass is worth doing monthly and at every stage gate.