A RAID log template tracks Risks, Assumptions, Issues, and Dependencies in one project list, with an owner, a status, and a review date for each item. The Taskade version groups the four types on a board and sends each owner a weekly reminder, so the log stays current long after kickoff week.
What Is a RAID Log Template?
A RAID log template is one project log for four kinds of items: risks that could happen, assumptions you made, issues happening now, and dependencies on other teams. Some teams read the A as Actions or the D as Decisions. One log means one weekly review instead of four.
What to Record for Each RAID Type
| Type | What it is | Extra fields | Example |
|---|---|---|---|
| Risk | Something that could go wrong | Likelihood, impact, mitigation | The vendor can miss the delivery date |
| Assumption | Something you treat as true without proof | How and when you will check it | The client replies to drafts within 2 days |
| Issue | A problem happening now | Impact, fix, escalation | The test server is down |
| Dependency | Work you wait on from another team | Who you wait on, needed-by date | Legal must approve the contract |
| Decision (if D = Decisions) | A choice the team made | Reason, who decided, date | Keep the current payment provider |
Every item, whatever its type, also gets a description, an owner, a status, and a date raised.
Why RAID Logs Go Stale
Most RAID logs are full at kickoff and empty of updates a month later. The cause is rarely the template. Items have no owner, nobody updates the status, and the log is not part of the weekly meeting. Fix all three: one owner per item, a review slot in every status meeting, and a reminder that asks owners to update their items first.
What's Inside
- Type column: Risk, Assumption, Issue, or Dependency, one board column each
- Description and owner: What it is and who tracks it
- Likelihood and impact: For risks only
- Status: Open, Watching, or Closed
- Due date: When the item needs an answer
- Weekly reminder: An automation asks each owner to update open items
How to Use It
Step 1: Copy the portal
Click Use Template to copy the project portal into your workspace.
Step 2: Set up the four types
Add a board column for each RAID type, and say in the log what your A and D stand for.
Step 3: Fill it at kickoff
Log the first risks, assumptions, issues, and dependencies at kickoff, each with an owner.
Step 4: Turn on the reminder
Set the weekly review reminder so owners update their items before the status meeting.
Step 5: Move and close items
Close items as they resolve. When a risk happens, move it to the Issue column.
Template vs App
This leaf opens the Project Portal, where the RAID log sits next to the plan. For risks alone, use the risk matrix template. For open problems only, use the issue log. To record decisions, try the project decision log generator.
Frequently Asked Questions
What does RAID stand for?
Risks, Assumptions, Issues, and Dependencies. Some teams use Actions for the A or Decisions for the D. Pick one and say which in the log.
What is the difference between a RAID log and a risk register?
A risk register tracks risks only. A RAID log adds assumptions, issues, and dependencies in the same place.
When do I set up a RAID log?
At project kickoff, from the plan and the charter. Add items through the project as they come up.
Who updates the RAID log?
The project manager owns it. Each item owner updates their own items before the weekly review.
How do I keep the RAID log alive after kickoff?
Review it in every status meeting, and use the weekly reminder so owners update items before the meeting.