RAID Log

A RAID log keeps track of the things that could derail a project or are already causing problems. RAID stands for risks, assumptions, issues and dependencies, though some organizations use actions or decisions in place of assumptions or dependencies. Each item is recorded with a description, an owner, an assessment of its importance and the actions planned to deal with it. Reviewing the log regularly keeps these items visible, so they are managed rather than forgotten. The same log also gives a new team member or sponsor a quick picture of what could go wrong and what is already being handled.

The RAID log is one of the simplest and most widely used project controls. It needs nothing more than a spreadsheet or a list in a project tool, yet it often reveals problems earlier than status reports do. For portfolio leaders and PMOs, RAID logs from individual projects can be combined to show common risks, shared dependencies and recurring issues across the portfolio, which helps leaders decide where intervention is needed.

Definition of a RAID Log

A RAID log is a structured register used to identify, record, assess and track a project's or program's risks, assumptions, issues and dependencies throughout its life.

It supports project governance by giving sponsors and steering committees a clear view of what needs attention, and it often feeds the RAG status reported for the project.

The Four Elements of RAID

Risks are uncertain events that could affect the project if they occur, such as a supplier delay or a key person leaving. Each is assessed for likelihood and impact. Risks can also be positive, such as an opportunity to reuse work from another project.

Assumptions are things the team believes to be true but has not confirmed, such as the availability of a system or the stability of requirements. If an assumption proves false, it can become an issue.

Issues are problems that are already affecting the project and need resolving, such as a missed deadline from another team or a defect blocking testing.

Dependencies are links between the project and other work, where one cannot proceed until the other delivers something. They are a frequent source of delay, especially in large portfolios. Dependencies can run in both directions, so a project may be waiting on others and holding up others at the same time.

Typical Fields in a RAID Log

Each entry usually includes an identifier, a description, the type of item, the date it was raised and the person who raised it.

Assessment fields record likelihood and impact for risks, severity for issues and the date by which dependencies must be met.

Management fields record the owner, planned actions, due dates, current status and any escalation.

Keeping the fields consistent across projects makes it possible to combine logs at program and portfolio level.

Importance of the RAID Log in Strategic Portfolio Management

The RAID log makes problems visible early. Recording risks and assumptions before they cause harm gives the team time to act.

It clarifies ownership. Every item has a named owner, which prevents risks and issues from being noticed by everyone and handled by no one.

It also supports portfolio oversight. Combining RAID logs shows where the same risk or dependency affects several projects, which may call for a portfolio-level response.

The RAID Log and Financial Management

Risks with significant cost impact can be quantified and used to set project and program contingency, so that reserves reflect actual exposure rather than a fixed percentage.

Issues that cause delays or extra work often have direct cost consequences. Tracking them helps explain variances between planned and actual spending.

Dependencies on other projects can affect when benefits are realized, which matters for cash flow and for business case assumptions.

At portfolio level, aggregated risk data supports portfolio risk management, helping leaders understand the overall risk carried by the organization's investments.

Common Challenges

RAID logs are often created at the start of a project and then neglected, so they no longer reflect the real situation.

Logs can become long lists of minor items that hide the few that matter. Regular pruning and clear assessment help keep the focus on significant items.

Teams sometimes confuse risks with issues, recording problems that have already happened as risks, which delays the response they need. Training teams on the difference, with a few clear examples, usually solves this.