Guide
RAID Log: What It Is and How to Use One
A RAID log is a simple way to track the issues that can affect delivery before they become bigger problems.
It helps teams keep risks, assumptions, issues and dependencies in one place so action and ownership are clear.
What is a RAID log?
RAID stands for:
- Risks
- Assumptions
- Issues
- Dependencies
A RAID log gives project teams a single place to record items that may block progress, create uncertainty or require escalation.
Risks
A risk is something that could happen and negatively affect the project.
Example:
- A third-party API may not be ready on time.
Assumptions
An assumption is something the team currently believes to be true even if it has not been fully verified.
Example:
- The business team will be available for user acceptance testing next week.
Issues
An issue is a problem that already exists and needs attention.
Example:
- The test environment is unavailable and the release is blocked.
Dependencies
A dependency is something your team needs before work can be completed.
Example:
- Another team must deliver an API before integration can be completed.
A simple RAID log example
| Type | Item | Owner | Priority | Status | Action |
|---|---|---|---|---|---|
| Risk | API delivery may be delayed | Alex | High | Open | Confirm delivery date |
| Assumption | UAT team available next week | Sam | Medium | Open | Confirm availability |
| Issue | Test environment unavailable | Priya | High | In Progress | Escalate to platform team |
| Dependency | Payment API required | Daniel | High | At Risk | Follow up with vendor |
Why use a RAID log?
A RAID log creates visibility. It helps teams answer questions like:
- What could affect delivery?
- What problems need attention?
- Who owns each item?
- Which dependencies are at risk?
- What actions are outstanding?
- What needs escalation?
Without a structured log, these items can get lost in meeting notes, chat threads and personal memory.
How to keep it useful
A RAID log is only valuable if it is kept current. The most useful ones have a clear owner and a next step.
- Type
- Title
- Description
- Owner
- Status
- Priority
- Due date
- Mitigation or action
- Date identified
- Notes or updates
A weekly review is often enough for teams that want a simple but effective structure.
A simple review process
- 1
Review high-priority items.
- 2
Check overdue actions.
- 3
Review upcoming dependencies.
- 4
Close resolved items.
- 5
Add newly identified risks or issues.
- 6
Escalate items requiring stakeholder attention.