What RAID Stands For
RAID is an acronym for the four categories of project information that most often cause trouble when nobody is tracking them:
- Risks (R): uncertain events that could affect the project if they occur
- Assumptions (A): things you are treating as true without proof
- Issues (I): problems that have already happened and need resolution
- Dependencies (D): things your project needs from others, or that others need from you
A RAID log is a single document (usually a spreadsheet or a page in your project tool) that records all four in one place. Each category gets its own section or tab, and each entry gets an owner, a date, and a status.
You will also see variants. Some organisations use the A for Actions and the D for Decisions, and some expand the acronym to cover all six categories. The four-category version described here (Risks, Assumptions, Issues, Dependencies) is the most common, and it maps most cleanly onto the project artefacts that PMI describes in the PMBOK Guide: the risk register, the assumption log, and the issue log.
What Goes in Each Section
A RAID log works when each entry is specific enough that someone can act on it. Vague entries like "budget concerns" help nobody. Here is what belongs in each section, with a worked example row for each.
Risks
A risk is an uncertain future event. It has not happened yet, and it might never happen. For each risk you typically record a description, the probability of it occurring, the impact if it does, a response plan, and an owner.
| Field | Example |
|---|---|
| ID | R-04 |
| Description | The vendor's API team may miss the integration-spec delivery date, delaying our build phase |
| Probability | Medium |
| Impact | High (two-week schedule slip) |
| Response | Agree a fallback stub interface by 15 August so the build can proceed against a mock |
| Owner | Technical lead |
| Status | Open, reviewed weekly |
Note the structure of the description: a cause, an uncertain event, and an effect on objectives. Writing risks this way makes them testable. You can ask "has this happened yet?" and get a clear answer.
Assumptions
An assumption is something you are treating as true for planning purposes without having confirmed it. Every project plan rests on assumptions, and unexamined assumptions are one of the most common sources of late-project surprises. Each assumption should record what is being assumed, why, the impact if it turns out to be false, and how and when it will be validated.
| Field | Example |
|---|---|
| ID | A-02 |
| Description | We assume the client will provide test data in the agreed format by the start of the testing phase |
| Basis | Stated verbally in the kickoff meeting |
| Impact if false | Testing phase cannot start; schedule slips day for day |
| Validation | Confirm in writing with the client sponsor by end of the planning phase |
| Owner | Project manager |
| Status | Unvalidated |
The validation column is the one most teams skip, and it is the one that matters most. An assumption with no validation plan is just a hope with a reference number.
Issues
An issue is a problem that exists right now. Where a risk is uncertain and future, an issue is certain and present. Each issue needs a description, a severity, the action being taken, an owner, and a target resolution date.
| Field | Example |
|---|---|
| ID | I-07 |
| Description | The staging environment has been unavailable since Monday, blocking user-acceptance testing |
| Severity | High |
| Action | Infrastructure team investigating; workaround is to run UAT against a local build |
| Owner | Delivery manager |
| Target resolution | 12 July |
| Status | In progress |
Issues are where the RAID log earns its keep in status meetings. A well-maintained issue section answers the question "what is blocking us right now, and who is unblocking it?" in one glance.
Dependencies
A dependency is anything your project needs from outside the team, or anything another project or team needs from you. Inbound dependencies are the ones most likely to hurt you, because you do not control the people delivering them. Record what is needed, who is providing it, when it is due, and what it blocks.
| Field | Example |
|---|---|
| ID | D-03 |
| Description | Security team must complete the penetration test before the go-live decision |
| Direction | Inbound |
| Provider | Security team (outside the project) |
| Due date | 1 September |
| Blocks | Go-live gate review |
| Owner | Project manager |
| Status | Scheduled, confirmed with security team lead |
RAID Log vs Risk Register: Which Do You Need?
This is the comparison that confuses most people, and the honest answer is that the two documents overlap by design.
A risk register is a dedicated, deeper document for risks alone. In PMI's framing it holds each identified risk along with its analysis (probability, impact, priority), the planned response strategy, the risk owner, and the results of ongoing monitoring, including residual and secondary risks. On a project with formal risk management, the risk register is where qualitative and quantitative risk analysis happens.
A RAID log is broader and shallower. It covers four categories in one document, but each entry carries less analytical depth than a full risk register entry.
In practice:
- On small and medium projects, one document is usually enough. A RAID log with a well-structured risk section can serve as the risk register. Duplicating the same risks in two places guarantees that one copy goes stale.
- On larger or higher-risk projects, you often need both. The risk register holds the full analysis (probability and impact scoring, response strategies, contingency plans, and residual risk tracking) while the RAID log gives stakeholders a single summary view across all four categories. In that setup the RAID log's risk section holds only the top risks, with a pointer to the register for the rest.
- If your organisation mandates a risk register, keep it as the source of truth for risks and let the RAID log reference it rather than copy it.
The failure mode to avoid is maintaining both documents independently. Pick a source of truth for risks and make the other document point at it.
How a RAID Log Is Used Through the Project Lifecycle
A RAID log is a living document, and its role changes as the project moves through its lifecycle.
At kickoff. Run a short RAID workshop with the team and key stakeholders. Brainstorm initial entries in all four categories. The assumptions section is especially valuable at this stage, because kickoff is when the most planning assumptions are being made and the fewest have been examined. Capturing dependencies early also forces conversations with external teams while there is still time to negotiate dates.
During status reviews. The RAID log should be a standing agenda item, and reviewing it should mean changing it. Close resolved issues, retire risks that have passed, add new entries, and chase overdue validations. If the log looks identical two reviews in a row, that is a warning sign that it has stopped reflecting reality.
When things change. New risks and issues get logged as they emerge, and materialised risks move from the risk section to the issue section (more on that below).
At closure. The RAID log is one of the best inputs to lessons learned. Which risks actually occurred? Which assumptions turned out to be false? Which dependencies were delivered late? The answers make the next project's kickoff workshop sharper.
How RAID Concepts Show Up on the PMP Exam
The PMP exam is unlikely to ask you to define the acronym. PMI's own vocabulary splits the RAID categories into separate artefacts, so the exam tests the underlying concepts instead:
- Risk identification and the risk register. Expect situational questions about when and how risks are identified, who owns them, and what belongs in the register. Our Risk Identification and the Risk Register practice questions cover this directly.
- The risk-versus-issue distinction. A classic exam pattern describes an event and asks what the project manager should do. If the event has already happened, it is an issue and belongs in the issue log with an owner and an action. If it might happen, it is a risk and belongs in the risk register with a response plan. Choosing the risk-response answer for an event that has already occurred is one of the most common mistakes on these questions. The issue identification, logging and resolution topic tests exactly this judgement.
- Assumption analysis. Assumptions and constraints are recorded from the project charter onwards, and assumption analysis appears as a data-analysis technique in risk identification. Questions probe whether you validate assumptions rather than let them sit unexamined. The project charter and integration management topics cover where assumptions enter the project record.
- Risk monitoring. Once responses are planned, the exam tests whether you track residual and secondary risks and keep the register current, which is the same discipline a RAID log demands.
Common RAID Log Mistakes
The stale log. The most common failure. The log is created at kickoff, attached to the project charter, and never opened again. A RAID log only works if it is reviewed on a rhythm, which is why it belongs on the status-meeting agenda rather than in a folder.
Risks logged as issues, and issues logged as risks. If it has happened, it is an issue. If it might happen, it is a risk. Mixing them up muddles ownership and response: risks get response plans and issues get corrective actions. When a risk materialises, close it in the risk section and open a corresponding issue, so the log tells the true story of what happened.
Assumptions that are never validated. Teams are good at writing assumptions down and poor at going back to check them. Every assumption needs a named owner and a validation date. An assumption that cannot be validated by a date should be treated as a risk, because that is what it really is.
Entries without owners. An entry owned by "the team" is owned by nobody. Every row needs one named person accountable for moving it forward.
Writing for the audit trail rather than for action. The test of a good RAID entry is whether the owner knows what to do next after reading it. If entries are being written to prove the process was followed rather than to drive decisions, the log has become theatre.
Practise the Concepts Behind the RAID Log
The RAID log itself is simple. The judgement it depends on (distinguishing risks from issues, analysing assumptions, and tracking dependencies and residual risks) is what the PMP exam actually tests, usually through situational questions.
Practise risk and quality management questions free on Got PMP, covering risk identification, the risk register, risk monitoring and residual risks, with detailed explanations for every answer.