RAID Log Template: Track Risks, Assumptions, Issues and Dependencies

A RAID log template gives a project one reviewed view of risks, assumptions, issues and dependencies. It helps the team distinguish uncertainty from current problems, expose beliefs that need validation and make cross-team commitments visible before they become surprises.

The log supports governance; it does not replace expert judgment, contractual notices, safety reporting, incident management or formal risk processes. Use approved thresholds, escalation routes and access rules. The project manager coordinates the record while accountable owners decide and act within their authority.

Define each RAID category

A risk is an uncertain event or condition that could affect an objective. An assumption is a proposition treated as true for planning but not yet fully verified. An issue already exists and requires resolution. A dependency is an input, decision, deliverable or event on which work relies.

Write classification tests into the log guidance. “Will the supplier deliver late?” is a risk; “the delivery missed Tuesday’s date” is an issue. “The interface will support our volume” is an assumption until tested. “Migration begins after security approval” is a dependency.

Categories can change over time. Preserve the original relationship when a risk materializes or an assumption is disproved rather than silently rewriting history. Link the resulting issue and response so reviewers can follow the chain.

Copy this RAID log

PROJECT RAID LOG

Project / workstream / reporting date:
Log owner / governance forum / access class:
Scales and escalation thresholds:

ENTRY
ID / category: Risk | Assumption | Issue | Dependency
Short statement / date raised / source:
Objective, milestone or deliverable affected:
Cause / event or condition / effect:
Evidence and uncertainty:
Likelihood / impact / urgency under approved scale:
Owner / action owner / escalation owner:
Response or validation action / due date:
Trigger, target date or dependency commitment:
Related decision, change or issue IDs:
Status / last review / next review:
Closure evidence / closure approver / date:

REVIEW SUMMARY
New and changed items:
Decisions required and latest decision dates:
Overdue actions / breached triggers:
Cross-project dependencies:

Adapt fields to project governance. Keep sensitive personnel, security, health or commercial detail in appropriately restricted systems and link only the minimum needed context.

Write entries that support action

Use a concise cause–event–effect structure for risks and a fact–effect–required decision structure for issues. Name the affected objective or milestone. Vague entries such as “resources may be a problem” do not tell an owner what to monitor or when to escalate.

Give every entry a stable identifier and raised date. Avoid combining several unrelated concerns in one row simply because they share an owner. Atomic entries can be closed, escalated and linked cleanly; compound entries tend to remain open after one part changes. Cross-reference separate items when they share a cause, decision or response.

Separate observations from interpretations. Link available evidence, identify what remains unknown and state the next validation step. Do not manufacture precision by assigning numerical probabilities when the project has no calibrated method. Use the organization’s approved qualitative or quantitative scale consistently.

For detailed uncertainty tracking, connect to the risk register template. The RAID log may be the project’s summary view, but duplicated fields need one declared source of truth.

Record and test assumptions

Every material assumption needs a reason, validation owner, evidence source and latest useful validation date. State what plan element changes if it is false. Assumptions about customer behavior, staffing, approvals or technical capacity should not quietly harden into facts through repetition.

Rank assumptions by sensitivity and reversibility. A low-cost, easily reversed belief may need lightweight validation; an assumption that drives procurement or a committed launch needs earlier, stronger evidence. Qualified owners determine what is sufficient.

Add an assumption expiry or revalidation date when context can change. Confirmation at project start may not remain valid after a design, supplier, policy or market change. Revalidate before irreversible commitments and distinguish direct evidence from inference or an unanswered request. This prevents an old planning convenience from silently controlling a later decision.

When an assumption is confirmed, record the evidence and date. When disproved, create or link the appropriate issue, change or decision. A decision log preserves the authorized choice made in response.

Assess risks without false precision

Use approved likelihood and impact definitions, including relevant schedule, cost, quality, safety, compliance and reputation dimensions. The highest applicable impact may matter more than an average. Route safety, legal, security or compliance risks to qualified owners and applicable specialist processes.

Choose responses such as avoid, reduce, transfer or accept only through accountable judgment. Record preventive actions, contingency actions, triggers and residual exposure. A task without a trigger may not help when the risk actually changes.

Review interactions between risks. Shared causes or resource constraints can make several moderate items significant together. Avoid summing scores unless the method supports that calculation.

Define escalation triggers before scoring live items. Include both quantitative and qualitative triggers because a low-cost event may still require immediate escalation for safety, privacy, legal, security or customer reasons. Record who can accept residual exposure and for how long. A response owner may recommend acceptance but should not be assumed to hold acceptance authority.

Resolve issues with decisions and evidence

For an issue, record current facts, effect, containment, root-cause work, resolution options and latest useful decision time. Assign one accountable owner even when several teams contribute. “Everyone” is not an owner.

Distinguish temporary containment from durable resolution. A workaround can protect a milestone while leaving cost, control or customer effects unresolved. Track both and set a review date. Use a delivery exception report template when a specific delivery deviation needs deeper operational evidence.

Track decision latency as part of the issue instead of hiding it as a scheduling problem. Show the requested decision, available options, decision owner and latest useful date. If evidence is incomplete, identify whether waiting will reduce uncertainty enough to justify the delay. Escalation should present a decision-ready summary rather than merely state that an owner is late.

Close only after the agreed outcome is verified by the appropriate reviewer. Document residual actions and transfer them to the receiving operational system rather than closing because discussion stopped.

Make dependencies reciprocal and dated

Name the provider, receiver, required output, acceptance condition and committed date. “Waiting on engineering” is incomplete because it hides the deliverable and commitment. Confirm that the provider recognizes the dependency; one-sided entries are merely expectations.

Track internal and external dependencies, including decisions, environments, data, vendors and regulatory or customer inputs. Show downstream milestones and the latest safe date. Escalate when confidence changes, not only after a deadline is missed.

Link related work through a client status report template pattern or the project’s approved reporting record. Keep the RAID log detailed enough for action while summaries highlight decisions and material movement.

Check dependency quality in both directions when plans change. If the receiver changes acceptance criteria or timing, notify the provider and obtain a revised commitment. Record lead time and notice requirements. A date copied from a plan is not a confirmed dependency unless the responsible provider has recognized the expected output and acceptance condition.

Run a focused RAID review

Review new items, changed exposure, overdue actions, near triggers, unvalidated assumptions and dependencies approaching their latest safe dates. Do not read every unchanged line aloud. Ask owners for evidence, decisions and revised dates, then record the reviewed outcome.

Use filters for workstream, objective, category, owner and next review date, but maintain one governed dataset. Separate spreadsheets invite conflicting identifiers and states. If access restrictions require a confidential annex, create controlled references and a safe summary rather than exposing details or hiding the existence of material exposure from authorized decision makers.

Set frequency according to project pace. A weekly review may fit one project; a release or incident may need daily attention. Significant changes should trigger immediate routing under governance rules rather than waiting for the calendar.

Use meeting follow-up to distribute verified actions. Meeting attendance is not acceptance of a risk or approval of a response; capture explicit decisions and authority.

Use automation and Kuno responsibly

Automation can flag overdue dates, missing owners and status changes. It cannot reliably infer materiality, consent, specialist obligations or whether an assumption is justified. Require human review before changing scores, owners, decisions or closure states.

RAID discussions may contain personal performance, security weaknesses, legal positions or confidential supplier information. Capture only with authorization, clear notice, required consent, restricted access and defined retention.

For an authorized project review with visible capture, Kuno can turn discussion into draft notes and RAID follow-ups for human verification. It does not assess exposure or accept risk. Explore Kuno

Verify generated wording against evidence and let accountable owners approve classifications and actions.

Close, archive and learn

Before closure, confirm the outcome, evidence, residual exposure, receiving owner and authorized reviewer. Retain records according to project, contractual and legal requirements. Do not delete uncomfortable history or retain personal data without purpose.

At milestones, examine recurring causes, inaccurate assumptions, late dependencies and responses that worked. Convert lessons into owned process changes. Meeting follow-up can structure the review record without turning anecdotes into unsupported conclusions.

Compare the RAID log with the current plan, decisions and accepted changes before archiving. Reconcile open actions and transfer continuing items to named operational owners. Closing a project does not eliminate an unresolved dependency or accepted exposure; it changes where accountability and future review reside.

Archive the final export with its scales, status definitions and review date. Without that context, later readers may misread a historical score or assume a closed entry was harmless. Apply the project’s retention rules and remove access when there is no continuing purpose.

A strong RAID log lets a new authorized reviewer understand what changed, why it mattered, who owned the response and which decision remains due. Its value comes from disciplined review, not the number of rows.

Keep project uncertainty reviewable without outsourcing judgment. Kuno supports consented capture and draft actions; project owners verify evidence and retain decision authority. See Kuno

FAQ