RAID log generator
The RAID log your meetings keep dictating.
Every steering committee and planning call is full of risks, assumptions, issues and dependencies, spoken out loud and then lost. Backlog.cloud captures them as structured RAID entries with owners, likelihood and mitigation, each traced to the exact quote it came from. Being upfront: the free browser tool on this site returns truncated backlog items only, and RAID generation runs inside the product where it can use the full conversation.
What this page does instead: a worked example from a steering committee, the reason most RAID logs die, and a starter structure you can copy today.
The definition
Four letters, four different kinds of trouble
A RAID log is one register for the four things most likely to derail a project. Risks: problems that could happen, tracked with likelihood, impact and a mitigation. Assumptions: things the plan treats as true without proof, tracked until validated. Issues: problems that are happening now, tracked with an owner and an action. Dependencies: things outside your control the plan needs, tracked with what they block.
The tense distinction does real work. A risk that materialises becomes an issue. An assumption that fails becomes an issue too, usually an expensive one, because the plan was built on it. A good log shows those transitions instead of hiding them.
Some teams add two more letters and track Actions and Decisions in the same register. Backlog.cloud generates those as their own artefact types, an action items list and a decision log, alongside the RAID log itself. Same meetings, separate registers, so each one stays scannable.
The uncomfortable bit
Why most RAID logs are dead on arrival
Maintained nowhere, updated never. The log lives in a spreadsheet with a name like RAID_v3_FINAL, owned by whoever set it up, opened the night before a governance review. The entries are whatever that person could reconstruct from memory, which means the risks are the obvious ones and the assumptions are missing entirely, because nobody remembers what they assumed six weeks ago.
The failure is not discipline, it is physics. The moments that belong in the log happen in meetings, at conversational speed, while the person who maintains the log is busy chairing the meeting. Asking them to also capture likelihood, impact, owner and mitigation in real time is asking them to be two people.
So the log gets retrofitted quarterly, which is the polite way of saying invented. A register built that way protects nobody. When the assumption about branch headcount fails in November, the question "when did we know?" has no answer, because the moment it was said out loud was never written down.
Worked example
One steering committee, four RAID entries
A curated example in the exact shape the product produces. Six lines from a programme steering committee on a claims platform migration, and the entries generated from them. Every entry cites its source.
1. What was said in the steering committee
Fiona (Programme lead): Straight to the claims platform migration. Raj, where did the dry run land?
Raj (Delivery lead): Four percent of policy records came through unmatched. If the second dry run in October is the same, we cannot cut over in November. I want a decision gate after that run.
Dele (Ops manager): Noted. On training, we are planning the branch schedule on the basis that the network keeps its current headcount through Q4. If the restructure lands early, that plan is fiction.
Raj (Delivery lead): One more. The payments provider still has not provisioned our test sandbox. Three weeks late now, and integration testing cannot start until it exists.
Priya (Finance): And the licence renewal quote came in 18 percent over the budget line. That is not a maybe, it is on my desk today.
Fiona (Programme lead): Right. Raj takes the matching rules and chases the sandbox, Priya takes the renewal back to the vendor, and Dele, get the headcount answer from HR before the next steering.
2. The RAID entries generated from it
November cutover slips if policy record matching does not improve
- Likelihood:
- Medium
- Impact:
- High
- Mitigation:
- Revise matching rules before the October dry run. Decision gate after that run: proceed, fix forward, or move the cutover date.
- Owner:
- Raj
"If the second dry run in October is the same, we cannot cut over in November. I want a decision gate after that run."
Branch network keeps current headcount through the Q4 training window
- Status:
- Unvalidated
- If wrong:
- The branch training schedule has to be rebuilt from scratch.
- Validation:
- Dele to confirm with HR before the next steering committee.
- Owner:
- Dele
"We are planning the branch schedule on the basis that the network keeps its current headcount through Q4."
Licence renewal quote is 18 percent over the approved budget line
- Severity:
- High
- Action:
- Take the renewal back to the vendor and renegotiate. Escalate to the programme board if the gap does not close.
- Owner:
- Priya
"The licence renewal quote came in 18 percent over the budget line. That is not a maybe, it is on my desk today."
Payments provider test sandbox, three weeks late, blocks integration testing
- Depends on:
- External vendor provisioning
- Blocks:
- All integration testing for the claims platform
- Action:
- Raj to chase weekly and report at each steering until provisioned.
- Owner:
- Raj
"The payments provider still has not provisioned our test sandbox. Three weeks late now, and integration testing cannot start until it exists."
Notice what did the classifying: tense and phrasing. The dry run result might repeat, so it is a risk. The licence quote already arrived, so it is an issue. "On the basis that" marks the assumption, and the sandbox belongs to someone else, so it is a dependency. Fiona's closing line also produces three action items, which land in the action items artefact rather than cluttering the RAID log.
Meeting by meeting
A log that grows continuously, not a quarterly retrofit
The fix for a dead RAID log is not more discipline, it is removing the transcription job. The meeting bot joins the steering committee, the sprint planning call or the kickoff from a pasted Zoom, Microsoft Teams or Google Meet link. No bot on the call? Paste the transcript or upload the recording afterwards. Either way the RAID entries are drafted minutes after the meeting ends, while the log owner was free to actually run the meeting.
Drafts wait in a review queue with their source quotes attached. You correct a likelihood, reassign an owner, discard a false positive, then approve. The reviewed entries join the project's RAID log, and because each carries its quote and its meeting, "when did we know?" always has an answer.
Approved entries can then push to your work management platform, Jira, Azure DevOps, Linear, GitHub Issues, Notion or ClickUp, so issues sit next to the delivery work they threaten. The wider workflow, one conversation into twelve artefact types, is covered on the meeting to backlog page.
Do it by hand
A manual RAID starter structure you can copy
No download form, just the columns. Set this up in whatever your team already opens daily, which is the single biggest predictor of whether the log survives.
| Column | How to use it |
|---|---|
| Ref | R-01, A-01, I-01, D-01. Stable, never reused. |
| Type | Risk, Assumption, Issue or Dependency. |
| Description | One or two sentences. What, and why it matters. |
| Owner | A named person. "The team" owns nothing. |
| Likelihood / Impact | Risks only. High, Medium or Low for each. |
| Mitigation or action | What is being done about it, concretely. |
| Status | Open, Mitigating, Validated, Closed. |
| Next review | A date. An entry without a review date is already dead. |
Two rules that keep it honest. Add entries within a day of the meeting that raised them, or the wording drifts from what was said. And walk the log at a recurring meeting, out loud, because a log nobody reads aloud is a log nobody updates.
FAQ
RAID logs, answered
- What does RAID stand for?
- Risks, Assumptions, Issues and Dependencies. A risk is a possible future problem, an assumption is something you are treating as true without proof, an issue is a problem that already exists, and a dependency is something outside your control that your plan needs. Some teams extend the log with Actions and Decisions, which turns RAID into RAAIDD in spirit if not in name.
- Is there a free RAID log generator on this page?
- No. The free browser tool on this site is limited to truncated story, bug and task drafts, and RAID entries sit outside that boundary, so generation runs inside the product where it works from the full conversation. A free account includes 3 generations covering all 12 artefact types, RAID log included, no card needed.
- What is the difference between a risk and an issue?
- Tense. A risk might happen, an issue is happening. In the worked example, the cutover slipping is a risk because the October dry run has not run yet. The licence quote being over budget is an issue because the quote already arrived. The distinction matters because risks get mitigation and monitoring, issues get actions and owners now.
- How does Backlog.cloud detect a risk in a meeting?
- From the language and context of the conversation. Conditional phrasing about future harm reads as a risk, statements of present fact about problems read as issues, "we are planning on the basis that" reads as an assumption, and reliance on an external party reads as a dependency. Every generated entry carries the verbatim quote it was derived from, so a reviewer can check the classification in seconds before approving it.
- Does the RAID log update itself after every meeting?
- Entries are generated from each meeting the tool attends or each transcript and recording you give it, and land in a review queue. A human approves them before they join the log, so the log grows meeting by meeting without anyone retyping, but nothing enters it unreviewed.
- Can RAID entries be pushed to Jira or other platforms?
- Yes. Approved entries push to your work management platform, whether that is Jira, Azure DevOps, Linear, GitHub Issues, Notion or ClickUp, so risks and issues live where the delivery work lives instead of in a spreadsheet nobody opens.
- How often should a RAID log be reviewed?
- Match the review to the rhythm that raises the entries. Programme-level logs are usually walked at each steering committee, delivery-level ones at sprint planning or weekly. The honest rule: every entry needs a next-review date, and any entry that has survived three reviews unchanged is either resolved or was never real.
Keep going
Related workflows and resources
AI backlog generator
Turn one conversation into a structured, prioritised backlog.
Meeting to backlog
The wider workflow: one conversation, twelve artefact types.
Sprint planning meetings
What Backlog.cloud listens for in sprint planning specifically.
Transcript to requirements
From a recorded conversation to a structured requirements document.
For product managers
How PMs run meetings when the artefacts write themselves.
Product backlog guide
Refinement, prioritisation and Definition of Ready, in depth.
Your next steering committee could maintain its own log
Create a free account, hand it a meeting or transcript, and review RAID entries with owners, likelihood and source quotes. 3 free generations, all 12 artefact types, no card.