RAID stands for Risks, Assumptions, Issues, and Dependencies — four categories of things that can derail a project, tracked together in a single document called a RAID log. The point isn't to keep four separate lists. It's to give a project manager and their sponsor one place to see everything uncertain or unresolved about a project, so nothing falls through the cracks between status meetings.
Most project managers already track these four things in some form. RAID just gives that habit a name and a structure that's easy to hand off, audit, or roll up across a portfolio. In practice, most teams also track a fifth thing alongside RAID — Action Items — since risks and issues are only useful once someone's actually assigned to do something about them. This guide covers all five, with the specific fields each log needs.
What each letter actually means
Risks are things that might happen and would hurt the project if they did. A vendor might miss a delivery date. A key engineer might leave mid-sprint. Risks get a likelihood, an impact, and — ideally — an owner and a mitigation plan, before they turn into problems.
Assumptions are things the team is treating as true without proof, because planning has to start somewhere. "The client's IT team will provision test environments within a week of request" is an assumption. It's not a risk yet, but if it turns out to be wrong, it becomes one fast — which is exactly why it belongs on the same log.
Issues are risks that already happened, or problems that showed up with no warning at all. The vendor missed the date. The engineer gave notice. Issues need an owner and a resolution path now, not a mitigation plan for later.
Dependencies are the sequencing constraints between tasks, teams, or even other projects — the things that must finish before something else can start. A dependency isn't inherently bad; it only becomes a project problem when the thing it depends on slips and nobody flagged the knock-on effect in time.
A quick example
Say a mid-market company is migrating its internal ticketing system from a legacy tool to a new platform integrated with Microsoft Teams.
— Risk: The data migration script might not handle custom fields correctly, corrupting historical tickets.
— Assumption: The vendor's API will support bulk export without rate limiting.
— Issue: Two weeks in, the vendor's API does rate-limit exports, and the migration is now behind schedule.
— Dependency: User training can't start until the new platform is provisioned and populated with real data — so a slip in provisioning pushes the whole training schedule out with it.
— Action Item: Assign the integration lead to renegotiate export batch limits with the vendor by Friday.
Notice how the assumption, the issue, and the action item are all connected. That's the real value of keeping RAID items in one log instead of four separate lists: you can see an assumption curdle into an issue, immediately trace what else it touches, and see exactly who's on the hook to fix it.
Standard fields for each log
A RAID log is really five related logs that happen to share a home. Each one needs slightly different fields to actually be useful — a risk log without a likelihood/impact score is just a list of worries, and an action item log without a due date is just a list of intentions. Here's what a complete version of each looks like.
Risk log fields
Risk ID. Unique identifier (e.g. R-014) so the risk can be referenced from issues, action items, or status reports
Title / Description. A specific, one-sentence statement of what might happen — not "vendor risk," but "vendor may miss the March 15 data export deadline"
Category. Technical, schedule, resource, vendor/third-party, financial, scope, compliance — whatever taxonomy your PMO standardizes on
Date identified. When the risk was first logged
Identified by. Who raised it — useful for follow-up questions and for spotting who's actually watching for trouble
Likelihood. Probability it occurs — a simple Low/Medium/High or a 1–5 scale
Impact. Severity if it does occur — same scale as likelihood, scored independently
Risk score. Likelihood × impact, calculated, not eyeballed — this is what lets you sort a long list by what actually matters
Owner. One named person accountable for watching and managing this risk — never "the team"
Mitigation plan. What's being done now to reduce likelihood or impact
Contingency plan. What happens if the mitigation fails and the risk occurs anyway
Status. Open, monitoring, mitigated, closed, or occurred (at which point it typically becomes an issue)
Related project / program. Needed the moment more than one project's risks need to roll up to a program or portfolio view
Last updated. Stale risk entries are as dangerous as missing ones — this field is what lets a reviewer spot them
Assumption log fields
Assumption ID. Unique identifier (e.g. A-007)
Description. The specific thing being treated as true — "the client's test environment will be ready within 5 business days of request," not "client will be responsive"
Category. Technical, resource, external/third-party, business or market
Date logged. When the assumption was first documented
Logged by. Who made the call to treat this as true rather than verify it upfront
Confidence level. How solid the assumption is — validated, partially validated, or unverified
Validation owner / method. Who's responsible for confirming it, and how (a vendor call, a test, a signed agreement)
Impact if invalid. What breaks if this turns out to be false — this is what determines how urgently it needs validating
Status. Open, validated, or invalidated (invalidated assumptions should convert directly into a risk or issue, not just get deleted)
Linked risk/issue ID. Reference to whatever it became, if it stopped being an assumption
Issue log fields
Issue ID. Unique identifier (e.g. I-021)
Description. What actually happened, stated as fact, not as a prediction
Category. Same taxonomy as the risk log, so issues and risks can be compared apples-to-apples
Date raised. When the issue was identified
Raised by. Who caught it
Severity / priority. Critical, high, medium, or low — how urgently it needs resolving
Owner. Who's driving resolution — not who caused it
Resolution plan. The specific plan to close it out
Target resolution date. A real date, not "ASAP"
Status. Open, in progress, resolved, or escalated
Originating risk ID. If this issue was a risk that occurred, link back to it — this is how you eventually learn which risks you're consistently underestimating
Escalated to. Filled in only if it's beyond the project manager's authority to resolve alone
Dependency log fields
Dependency ID. Unique identifier (e.g. D-009)
Description. What depends on what, stated specifically
Type. Internal (between tasks or teams in the same project) or external (another project, a vendor, a different department)
Predecessor. The thing that must finish first
Successor. The thing that's blocked until the predecessor finishes
Owner. Who's tracking whether the predecessor stays on schedule
Due date. When the predecessor needs to complete to avoid delaying the successor
Status. On track, at risk, or breached
Impact if delayed. What downstream work slips, and by roughly how much
Related project. Essential for cross-project dependencies — this is usually the single most useful field at the program level
Action items log fields
Action ID. Unique identifier (e.g. AC-033)
Description. A specific, assignable task — "renegotiate export batch limits with vendor," not "deal with vendor issue"
Source. The risk, issue, or meeting that generated this action — every action item should trace back to something
Owner. One named person — action items assigned to a group rarely get done
Date assigned. When it was created
Due date. When it's due — required, not optional
Priority. Critical, high, medium, low
Status. Not started, in progress, complete, or overdue
Date completed. Filled in on close, useful for auditing how quickly the team actually resolves things
Notes. Free text for context that doesn't fit the other fields
RAID log vs. risk register: what's the difference
A risk register only tracks risks. A RAID log tracks risks plus the three other categories that risk registers typically leave out — which matters because issues, assumptions, and dependencies are often what actually blow up a timeline, not the risks that got caught in advance. If your team already maintains a solid risk register, extending it into a full RAID log is usually a matter of adding three more tables with the fields above, not starting over.
Who owns the RAID log
On a single project, the project manager typically owns it, updating it weekly and flagging anything that needs sponsor attention. On a portfolio with dozens of projects running at once, that ownership model breaks down fast — a PMO director can't manually read forty separate RAID logs to spot the two or three risks that are actually strategic. That's usually the point where organizations either build a standardized RAID template that rolls up automatically across projects, or move to a portfolio management platform that aggregates RAID data from every project instead of trusting someone to escalate manually.
How to build a RAID log
You don't need special software to start. A shared spreadsheet with five tabs — one per log, using the field tables above — covers a single project well. What matters more than the tool is the discipline: review it on a fixed cadence, retire closed items instead of deleting them (they're useful history for the next similar project), and make sure every risk, issue, and action item has a named owner, not just a description.
Where a spreadsheet starts to strain is exactly the portfolio-rollup problem above: five tabs work fine for one project, but forty projects' worth of RAID logs living in forty separate files means nobody at the PMO level can see the pattern across them without a lot of manual copying. That's the specific gap a platform like PPM Express is built to close — risks, issues, dependencies, and action items logged at the project level roll up automatically into a portfolio view, so a PMO director sees the two or three things that actually need executive attention without reading every project's log line by line.
Frequently asked questions
What does RAID stand for in project management? Risks, Assumptions, Issues, and Dependencies — four categories of uncertainty or constraint tracked together in one log. Many teams also track a fifth, related list — Action Items — alongside it.
What's the difference between a risk and an issue in a RAID log? A risk hasn't happened yet; it's a possibility with a likelihood and an impact score. An issue has already happened and needs a resolution plan and a target date now, not a mitigation plan for later.
Is a RAID log the same as a risk register? No. A risk register covers only risks. A RAID log covers risks plus assumptions, issues, and dependencies, giving a fuller picture of what could disrupt a project.
What fields should a risk log include? At minimum: a unique ID, description, category, likelihood, impact, a calculated risk score, an owner, a mitigation plan, and status. See the full field table above for the complete list most mature PMOs use, including contingency plan and last-updated fields.
Who should update the RAID log? The project manager typically owns and updates it, but any team member should be able to flag a new risk, issue, dependency, or action item as soon as they spot one.
How often should a RAID log be reviewed? Weekly is standard for active projects — often as a fixed agenda item in the team's status meeting, with anything urgent (especially issues and overdue action items) escalated immediately rather than waiting for the next review.
.svg){kind=small}
