RAID Log
Also known as: RAID Analysis, Risks Actions Issues Dependencies Log
A project management tool that tracks four critical categories — Risks, Assumptions, Issues, and Dependencies — to ensure nothing falls through the cracks during project delivery.
Quick Reference
Memory Aid
R = what could go wrong. A = what we're assuming. I = what's already wrong. D = what we depend on.
TL;DR
RAID Log tracks four categories: Risks (uncertain events), Assumptions (unvalidated beliefs), Issues (current problems), and Dependencies (external reliances). Set up at project kickoff, review weekly, assign owners, and keep it simple.
What Is RAID Log?
A simple log that tracks four things in any project: what could go wrong (Risks), what we're assuming is true (Assumptions), what's already wrong (Issues), and what we depend on others for (Dependencies).
On Anticipating Problems
The time to repair the roof is when the sun is shining.
— John F. Kennedy, State of the Union Address (1962)
The RAID Log is one of the most practical and widely-used project management tools. It provides a structured way to capture and monitor four categories: Risks (uncertain events that could impact the project), Assumptions (things believed to be true but not yet proven), Issues (problems that have already occurred and need resolution), and Dependencies (external factors or deliverables the project relies on). Each item is logged with an owner, status, priority, and action plan. Regular RAID reviews ensure proactive project management.
RAID Categories at a Glance
Comparison of the four RAID categories showing what they track, when they matter, and how they relate.
Origin & Context
Emerged from project management practice as a practical tool for tracking the most common categories of project concerns.
Core Components
Risks
Uncertain events that could positively or negatively impact the project if they occur.
Example
Risk: Key vendor may not deliver API integration on time. Mitigation: Identify backup vendor and begin parallel evaluation.
Assumptions
Factors believed to be true for planning purposes but not yet confirmed.
Example
Assumption: The existing database schema can support the new feature without migration. Validation: Technical spike in Sprint 2.
Issues
Problems that have already materialized and require resolution.
Example
Issue: Production server ran out of disk space causing 2-hour outage. Action: Expand storage and implement monitoring alerts.
Dependencies
External deliverables, decisions, or conditions the project relies on.
Example
Dependency: Legal team approval of terms of service changes needed before launch. Owner: Legal Director. Due: March 15.
Did You Know?
Research by the Project Management Institute (PMI) found that projects using formal risk tracking tools like RAID logs are 2.5 times more likely to meet their original goals and business intent than those relying on informal risk management.
When to Use RAID Log
Project kickoff
Problem it solves: Projects start without identifying potential problems.
Real-World Application
A project manager creates a RAID log during the kickoff meeting, capturing 15 risks, 8 assumptions, 3 known issues, and 12 dependencies.
Weekly project status meetings
Problem it solves: Status meetings lack structure and miss important concerns.
Real-World Application
Every Monday, the project team reviews the RAID log: updating existing items, adding new ones, and escalating items that need attention.
Stakeholder communication
Problem it solves: Stakeholders are surprised by problems that were foreseeable.
Real-World Application
The project sponsor receives a weekly RAID summary highlighting the top 5 items requiring attention or decisions.
Assumptions Are Hidden Risks
Every unvalidated assumption is a risk in disguise. Make assumptions explicit and validate them as early as possible. If an assumption proves false, it becomes an issue.
How to Apply RAID Log: Step by Step
Before You Start
- →A defined project or initiative
- →A team or stakeholder group to contribute
- →A simple tracking tool (spreadsheet or project tool)
Set up the RAID log
Create a structured log with sections for Risks, Assumptions, Issues, and Dependencies.
Tips
- ✓Use a shared spreadsheet or project tool
- ✓Include columns: ID, Category, Description, Owner, Priority, Status, Action, Due Date
Common Mistakes
- ✗Making the template too complex — keep it simple
Populate during project kickoff
In the kickoff meeting, brainstorm items for all four categories with the team.
Tips
- ✓Walk through the project plan and ask 'What could go wrong?' at each stage
- ✓Explicitly ask about assumptions
Common Mistakes
- ✗Only populating risks and ignoring assumptions and dependencies
Assign ownership and actions
Every RAID item needs an owner and an action or mitigation plan.
Tips
- ✓Owners must be specific individuals, not teams
- ✓Set due dates for actions
Common Mistakes
- ✗Logging items without assigning clear ownership
Review regularly
Review the RAID log weekly (or more frequently for critical projects).
Tips
- ✓Make it a standing agenda item
- ✓Close resolved items and add new ones
Common Mistakes
- ✗Creating the log at kickoff and never updating it
Value & Outcomes
Primary Benefit
Provides a simple, comprehensive system for tracking project risks, assumptions, issues, and dependencies in one place.
Additional Benefits
- ✓Easy to set up and maintain
- ✓Improves project team communication
- ✓Enables proactive rather than reactive project management
What You'll Learn
- →How to systematically identify project risks and dependencies
- →How to make implicit assumptions explicit
- →How to maintain project awareness throughout delivery
Typical Outcomes
Best Practices
📋 Preparation
- •Set up the log before the kickoff meeting
- •Brief the team on the four RAID categories
🚀 Execution
- •Review weekly — this is the single most important practice
- •Prioritize items: not all risks are equal
- •Convert assumptions to risks when they become uncertain
🔄 Follow-Up
- •Archive closed items for lessons learned
- •Include RAID insights in project retrospectives
💎 Pro Tips
- •Add a 'trigger date' for risks — when should you activate the mitigation plan?
- •Use color coding for priority: Red (critical), Amber (important), Green (low/managed)
A RAID log is only valuable if it's reviewed regularly. An unreviewed RAID log is worse than none — it creates false confidence that risks are being managed.
NHS Digital Health Platform Launch
When NHS Digital launched a nationwide electronic health records platform, the project team maintained a rigorous RAID log that grew to over 200 items. A critical dependency on third-party data migration was flagged early in the log. When the data migration vendor fell behind schedule, the pre-planned mitigation (a parallel in-house migration team) was activated immediately, keeping the overall program on track and avoiding a six-month delay.
Limitations & Pitfalls
Can become unwieldy if every minor concern is logged
Mitigation: Set thresholds for what gets logged; focus on items that could genuinely impact the project
Doesn't provide analytical rigor for risk assessment
Mitigation: Combine with formal risk assessment methods (likelihood × impact scoring) for critical projects
Apply RAID Log with Stratrix
Turn this framework into a professional strategy deck in under a minute. Stratrix applies RAID Log automatically to your business context.
Try Stratrix Free