What Is a RAID Log? (Risks, Assumptions, Issues, Decisions)

Project managers keep several documents to stay in control — a risk register, an issue log, a decision log — and the more documents there are, the more of them fall out of date. A RAID log solves that by putting the four things that most often derail a project into one table: risks, assumptions, issues, and decisions. It is a simple format with a powerful effect: at a glance, anyone can see what might go wrong, what the team is taking for granted, what has already gone wrong, and how the team decided to respond. This article defines what a RAID log is, what each of the four categories means, the columns it needs, a filled-in example, when and by whom it should be used, and how it relates to the risk register, issue log, and decision log.

Quick Answer: What Is a RAID Log?

A RAID log is a project management document that records risks, assumptions, issues, and decisions — the four categories that most affect whether a project stays on track — in a single table. Each row captures one item, its impact on the project, the response or action planned, and the owner and status. The nuance: RAID is a working tool, not a static checklist. It is built during planning, updated continuously through execution, reviewed in regular meetings, and archived at the end of the project as a reference for the next one.

What Does RAID Stand For?

RAID is an acronym, and the letters vary slightly across teams. The most common version is:

Some teams write the A as Actions (the action items the project needs to keep moving) and the D as Dependencies (external conditions the project depends on). A closely related variant you will see in some references is CAIR — constraints, assumptions, issues, and risks. The exact letters matter less than the discipline: putting the four or five things that threaten a project into one place and keeping them current.

What Is the Difference Between Risks, Assumptions, Issues, and Decisions?

The power of a RAID log comes from using each category correctly. Here is how to tell them apart:

• Risks. A risk is something unexpected that could happen and affect the project, positively or negatively. Risks are managed before they happen: you estimate their probability and impact, then plan a response. When a risk actually occurs, it stops being a risk and becomes an issue.
• Assumptions. An assumption is something the team takes to be true for the plan to work. It is a condition you are counting on — a supplier’s price, a vendor’s availability, a regulatory timeline. Assumptions must be validated and monitored; if an assumption proves false, it can turn into an issue or a risk.
• Issues. An issue is a problem that is already present. It may have been identified at the start of the project or surfaced during execution. Issues are not planned around — they are assigned, resolved, and verified.
• Decisions. This is where the team records the choices it has made: how it decided to act, who decided, when, and why. The decisions column collects the project’s thought process and keeps it available for future projects.

A useful rule of thumb: risks are “might happen”, issues are “are happening”, assumptions are “we are counting on this”, and decisions are “here is what we chose and why”. Getting one of these wrong — treating a risk as an issue, for example — puts the row in the wrong management flow and the response is wrong too.

What Is a RAID Log Used For?

A RAID log is used to keep the factors that threaten a project visible, owned, and current. Concretely, it does four jobs:

1. Gives a single source of truth. Instead of a risk register here, an issue log there, and decisions in someone’s memory, the team has one place to look for project health.
2. Forces proactive thinking. Building the log during planning makes the team name its risks and assumptions before they bite, rather than discovering them mid-project.
3. Supports meetings and reviews. A RAID log is a ready-made agenda for a status review: walk each category, update statuses, and engage stakeholders in the decisions that need to be made.
4. Becomes a reference for future projects. Archived at the end of a project, a RAID log is historical data — which assumptions held, which risks materialized, how issues were resolved — that informs planning on the next similar project.

In short, a RAID log is a control tool. It is more comprehensive than a risk register because it captures assumptions, issues, and decisions alongside risks — and in one place, so nothing gets lost between documents.

What Columns Should a RAID Log Have?

A RAID log is a table, and each row is one item from one of the four categories. A practical column set:

This is the core. Depending on your team you may add probability, due date, notes, or a link to the related risk register or issue log row. Keep the columns that get used — a RAID log bloated with unused fields is abandoned faster than a lean one.

What Does a Filled-In RAID Log Look Like?

Here is a realistic slice from a construction project’s RAID log. The project team identified risks and assumptions during planning, and some of those risks have since become issues — which is exactly how a live RAID log behaves.

Note two things. First, RD-04 is the risk RD-01 turned into an issue — the log shows the chain, and the response changed from “monitor” to “resolve”. Second, the decisions row (RD-05) records the response with its owner and status. The whole project’s health fits on one screen, and a weekly review can walk the table top to bottom in minutes.

Who Should Use a RAID Log and When?

The RAID log is usually maintained by the project manager, but it is a team tool. The realistic users: project managers oversee risks, assumptions, issues, and dependencies and use the log to distribute work and justify choices; business analysts use it to understand requirements and identify risks and issues; risk managers use it to prioritize and mitigate risks; and team leads and operations managers use it to keep their team’s tasks and issues visible to the whole group.

When it is used follows the project life cycle:

• Planning: the RAID log is first populated during planning, when risks and assumptions are identified — often with the help of a risk breakdown structure and a risk matrix.
• Execution: it is updated continuously. Risks that materialize become issues; assumptions are validated and checked off or escalated; decisions are logged as they are made.
• Reviews: it is walked in periodic reviews, where stakeholders engage on status and pending decisions.
• Close: it is archived at the end of the project and used as historical input for planning similar future projects.

A RAID log is most useful on complex projects with multiple variables — but it works just as well on small ones. In agile teams, a RAID log is commonly kept alongside sprint and backlog documents, especially to record action items and decisions across larger teams. The acronym should not scare anyone off: it is a single table.

How Does a RAID Log Relate to the Risk Register, Issue Log, and Decision Log?

The RAID log overlaps with three other project documents, and the relationship is worth being precise about:

There are two schools of practice. Some teams keep a RAID log as their only document — a single table with a column for each category. Others run a full risk register and issue log for depth and use the RAID log as the summary view that links to them. Both are valid. The choice depends on project size: small and medium projects do fine with a standalone RAID log; large projects usually need the depth of separate registers with a RAID summary on top. The important thing is that nothing lives in only one place by accident — the risk register, issue log, and decision log should never diverge from the RAID log silently.

Where Should a RAID Log Live? (Real Tools With Trade-Offs)

A RAID log works in anything that can hold a table, but the tools have real differences.

Excel or Google Sheets

The most common home for a RAID log — a simple spreadsheet with a category filter.

• Pros: free, familiar, instantly shareable, easy to filter by category and owner, no training.
• Cons: no automatic reminders for review dates, no workflow, no link from a risk to the issue it became unless you paste references, and the log can drift from live project status.
• Trade-off: fine for a single project with a small team; weak when the log needs to stay connected to real tasks and updates.

Smartsheet or monday.com

Work platforms with a table or board structure that can host a RAID log with automations.

• Pros: RAID rows can connect to tasks, owners, and reminders; dashboards show issue and risk counts by status; updates are visible to the whole team.
• Cons: more structure than a spreadsheet; the log only works if the team opens the platform daily; free plans cap users and features.
• Trade-off: worth it when RAID items must be tracked alongside execution and review dates need enforcement.

Notion or Confluence

Wikis where the RAID log lives as a page or database next to project documentation.

• Pros: RAID rows link to meeting notes, decisions, and full registers; searchable; great for documentation-heavy teams.
• Cons: no real workflow or reminders; the log depends on the team’s discipline to update it; can drift from actual project status.
• Trade-off: strong where documentation is the team’s habit; weaker where execution happens elsewhere.

Doitify

An all-in-one platform where risks and constraints, tasks, meeting notes, and project documents live together, so RAID items can be logged with owners, due dates, and statuses and linked to the tasks they affect.

• Pros: the RAID log stays connected to the work — a risk that becomes an issue can be escalated into a tracked task with an owner and deadline; review dates and reminders are part of the task system.
• Cons: a full platform rather than a standalone file — more than a very small one-off project needs.
• Trade-off: the right fit when you want RAID items to be living, owned, connected rows in the same workspace where the team actually runs the project. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. For a short project with a small team, a spreadsheet RAID log is genuinely enough — when risks and issues must be linked to tasks and chased on a schedule, a project management platform keeps the RAID log honest.

What Are the Real Scenarios Where a RAID Log Pays Off?

Scenario 1: The manufacturing launch that avoided a materials surprise

A mid-size manufacturer planned a new product launch with a six-month horizon. During planning, the project manager filled the RAID log and logged a risk that a key material’s price could rise after the contract was signed. Because the risk was written down with an owner, the team secured a backup supplier early. When the price increase hit in month three, the risk became an issue — but the response was already in place. The project absorbed the change with a 2% budget adjustment instead of the 8% overrun the original estimate suggested, and the launch date held.

Scenario 2: The software team that turned one project’s log into the next project’s plan

A software delivery team kept a RAID log on a twelve-week client implementation. At the close of the project, they archived it. When a second client requested a nearly identical implementation, the team reused the archived log as a planning starting point: the same supplier risk, the same assumption about a third-party API that had proven false, and the same decision pattern on scope changes. The second project’s planning phase finished in half the time of the first, and the team avoided the API assumption that had caused a two-week delay the first time.

Scenario 3: The operations manager who stopped surprises in weekly reviews

An operations manager running a set of concurrent projects adopted a RAID log walked every Friday with the team. Each category got five minutes: new risks, assumptions needing validation, open issues, and pending decisions. In the first quarter, the number of issues discovered at the “too late” stage dropped noticeably — from roughly three per month to roughly one — because risks were being named while they were still risks, and assumptions were being validated before they failed. The meeting itself also shortened, because the RAID log was the agenda.

Common Mistakes When Using a RAID Log

• Using the letters loosely. If assumptions are mixed into issues and decisions mixed into risks, the log cannot drive the right responses. Keep each category distinct.
• Filling it once and never updating it. A RAID log written at planning and never touched is decoration. Risks materialize, assumptions fail, decisions get made — update the rows.
• Not naming an owner. A RAID row with no owner is a row no one acts on. Assign an owner for every risk, assumption, and issue.
• Forgetting to validate assumptions. An assumption that is never checked is a risk in disguise. Give each assumption an owner and a validation date.
• Treating a realized risk as a risk. When a risk happens, it is an issue. Move it, change the response from mitigation to resolution, and record the change.
• Overloading the log. A RAID log with 200 rows becomes unreadable. Keep it lean, escalate the deep detail to a full risk register or issue log, and use the RAID as the summary view.
• Never reviewing it. The log is reviewed on a schedule — weekly on active projects. A review-free log is a graveyard.
• Choosing a tool nobody opens. The best RAID log is the one in the tool the team already uses daily.

Know This Before You Choose

• [ ] Which letter set do we use — risks, assumptions, issues, decisions — or actions/dependencies?
• [ ] Who owns the log and updates it, and who reviews it on what schedule?
• [ ] What is our minimum row quality — description, impact, response, owner, status, review date?
• [ ] Do we validate assumptions on a schedule, and who does it?
• [ ] What happens when a risk materializes — do we move it to issues and change the response?
• [ ] Do we link the RAID log to the full risk register, issue log, and decision log, or keep it standalone?
• [ ] Is a spreadsheet enough, or do we need owners, reminders, and links to real tasks?
• [ ] Do we archive the log at project close to feed future planning?

Conclusion

A RAID log is one table that keeps the four things most likely to derail a project — risks, assumptions, issues, and decisions — visible, owned, and current. Build it during planning, keep every row populated with an owner, a response, and a status, move realized risks into issues, validate assumptions on a schedule, and walk the log in every review meeting. For a small project, a spreadsheet RAID log is genuinely enough. For a project where RAID items must be linked to the tasks they affect and chased on a schedule, keep it in a project management platform where risks, issues, decisions, and the work that follows them live in one workspace. Explore Doitify Project Management to run a living RAID log and keep every risk, assumption, issue, and decision under control.