RAID Log Explained: A Worked Example You Can Copy

You've heard "put it in the RAID log" in a meeting, right? Everybody nods. But when you open a blank one, it's not obvious what goes where. Is a vendor delay a risk or a dependency? Is "the budget will be approved" an assumption or a risk?

If you're new to running projects, the RAID log is one of the habits in the accidental project manager's first 90 days. Let's settle what goes where with a real example instead of definitions alone. Below you'll walk through a RAID log for one sample project, item by item, so you can see what a good entry actually looks like. Then you'll get an AI prompt that sorts your own messy notes into the right buckets.

Why does this matter? In real PM work, projects rarely fail from one big surprise. They fail from small things somebody mentioned once and nobody wrote down: the vendor who "should be fine," the data everyone assumed would migrate cleanly. A RAID log is where those things go so they can't hide.

What RAID Stands For (and Why Sources Disagree)

RAID most often stands for Risks, Assumptions, Issues and Dependencies. You'll also see Actions in place of Assumptions and Decisions in place of Dependencies. Both versions are common, and that's why two articles can define it differently. There's not one right answer here. Pick one meaning, write it at the top of your log, and stick with it.

Here's what each one means in the four-part version:

• Risk: something that might happen and would affect the project if it did. It hasn't happened yet.
• Assumption: something you're treating as true so you can plan, without proof yet. If it turns out false, your plan changes.
• Issue: something that's happening now and needs action. A risk that came true becomes an issue.
• Dependency: something you need from someone else, or that someone else needs from you, before work can move.

If your team also needs to track action items and decisions, use a log that adds them as separate sections instead of overloading the four. The RAID + Actions and Decisions Log does exactly that.

The Example Project: Northwind Regional Health

The example below comes from Northwind Regional Health, the sample project built into the ProjectMentorPro RAID Log template. Northwind is a fictional health system replacing its IT service management (ITSM) platform, with an outside assessment from SecureGrid, an integration build from Brightpath, and a state audit deadline in the mix.

The risk entries and scores below are the ones in the template's sample data. The assumption, issue and dependency entries are illustrations written for this walkthrough, so you can see how each type reads on the same project.

Step 1: Log and Score the Risks

Each risk gets a probability and an impact on a 1 to 5 scale. Multiply them and you get a score from 1 to 25. That number tells you where to spend your attention.

Here are six risks from the Northwind example, highest score first:

• R-001 SecureGrid assessment lands late. Owner: Jordan Ellis. Probability 4, impact 4. Score 16, High.
• R-002 Brightpath integration build slips. Owner: Jordan Ellis. Probability 4, impact 4. Score 16, High.
• R-004 State audit evidence deadline. Owner: Priya Raman. Probability 3, impact 5. Score 15, High.
• R-003 Scope additions exceed change authority. Owner: Jordan Ellis. Probability 4, impact 3. Score 12, High.
• R-005 Core team pulled back to operations. Owner: Jordan Ellis. Probability 3, impact 3. Score 9, Medium.
• R-008 Legacy ticket history migrates poorly. Owner: Marcus Bell. Probability 2, impact 4. Score 8, Medium.

Notice what makes these good entries. Each title names the event, not a vague category ("SecureGrid assessment lands late," not "vendor risk"). Each one has a single named owner. You're the conductor of the orchestra: you don't own every risk yourself, but you make sure every risk has someone who does. And the scores sort themselves, so the conversation in your next status meeting starts with the top three, not with whoever talks loudest.

Look at R-004 too. Its probability is only 3, so it's not the most likely thing on the list. But what happens if Northwind misses a state audit deadline? That's an impact of 5, the top of the scale. It's the kind of risk you watch closely even when it doesn't feel likely. That's why you score both dimensions instead of going on gut feel.

Step 2: Write Assumptions You Can Test

Assumptions are where projects quietly go wrong, because nobody writes them down. A good assumption entry says what you're assuming, what happens if it's false, and how and when you'll check.

Here's an illustrative entry for Northwind:

• A-001 Northwind's current ticket data can be exported in a format the new system can import.
• If false: migration needs a conversion step, which adds time and cost.
• Validate by: a test export of one month of tickets, owned by the data lead, before migration design is signed off.

See how that connects to R-008, the migration risk? When an assumption has a real impact if false, it often deserves a matching risk. Link the two so nobody has to remember the connection.

Step 3: Turn Risks That Happen into Issues

An issue is a risk that showed up, or a problem nobody predicted. The difference matters because they need different handling. A risk needs a plan to prevent it. An issue needs a plan to fix it, with a severity and a target resolution date.

Illustrative example: suppose SecureGrid confirms their assessment will arrive two weeks late. R-001 is no longer a risk. Close it as a risk and open an issue:

• I-001 SecureGrid assessment confirmed two weeks late.
• Severity: High, because it sits on the path to go-live.
• Owner: Jordan Ellis.
• Action plan: resequence testing so work that doesn't depend on the assessment moves first, and tell the sponsor this week.
• Linked to: R-001.

Notice that last step in the action plan, right? You have to manage up as well as down. Your sponsor should hear about I-001 from you, with your plan attached, before they hear it anywhere else.

The link back to R-001 keeps the history. Six months from now, anyone can see the risk was flagged early and handled, which is exactly the record you want. If your project runs a lot of issues, a dedicated Issue Log gives them more room.

Step 4: Track Dependencies in Both Directions

Dependencies are handoffs. Some come in to you (you're waiting on someone), and some go out from you (someone's waiting on you). Log both, because your outbound commitments are somebody else's risk.

Here are two illustrative entries for Northwind:

• D-001 (inbound): Brightpath's integration build is needed before end-to-end testing. Needed by a set date, owned on the Brightpath side by their delivery lead, tracked on our side by Jordan Ellis.
• D-002 (outbound): Northwind owes the state auditor its evidence package by the audit deadline. Owned by Priya Raman.

D-001 also lines up with R-002, the Brightpath slip risk. When a dependency's committed date moves, check its linked risk right away. When cross-team handoffs pile up, sketch them on a Dependency Map so everyone sees the chain.

The Weekly 20-Minute RAID Review

A RAID log isn't a filing cabinet. It works when you look at it on a rhythm. Once a week, go through it in this order:

1. Risks: re-score anything where the facts changed, and confirm every High risk has a mitigation step with an owner and date.
2. Assumptions: check which ones are due for validation, and turn any that proved false into a risk or an issue.
3. Issues: confirm each open issue has a next action and a target date. Escalate anything past its date.
4. Dependencies: compare needed-by dates with committed dates, and chase anything that slipped.

I stay ready, so I don't have to get ready. Twenty minutes a week on this log is how you stay ready.

Use AI to Sort Your Notes into RAID

The hardest part of a RAID log isn't the format. It's deciding what each item is. This prompt does the first sort for you. (For a version that works straight from a meeting transcript, see workflow 1 in 5 AI Workflows for Project Managers.)

Sort the project notes below into RAID log candidates.

Definitions:
- Risk: might happen, has not happened yet, would affect the project
- Assumption: treated as true for planning, not yet proven
- Issue: happening now and needs action
- Dependency: something we need from others, or others need from us

For each candidate give:
- Type (Risk, Assumption, Issue, Dependency)
- A specific title that names the event (not a category)
- Owner, only if the notes name one; otherwise "Unassigned"
- For risks: suggested probability and impact (1 to 5) with a one-line reason
- For assumptions: what happens if it is false
- The sentence from the notes that supports it

Do not invent owners, dates or facts. If an item could fit two types,
list both and say why.

Notes:
[PASTE MEETING NOTES, EMAILS, OR STATUS UPDATES]

Common RAID Log Mistakes

• Logging categories instead of events. "Resourcing" isn't a risk. "Core team pulled back to operations" is.
• Leaving risks open after they happen. Once a risk occurs, it's an issue. Move it and link it.
• Assigning owners to teams. "IT" can't be accountable. A person can.
• Never validating assumptions. An untested assumption is a risk you haven't scored yet.
• Only tracking inbound dependencies. What you owe others can slip too.

Frequently Asked Questions

What does RAID stand for in project management?

RAID most often stands for Risks, Assumptions, Issues and Dependencies. Some teams swap in Actions for Assumptions or Decisions for Dependencies. Pick one meaning, write it at the top of your log, and use it consistently.

What is the difference between a risk and an issue?

A risk is something that might happen and would affect the project if it did. An issue is something that is happening now. When a risk occurs, close it as a risk and log it as an issue with an owner and a resolution date.

How often should you update a RAID log?

Update it after every working session where something new comes up, and review the whole log once a week. Check open items for a current owner, a next action and a date, and close anything that is resolved.

Want this example in a working spreadsheet? The RAID Log template includes the full Northwind sample project, automatic risk scoring, a Mitigation Log and a dashboard across all four logs. Need actions and decisions too? Choose the RAID + Actions and Decisions Log. To practice running logs like this with live coaching, join the six-week ProjectMentorPro Foundations cohort.