What Is a RAID Log? A Practical Guide for Project Managers

Every project has things that could go wrong, things that already went sideways, assumptions nobody wrote down, and decisions that are blocking progress. A RAID log is the single document that captures all four. It sounds simple because it is — and that simplicity is exactly why experienced project managers swear by it.

What Does RAID Stand For?

RAID is an acronym for four categories of project information:

• Risks — things that haven't happened yet but could negatively affect the project if they do
• Assumptions — facts you're treating as true even though you haven't confirmed them
• Issues — problems that have already occurred and need resolution
• Dependencies — tasks, decisions, or deliverables that rely on something (or someone) else

Some teams extend RAID to RAIDO or RAAID, adding Opportunities or Actions. Those variations are valid, but the core four categories cover 90% of what you need to track.

Why Project Managers Use a RAID Log

Without a structured log, risk tracking tends to happen in people's heads or buried in meeting notes. Assumptions go unspoken until they turn into problems. Dependencies get missed during planning. A RAID log forces those invisible pressures into the open.

The practical benefits are concrete:

• Fewer surprises. When risks are written down and owned, someone is responsible for monitoring them. Issues don't fester.
• Faster onboarding. A new stakeholder or team member can read the RAID log and immediately understand the project's pressure points.
• Better decision-making. When assumptions are explicit, decisions are made with better information. When they turn out to be wrong, you know what to revisit.
• Clear accountability. Every entry in a RAID log should have an owner and a status. That alone closes a lot of gaps.

How to Structure Each Entry

A RAID log doesn't need to be complicated. Each entry typically includes:

• Category — Risk, Assumption, Issue, or Dependency
• Description — What is it, in plain language
• Owner — Who is responsible for managing or resolving it
• Probability / Impact — For risks: how likely is it, and how bad would it be
• Status — Open, In Progress, Closed, or Accepted
• Due Date — When does it need to be resolved or reviewed
• Mitigation / Action — What's being done about it

Keep descriptions short and specific. "The client might not approve the design" is less useful than "Client design review is scheduled for March 22. If approval doesn't happen by March 25, development start slips by two weeks."

Common Mistakes to Avoid

RAID logs fail when teams treat them as a checkbox exercise rather than a live document. Watch out for these patterns:

• Logging and forgetting. A RAID log that isn't reviewed regularly is just a list of worries. Build a 10-minute RAID review into your weekly status meeting.
• Vague entries. "Technical risks" is not a risk. Be specific about what could happen, when, and to whom.
• No ownership. Every entry needs a named owner. "Team" is not an owner.
• Conflating risks and issues. A risk hasn't happened yet. An issue has. Keeping them separate helps you know which require monitoring versus active resolution.
• Letting the log grow unchecked. Close items when they're resolved. Archive them, but close them. A log with 80 open items is unusable.

How Often Should You Review a RAID Log?

For most projects, a weekly review is the right cadence. Spend a few minutes at the start or end of your status meeting:

• Review open items — has anything changed?
• Update statuses and add context
• Identify anything new that emerged during the week
• Escalate anything that's moved from low probability to high

For fast-moving projects or high-stakes phases (like go-live week), a daily review makes sense.

RAID Logs in Projenta

Building and maintaining a RAID log in a spreadsheet works fine until it doesn't — which usually happens when the project scales, the team grows, or you need to report upward on risk status.

Projenta's RAID Log feature gives you a structured, purpose-built log that lives alongside your tasks and schedule. Every entry has fields for category, owner, probability, impact, status, and mitigation. You can filter by category or owner, sort by due date, and see at a glance which items are open versus resolved.

Because the RAID log sits inside the same project workspace as your tasks and timeline, context is always one click away. Projenta's AI assistant can also help you draft risk descriptions or log new items from a chat message — useful when you're under pressure and need a second set of eyes.

The Bottom Line

A RAID log is one of the highest-leverage habits a project manager can build. It takes 20 minutes to set up and 10 minutes a week to maintain. In return, you get a project that's harder to surprise, easier to communicate about, and far less likely to get derailed by something everyone knew was coming but nobody wrote down.

If your team isn't running one yet, start this week. Pick a format, log your first five items, and make it a standing agenda item. The log will pay for itself the first time it surfaces a risk before it becomes a crisis.