What is a RAID log? How to use it in project management
A practical guide to RAID logs — what the acronym stands for, how each category works, and when to use a RAID log instead of a risk register. Includes a filled-in example with real project entries and a walkthrough of the ready-made RAID log template in Vaiz.
Every project has risks, assumptions, issues, and dependencies. Too often, those details end up scattered across people's heads, chat threads, and email chains, which means some of them eventually get lost.
A RAID log offers a simple way to bring all of that into one place and make it visible to the whole team. That makes day-to-day work easier and reduces the chance that something important gets missed.
People often ask what is RAID log, when to use it, and how to keep it simple. In this article, we explain what a RAID log is about, break down each part of the acronym, and show clear examples of how to use it without relying on complicated tools.
What does RAID stand for?
RAID stands for Risks, Assumptions, Issues, and Dependencies. Each part points to a different type of factor that can affect delivery. The raid log meaning becomes clearer when you separate these four elements and review them one by one. In day-to-day work, teams use this structure to make hidden project factors visible before they start affecting delivery.
Letter | Element | What it tracks |
|---|---|---|
R | Risks | Events that may affect the project, along with the likelihood that they will happen |
A | Assumptions | Things the plan depends on — if they turn out to be wrong, the plan may fall apart |
I | Issues | Problems that are already happening and need action |
D | Dependencies | Work that relies on another team, vendor, or decision |
A raid log works because each category needs its own response: a risk needs monitoring while an issue needs action. The raid log meaning becomes especially practical when the team sees that assumptions need validation and dependencies need follow-up with the person or team they rely on.
Example: a risk is "the vendor might delay delivery." An issue is "the vendor delayed delivery." The difference matters because one requires monitoring, while the other requires action.
That distinction helps the team react earlier and discuss the real problem instead of mixing different types of project factors together. Over time, that is what gives the raid log meaning in day-to-day project work.
Why teams use a RAID log
Teams usually start using a raid log when project risks are discussed in meetings, assumptions stay unwritten, issues are tracked in scattered places, and dependencies with outside teams live in someone's head until they cause a delay. Instead of keeping a separate assumptions log or issue tracker, teams bring those moving parts into one view and review them on a regular basis. When something goes wrong, nobody clearly remembers what was expected or which blocker had already been identified. In raid project management, that shared view becomes a practical layer for project tracking and dependency management inside a broader project management framework.
- One place for all four factors — a raid log keeps risks, assumptions, issues, and dependencies visible in one view.
- Shared context for everyone involved — the team and stakeholders can discuss the same facts instead of piecing them together from chats and memory.
- Regular review of project risks — risks and assumptions are checked early, instead of being rediscovered after something slips.
- Clearer dependency management — external blockers stop hiding in someone's head and become easier to track.
This is especially useful for projects that run longer than four weeks and for teams that rely on contractors or other departments. It also helps in any setup where "we assumed that was covered" keeps coming back.
RAID log example
Below is a raid log example based on a real project scenario: a product launch run by a small team. It can also work as a raid log sample, because it shows how risks, assumptions, issues, and dependencies are usually recorded in day-to-day project work, with two items for each category.
Category | Item | Owner | Status |
|---|---|---|---|
Risk | Payment provider API may not support our use case without extra integration work | Tech Lead | Monitoring |
Risk | Launch delayed if legal review takes more than 2 weeks | PM | Open |
Assumption | Users will be comfortable with email-only onboarding (no phone) | Product | Unverified |
Assumption | Support can handle double ticket volume during launch week | Ops | Confirmed |
Issue | Design handoff is delayed by 3 days, so development started without final assets | Design Lead | In Progress |
Issue | Staging environment has been unavailable since Monday | DevOps | Escalated |
Dependency | Analytics dashboard requires data team to set up event tracking first | Data Team | Waiting |
Dependency | Go-live approval needed from legal before any public announcement | Legal | Pending |
Read this raid log example row by row and focus on two things: what needs monitoring, and what needs action now. In practice, the team can review the open items once a week, update owners or statuses, and use the table to decide what needs follow-up first.
RAID log vs risk register: what's the difference?
Many teams already know the term risk register, so this is where confusion usually starts. When people compare raid log vs risk register, the main difference is scope: a risk register tracks only risks, usually with probability and impact, plus a mitigation plan, while a RAID log also covers assumptions and current issues, plus dependencies.
When to use each one:
- Use a risk register if your team has a formal risk management process in place.
- Use a RAID log if you need a practical tracker for a smaller team that wants clear visibility without heavy documentation.
For most teams with up to 50 people, raid logs are usually enough. They give a wider view of delivery risk and current blockers, while staying easier to maintain in weekly project work.
How to set up a RAID log in Vaiz
Vaiz has a ready-made RAID log template that covers all four categories out of the box. You can use it to start tracking risks and blockers without building a board from scratch, or keep it next to your main project board if your delivery work already lives there.
What the template includes
- The template comes with five lifecycle columns: Open, In Progress, Monitoring, Mitigated, and Closed.
- It also includes four task types: Risk, Assumption, Issue, and Dependency.
- In addition, it has nine custom fields: Probability, Impact, Owner, Mitigation Plan, Target Date, Related Tasks, Category, Source, and Trigger. The Probability and Impact fields help the team decide which items need attention first, without keeping a separate spreadsheet.
How to use it
If you are wondering how to create a RAID log, open the template and add each item as a Risk, Assumption, Issue, or Dependency. Then fill in Probability and Impact to set priorities. After that, assign an Owner and add a Mitigation Plan where action is needed. As the project moves forward, update the entry and move it through the lifecycle columns.
The Related Tasks field connects each RAID item to the work it affects. That matters in raid project management, because the team can see both the blocker and the task created to respond to it. It also makes risk mitigation easier to track during weekly reviews or sprint check-ins.
This setup is also a good fit for a simple RAID log for startups, where one small team needs a practical work management without extra documentation.
Conclusion
A RAID log is a simple tool. It is really just four lists kept in one place, so the team can see what may affect delivery. Start with Issues and Dependencies first, because they usually need attention sooner. Add Risks and Assumptions as the project grows.
The key part is regular review. RAID logs that nobody checks once a week quickly turn into an archive.