RAID stands for Risks, Assumptions, Issues, and Dependencies. The idea is simple: keep a running log of everything that could affect your project, organised by type, so nothing falls through the cracks.
In practice, RAID logs often become exactly what they were designed to prevent. Risks get logged once and never revisited. Issues are added but never resolved. Dependencies are noted but never tracked. The log grows. Nobody reads it. Something breaks.
The problem isn't the RAID framework. It's how teams use it.
What a RAID Log Is Supposed to Do
A RAID log exists to give a project team — and its stakeholders — a single, current view of what is threatening the project. It's a decision support tool. It tells you what to watch, what to act on, and what to escalate.
When it works, a RAID log creates visibility. The programme manager can see across multiple projects. The board can see the portfolio-level picture. Owners know what they're responsible for. Escalation happens at the right time, not after the damage is done.
That's the theory. Here's why it breaks down.
Why RAID Logs Become Parking Lots
Across project teams, there are four patterns that turn a RAID log from a live management tool into a static document nobody trusts.
No clear owner per risk
A risk logged without an owner is a risk nobody is responsible for. "Supplier delivery delay" with no owner name next to it will sit in the log until the delivery delay materialises. At that point, it's not a risk any more — it's an issue. And you've lost your window to mitigate.
Every risk needs one named owner. Not a team. Not a role. One person. That person is responsible for monitoring the risk, updating the score when circumstances change, and escalating when the score crosses the threshold.
No trigger for escalation
Most RAID logs don't define when a risk should move from monitoring to action. There's no automatic trigger. Escalation happens when someone remembers to check the log, reads the score, decides it looks high, and sends an email. Which is to say: escalation often doesn't happen.
A working system defines the threshold up front — probability and impact scoring calibrated to P×I ≥ 15 — and flags automatically when a risk crosses it. The human judgment comes at the review stage, not at the detection stage.
Risks and issues mixed together
RAID logs that mix risks (things that haven't happened yet) with issues (things that have) create noise. When everything is in one undifferentiated list, urgent issues crowd out the risks that need proactive management. You end up firefighting while the slow-burn risks accumulate.
Keeping risks and issues in separate views — while maintaining the links between them, because today's risk is tomorrow's issue — keeps both manageable.
Manual updates, infrequent reviews
Risk is not static. A risk scored at P2 × I3 when a project kicks off might be P4 × I4 three months later if the context has changed. But if the process for updating the log is manual — a PM has to remember to open the spreadsheet, find the row, change the score, save the file — most scores will never be updated.
The log becomes a snapshot from project initiation. By the time anyone reads it, it's an archaeology exercise, not a management tool.
The Difference Between Logging and Managing
Logging a risk means writing it down. Managing a risk means watching it, updating it, escalating it when necessary, and closing it when it's resolved or no longer relevant.
Most RAID logs handle the first part well. It's the second part where they break down. The log becomes a record of what someone once thought might go wrong, rather than a live picture of what's currently threatening the project.
The gap between logging and managing is where risks materialise unchallenged.
When governance is working, every AI-proposed score has a named human behind it — see how AI risk scoring and governance fit together to close that gap.
What a Working Risk Log System Looks Like
A risk log that actually manages risks rather than parking them has a few non-negotiable characteristics:
- Every risk has a named owner and a current AI-proposed score
- Escalation is automatic: when a score crosses the threshold, the risk enters a reviewer's queue immediately. Email escalation alerts are available from the Starter plan (£5/month) and above
- Risks are linked across the portfolio so you can see cascade effects — a risk in Project A that affects Programme B is visible at both levels
- Closed risks and resolved issues are archived but accessible — the history is preserved
- Owners have a dedicated My Actions queue showing all risks assigned to them that need review
- The log is the single source of truth — not one of several lists scattered across Jira, email, and a shared drive
Most of these are process failures, not tool failures. You can run a good risk log in a spreadsheet if the process is disciplined. But when you're managing 20+ active risks across multiple projects and programmes, manual process discipline becomes the weakest link.
RAID Logs and Portfolio Visibility
The hardest part of RAID log management isn't the individual project. It's the view across programmes and portfolios. When each project team keeps its own RAID log in its own format, consolidating that into a portfolio risk view takes a week of manual work.
What you actually need is a hierarchy. Risks logged at project level roll up to programme level. Programme risks roll up to portfolio level. The programme manager can see all project-level risks that have escalated. The portfolio owner can see programme-level risks and spot patterns — the structure that separates a working risk register from a spreadsheet you open once a quarter.
Risk clustering at portfolio level — where the same type of risk keeps appearing across multiple projects — is often more informative than any individual project risk. It tells you something about the organisation, not just the project.
KinetiRisk turns your RAID log into a live risk management system — automatic escalation, scoring, and audit trail. Start free →
Start free See how it worksFrequently Asked Questions
What is a RAID log in project management?
RAID stands for Risks, Assumptions, Issues, and Dependencies. A RAID log is a structured record of the four most common sources of project uncertainty. Done well, it gives a project team and its stakeholders a single, current view of what is threatening the project and what decisions need to be made.
Why do RAID logs stop getting updated?
The most common reason is that updating them is manual and disconnected from how the team actually works. There is no trigger to remind someone when a risk score changes, no automatic escalation when a threshold is crossed, and no visibility for programme managers beyond the individual project. When RAID logs require discipline to maintain rather than rewarding maintenance, they go stale.
What is the difference between a risk and an issue in a RAID log?
A risk is something that might happen — a future uncertainty you can still influence. An issue is something that has already happened and needs to be managed. Keeping them separate matters because the response is different: risks get scored, monitored, and mitigated proactively; issues get resolved reactively. When mixed together, urgent issues tend to crowd out the risks that need proactive attention.
At what point should a risk in a RAID log be escalated?
Escalation should trigger automatically when a risk score crosses a defined threshold — not when someone happens to notice it. A common threshold is P×I ≥ 15. The human judgment comes at the review stage after escalation: the programme manager or PMO decides what to do about the escalated risk, and that decision is recorded.
Your RAID log should also reflect residual risk positions as mitigation actions complete — not just the initial scores from when risks were first logged. Tracking inherent and residual scores side by side is what separates a live register from a historical document.
Key Takeaways
- RAID logs fail not because the framework is wrong, but because logging replaces managing
- Every risk needs a single named owner — teams and roles don't escalate, people do
- Escalation should be automatic when a score crosses the threshold, not dependent on someone reading the log
- Keep risks and issues in separate views to prevent firefighting from crowding out proactive risk management
- Risk scores must be updated regularly — a log frozen at project initiation is a historical document, not a management tool
- Portfolio visibility requires a consistent hierarchy — project risks feeding into programme views feeding into portfolio-level reporting