RAID Log vs. Risk Register: What’s the Difference and Which Do You Need?

A RAID log and a risk register are not the same tool, even though teams often use the names interchangeably. A RAID log tracks four categories of project information risks, assumptions, issues, and decisions in one document. A risk register tracks only risk, in far greater analytical depth. Confusing the two usually means one of them gets skipped entirely, leaving a gap in either day-to-day tracking or formal risk analysis. The rest of this guide breaks down both tools, where they overlap, and how to decide which one a given project actually needs.

What Is a RAID Log?

A RAID log is a project management tool that tracks Risks, Assumptions (or Actions), Issues, and Decisions (or Dependencies) in a single document. It's created during planning and updated continuously through execution.

The RAID log definition breaks down letter by letter:

• Risks: potential problems that haven't happened yet but could affect the project if they do — for example, a key vendor might miss a delivery deadline.
• Assumptions or Actions: things the team treats as true without full confirmation, such as assuming a server can handle extra load, or the specific tasks needed to keep the project moving. Teams pick whichever fits their project, or track both.
• Issues: problems that have already happened and need a response now, such as a bug that broke checkout. The difference between a risk and an issue is timing — a risk might happen, an issue already has.
• Decisions or Dependencies: the choices made along the way and who made them, such as picking one vendor over another, or tasks that can't move forward until another task finishes.

What is a RAID log in project management used for, beyond the acronym? It works as a lightweight audit trail:

• One central place for risk information instead of a separate spreadsheet
• A record of decisions instead of buried meeting notes, so the reasoning behind a choice isn't lost when someone changes teams
• A log of issues instead of scattered email threads, making it easy to spot repeat problems
• A clear owner attached to every entry, so anyone can see who's responsible without having to ask around

Most teams build a project RAID log at kickoff, then review and update it through status meetings and the project post-mortem.

RAID Log Example

Here's a single risk entry from a software project:

• ID: R-014
• Category: Risk
• Description: The third-party payment gateway has a documented history of outages during peak traffic, which could disrupt checkout during launch week.
• Owner: Maria Chen, Engineering Lead
• Priority: High
• Status: Open
• Action plan: Build a fallback payment path and load-test the gateway under peak conditions before launch.

The format stays consistent across categories. Here's how an issue entry on the same project might look once that risk actually materializes:

• ID: I-009
• Category: Issue
• Description: The payment gateway went down for 40 minutes during a traffic spike, blocking checkout for an estimated 300 users.
• Owner: Maria Chen, Engineering Lead
• Priority: High
• Status: In Progress
• Action plan: Switch to the fallback payment path immediately and notify affected customers; root-cause the outage with the vendor.

A decision entry would follow the same shape but swap the action plan for a rationale: what was decided, who decided it, and why.

What Is a Risk Register?

A risk register is a project management tool focused entirely on risk. It lists every identified threat to a project, how likely each one is to occur, how severe the impact would be, and the planned response. Unlike a RAID log, it doesn't try to cover assumptions, issues, or decisions it exists purely to give risk the depth of analysis a broader log can't provide.

A typical entry includes:

• Risk ID and description — a short name and clear explanation of the threat
• Risk category (technical, financial, schedule, resource, external) — helps spot patterns across a project
• Probability rating (low/medium/high, or a numeric scale) — how likely the risk is to occur
• Impact rating — how severe the consequences would be if it did
• Risk score, usually probability multiplied by impact, used to rank which risks need attention first
• Response strategy: avoid, mitigate, transfer, or accept
• Owner and status (open, resolved, or already turned into an issue)

Risk registers are most common on projects that follow formal risk management frameworks, such as those built around PMI's PMBOK guide. Because the register only covers one category, it can go deeper on each entry than a RAID log usually does. Some teams also track risk triggers early-warning signs a risk is about to become an issue as an additional field.

RAID Log vs. Risk Register: Key Differences

The short version:

• A RAID log trades depth for breadth — it covers more ground, but less detail per item.
• A risk register trades breadth for depth — it covers only risk, but covers it thoroughly enough to support formal risk management.
• A RAID log is read by the whole project team; a risk register is often read more closely by stakeholders, auditors, or a risk committee who want the underlying numbers, not just a summary.

Where the Two Overlap

The Risk section of a RAID log is, functionally, a small risk register embedded inside a larger document both ask the same basic question, just at different levels of detail. That overlap is why the two get confused.

• If a team already maintains a full risk register, there's no need to duplicate the analysis inside the RAID log's Risk section — just reference it or summarize the top items there.
• Small projects can usually track a handful of risks inside the RAID log without issue.
• Larger projects tend to outgrow that setup once risks need probability scoring and documented response strategies across dozens of entries, at which point that section graduates into its own risk register.
• Even after that split, the two stay connected: a risk that gets fully scored and analyzed in the register usually still gets a one-line summary back in the RAID log, so nothing important only lives in one place.

When to Use a RAID Log vs. a Risk Register

Use a RAID log when:

• The project needs lightweight, all-in-one tracking
• Risk isn't complex enough to need separate quantitative scoring
• The project is small to mid-sized, or an internal initiative
• One person is managing the project solo and wants a single document instead of two
• Example: an internal marketing campaign or a small software feature rollout usually only needs a RAID log.

Use a risk register when:

• Risk itself is the primary concern and needs structured, ongoing analysis
• The project is large, regulated, or high-stakes — construction, infrastructure, government contracts, clinical trials
• Stakeholders expect documented probability and impact scoring, not just a priority label
• A dedicated risk manager or risk committee owns risk separately from the rest of the project
• Example: a hospital construction project typically needs a full risk register, with a RAID log running alongside it for everything else.

Using Both Together on a Project RAID Log

Most experienced project managers don't pick one over the other; they run both, because each one covers a gap the other leaves open.

• The risk register holds the detailed, scored analysis for every identified risk.
• The RAID log's Risk section holds a condensed view, usually just the highest-priority items, with a reference back to the full register.
• Status meetings stay fast: the project manager points to the RAID log summary and only opens the full register when someone asks for more detail.
• The complete register stays available for audits and retrospectives, while the RAID log remains the day-to-day source of truth for risks, issues, decisions, and dependencies.
• Many project management tools support this setup natively, letting a risk register entry link directly to its summary line in the RAID log, so updating one keeps the other accurate.