Use this RAID log template to keep project risks, assumptions, issues, and dependencies visible before they slow delivery.
A RAID log template gives project managers and operations teams one practical place to track the conditions that can change a project: risks, assumptions, issues, and dependencies. Instead of spreading them across meeting notes, chat threads, status decks, and task tools, the RAID log keeps the control points visible.
The format is simple, but it only works when the team treats it as a live operating document. A good RAID log names the item, classifies it correctly, assigns an owner, records impact, captures the next action, and gets reviewed on a steady cadence.
What’s included
- A copyable RAID log template for business projects.
- Clear definitions for risks, assumptions, issues, and dependencies.
- Example entries that show how to write useful items.
- A weekly review workflow for keeping the log current.
- Common mistakes that make RAID logs become stale paperwork.
How to use this RAID log template
Start the RAID log during project planning, then keep it open during delivery. The Institute of Risk Management describes a RAID log as a way to present project-related information across categories such as risks, assumptions, issues, and decisions or dependencies. Teams may use slightly different acronym variants, but the operating purpose is the same: make uncertainty, blockers, and commitments easier to manage.
Use one row per item. Do not mix several concerns in one row. Review high-impact items every week, update owners and due dates, and close items only when the risk is no longer active, the issue is resolved, the assumption is validated, or the dependency is satisfied.
RAID log template
| Field | What to capture | Example |
|---|---|---|
| ID | A short reference number for discussion and reporting. | R-014 |
| Type | Risk, assumption, issue, or dependency. | Dependency |
| Description | The specific condition, event, blocker, or reliance. | Finance approval is required before vendor onboarding can begin. |
| Impact | What happens if this item is not managed. | Project kickoff may slip by five business days. |
| Likelihood | Low, medium, or high probability for risks and assumptions. | Medium |
| Priority | Low, medium, high, or critical based on impact and timing. | High |
| Owner | The person accountable for the next update or resolution. | Procurement lead |
| Next action | The concrete step that moves the item forward. | Confirm approval meeting date with finance. |
| Due date | The date for the next action or decision. | August 6 |
| Status | Open, watching, escalated, blocked, resolved, or closed. | Escalated |
What each RAID category means
Risks are possible future events that could affect the project. They have not happened yet. Write them as conditions that may occur, then define the mitigation or contingency.
Assumptions are beliefs the plan depends on. They may be true, but they are not proven. Treat assumptions as items to validate, not background notes to ignore.
Issues are active problems. A risk becomes an issue once it happens. Issues need owners, actions, due dates, and escalation paths because they are already affecting progress.
Dependencies are things the project needs from another person, team, vendor, system, or decision. Some teams use the D for decisions instead. If decisions are frequent in your project, keep a decision field or connect the RAID log to a separate decision log.
Asana’s RAID guide also notes that the acronym can vary, with assumptions sometimes replaced by actions and dependencies sometimes replaced by decisions. Pick the version your stakeholders understand and use it consistently.
Example RAID log entries
| Type | Example entry | Owner | Next action |
|---|---|---|---|
| Risk | Customer data export may arrive after the migration test window. | Data lead | Confirm export owner and fallback date. |
| Assumption | Support team will have two reviewers available for user acceptance testing. | Project manager | Validate staffing with support manager. |
| Issue | API credentials for the vendor sandbox are not working. | Engineering lead | Escalate to vendor technical contact. |
| Dependency | Legal must approve the data processing terms before production access. | Legal counsel | Review redlines and confirm decision date. |
Weekly RAID review workflow
- Update before the meeting. Owners refresh status, next action, and due dates before the project review.
- Review critical and high-priority items first. Do not walk every row if only a few rows need decisions.
- Separate risks from issues. Risks need prevention or contingency. Issues need resolution.
- Escalate blocked dependencies. If another team owns the blocker, name the decision-maker and due date.
- Close with evidence. Record why the item is closed so the log remains useful during retrospectives or audits.
ProjectManagement.com describes a RAID log as a simple way to track project events and maintain an audit trail. That audit trail matters because project memory is fragile. If the team cannot see when a risk was raised, who owned it, and what decision was made, the same problem will reappear in the next status meeting.
Common mistakes
- Using the log as a parking lot. A RAID log should drive action, not collect vague concerns.
- No owner. Every open item needs one accountable person, even if several teams contribute.
- Confusing risks and issues. Future events need mitigation; active problems need resolution.
- Tracking too many low-value items. If everything is high priority, the team will stop trusting the log.
- Skipping assumptions. Assumptions often become the hidden reason timelines slip.
Where Workhint fits
Workhint helps teams turn a RAID log template into a live project control workflow. Instead of keeping the log in a spreadsheet that only the project manager updates, a team can define item types, assign owners, route escalations, attach documents, track due dates, connect dependencies to approvals, and report status across projects.
That matters when the RAID log touches several teams. A risk may need executive review, a dependency may need procurement approval, an issue may need engineering action, and an assumption may need customer validation. Workhint helps connect those owners and steps so the template becomes a managed workflow rather than a static document.
FAQ
What does RAID stand for in project management?
RAID usually stands for risks, assumptions, issues, and dependencies. Some teams use actions instead of assumptions, or decisions instead of dependencies. The important point is to define the categories clearly and use them consistently.
What is the difference between a risk and an issue?
A risk is a potential future problem. An issue is an active problem that has already happened. Risks should have mitigation plans; issues should have resolution actions, owners, and due dates.
Who should own the RAID log?
The project manager usually owns the RAID log process, but each item should have its own business owner. The project manager keeps the review cadence; item owners move the actual work forward.
How often should a RAID log be updated?
Update it before every major project review and whenever a critical item changes. For active projects, a weekly update cadence usually keeps the log useful without turning it into daily administration.
Is a RAID log the same as a risk register?
No. A risk register focuses on project risks. A RAID log is broader because it also tracks assumptions, issues, and dependencies or decisions. PMI guidance on project logs emphasizes that these tools are useful when they help teams manage information without drowning in paperwork.
Conclusion
A useful RAID log template gives the project team one shared view of what could derail the work, what is already blocking progress, what assumptions need validation, and what dependencies need action. Keep it specific, assign owners, review it on a cadence, and use it to make decisions. The template is simple; the discipline around it is what protects delivery.
Leave a Reply