A RAID log earns its place when it helps someone act, resolve a problem or explain a decision. If the weekly ritual is reading old rows aloud, the register needs attention before it needs another column.
RAID log: A project register that makes ownership, follow-up and closure visible. Two common expansions are equally valid: Risks, Assumptions, Issues, Dependencies, and Risks, Actions, Issues, Decisions.
Choose one expansion per register (or keep Actions and Decisions in separate linked logs). Mixing eight overlapping types in one sheet without clear prefixes creates conflicting owners and closure rules.
In practice: Write the chosen meaning at the top of the sheet, give every row one owner, and close items only against an agreed evidence condition.
Not the same as: A full project plan or backlog, which schedules wider delivery work.
Download the free Insights Spotter RAID log template (Excel) for both expansions, with column guidance, status lists and a worked example. Pair the colour story with computable RAG status criteria so the RAID register and the status slide do not drift apart.
Two equally valid RAID expansions
Neither expansion is “more correct”. Both appear in PMO practice. Agree the letters before you import a template, and keep the same meaning for the life of the project unless you formally re-baseline the register.
| Expansion | Letters | Best when |
|---|---|---|
| Assumptions & Dependencies | Risks, Assumptions, Issues, Dependencies | Delivery risk sits in unvalidated beliefs or in work you cannot finish without another party, and actions/decisions already live in a plan or decision log. |
| Actions & Decisions | Risks, Actions, Issues, Decisions | The weekly review is mainly about who will do what by when, and which choices need authority recorded. |
Shared letters in both expansions are Risk and Issue. The variable letters are Assumption and Dependency, or Action and Decision. The sections below cover every letter with a definition, example, owner rule, status set and escalation trigger. Examples are fictional teaching shapes, not reported results. There is no reliable industry percentage for which expansion is more common.
Shared letters: Risk and Issue
Risk
Definition: An uncertain event or condition that could affect project objectives if it occurs.
Example (fictional): RSK-001 — If the test environment is unavailable by 6 November 2026, integration testing may miss the trial readiness review.
Owner: One named person who maintains the record, drives the response and raises escalation. They need not personally fix every task.
Status (starting set): Open → Monitoring → Mitigated → Accepted → Closed. Reopen only with a reason.
Escalate when: Readiness cannot be evidenced by the review date; impact threatens a committed milestone or needs sponsor authority.
Issue
Definition: A current problem that already affects delivery, or will without prompt resolution.
Example (fictional): ISS-001 — The booking confirmation interface failed its integration test on 2 November 2026, blocking an end-to-end readiness check.
Owner: One named person accountable for resolution and for keeping impact and next step current.
Status (starting set): Open → In progress → Resolved → Accepted → Closed.
Escalate when: Retest fails, the fix threatens the next milestone, or authority beyond the team is required.
Expansion 1: Assumption and Dependency
Assumption
Definition: A belief treated as true for planning that has not been fully validated, and that would change the plan if it proved false.
Example (fictional): ASM-001 — Staff users will complete the booking flow without training materials by trial start. Validate by a usability check on 4 November.
Owner: The person who owns validation (evidence gatherer), not “the project team”.
Status (starting set): Proposed → Validated → Invalidated → Retired.
Escalate when: Validation is overdue, evidence contradicts the belief, or invalidation forces a scope, date or cost decision.
Dependency
Definition: Work, information, access or a decision your project needs from another party before a committed step can finish.
Example (fictional): DEP-001 — Test environment credentials from Platform Ops required by 6 November for integration testing.
Owner: An internal chase owner plus a named external contact where possible. “Supplier” alone is not enough.
Status (starting set): Open → Monitoring → Satisfied → Blocked → Closed.
Escalate when: Needed item will miss the required-by date, the provider is unresponsive, or a blocked dependency threatens a committed milestone.
Expansion 2: Action and Decision
Action
Definition: An agreed task with a named owner, a due date and a clear completion condition.
Example (fictional): ACT-001 — Leo will confirm whether the fallback environment supports the required interfaces by 4 November 2026.
Owner: The person who will complete the work or obtain the completion evidence. Group names are not owners.
Status (starting set): Open → In progress → Closed (or Superseded if replaced).
Escalate when: Due date will be missed, repeated slips have no changed response, or completion needs authority the owner does not have.
Decision
Definition: An agreed choice, recorded with rationale, authority and consequences. Recording a proposal is not the same as approval.
Example (fictional): DEC-001 — On 3 November 2026 the project sponsor approved a trial limited to staff users because the unresolved interface issue made a wider trial premature.
Owner: A record owner who maintains the entry, distinct from the approving authority or forum where required.
Status (starting set): Proposed → Approved / Partially approved / Rejected → Superseded (keep history; link the replacement).
Escalate when: A choice is blocking delivery and no authorised forum is scheduled, or an approved decision is being ignored in implementation.
Prefixes, ownership and evidence
Agree ID prefixes so letters do not collide across expansions: RSK, ISS, ASM, DEP, ACT, DEC. Never reuse A/D alone when both expansions might appear in linked documents.
One person owns each row. “Operations”, “supplier” or “project team” leave everyone free to assume someone else will act. For decisions, distinguish the record owner from the approving authority. For dependencies, name an internal chase owner.
Close only against an explicit evidence condition (retest note, approval record, received access, validation result). Do not close a risk merely because the event happened—open or link the resulting issue. Do not mark an action closed because an email was sent if the completion condition was an approved outcome.
When a single sheet is the wrong tool
Keep a separate risk register where governance requires particular fields, assessments, approvals or retention. Programme-level items may need their own board. Sensitive issues may need a restricted record with only a summary in the shared log. Splitting registers should preserve stable references, not create competing versions of the truth.
Set up the template around ownership and evidence
Use the free Insights Spotter RAID log template (Excel). Core columns for every type: ID, Type, Summary, Details, Owner, Status, Response or next step, Review or due date, Impact (and Likelihood for risks; Priority for issues), Escalation condition, Evidence or source reference, Related IDs, Last updated.
Keep descriptions concrete. “Supplier risk” is a label. “If the test environment arrives after the integration window, acceptance testing will start late” explains condition and consequence.
A worked example: four connected entries
Illustrative booking-service trial. Names, dates and records are fictional teaching examples, not reported results. This example uses the Actions & Decisions expansion; the Excel workbook also includes Assumption and Dependency sample rows.
Risk: the test environment may arrive late
RSK-001 — Risk. If the test environment is unavailable by 6 November 2026, integration testing may miss the trial readiness review. Maya owns the risk. Status: Monitoring, review 3 November. Response: confirm readiness and assess a fallback route. Escalate to the sponsor if readiness cannot be evidenced at review.
Action: verify the fallback route
ACT-001 — Action. Leo will test whether the fallback environment supports the required interfaces by 4 November 2026. Status: Open. Completion means the technical lead has reviewed the compatibility note. Links to RSK-001; completing the action may improve the response without removing the exposure.
Issue: an interface is already failing
ISS-001 — Issue. The booking confirmation interface failed its integration test on 2 November 2026. Noor owns resolution. Status: In progress; fix and retest planned for 5 November. Escalate if the retest fails or the fix threatens readiness.
Decision: limit the trial scope
DEC-001 — Decision. On 3 November 2026 the project sponsor approved a staff-only trial because the unresolved interface issue made a wider trial premature. Eva owns the record (Closed following approval). Implementation of invitations is a separate action. Closing the decision does not close the issue.
Run a 15-minute weekly RAID review
The review is triage, not a workshop for solving every problem. Circulate the filtered log beforehand. Urgent issues and escalation triggers need action when they arise; they should not wait for a calendar slot.
Minutes 0–3: scan for meaningful changes
Review new items, overdue actions or reviews, missed dates and changed impacts. Check whether any risk has become an issue, any assumption has been invalidated, or any dependency is blocked. Include accepted risks whose review conditions have triggered.
Minutes 3–8: agree responses and escalation
Focus on items that threaten the next milestone, lack an owner or need authority beyond the team. Confirm one owner, the next step and its date. Escalation should state the impact, the choice required and the decision-needed-by date. Use the steering committee’s decision-making role when the trade-off belongs there.
Minutes 8–12: test closure and acceptance
Check proposed closures against completion conditions and evidence references. For acceptance, confirm who has authority and what would trigger reconsideration. Challenge repeated date extensions without a changed response.
Minutes 12–15: record decisions and confirm follow-up
Read back decisions, escalations, owners and dates. Preserve a short dated update for each changed item. If triage regularly exceeds fifteen minutes, filter to new, changed and overdue items and park deep dives outside the meeting.
Keep an audit trail people can follow
Keep stable IDs and dated updates for material changes to impact, owner, response, due date and status. Record who approved acceptance or a decision and link the supporting record. Retain closed and superseded entries. When preparing a report, draw the summary from the current log and reconcile discrepancies with RAG status criteria. These habits also help reduce project reporting time.
Where AI helps, and where judgement stays human
AI can help turn approved meeting notes into candidate entries or draft a concise summary. Treat outputs as proposals: check type, owner, date and evidence against the source before adding them to the live record. Do not let a generated summary invent agreement, turn uncertainty into certainty or close an item because its wording sounds resolved. For the broader workflow, see AI in project management.
Make the log worth maintaining
If people call RAID dead weight, ask what the last review changed. A useful log prompts a response, secures a decision or makes closure defensible. Remove duplicate administration and keep the fields that support those outcomes.
For more practical project governance guidance, subscribe to the newsletter.
Frequently asked questions
What does RAID stand for?
Two expansions are equally common: Risks, Assumptions, Issues, Dependencies, and Risks, Actions, Issues, Decisions. Define the four letters on the template before you share it. Do not mix both expansions in the same register without clear prefixes and links.
How often should a RAID log be updated?
Update it when material information changes. A weekly review provides a regular checkpoint; urgent issues and escalation triggers need prompt attention between meetings.
Can a spreadsheet be enough?
Yes, where access, traceability and reporting needs are manageable. Use separate or more controlled records when governance requirements exceed what the shared sheet can reliably support. Start from the Insights Spotter RAID log template.
How do you keep a RAID log from becoming a task list?
Keep routine delivery work in the plan. Record actions (or dependencies and assumptions) that need this oversight, link to the underlying work, and close them against explicit completion conditions.
Should Actions and Decisions sit inside RAID?
They can, when you choose the Actions & Decisions expansion. If you choose Assumptions & Dependencies instead, keep Actions and Decisions in linked registers so ownership and approval rules stay clear. Insights Spotter also publishes separate action log and decision log templates you can use alongside RAID.