Most project problems are knowable before they happen. Risks can be identified in advance. Assumptions can be made explicit and tested. Issues that emerge have usually been simmering in some form before they become emergencies. A RAID log is a structured way to surface, document, and track all of these things before they derail a project.

RAID stands for Risks, Assumptions, Issues, and Dependencies. A RAID log is a single document that captures all four categories in one place, giving project managers and teams a shared view of what might go wrong, what has gone wrong, what the project is betting on, and what it depends on to succeed.

This guide explains what a RAID log is, what goes in each section, when to use one, and how to keep it useful over a project's life cycle.

Key Takeaways

• A RAID log is a project management tool that consolidates Risks, Assumptions, Issues, and Dependencies into a single living document.

• The value of a RAID log isn't in creating it. It's in reviewing it regularly. A RAID log that gets updated and discussed weekly keeps projects proactive. One that gets created on day one and never opened again is just a formality.

• RAID logs work best alongside other project management artifacts, not as a replacement for them. They supplement a project plan, not substitute for one.

What Is a RAID Log?

A RAID log is a structured document used in project management to track four categories of project intelligence: Risks, Assumptions, Issues, and Dependencies. Some variations use slightly different expansions (Actions instead of Assumptions, Decisions instead of Dependencies), but the core purpose stays the same: give teams a single place to capture and monitor the factors most likely to affect project outcomes.

The format is typically a spreadsheet or table with one section or tab per RAID category. Each entry includes a description, owner, status, priority, and any planned response or mitigation action. The log gets reviewed at regular intervals and updated as the project evolves.

RAID logs are common in project management for large or complex initiatives but they're equally useful for smaller projects. Any work with multiple stakeholders, moving parts, or external dependencies benefits from having its unknowns made explicit.

Breaking Down Each RAID Category

R: Risks

Risks are potential future events that could negatively affect the project if they occur. They haven't happened yet. The key word is "potential." A risk that materializes stops being a risk and becomes an issue.

Each risk entry in a RAID log typically includes a description of what might happen, the likelihood it will occur (low/medium/high or a percentage), the potential impact if it does occur, and the planned mitigation or contingency response. Teams often also track who owns each risk.

Common project risks include: key personnel leaving, vendor delays, scope expansion (see our guide to scope creep), technology changes, budget constraints, and regulatory or compliance shifts. The purpose isn't to predict every possible problem. It's to identify the most plausible and highest-impact ones, so the team can monitor them and respond quickly if conditions change.

A: Assumptions

Assumptions are things the project is treating as true without confirmed proof. Every project runs on assumptions. The problem is that unexamined assumptions become invisible risks. When an assumption turns out to be wrong, it typically surprises the team because no one was tracking it.

Documenting assumptions makes them visible and testable. Common project assumptions include: the budget will remain stable, a key stakeholder will be available throughout the project, a certain technology will work as expected, regulatory approval will be granted by a certain date, or the team's velocity will match the plan. Each one should be listed with its status (confirmed or unconfirmed), the date it was last reviewed, and what would happen to the project if the assumption proved false.

I: Issues

Issues are problems that have already occurred and need resolution. They're the materialized version of risks. An issue log entry includes a description of the problem, when it was identified, its current status, who owns the resolution, and the target resolution date.

Issue tracking is where many teams substitute ad hoc Slack messages and verbal updates for a structured record. That works until the project is audited, a new team member joins, or a pattern of recurring issues needs to be surfaced. A RAID log provides the paper trail. It also forces clarity on ownership: who is actually responsible for resolving this, and by when?

D: Dependencies

Dependencies are things the project needs from outside itself to succeed. Another team's deliverable. An external vendor's output. A regulatory approval. A budget release from finance. Dependencies are often the most underestimated category in a RAID log because they represent things outside the team's direct control.

Each dependency entry should describe what is needed, who or what it depends on, the expected delivery date, and what happens to the project if the dependency is late or unavailable. The project manager's job is to monitor dependencies actively and escalate early when they're at risk. Waiting to discover a dependency failure at a project milestone is almost always too late.

When to Use a RAID Log

RAID logs are most valuable for projects that have multiple stakeholders, significant complexity, or high stakes for failure. They're standard practice in large enterprise projects, government initiatives, infrastructure work, and multi-team software programs.

They're equally useful for smaller projects when the team is new, the stakeholders are numerous, or the project has explicit dependencies on other teams or external parties. If the consequences of a project going wrong are serious, a RAID log is worth creating regardless of project size.

RAID logs are less necessary for small, self-contained work with a single owner and no external dependencies. Not every project needs one. The ones that benefit most are those where complexity creates blind spots that need to be actively managed.

How to Create a RAID Log

A RAID log can be a spreadsheet, a document, or a dedicated section within a project management tool. The format matters less than the habit of using it. A simple spreadsheet with four tabs (one per RAID category) with consistent columns works fine for most projects.

Standard columns for each category:

• ID: a reference number for tracking and discussion

• Description: a plain-language summary of the risk, assumption, issue, or dependency

• Owner: the person responsible for monitoring or resolving it

• Priority/Severity: Low, Medium, High, or Critical

• Status: Open, In Progress, Resolved, or Closed

• Response/Notes: what the team is doing about it, or why it's being monitored

• Date Identified / Target Date: when it was logged and when resolution is expected

Create the initial RAID log at project kickoff. Run a dedicated session with key stakeholders to surface risks, document existing assumptions, identify known issues, and map dependencies. Then establish a regular review cadence to keep it current.

RAID Log Best Practices

Review it regularly, not just at kickoff. A RAID log created at the start of a project and never revisited is almost worthless. Schedule a brief RAID review at each project status meeting. Even five minutes of "any new risks, any assumption changes, any dependency delays" keeps the log alive and the team alert.

Assign clear owners to every entry. A risk or issue without an owner is just a worry. Every item in the RAID log should have one person responsible for monitoring it and driving resolution. Shared ownership usually means no one is actually watching it.

Escalate risks before they become issues. The whole point of a risk register is to give you lead time. If a risk's probability is rising or its potential impact is increasing, escalate it to the appropriate stakeholder before it materializes. Don't wait for the weekly status call if the situation is moving fast.

Keep entries concise but specific. "Technical risk" is not a useful RAID entry. "Risk that the payment API integration will require more custom work than estimated, potentially adding two weeks to the timeline" is useful. Specificity makes it actionable.

Track action items from RAID reviews. RAID log reviews generate tasks: someone needs to validate an assumption, chase a dependency, or implement a risk mitigation. Those action items need to land somewhere and get done. Using a dedicated task manager to capture follow-up actions from RAID reviews keeps them from falling through the cracks. Tools like Lifestack that schedule tasks around your actual energy and availability make it easier to ensure follow-up work on project risks actually gets prioritized rather than buried under day-to-day activity. For teams using AI-powered work tools, this kind of automatic prioritization keeps project health work from getting crowded out by reactive tasks.

Benefits and Limitations of RAID Logs

The benefits are real: RAID logs make project intelligence explicit and shared. They reduce the chance of known risks surprising the team. They create a record of project decisions and assumptions that's invaluable during audits or post-mortems. They give new team members context that would otherwise take weeks of conversations to absorb. And they force a discipline of proactive rather than reactive project management.

The limitations are also real. A RAID log requires ongoing maintenance to stay accurate. Outdated entries are worse than no entries at all. RAID logs can become a bureaucratic exercise if teams treat them as compliance artifacts rather than working documents. And they don't replace judgment: documenting a risk doesn't manage it. The log is the input, not the output.

Used well, a RAID log is one of the simplest and most effective tools for maintaining project clarity. Combined with strong project management habits and regular stakeholder communication, it keeps complex projects navigable.

Frequently Asked Questions

What does RAID stand for in project management?

RAID stands for Risks, Assumptions, Issues, and Dependencies. Some practitioners use variations: Actions instead of Assumptions, or Decisions instead of Dependencies, making it RAIDD or other combinations. The four-category structure remains consistent across variations. The goal is to document the main categories of uncertainty and complexity that affect project outcomes in a single, shared reference document.

What is the difference between a RAID log and a risk register?

A risk register tracks only risks. A RAID log is broader: it includes risks but also tracks assumptions, active issues, and dependencies. Think of a risk register as a subset of a RAID log. For simple projects, a risk register may be sufficient. For complex projects with multiple external dependencies and numerous stakeholders, the full RAID log gives teams a more complete picture of project health.

How often should a RAID log be updated?

At minimum, a RAID log should be reviewed at each project status meeting, which is typically weekly for active projects. Items should be updated whenever their status changes, including when risks escalate, assumptions are confirmed or invalidated, issues are resolved, or dependency timelines shift. For high-velocity or high-stakes projects, daily reviews of critical items may be warranted. The log should never go more than two weeks without a full review during active project execution.

Who is responsible for maintaining the RAID log?

The project manager is typically the owner and primary maintainer of the RAID log. However, individual entries should have their own owners: the person responsible for monitoring a specific risk, resolving a specific issue, or chasing a specific dependency. The project manager facilitates the RAID review sessions and ensures the log stays current. Item owners are responsible for providing status updates and escalating when their assigned items require attention.

What is the difference between a risk and an issue in a RAID log?

A risk is a potential future problem. An issue is a problem that has already occurred. When a risk materializes, it gets reclassified as an issue. The distinction matters for how you respond: risks call for prevention and mitigation planning (what can we do to reduce the probability or impact?). Issues call for resolution (what needs to happen to fix this now?). Keeping them separate in the RAID log ensures the team's responses are calibrated to the actual state of each item.

Can a RAID log be used for agile projects?

Yes. RAID logs are sometimes seen as a waterfall or traditional project management tool, but they translate well to agile environments. In agile contexts, the RAID log is typically lighter and reviewed in sprint ceremonies rather than dedicated sessions. Risks and dependencies map naturally onto sprint planning (what blockers might affect this sprint?). Issues map onto impediment boards. Assumptions often surface during backlog refinement. The key is adapting the review cadence to the sprint rhythm rather than running RAID reviews as separate ceremonies that compete with agile rituals.