Learn moreTalk to usDownload for free

Meeting canvases · Deliver and recover

RAID log: risks, assumptions, issues and dependencies, built in the meeting

A RAID log is one shared register of a project’s risks (what might go wrong), assumptions (what the plan takes as true without proof), issues (problems already happening) and dependencies (what you need from others, or they from you). Every entry has an owner, a status and a next step, and the team reviews it on a set rhythm, usually weekly.

Troopa builds the log during your project meeting on Teams, Zoom or Google Meet. Say “Hi Troopa, open a RAID log for the migration”, and each risk, assumption, issue and dependency the room names goes in its own quarter, with whoever takes it on.

Institute of Risk Management, Infrastructure Risk group: short guide to RAID →
Download Troopa, freeSee it worked through

14 days free, no card. Then $15 per seat, per month. Cancel any time. Last checked against the product on 21 October 2026.

Why RAID logs stop being read

  • It is set up at the kick-off and dead within weeks, and a stale log gives everyone false confidence.
  • Risks, issues and vague concerns are filed interchangeably, until nobody trusts the categories.
  • Items are owned by a team or a workstream, which means nobody in particular.
  • A risk happens and stays a risk on the log, instead of becoming the issue it now is.
  • The review is where problems are discovered for the first time, so it runs long and solves nothing.
  • Writing the log up after the meeting takes an hour, so it is done late or not at all.

How to keep a RAID log in a meeting with Troopa

  1. Step 1: Open the log

    Say “Hi Troopa, open a RAID log for the help desk migration”. In a client workshop, Troopa may offer one when the talk turns to what could go wrong.

  2. Step 2: Name things as they come up

    Say “that’s a risk” or “we’re assuming the vendor is ready in January”, and each item goes in its quarter, with its owner when somebody takes it.

  3. Step 3: Sort a risk from an issue

    When something on the log has already happened, say so, or drag it on the card: a risk that has happened is now an issue.

  4. Step 4: Review it on screen

    Present the log for the weekly review, so the room checks each entry and its owner together rather than discovering problems for the first time.

  5. Step 5: Bring it into the project’s log

    Download it as Excel or CSV and add it to the project’s own RAID log, where the team keeps it up to date between meetings.

A worked example: a help desk migration

A customer support team is moving to a new ticketing system by the start of March. Claire runs the project meeting on Microsoft Teams with Troopa open.

  1. Claire“Hi Troopa, open a RAID log for the help desk migration.”
  2. Dev“Risk: the migration could drop attachments. Sam, can you run a trial with five hundred tickets?”
  3. Sam“Yes, that one’s mine.”
  4. Claire“We’re assuming the vendor’s EU data centre is live in January. I’ll get that confirmed in writing.”
  5. Dev“Single sign-on isn’t a risk any more, it’s an issue: it’s already failing in staging. I’ll take it.”
  6. Claire“And we depend on IT security signing off before go-live. I’ll chase Priya there.”
RAID log: the board from the exampleA RAID log in four quarters. Risks: migration may drop attachments (Sam); agents not trained before cutover (Claire). Assumptions: vendor’s EU data centre live in January (Claire); old system read-only for a month (Dev). Issues: single sign-on failing in staging (Dev); two macros do not migrate (Sam). Dependencies: IT security sign-off before go-live (Claire); email routing change from IT (Dev).RAID logHelp desk migrationDownloadPresentRisks2Migration may drop attachmentsSamAgents not trained beforecutoverClaireAssumptions2Vendor’s EU data centre live inJanuaryClaireOld system read-only for a monthDevIssues2Single sign-on failing in stagingDevTwo macros do not migrateSamDependencies2IT security sign-off beforego-liveClaireEmail routing change from ITDev2 risks · 2 assumptions · 2 issues · 2 dependencies
The log after the first pass: two items in each quarter, each with one owner, and single sign-on filed under Issues rather than Risks because Dev pointed out it was already happening.

Where RAID logs are expected

  • UK public sector

    Major government projects keep a RAID log that gate reviewers expect to see, with the risk register inside it; councils and grant applicants are often asked for one too. The programme board reviews it monthly.

  • Energy and regulated industries

    Industry design groups working on regulatory change keep a public RAID log, where every assumption carries a note of how and when it will be checked.

  • Construction and infrastructure

    Material prices, weather, subcontractors and utility connections: the dependencies outside the site team’s control, each with a named contact on the other side and a date it is needed by.

  • Healthcare operations

    A service change or a new system going live, where the RAID log keeps the project honest week to week. Project risks only, never clinical ones, and always called a RAID log, since in the NHS “RAID” alone names a liaison service.

  • Professional services and agencies

    A client implementation where many dependencies are the client’s own, such as access, assets and approvals, each with a named client contact, reviewed together on the weekly client call.

  • Software and fintech

    A payments migration that depends on a partner bank’s test environment and assumes a regulatory approval date: both on the log with owners, so a slip shows up the week it happens.

A RAID log template and a weekly review agenda

Agree what counts as a risk, an issue, an assumption and a dependency before the first entry, and give every entry one named owner. Keep personal details off the log.

Project: [name]    Owner of the log: [name]    Reviewed: [weekly, in the status meeting]

ID   | Type       | What                         | Owner  | Status     | Next step and date
R-01 | Risk       | [cause, event, effect]       | [name] | open       | [mitigation] by [date]
A-01 | Assumption | [what we take as true]       | [name] | to check   | [how and when we check it]
I-01 | Issue      | [what is happening, impact]  | [name] | open       | [fix] by [date]
D-01 | Dependency | [what, from or to whom]      | [name] | waiting    | needed by [date]

Risks: likelihood 1-5 x impact 1-5 = score; what we do if it happens
Assumptions proved wrong become risks or issues; risks that happen become issues

Weekly review (10 to 15 minutes)
1. New items since last week
2. Anything unchanged for two reviews: escalate
3. Assumptions due to be checked before the next milestone
4. Close what is done, with a reason

Questions for a RAID review

  • What could still stop us hitting the date or the budget?
  • What are we treating as true that nobody has checked, and who can confirm it by when?
  • What is already hurting us this week?
  • What are we waiting on from someone else, and who is waiting on us?
  • Who owns this, by name, and what happens next?
  • At a project’s kick-off, run a RAID analysis: ten minutes on each of the four quarters in turn.
  • Some teams read the A as actions and the D as decisions: agree your four letters before the first entry.
Association for Project Management, Competence framework: planning and managing deployment →

Questions about RAID logs

What does RAID stand for in project management?

Risks, assumptions, issues and dependencies, the form used in UK government gate reviews and by the Association for Project Management and the Institute of Risk Management. Some organisations read the A as actions and the D as decisions; what matters is that the team agrees its four letters.Institute of Risk Management, Infrastructure Risk group: short guide to RAID →

How is a RAID log different from a risk register?

A risk register goes deep on risks alone. A RAID log is broader, covering assumptions, issues and dependencies as well, and in UK government projects the risk register sits inside the RAID log as one of its parts.GOV.UK, Gate 2 review: delivery strategy →

What is the difference between a risk and an issue?

A risk might happen; an issue already has. When a risk happens it becomes an issue, with a fix and an owner rather than a mitigation, and keeping the two apart is what stops a RAID log becoming a list of worries.

How often should a RAID log be reviewed?

Weekly for most projects, as a short standing item in the status meeting, with a fuller look before each milestone and a monthly review by the programme board. Anything unchanged for two reviews in a row is worth escalating.

Who owns a RAID log?

The project manager usually owns the log itself, but every entry needs its own named owner, the person accountable for that risk, assumption, issue or dependency. An entry owned by a team is owned by nobody.

What is the difference between RAID and RACI?

A RAID log lists what could affect the project: risks, assumptions, issues and dependencies. A RACI chart says who is responsible, accountable, consulted and informed for each task. They answer different questions, and many projects keep both.

Sources

  1. Institute of Risk Management, Infrastructure Risk group: short guide to RAID
  2. GOV.UK, Gate 2 review: delivery strategy
  3. Association for Project Management, Competence framework: planning and managing deployment

Read on 15 October 2026, by the people who make Troopa.

Try it in your next meeting

Install Troopa on your Mac, Windows PC or Ubuntu computer, join your call on Teams, Zoom or Google Meet as you always do, and ask: “Hi Troopa, open a RAID log for the help desk migration.”

Download Troopa, freeWhat is kept, and where

14 days free, no card. Then $15 per seat, per month. Cancel any time.