The RAID Log: Discipline That Makes Audit Week Painless

The RAID log is the single most important operational artefact in a complex programme, and the most consistently misused. Teams maintain it because the steering pack demands it. They produce a slide deck each week with a heatmap. The log itself is a spreadsheet with 40 rows, 15 of which have not been updated in three months, and when a risk materialises everybody is surprised because the log said it was being managed.

In regulated delivery, this pattern has specific consequences. The RAID log is one of the first documents an internal auditor asks for, and one of the first pieces of evidence a senior manager with attested accountability relies on. A log that is kept ceremonially rather than seriously is worse than no log at all, because it creates the illusion of control.

This post covers how to run a RAID log as a live operational tool, the discipline that distinguishes serious logs from ceremonial ones, and the specific patterns that work in regulated programmes.

What RAID actually means

RAID is an acronym: Risks, Assumptions, Issues, Dependencies. Each of the four has a specific discipline and a specific failure mode.

Risks

Future events that might happen and would materially affect the programme. Each risk has a probability, an impact, an owner, a mitigation plan, and a contingency plan. The mitigation reduces the probability or impact. The contingency is the response if the risk materialises despite the mitigation.

Assumptions

Things the programme is taking as true without verification, often because verifying them is expensive or impossible. Assumptions become risks when their validity is questioned and issues when they are proven false. Tracking assumptions explicitly is what prevents the "we always assumed X was true" surprise at month six.

Issues

Problems that are happening now. Not future events. Actual blockers, actual resource gaps, actual scope disagreements. Issues have owners, resolution plans, and target resolution dates. An issue with no target date is an item destined to age silently.

Dependencies

Things outside the programme's direct control that the programme needs: another programme's deliverable, a vendor decision, a regulatory ruling, a third-party integration window. Dependencies have owners (usually external), due dates (usually aspirational), and escalation paths for when they slip.

Why the RAID log matters more in regulated programmes

Regulated delivery has three properties that raise the stakes on RAID discipline.

Attested accountability

Under the SMCR and equivalent regimes, senior managers have personal accountability for specific domains. When a programme affects their domain, they rely on the RAID log to understand where the risks are and whether they are being managed. A log that fails to disclose material risks exposes the SMF to attestation risk they cannot manage.

Regulatory surprise intolerance

Regulators can accept bad news on time. They cannot accept bad news late. A risk that materialises and was never in the log is treated more seriously than a risk that was disclosed, managed and still crystallised, because the former suggests a governance failure while the latter suggests a difficult situation honestly handled.

Audit trail requirements

The RAID log is evidence of programme governance. Its completeness and currency is examined by internal audit, external audit, and supervisory reviews. A log with obvious gaps implies a programme that is not in control of itself.

The structural disciplines

Every item has an owner

Items without owners die. The RAID log discipline is that no item enters the log without an owner, and no item survives review if its owner has changed without reassignment. Ownership is at the individual level, not the team level.

Every item has a next action and a review date

The next action is specific. "Monitor" is not an action. "Meet with the vendor technical lead on 22 April to confirm their position on the data migration window" is an action. The review date is when the next assessment of the item happens. If the review date passes without an update, the item surfaces as overdue.

Every material risk has a mitigation plan and a contingency plan

The difference matters. The mitigation reduces the risk. The contingency is what happens if mitigation fails. Items without a contingency are often over-reliant on mitigation optimism. The contingency section forces the conversation about acceptable fallbacks.

Assumptions are challenged, not left unchallenged

The discipline that separates serious programmes from ceremonial ones is the regular assumption challenge. Every two to four weeks, the programme reviews its assumptions and asks what evidence now exists to support or invalidate each one. Assumptions that have become issues are moved to the issues section. Assumptions that have been validated are retired.

Weighting and prioritisation

Not every risk is equal. A simple 5x5 probability-impact matrix works for most programmes. What matters is that the matrix scoring is anchored to concrete consequences, not hand-waved.

Impact bands

For regulated programmes, impact bands should include explicit regulatory dimensions. Catastrophic: breach with regulatory reporting, SMF exposure. Severe: significant operational or financial impact, supervisory attention likely. Moderate: programme-internal impact, no regulatory exposure. Minor: cost or schedule impact only. Negligible: below reporting threshold.

Probability bands

Probability is famously hard to estimate. Use calibrated bands: very high (more likely than not within the remaining programme timeline), high (significant chance), medium (credible possibility), low (possible but not expected), very low (tail risk, track but do not actively manage).

Escalation triggers

The matrix cells drive escalation. Risks in specific cells (typically catastrophic regardless of probability, or severe at medium or higher probability) escalate to the SMF and the steering committee. The log should document the escalation trigger so the escalation is not surprise.

Patterns that work in regulated scope

Pattern one: the weekly rhythm

RAID review happens weekly with a fixed rhythm. The programme manager chairs a 30-minute session where every item with a review date in the past week is discussed. Items are updated, closed or escalated. The rhythm is the discipline.

Pattern two: the two-tier log

A working log for the delivery team and a governance log for the steering committee. The working log has all items, including minor ones. The governance log has only items above a threshold of materiality. The governance log is derived from the working log, not maintained separately.

Pattern three: integrated with the change impact assessment

When scope changes, the RAID log is reassessed in the same session. New risks introduced by the change, assumptions that become questionable, dependencies that shift. The two artefacts (change impact assessment and RAID log) are tightly coupled.

Pattern four: risks with specific triggers

Good risk entries have named triggers that would cause the risk to materialise. "If the vendor does not confirm the data migration plan by 15 May, the September go-live is at risk". This lets the programme manage forward against specific dates rather than reacting to vague deterioration.

Common failure modes

Failure: the log of everything

The log has 120 items. Most are trivial. Nobody reads all 120 items. Material items hide in the noise. Fix: a materiality threshold below which items are tracked in the team's own tools (Jira, for example) and above which they enter the RAID log. The log is for items that merit steering attention.

Failure: the log of nothing material

The log has 15 items, all of them minor. The material risks are not in the log because they are politically uncomfortable to write down. Fix: a culture that rewards honest disclosure. The SMF and the steering committee should make it explicit that omitted risks are worse than disclosed risks.

Failure: the ageing log

Items were entered in month one and never updated. Their status is whatever it was in month one. Reality has moved on. Fix: a review date on every item, and a weekly review rhythm that forces updates.

Failure: the risk-mitigation-as-aspiration

Mitigation plans are written as aspirations, not actions. "The team will work closely with the vendor to ensure the data migration is successful." This is not a mitigation. A mitigation specifies what action is taken, by whom, by when, to reduce probability or impact. Fix: mitigation plans are written as actions with owners and dates.

Failure: dependencies tracked as risks

Dependencies are different from risks. A risk has a probability; a dependency is a thing that must happen. Tracking dependencies as risks distorts the log. Fix: dependencies are a separate section with their own structure: what is needed, from whom, by when, what happens if it slips.

Connection to other artefacts

The RAID log does not live alone. It connects to:

• The stakeholder register: risks and dependencies often involve specific stakeholders.
• The change impact assessment: material changes generate new RAID entries.
• The requirements traceability matrix: risks sometimes attach to specific requirements.
• The decision log: when a risk is accepted or a contingency invoked, the decision is recorded separately.

These links are what turn the RAID log from a standalone spreadsheet into an integrated governance artefact.

External references

The APM Body of Knowledge covers risk management as a project management discipline. The ISO 31000 risk management standard provides a broader framework applicable to regulated settings. The FCA guidance on operational resilience covers the broader risk discipline that frames RAID in the UK financial services context.

The short version

The RAID log is either a live operational tool or a ceremonial deliverable. The difference is discipline: ownership on every item, specific next actions, review dates, a weekly rhythm, honest disclosure culture, and integration with the broader artefact stack.

Programmes that invest in the log as a live tool find that audit week, steering committees, and senior manager briefings become straightforward. Programmes that run the log as a slide-deck exercise find that the same events are stressful because the real state of the programme is not in the log.

If you are inheriting a programme where the RAID log has drifted, or setting up a new programme that needs the discipline from the start, our business analysis service and change management and adoption service both cover the RAID discipline as part of the integrated delivery stack.