Critical Path
Dan Sunil monogram
PMI standard template · Excel, Word & PDF · Toolkit only

RAID Log Template (PMI Standard Excel, Word & PDF)

8 min read · Reviewed August 2026 by Dan Sunil Kumar

A RAID log is the single register where a project records its risks, assumptions, issues and dependencies. One document, four entry types, one weekly review — instead of four half-maintained spreadsheets that disagree with each other.

The distinction is the whole value. A risk might happen; an issue already has. An assumption is something you decided to believe without evidence; a dependency is work owned by someone else that your dates rest on. Blur them and you end up managing risks like issues, and never testing the assumptions that quietly hold your plan together.

PMI standard alignment
Standard followed
PMBOK Guide 7th ed. / PMI Practice Standard for Project Risk Management
Performance domain
Uncertainty
Process group
Monitoring & Controlling
Knowledge area
Risk Management

The Excel, Word & PDF files for this template are part of the paid PM Delivery Toolkit — there is no free download. The full walkthrough, worked example and section guidance below stay open to read.

Get the raid log in the toolkit

When to use it

  • You are starting a project and want one register in place before the first steering meeting.
  • Risks are being tracked in meeting minutes, so nothing has an owner or a date.
  • Dates keep slipping because of other teams' work that was never logged as a dependency.
  • A PMO or stage gate expects a RAID review at every checkpoint.
  • You want a defensible trail of what was known, when, and who was told.

Every section, and what good looks like

  1. Section 1

    ID and type

    A short reference (R1, A1, I1, D1) and which of the four RAID categories the entry is.

    The prefix tells you the type at a glance, and IDs are never reused after closure.

  2. Section 2

    Description

    One sentence on the situation, written so someone outside the team understands it.

    Cause-and-effect phrasing: "Vendor rate limits are undocumented, so the migration batch may exceed them."

  3. Section 3

    Impact if it lands

    The consequence in days, money, scope or reputation — not an adjective.

    "Cutover overruns; a second outage window is needed" beats "high impact".

  4. Section 4

    Probability and impact score

    Probability 1-5 multiplied by impact 1-5, giving a 1-25 score. Risks only — issues are already certain.

    The threshold for escalation is written down, so nobody argues about whether a 12 goes to the sponsor.

  5. Section 5

    Response

    Avoid, reduce, transfer or accept for risks; resolve for issues; validate for assumptions; manage for dependencies.

    A dated action a named person can start on Monday, not the word "monitor".

  6. Section 6

    Owner and due date

    One person — not a team — and the date the next action is due.

    The owner is whoever can actually act, which is often outside the project team.

  7. Section 7

    Status and closure note

    Open, in progress, validated, closed — plus one line on what actually happened at closure.

    Closed entries stay in the log; they are the raw material for the lessons learned log.

A filled-in example

One register from a live system migration, showing how each of the four RAID types is written differently — and what a response with teeth looks like.

Worked raid log example
R1 — RiskVendor API rate limits are undocumented; the migration batch may exceed them. Impact: cutover overruns and a second outage window. P3 × I4 = 12. Mitigate — throttled dry run in week 2 and a written limit. Integration lead, 18 Mar, open.
A1 — AssumptionFinance data owners stay available two days a week through April. Impact if wrong: validation stalls and UAT slips a fortnight. Validate — sponsor confirms allocation at the 11 Mar steering meeting. Sponsor, 11 Mar, validated.
I1 — IssueThe legacy export drops records with non-Latin characters. Impact: roughly 1,800 incomplete customer records at go-live. Resolve — patch the encoding and re-run reconciliation. Data engineer, 20 Mar, in progress.
D1 — DependencySecurity sign-off is needed before production credentials are issued. Impact: no deployment; cutover moves a full sprint. Manage — review booked 14 Mar, escalate 15 Mar if unbooked. Project manager, on track.
R2 — RiskOnly one engineer knows the reconciliation scripts. Impact: single point of failure over the cutover weekend. P2 × I4 = 8. Reduce — pair a second engineer through the dry run and write a runbook. Tech lead, 25 Mar, open.
Escalation ruleScore 12 or above, or any issue with a delivery-date impact, goes to the steering group the same week with an option and a recommendation.

Mistakes that turn a RAID log into shelfware

  • Logging everything as a risk, so genuine issues never get the urgency they need.
  • Writing "monitor" or "manage carefully" as the response — neither is an action anyone can do.
  • Scoring risks once at initiation and never re-scoring them as the project changes.
  • Owners recorded as a team or a department, which means nobody owns it.
  • Assumptions with no validation date, so they stay assumptions until they break.
  • Reviewing the log only when the PMO asks, instead of ten minutes every week.
  • Deleting closed entries and losing the record of what was known and when.
Paid toolkit

26 more artifacts, ready to fill in

The PM Delivery Toolkit packages the RAID log, status pack, estimation and earned value workbooks, capacity planner, agile sprint tools and 150 PMP-style questions — Word, Excel and print-ready PDF.

  • Status pack and steering deck with RAG logic built in
  • Estimation and EVM workbook: CPI, SPI and EAC calculated
  • Capacity planner with an over-allocation heatmap
  • Agile set: sprint planning, user stories, retros, backlog, WSJF
What’s inside all 26 artifacts

One payment · lifetime updates · 14-day refund. Files unlock on your download page as soon as payment clears.

Questions people ask

What does RAID stand for in project management?
Risks, assumptions, issues and dependencies. Some organisations swap in "actions" or "decisions" for the A, but the four-way split above is the version that keeps risk and issue management honest.
What is the difference between a risk and an issue?
A risk is a future event with a probability attached, so it gets a probability × impact score and a mitigating response. An issue has already happened, so it has a resolution owner and a date instead of a score.
What is the difference between a RAID log and a risk register?
A risk register covers risks only. A RAID log adds assumptions, issues and dependencies alongside them, so one weekly review covers everything that can move your dates.
How do you score risks in a RAID log?
Rate probability 1-5 and impact 1-5, then multiply for a 1-25 score. Set a written threshold — 12 is a common one — above which an entry needs a dated response and steering-group visibility.
How often should a RAID log be reviewed?
Weekly with the delivery team, and at every stage gate with governance. Review new entries, movers, and anything overdue; escalate by exception rather than reading the whole log aloud.
Who owns the RAID log?
The project manager maintains the register, but each entry has its own owner — often a functional lead, vendor manager or the sponsor, because most responses need authority the project manager does not hold.

Read next

Other PMI-standard templates

Every one has the same walkthrough, worked example and PMI mapping, and every file ships inside the PM Delivery Toolkit.

Keep going on the site

The hubs and tools that pair with this raid log.

Free tips

Get five PM habits that quietly save projects

Baselines, critical path discipline, RAID logs that people read, range estimating and status packs sponsors act on — sent straight to your inbox, free.

One email, no spam, unsubscribe any time.