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. |
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. |
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 |
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.
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.