What Is a RAID Log, and Why Does It Keep Dying?

A RAID log is a structured register that tracks four categories of project intelligence: Risks (things that might go wrong), Actions (tasks requiring follow-through), Issues (risks that have already materialized), and Decisions (choices made and the rationale behind them). It is foundational to delivery governance and a core artifact in any Agile or PRINCE2 environment.

So why does it fail so consistently? In my experience leading higher education SaaS implementations and public sector transformation programs, the RAID log dies for one of three reasons:

  1. It becomes a dumping ground rather than a decision tool, entries added but never reviewed.
  2. It is owned by one person (usually the PM) rather than the whole team.
  3. It has no connection to meetings or milestones, it sits in a SharePoint folder while the real conversations happen in Teams chats.

The result is a project team that loses institutional memory, repeats the same mistakes, and is blindsided by risks they had already documented. I have walked into programs where a critical vendor dependency was logged as a risk six weeks earlier, and nobody had reviewed the register since.

Five Principles for a RAID Log That Stays Alive

1. Make It the Single Source of Truth for Governance Conversations

The RAID log should be opened at the start of every status call, sprint review, and steering committee. Not referenced, not mentioned, opened. If it is not on the screen during the meeting, it does not exist. This sounds obvious, but most teams treat the log as a documentation exercise and their verbal updates as the real governance. Those two things need to be the same thing.

In a recent program I led supporting a public sector client through a multi-phase SaaS implementation, we built RAID review into the standing agenda as the second item, right after the headline status update. That alone cut the average time-to-resolution on flagged risks by about 40%.

2. Every Entry Needs an Owner and a Due Date

A risk without an owner is a wish. A decision without a date is a rumour. Every row in your RAID log must have a named individual, not a team, not a workstream, and a specific date by which the entry will either be resolved, escalated, or re-assessed. This is non-negotiable.

When entries have no owner, the implicit owner is the project manager, which creates a bottleneck and creates resentment. When entries have no due date, they drift indefinitely. Both kill the log.

3. Separate Risks from Issues, and Treat Them Differently

Risks are probabilistic. Issues are live. They need different columns, different owner dynamics, and different escalation thresholds. A risk rated High/High (high probability, high impact) should trigger a mitigation plan. An issue that has broken a dependency should trigger an immediate escalation path to the sponsor or governance committee.

Many templates conflate the two, which leads to teams treating active issues with the passive management style appropriate for risks. By the time someone realizes the issue has cascaded into a programme-level problem, it is too late to contain.

4. Keep the Format Ruthlessly Simple

Your RAID log does not need fifteen columns. The minimum viable register has: ID, Category (R/A/I/D), Description, Owner, Date Raised, Due Date, Status, and Notes. That is eight fields. You can add probability and impact scoring for risks, but resist the urge to add sub-categories, traffic light formulas, and linked JIRA tickets until the team is actually using the base version consistently.

Complexity is the enemy of adoption. I have seen beautifully designed RAID log templates that nobody filled in because the barrier to entry was too high.

5. Archive, Do Not Delete, Resolved Entries

Resolved risks and closed decisions are project history. When you delete them, you lose the rationale, the context, and the learning. Move resolved entries to an Archive tab rather than deleting rows. This matters especially when new team members join mid-program, or when a closed risk re-opens (which happens more often than people expect).

In ISO 27001 audits and post-implementation reviews, the decision log in particular is invaluable, it shows auditors and stakeholders that governance was applied with intention, not improvised after the fact.

“A risk without an owner is a wish. A decision without a date is a rumour. The RAID log is not a documentation exercise, it is the governance backbone of your program.”

– Atin Sood, PSM II | ITIL v4 | ISO 27001 Auditor

A Worked Example: Public Sector SaaS Implementation

In a recent $10M+ higher education SaaS implementation I supported, the program had inherited a RAID log from a previous phase that contained 47 entries, most of them undated, most of them unowned. The team had essentially stopped looking at it.

We reset the register in the first governance review: archived everything older than four weeks, re-validated current risks with the workstream leads, assigned owners to every open item, and moved it into the standing weekly status call agenda.

The immediate effect: three issues that had been sitting as passive risks were escalated to the steering committee within the first two weeks. One of those escalations prevented a vendor delay from becoming a go-live blocker. The sponsor specifically cited the RAID governance as a differentiator in the mid-program satisfaction review, it was one of the factors that contributed to a final NPS of 9.8/10 from the client team.

The Bottom Line

RAID log best practices are not about the template, they are about the behaviours you build around the register. Open it in every meeting. Give every entry an owner. Treat issues as live fires and risks as monitored hazards. Keep the format simple enough that filling it in takes less time than complaining about it.

A RAID log done well is the closest thing a project has to an institutional memory. Done poorly, it is the artifact everyone points to after things go wrong and says: “We had that in the log.”