What Is a RAID Log in Project Management? A Plain-English Guide

## The short answer

A RAID log is a single living document that a project or programme uses to capture and track four categories of information: **Risks, Assumptions, Issues and Dependencies**. It exists so that the things most likely to derail delivery are written down, owned by someone, reviewed regularly, and acted on before they become surprises. If you only take one thing away: a RAID log is a memory and accountability tool, not paperwork for its own sake.

Most delivery managers, PMO leads and project sponsors keep a RAID log because human memory is unreliable and projects are too complex to hold in one person's head. Writing things down in a structured way turns vague worry into something you can manage.

## What each letter means

- **Risks** are things that *might* happen and would have a negative (or sometimes positive) effect if they did. They are uncertain and future-facing. Example: "A key supplier may not deliver test environments on time."

- **Assumptions** are things you are treating as true in order to plan, but which haven't been confirmed. Example: "We assume the finance team will be available for UAT in Q3." If an assumption turns out to be false, it often becomes a risk or an issue.

- **Issues** are problems happening *now*. They are certain, not hypothetical. Example: "The integration environment has been down for three days."

- **Dependencies** are things your work relies on from another team, project or third party, or things others rely on from you. Example: "We cannot go live until the data migration team completes its cleanse."

Some teams extend the acronym to **RAAID** (adding Actions) or **RAIDD** (separating decisions). The exact letters matter less than the discipline of capturing, owning and reviewing.

## Why these four sit together

The power of RAID is that the four categories are related and flow into one another. An unvalidated assumption can become a risk. A risk that materialises becomes an issue. A missed dependency can create both. Keeping them in one place makes those transitions visible, so you can intervene at the cheapest possible moment rather than firefighting at the end.

## What a good RAID entry contains

A useful entry is more than a one-line note. Each item should typically include:

- A unique **ID** so you can reference it in meetings and reports

- A clear **description** written so a newcomer understands it

- An **owner** (a named person, never a team)

- A **status** (open, in progress, closed)

- For risks: a **likelihood** and **impact** rating, plus a **mitigation** and a **contingency**

- For issues: an **action** and a **target resolution date**

- For dependencies: the **direction** (inbound or outbound) and the **due date**

- A **last updated** date so stale entries are obvious

## How a RAID log is used in practice

The log is reviewed on a regular cadence, often weekly within the delivery team and at a summary level in steering or board meetings. A typical rhythm looks like this:

1. The delivery manager opens the log before each team checkpoint.

2. New items raised during the week are added.

3. Existing items are reviewed: has anything changed, has a risk materialised, can anything be closed?

4. The highest-priority items feed into the project status report and any escalations.

The log should never be a write-once document that nobody reopens. A RAID log that hasn't been updated in a month is usually a sign of a project drifting.

## Common misunderstandings

- **"RAID is just a risk register."** A risk register is only the R. RAID is broader and deliberately joins the four together.

- **"It's the PMO's job to fill it in."** The PMO may own the template and cadence, but the content belongs to the people doing the work.

- **"More entries means better governance."** A bloated log with hundreds of trivial items hides the few that matter. Quality and currency beat volume.

## When to start one

Start at project initiation, not when trouble appears. Early assumptions and dependencies are some of the most valuable things to capture because they shape the plan. As work progresses, the centre of gravity naturally shifts from assumptions and risks towards issues.

At neart.ai we build enterprise-grade delivery and PMO products, and we consistently see that teams who treat the RAID log as a live conversation rather than a static spreadsheet spot trouble earlier and escalate with far more confidence.

## Practical takeaway

Set up your RAID log on day one, give every item a named owner and a last-updated date, and review it on a fixed weekly cadence. Keep it lean enough that the entries that truly matter stay visible. A RAID log only protects your project if it stays alive.