Most project teams have a RAID log. Far fewer have one that is genuinely useful. The typical failure mode is a spreadsheet that was filled in during project initiation and then referenced only when someone asks "what's the risk register saying?" before a steering committee.
In regulated manufacturing and med-tech, that approach creates real problems. A RAID log that is not actively maintained means risks go unmonitored, assumptions go unchallenged, and dependencies get missed until they cause a schedule impact. In a regulated environment, it also means the audit trail of how the team identified and managed risk is incomplete.
This post explains what belongs in each section of a RAID log, what a good entry looks like, and how to run the log so it stays useful throughout the project lifecycle.
RAID is an acronym for Risks, Assumptions, Issues, and Dependencies. The concept is widely used across project management frameworks. ISO 21502:2020 (Guidance on project management, published by the International Organization for Standardization) references risk management and issue management as distinct but related project management processes. The RAID log is a practical way to consolidate both, along with assumptions and dependencies, into a single living document.
Definition: Something that might happen and could affect the project if it does.
In regulated projects: Includes technical, schedule, regulatory, supplier, and resource risks. Each risk should have a probability rating, an impact rating, and a mitigation or contingency plan.
When it closes: When the risk window has passed, or when the risk has materialised (at which point it becomes an issue).
Definition: Something the project plan treats as true without confirmed evidence.
In regulated projects: Common assumptions include regulatory timelines, supplier lead times, and test facility availability. Each assumption should be reviewed periodically and updated when the status changes.
When it closes: When the assumption is confirmed as fact, or when it is invalidated (at which point it may become a risk or issue).
Definition: Something that has already happened and is actively affecting the project.
In regulated projects: Issues include failed tests, supplier delays that have materialised, resource gaps, and documentation deficiencies. Each issue should have a named owner and a resolution plan with a target close date.
When it closes: When the issue has been resolved and the impact on the project has been addressed.
Definition: Something the project relies on from outside the project team's direct control.
In regulated projects: Common dependencies include regulatory body decisions, outputs from parallel projects, supplier deliveries, and shared resource availability from other programmes. Each dependency should have a status and a confirmed delivery date.
When it closes: When the dependency has been delivered or is no longer on the critical path.
This is the most common source of confusion in RAID log maintenance. A risk is a future uncertainty. An issue is a current reality. When a risk materialises, it should be moved from the risk section to the issue section of the log, and a resolution plan should be created.
For example: "The primary supplier may not meet the lead time required for the Q3 build" is a risk. "The primary supplier has confirmed a four-week delay to the agreed delivery date" is an issue. The former requires monitoring and mitigation planning. The latter requires a recovery action.
Tip: If you find entries in your risk log that have already happened, your RAID log is not being maintained actively enough. Set a standing agenda item in your weekly project review to check whether any open risks have materialised.
Vague entries are the most common reason RAID logs stop being useful. "Supplier risk" tells a reviewer nothing actionable. A good entry is specific enough that someone unfamiliar with the project can understand what is at stake and what is being done about it.
| Field | Weak entry | Strong entry |
|---|---|---|
| Description | Supplier risk | Component X supplier has a 14-week lead time. If PO is not raised by 15 August, delivery will not support the planned November build. |
| Owner | Procurement | Sarah O'Brien, Procurement Lead |
| Probability / Impact | High | Probability: Medium (3/5). Impact: High (4/5). Risk score: 12. |
| Mitigation | Chase supplier | Raise PO by 8 August (two weeks early). Identify alternative supplier as contingency. Alternative sourced; lead time 16 weeks, so would require schedule change. |
| Next action / Due date | Monitor | PO approval from finance by 5 August. Owner: Sarah O'Brien. |
The initial RAID log should be built during or immediately after the project kick-off. The project manager should facilitate a structured session with the core team to identify the top risks, document key assumptions, surface known dependencies, and flag any issues already in play. Do not aim for completeness at this stage; aim for the items that have material potential to affect the project.
The RAID log should be a standing agenda item in the weekly project status review. The review does not need to go through every entry. It should cover: any new items raised since the last review, any changes in the status or severity of existing items, and any actions that are overdue.
A full RAID log review should be conducted before every phase gate. This is the point at which the gate board will want to understand the risk profile of the project going into the next phase. The gate pack should summarise the open high-severity risks, any unresolved issues, and any assumptions that have been invalidated and need the board's attention.
For more on what a gate review should cover, see the phase gate review checklist for regulated manufacturing projects.
Common failure mode: RAID logs that grow without being closed out. Every entry should eventually be closed. A log with 80 open items and no closed items is a log that is not being used as a decision-making tool. Build a habit of closing items explicitly, with a closure date and a brief note on how they were resolved.
In regulated manufacturing and med-tech, the RAID log serves a dual purpose. It is both a project management tool and a compliance record. An auditor reviewing a project's risk management approach will expect to see evidence that risks were identified, assessed, monitored, and either mitigated or accepted with documented rationale.
This does not mean the RAID log needs to be formatted differently. It means it needs to be maintained consistently, stored in a version-controlled system, and accessible alongside the rest of the project record. A RAID log kept in a shared Excel file that is overwritten each week provides very little audit trail. A RAID log maintained in a project management system with a change history provides a complete record of how risks evolved and were addressed throughout the project.
RAID stands for Risks, Assumptions, Issues, and Dependencies. A RAID log is a single register that tracks all four categories for a project. Some organisations extend it to RAIDO (adding Opportunities) or RAIDS (adding Stakeholders), but the core four categories are the most widely used.
A risk is something that might happen and could affect the project if it does. An issue is something that has already happened and is actively affecting the project. A risk becomes an issue when it materialises. The RAID log should track both because they require different responses: risks need mitigation plans, issues need resolution actions.
At minimum, a RAID log should be reviewed at every project status meeting, typically weekly. High-severity risks or active issues may warrant more frequent review. The log should also be reviewed in full before each phase gate. The most common failure mode is a RAID log that is updated once at project start and then ignored.
A good RAID log entry has a clear description of the item (specific enough that someone unfamiliar with the project can understand it), a named owner, a current status, and a next action with a due date. For risks, it should also include a probability and impact rating and a mitigation plan. Vague entries like "supplier risk" or "schedule concern" are not actionable and should be rejected.
Arcturus Pro gives regulated project teams an integrated RAID log alongside their Gantt, budget, and gate governance. No more separate spreadsheets. Book a 30-minute walkthrough.
Book a Demo