RAID Log vs Risk Register: What's the Difference and When to Use Each

## The short answer

A **risk register** tracks one thing: risks (uncertain future events that could affect the project). A **RAID log** is broader: it tracks Risks, Assumptions, Issues and Dependencies together in one connected document. Put simply, a risk register is a subset of a RAID log. You use a standalone risk register when risk is the dominant governance concern; you use a RAID log when you want a single place to manage the full set of delivery uncertainties and the ways they interact.

They are not competitors. On many programmes the risk register *is* the R section of the RAID log, just maintained with extra rigour.

## What each tool is built to do

**Risk register.** Its job is depth on risk. A mature register usually carries probability and impact scores, a calculated risk exposure, mitigation and contingency plans, risk owners, proximity (how soon the risk could hit) and sometimes a quantified cost or schedule effect. In regulated or high-assurance environments it may follow a formal methodology and feed enterprise risk reporting.

**RAID log.** Its job is breadth and connection. It accepts that risks rarely exist in isolation: an unproven assumption can spawn a risk, a risk that lands becomes an issue, and a missed dependency can cause all three. By sitting these four categories side by side, the RAID log makes those relationships visible and keeps the whole delivery picture in one view.

## A quick comparison

- **Scope** — Risk register: risks only. RAID log: risks, assumptions, issues, dependencies.

- **Time orientation** — Risk register: future/uncertain. RAID log: spans past assumptions, present issues and future risks.

- **Typical depth per risk** — Risk register: high (scoring, exposure, proximity). RAID log: moderate, balanced across categories.

- **Best suited to** — Risk register: risk-heavy, assurance-driven contexts. RAID log: general delivery management.

- **Audience** — Risk register: risk committees, assurance, sponsors. RAID log: delivery team, PMO, steering group.

## When to use a standalone risk register

Reach for a dedicated risk register when:

- You operate in a **regulated or safety-critical** domain where risk must be evidenced to a defined standard.

- Risks need to **roll up to an enterprise or portfolio risk framework** with consistent scoring.

- The volume or complexity of risks is high enough that they need their own analytical treatment, such as quantitative modelling.

- An audit or assurance function requires a clear, isolated risk artefact.

## When to use a RAID log

Reach for a RAID log when:

- You are running a **typical project or programme** and want one place to manage delivery uncertainty.

- Your assumptions and dependencies are as likely to hurt you as your risks (which, in practice, is most projects).

- You want a lightweight cadence the **whole delivery team** can engage with, not just a risk specialist.

- You need a single artefact to drive weekly reviews and feed status reporting.

## Can you run both?

Yes, and large programmes often do. The common pattern is a RAID log for day-to-day delivery management, with the most significant risks promoted into a more rigorous risk register (or an enterprise risk tool) for formal scoring and board-level oversight. The key is to avoid two diverging sources of truth: decide which artefact is authoritative for each risk and keep the link between them explicit, for example by sharing the same risk ID.

## The trap to avoid

The most common failure isn't choosing the "wrong" tool, it's maintaining two overlapping lists that drift apart. When a risk is updated in one place but not the other, people lose trust in both, and the governance becomes theatre. Decide on one source of truth per item, and make the relationship between the register and the log unambiguous.

At neart.ai we build enterprise-grade delivery and PMO products, and the pattern we see work best is a connected model: assumptions, issues and dependencies live alongside risks, while the highest-severity risks carry the extra scoring rigour a register demands, without being copied into a second disconnected spreadsheet.

## Practical takeaway

If you're unsure, start with a RAID log: it covers more ground and suits most projects. Add a dedicated risk register only when assurance, regulation or risk volume genuinely demands deeper, standalone treatment, and if you run both, nominate one source of truth per risk so they never contradict each other.