RAID Log Explained: Risks, Assumptions, Issues, and Dependencies in Real Projects

RAID Log Explained in One Sentence

A RAID log is a working project document that tracks risks, assumptions, issues, and dependencies so the team can see what might go wrong, what is currently wrong, what you are taking for granted, and what other work your project is waiting on. The value is not the acronym itself. The value is forcing those four categories apart, because each one needs a different response.

What each RAID category means

Category	What it is	Typical response
Risk	A possible future problem	Mitigate, monitor, or accept
Assumption	Something the plan currently treats as true	Validate or replace with evidence
Issue	A problem that is already happening	Assign an owner and escalate resolution
Dependency	Work your project needs from someone else	Sequence, negotiate, and follow up

Why beginners confuse issues and risks

If the vendor has not delivered the asset yet and the due date is next week, that may still be a risk. If the due date passed and your work is blocked now, it is an issue. Good project managers label that change correctly because leadership should see whether the team is managing uncertainty or actively dealing with a delay. A RAID log becomes much more useful when those states are not blended together.

A practical example

Imagine a website migration project. The team assumes the marketing team will approve new copy within three business days. That belongs in the assumption section until validated. The team also knows the analytics implementation depends on one engineer from another department being available next Thursday. That is a dependency. A possible risk is that the redirect map may not cover legacy blog URLs, which could hurt launch quality. If launch week arrives and the redirect map is still incomplete, the item moves from risk to issue.

What a useful RAID log includes

A clear statement of the item in plain language.
An owner who is accountable for next action.
A date or milestone when the item matters.
Status notes that tell you what changed since last review.
An action field, not just a label.

How teams use a RAID log in weekly cadence

The strongest teams do not review every line item with equal energy. They ask four fast questions: what changed, what is becoming time-critical, what needs escalation, and what assumption still has no proof behind it? That keeps the log tied to decision-making instead of turning it into a clerical ceremony.

For new PMs, this connects directly to the communication and tracking habits taught throughout the certificate. The same discipline you use in stakeholder planning and status updates should show up here. If you want supporting context, pair this page with what the certificate actually teaches and the six-course breakdown.

What not to put in a RAID log

Every normal task from the project plan.
Vague statements like “communication may be difficult.”
Risks with no trigger or impact described.
Issues with no owner.
Assumptions that nobody intends to validate.

A quick RAID example row set

Type	Item	Owner	Next action
Risk	Procurement approval may take longer than planned	PM	Confirm review timeline with finance by Tuesday
Assumption	Users can migrate without retraining	Change lead	Validate with pilot group
Issue	QA found sign-in failure on staging	Engineering lead	Patch and retest before release review
Dependency	Legal must approve updated privacy language	Marketing lead	Escalate review deadline in weekly status

Why this matters in real PM work

RAID logs are popular because they turn fuzzy project talk into categories people can act on. They also make status reporting cleaner. “We have one issue, two major risks, and one unresolved dependency” is a much better executive summary than a paragraph full of soft warnings.

FAQ

Is a RAID log required in every project?

No. Small projects may not need a formal log, but every project still needs a way to track these four kinds of uncertainty.

Can one item move between RAID categories?

Yes. A risk often becomes an issue once the problem occurs.

Should assumptions stay in the log forever?

No. They should either be validated, revised, or removed.

Project-management terminology in this article reflects standard certificate-level usage current as of May 24, 2026. Organizations format RAID logs differently, but the category logic and operating purpose described here remain consistent across common PM workflows.