RAID Log Template: Track Risks, Actions, Issues and Decisions Before They Derail Delivery

RAID Log Template: Track Risks, Actions, Issues and Decisions Before They Derail Delivery

A RAID log is a single project register that tracks risks, actions or assumptions, issues, and decisions or dependencies. Use it to give every important uncertainty, problem, commitment, and choice an owner, due date, status, and next action. Review it weekly so problems surface before they become expensive surprises.

Updated September 13, 2026

What is a RAID log and which version should your team use?

A RAID log is the control panel beside your project plan. The plan says what should happen. The RAID log records the conditions, problems, commitments, and choices that could change what actually happens.

RAID has two common meanings:

• Risks, Assumptions, Issues, and Dependencies.
• Risks, Actions, Issues, and Decisions.

Neither version is universally correct. The right choice depends on what your team already tracks elsewhere.

Use Risks, Assumptions, Issues, and Dependencies when your project has many external approvals, vendors, handoffs, estimates, or uncertain conditions. This version is particularly useful during planning because it forces the team to expose what it is taking on faith and what must arrive from somewhere else.

Use Risks, Actions, Issues, and Decisions when assumptions and dependencies already live in the project plan, but governance commitments and important choices disappear into meeting notes. This version is usually easier for a leadership team that wants one weekly view of what could go wrong, what someone promised to do, what is wrong now, and what has been decided.

Atlassian describes a RAID log as a structured document for risks, assumptions, issues, and decisions or dependencies, while ProjectManagement.com publishes a four-tab version for risks, actions, issues, and decisions. That split is useful evidence that the acronym is flexible, not a test your team can fail. Sources: Atlassian, RAID Log Explained, captured September 13, 2026; ProjectManagement.com, Project RAID Log Template, captured September 13, 2026.

Pick one definition at kickoff, write it at the top of the file, and keep it stable for that project. Quietly switching what the A or D means halfway through creates the exact confusion the log is meant to remove.

The need for a shared control view is growing. PMI's May 2026 Pulse of the Profession report found that 97 percent of project professionals had managed at least one complex project in the previous year, more than half described projects as significantly complex, and roughly one-third of complex projects failed. Source: Project Management Institute, Pulse of the Profession 2026, published May 2026 and captured September 13, 2026.

A RAID log will not make a difficult project simple. It will make the difficulty visible, owned, and discussable. That is the job.

What fields belong in a useful RAID log template?

Start with one table. Separate tabs can come later if the log becomes large. A single table makes it easier to sort by owner, urgency, due date, workstream, or status without forcing leaders to inspect four files.

Use these fields:

• ID: a stable reference such as R-014 or D-006.
• Type: risk, action, assumption, issue, decision, or dependency.
• Date raised: when the item entered the log.
• Description: one plain-language statement of the condition or problem.
• Business impact: the customer, revenue, cost, compliance, scope, or timeline consequence.
• Probability: for risks only, using a simple low, medium, or high scale.
• Severity: the consequence if the item is not handled.
• Owner: one person accountable for moving the item, not a department.
• Next action: the specific next move required.
• Due or review date: when the item must change or be reconsidered.
• Status: open, monitoring, blocked, awaiting decision, or closed.
• Escalation trigger: the condition that requires sponsor attention.
• Related item: the risk, action, issue, decision, or dependency connected to it.
• Evidence link: the email, approval, contract, test result, or source behind the entry.
• Closed date and outcome: what happened and why the item can stop consuming attention.

Do not add fields because a template site included them. Every column creates maintenance work. If nobody uses a field to prioritize, decide, escalate, or learn, remove it.

The most important fields are often the least glamorous: one owner, one next action, one date, and one escalation trigger. Without them, the log is merely a list of worries.

Avoid putting every task into RAID. Your project plan or task board already tracks ordinary delivery work. RAID should hold items that can alter delivery, cross team boundaries, require governance attention, or preserve context that would otherwise be lost.

PMI's 2025 project-success research shows why measurement fields matter. Across 3,605 projects in the comparison cited by the report, projects that defined success up front, used a measurement system, and measured outcomes throughout delivery achieved a Net Project Success Score 23 points higher than projects missing one or more of those elements. The same report found that 86 percent defined success criteria up front, but only 50 percent measured progress toward intended outcomes throughout the project. Source: Project Management Institute, Step Up: Redefining the Path to Project Success with M.O.R.E., published 2025 and captured September 13, 2026.

Your RAID fields should therefore connect each item to a project outcome, not only a date. “Vendor response late” is weak. “Vendor response is four days late; testing starts Monday; if approval is not received by Thursday, launch moves one week” gives the team something it can act on.

How do you tell a risk, action, issue and decision apart?

The quickest test is to ask what is true today.

A risk is a possible future event. It has not happened. “The payment provider may not complete certification before testing” is a risk. Give it a probability, impact, owner, mitigation, and trigger.

An issue is a current problem. It has happened or is happening. “Certification is five days late and testing cannot begin” is an issue. Give it a severity, resolution plan, owner, target date, and escalation rule.

An action is a commitment. Someone must do something. “Priya will get a written certification date from the provider by Thursday” is an action. Give it one owner and one due date. “Team to follow up” is not an action; it is fog wearing office clothes.

A decision records a consequential choice. “The sponsor approved a one-week launch delay rather than removing the payment method” is a decision. Record who decided, when, which options were considered, the reason, and the affected work.

An assumption is an unverified condition used for planning. “Legal review will take three business days” is an assumption. Name who will validate it and by when. If nobody plans to validate it, you have hidden a risk inside a confident sentence.

A dependency is something your work needs from another task, team, vendor, or authority. “Testing depends on the provider's certification” is a dependency. Record the supplying owner, needed-by date, receiving work, and what happens if it arrives late.

Items should move between categories as reality changes. A risk that occurs becomes an issue. An assumption that proves false may create a risk, issue, action, or decision. A decision creates actions. An unresolved issue may require a sponsor decision. Those links are where the RAID log becomes a management system rather than a filing cabinet.

Use the language of the business. A general manager does not need a taxonomy lecture. They need to know what may happen, what has happened, who owes what, what must be decided, and what delivery consequence follows.

What does a completed RAID log look like in practice?

Consider a hypothetical professional-services firm replacing its lead intake, proposal approval, and client onboarding workflow. The project touches marketing, sales, finance, delivery, and an outside software provider. The team wants to launch before the next quarter.

Here is a compact working example:

Notice what is absent. There is no vague “data risk.” There is no owner called “marketing and sales.” There is no date called “ASAP.” Each row states the delivery consequence and the next move.

The example also connects items. Decision D-01 changes the launch plan. That decision should create actions for communications, support, and testing. Issue I-01 may threaten the staged launch if the matching rule is not accepted. Risk R-02 should be tested before the sales team is trained.

The log is not trying to predict everything. It is forcing the team to handle the few conditions that could change the outcome.

How should you run a weekly RAID review?

Run the review as a decision meeting, not a recital.

Before the meeting, owners update their items. The project manager flags overdue actions, new high-severity issues, risks whose probability or impact changed, assumptions awaiting validation, dependencies within the next two weeks, and decisions needed from the sponsor.

During the meeting, review by exception:

• New items that need classification and ownership.
• Critical or high-severity items.
• Items whose date, probability, impact, or status changed.
• Overdue actions and dependencies approaching their needed-by date.
• Decisions that cannot wait until the next review.
• Items proposed for closure.

For each item, ask four questions: What changed? What is the business consequence? Who owns the next move? When must we know whether it worked?

Do not spend ten minutes polishing wording while a launch decision waits. Capture enough detail to preserve accountability, make the decision, and move on.

After the meeting, publish the decisions and new actions in the same place. Do not create a separate set of meeting minutes that competes with the log. Link any detailed evidence, but keep the current truth in RAID.

Set service rules for the log. A critical issue may require same-day escalation. A high risk may need weekly review. An assumption may need a validation date before dependent work begins. An action may become overdue at the end of its due date, not after someone notices it next month.

PMI's December 2025 research, based on more than 5,800 project professionals, stakeholders, and knowledge workers, found that only 50 percent of projects met its modern definition of success; 13 percent failed outright and 37 percent only partly delivered expected results. The same release identified the disconnect between planning and execution as the top barrier to reinvention, cited by 35 percent of executives. Source: Project Management Institute, strategy-execution research, published December 2025 and captured September 13, 2026.

A weekly RAID review is a small bridge across that gap. It connects the plan to current evidence and forces trade-offs before the team quietly absorbs them.

Which RAID log tasks should you automate?

Automate the mechanical work after the operating rules are stable. Keep judgment and accountability with people.

Good candidates for automation include:

• Collecting proposed entries from a standard form.
• Alerting an owner when a new high-severity item is added.
• Reminding owners before review dates and due dates.
• Flagging overdue actions or dependencies due within a set window.
• Creating a meeting view that shows only changed and decision-ready items.
• Copying approved decisions into the project update.
• Linking a realized risk to a new issue while preserving the original history.
• Sending closed items into a lessons-learned review at project end.

Poor candidates include deciding severity without context, approving a risk response, changing a project commitment, closing an issue because its due date passed, or assigning ownership based on who appears least busy.

AI can summarize updates, extract possible risks from notes, or suggest duplicate entries. Treat those outputs as proposals. A named person should still decide whether an item belongs in the log, how serious it is, who owns it, and whether the evidence is sufficient to close it.

Start with one painful handoff. Perhaps decisions live in email, actions live in meeting notes, issues live in a task board, and risks live in a spreadsheet. Map how an item enters, changes, escalates, appears in leadership reporting, and closes. Then consolidate the stable parts without forcing every team to replace its daily tool.

The best automation result is not a more impressive dashboard. It is fewer stale entries, faster escalations, less time assembling status, and clearer evidence for decisions.

PMI's February 2024 Pulse of the Profession research reported a 73.8 percent average project performance rate across respondents and a 57 percent increase in the use of hybrid delivery approaches. Source: Project Management Institute, Pulse of the Profession 2024, published February 2024 and captured September 13, 2026.

That matters because a RAID workflow should survive different delivery methods. The team may run agile product work, a fixed client implementation, and a vendor rollout at the same time. The register needs consistent ownership and escalation rules even when the underlying task boards differ.

How do you know the RAID log is improving delivery?

Measure whether the log changes decisions and response, not how many rows it contains.

Useful measures include:

• Percentage of open items with one named owner and next action.
• Percentage of actions completed by the agreed date.
• Average age of open high-severity issues.
• Percentage of assumptions validated before dependent work begins.
• Dependencies missed without prior escalation.
• Time from decision request to recorded decision.
• Risks first identified only after they became issues.
• Closed items reopened because the resolution lacked evidence.
• Time spent assembling the weekly project update.

Set a baseline before changing the process. If the project currently has 24 open issues and 11 have no owner, record that. If sponsor decisions take nine days because the request lacks options and impact, record that too.

Then choose two or three targets for the next month. For example: every high-severity item has one owner and next action; decisions are presented with options and impact within one business day; no dependency passes its needed-by date without prior escalation.

Watch for gaming. Closing entries faster is not useful if owners reopen them next week. Reducing the number of risks is not useful if the team has stopped reporting them. Pair speed measures with evidence and quality checks.

Retire the log when the project ends, but keep the learning. Review which risks occurred, which assumptions proved false, which dependencies were missed, which decisions were repeatedly reopened, and which controls prevented damage. Feed those patterns into future estimates, contracts, project charters, and workflow designs.

If RAID is always stale, the problem may not be employee discipline. The update path may be too fragmented, the fields may be unclear, ownership may be political, or the meeting may not produce decisions. Fix the operating system before blaming the people using it.

Wavicle helps non-technical leaders turn scattered project evidence into a clear control workflow. We can map where risks, actions, issues, and decisions currently live; define ownership and escalation rules; connect stable reminders and reporting; create review queues for exceptions; and keep consequential choices with the people accountable for them.

Bring one project whose risks and decisions are scattered across spreadsheets, chat, and meeting notes to a free growth consultation with Wavicle. We will help you identify the control gap and the smallest practical fix.

What are the most frequently asked questions about RAID logs?

What does RAID stand for in project management?

RAID commonly means Risks, Assumptions, Issues, and Dependencies. Some teams use Risks, Actions, Issues, and Decisions. Choose the version that fills the gap in your existing project controls, write the definition at the top of the log, and use it consistently through the project.

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

A risk register focuses on uncertain future events, their probability, impact, response, owner, and triggers. A RAID log combines risks with other control information such as assumptions, actions, issues, decisions, or dependencies. Use a dedicated risk register when risk volume and analysis require more depth; use RAID for a compact cross-project governance view.

What is the difference between a RAID log and a project status report?

The RAID log is a working register that changes as items are raised, updated, escalated, and closed. A status report is a periodic summary for a particular audience. The report should draw its risk, issue, decision, and dependency summary from the current RAID log rather than recreate the information by hand.

Who should own the RAID log?

The project or program manager usually owns the process, structure, and review cadence. Individual items must have their own named owners. The sponsor owns consequential trade-offs and decisions, while workstream owners supply updates and evidence. One administrator can maintain the file, but accountability cannot belong to the administrator alone.

How often should a RAID log be updated?

Update an item when the underlying condition changes, not only before a meeting. Review the whole log weekly for most active projects, with faster escalation for critical issues and time-sensitive dependencies. A monthly review may suit a slow initiative, while a launch week may require daily exception checks.

Should a RAID log include every project task?

No. Keep ordinary planned work in the project plan or task board. Add an item to RAID when it creates meaningful uncertainty, crosses an ownership boundary, threatens an outcome, requires escalation, records a consequential choice, or preserves context the team will need later.

Can a RAID log be kept in a spreadsheet?

Yes. A shared spreadsheet is enough when the team has clear ownership, one source of truth, a review habit, and manageable volume. Move to a connected workflow when manual reminders, duplicate entries, permissions, reporting, or cross-project views become a recurring burden.

What makes a RAID log fail?

RAID logs fail when descriptions are vague, owners are teams instead of people, dates are optional, the file is separate from weekly decisions, every minor task is included, closed items lack evidence, or leadership repeatedly avoids the decisions the log exposes. A clean template cannot compensate for weak governance.

Your project does not need another spreadsheet nobody trusts. It needs a living record that turns uncertainty into ownership and evidence into decisions. Book a free consultation at wavicle.tech to review the project-control workflow slowing your team down.