Almost every delivery methodology tells you to keep a RAID log. Almost none of them tell you how to keep it alive past week three. The log gets created at kickoff, populated with a dozen entries, and then quietly abandoned while the real risk conversations happen in hallway chats and Slack threads no one can search later.
A RAID log earns its place on a project when it becomes the single place decisions get traced back to — not another status artifact nobody opens between steering committee meetings.
What actually belongs in each category
The four categories get blurred together constantly. Keeping them distinct is what makes the log useful for triage.
Risks
Something that might happen and would hurt the project if it did. Risks need a probability, an impact, and an owner — without those three fields, a risk is just a worry.
Assumptions
Something you're treating as true without confirmation, because confirming it would slow the project down. Assumptions are risks in disguise — if the assumption turns out false, it becomes a very live issue. Track them so you know which foundations under your plan are unverified.
Issues
Something that has already happened and needs resolution now. Issues should convert from risks the moment probability hits 100% — don't let a "risk" linger on the log after it's materialized.
Dependencies
Something your project needs from outside your direct control — another team, a vendor, a decision from a sponsor. Dependencies are where schedules quietly slip, because the delay isn't yours to fix directly.
Field note: if your log has fifteen "risks" and zero "issues," you're probably not tracking the log honestly — issues have almost certainly already occurred and just haven't been reclassified.
The structure that makes a RAID log usable
Every entry needs enough structure to support triage in under ten seconds. At minimum:
| Field | Purpose |
|---|---|
| ID | Stable reference number so entries can be cited in status reports and meeting notes. |
| Category | Risk, Assumption, Issue, or Dependency — never mixed. |
| Description | One or two sentences. If it needs a paragraph, it needs its own document linked from here. |
| Owner | A named individual, not a team. Teams don't close action items; people do. |
| Impact / Probability | For risks: rate both (High/Med/Low) to prioritize triage order. |
| Status | Open, Monitoring, Escalated, Closed — kept current, not aspirational. |
| Date raised / target date | When it was logged and when a decision or resolution is needed. |
| Mitigation / next action | The specific next step — not "monitor," which is not an action. |
The review cadence that keeps it alive
- Weekly working review. The PM and workstream leads scan every open item — five minutes per item, no exceptions. Anything stale gets a decision: escalate, close, or update.
- Bi-weekly or monthly steering review. Only High-impact and Escalated items go in front of sponsors. Don't make executives wade through the full log.
- Retrospective sweep at phase gates. Before moving from design to build, or build to test, review every open item and ask whether the upcoming phase changes its status.
Common mistakes that quietly kill a RAID log
- No owner, or "the team" as owner. Unassigned risks never get mitigated — they just get older.
- No target date. Without a date, an item sits at "Open" indefinitely with no forcing function to revisit it.
- Treating it as a historical record instead of a working tool. If closed items are never archived and the log becomes 300 rows long, no one will scroll through it during a live discussion.
- Keeping it invisible to the team doing the work. If only the PM sees the log, workstream leads have no reason to flag new risks proactively.
RAID logs on ServiceNow projects specifically
On ServiceNow implementations, recurring RAID categories worth watching closely include: integration endpoints that behave differently in production than in the vendor's sandbox, licensing/entitlement assumptions that turn out wrong once actual user counts are confirmed, and dependencies on other teams' CMDB data quality. See our companion guide on PM fundamentals for ServiceNow projects for how these risks map to the broader project plan.
Who should own the RAID log
The PM typically owns the log administratively — keeping it current, chasing stale entries, and preparing the steering-committee summary — but ownership of individual entries belongs to whoever is closest to resolving them. A common mistake is having the PM personally own every entry's mitigation, which turns the PM into a bottleneck and quietly signals to the rest of the team that risk-spotting isn't their job. Make it explicit in a kickoff or team charter that any team member can and should raise a new RAID entry, not just leads.
Where to start
You don't need custom tooling to run a good RAID log — a shared spreadsheet with the fields above, reviewed weekly with real discipline, will outperform an elaborate tool used sporadically. ClearPath PM's RAID Log template is built around exactly this structure and is available now for $3.99 as an instant download.