If you've been told to "keep a RAID log" and nobody has said what goes in it, or you run a program where five project teams each track risks in a different place, this guide is for you. It defines the log, shows a filled-in example at program level, gives you a template to copy and explains how to roll several project logs up into one program view.
- A RAID log is one document that tracks a project's risks, assumptions, issues and dependencies, each with an owner and a status.
- The D and the A don't mean the same thing everywhere: Atlassian pairs decisions with dependencies, and Smartsheet's help page uses risks, actions, issues and decisions. Pick one version and write it at the top of the log, because people will otherwise argue about it mid-project.
- A risk is something that might happen, an issue is something that already has. When a risk happens, log an issue, keep the risk's ID and link the two.
- On a program, keep one log per project with identical columns, then roll up only what crosses workstreams or passes your escalation threshold.
What Is a RAID Log?
A RAID log is a single document that tracks a project's risks, assumptions, issues and dependencies in one place, with an owner and a status for each entry. That makes four types of entry. Any project can use one, but Atlassian says it fits large, cross-functional projects best, where more teams and partners can change the plan. It replaces the notes scattered across emails, chats and personal files.
What it's for is simple. It makes the things that can derail a project visible to everyone who needs to act on them, and it records who is acting. Asana puts it as documenting potential risks at the start of a project and then tracking the issues that appear after kickoff. A new contributor can read the log and understand the context without searching old threads, which Atlassian lists as one of the benefits.
It's a working document, not a report, and of course it only helps if people open it. Atlassian's own list of drawbacks is worth taking seriously: a RAID log needs frequent updates, and logging every small question can bury the items that matter. Both problems come back in the mistakes section below.
What Does RAID Stand For?
RAID stands for risks, assumptions, issues and dependencies. That's the version most guides use, but not every source agrees on the last two letters. Atlassian's guide lists the fourth element as "decisions or dependencies", Asana says a team might log risks, actions, issues and decisions instead, and Smartsheet's help center defines the log as risks, actions, issues and decisions.
| Source | What RAID stands for in that source |
|---|---|
| Atlassian | Risks, assumptions, issues, and decisions or dependencies |
| Smartsheet help center | Risks, actions, issues, decisions |
| Asana | Risks, assumptions, issues, dependencies; or risks, actions, issues, decisions |
| Rebel's Guide to Project Management | Formally assumptions and dependencies, though the author gets more use from recording actions and decisions |
| Career Smarter | Risks, assumptions, issues, dependencies |
The four standard terms are easy to confuse, so here is how each one differs.
| Type | The question it answers | Example | Has it happened yet? |
|---|---|---|---|
| Risk | What might go wrong, or go right? | A vendor may miss its release date | No |
| Assumption | What are we treating as true without proof? | Legal approval will take three weeks | Not confirmed |
| Issue | What is going wrong now? | The test environment has been down for two days | Yes |
| Dependency | What do we need from someone else? | Checkout testing needs another team's customer ID service | Depends on delivery |
Career Smarter notes that a risk can be positive as well as negative, and that's how the Rebel's Guide to Project Management treats it too. Most logs only record the negative ones, but that's fine as long as you do it on purpose.
RAID Log Example for a Program
A program RAID log gives every entry a unique ID, a type, a plain-language description, the workstream it belongs to, an owner and a status. The example below is illustrative: a hypothetical program replacing a customer portal, run as four workstreams. Probability and impact are scored from 1 to 5 and multiplied, a convention we use in this article. It only applies to risks, because an issue has already happened. Cafe Associates makes the same point: likelihood doesn't apply to issues, since they're already occurring.
| ID | Type | Entry | Workstream | Owner | Probability | Impact | Score | Status |
|---|---|---|---|---|---|---|---|---|
| R-01 | Risk | If the identity vendor misses its August release, single sign-on can't ship with the portal launch | Platform | Platform lead | 3 | 5 | 15 | Open, escalated to program |
| R-02 | Risk | Two people on the migration team may be pulled onto the finance close in Q4 | Data migration | Migration lead | 3 | 3 | 9 | Open, mitigation agreed |
| A-01 | Assumption | Legal approves the new terms of service within three weeks of submission | Launch | Program manager | n/a | n/a | n/a | Unvalidated, check at next steering meeting |
| A-02 | Assumption | Customer support can absorb launch ticket volume without extra headcount | Launch | Support lead | n/a | n/a | n/a | Unvalidated, owner gathering ticket forecasts |
| I-01 | Issue | The test environment has been down for two days and blocks regression testing | Platform | Platform lead | n/a | 4 | n/a | Open, workaround in place |
| I-02 | Issue | Payments sandbox credentials expired, so checkout can't be tested | Payments | Payments lead | n/a | 3 | n/a | Resolved, close at next review |
| D-01 | Dependency | Checkout testing needs the new customer ID service from the platform team | Payments, needs Platform | Program manager | n/a | n/a | n/a | Delivery date not yet confirmed |
| D-02 | Dependency | Help center rewrite needs final screens from design | Launch, needs Design | Launch lead | n/a | n/a | n/a | On track |
| D-03 | Dependency | Migration needs finance to freeze the product catalog | Data migration, needs Finance | Migration lead | n/a | n/a | n/a | Waiting on finance |
Here's what to notice when you read it.
- Every entry has one named owner. The owner is the person who keeps the entry moving, not necessarily the person who fixes it. That's the point Atlassian makes about ownership and accountability.
- R-01 is escalated and the rest aren't. It scores 15, crosses into another team's work and affects the launch. The other entries stay in their workstream logs. The next sections show how to decide that, but the short version is a score threshold plus any cross-team impact.
- D-01 and R-01 are linked. Both sit on the platform team's delivery. Link entries that share a cause, so one slip doesn't show up as four unrelated problems.
- The assumptions have a plan to be checked. An assumption without a validation step is just a risk nobody has named yet.
If you also need to settle who owns each of these entries and each decision around them, a RACI chart is the companion document.
Free RAID Log Template
Smartsheet publishes five RAID templates (a basic log, a matrix log, a presentation, an Agile version and an analysis report) in Excel, Word, PDF, PowerPoint and Google formats. If you'd rather not download anything, build the template yourself. Create a spreadsheet with the columns below as the header row (13 columns in all, but these eight are enough to start: ID, type, description, workstream, owner, response, status and review date), add a drop-down list for Type and Status, and copy the same sheet for each project. Add the other columns only when a meeting keeps asking for that information. The column set follows what Career Smarter lists for its own template and what Cafe Associates recommends recording for each entry, plus a workstream column for programs.
| Column | What to write | Applies to |
|---|---|---|
| ID | A unique number with a type prefix, for example R-01 or D-03 | All |
| Type | Risk, assumption, issue or dependency | All |
| Description | One sentence: the event or condition and what it affects | All |
| Workstream | Which project or workstream it belongs to | All |
| Owner | One named person | All |
| Probability | 1 to 5 | Risks |
| Impact | 1 to 5 | Risks and issues |
| Score | Probability times impact | Risks |
| Response | The mitigation, the validation step, the workaround or the delivery date you're waiting for | All |
| Contingency | What you'll do if the risk happens (Cafe Associates separates this from mitigation) | Risks |
| Status | Open, escalated, resolved or closed | All |
| Date raised | The day the entry was added | All |
| Review date | When someone must look at it next | All |
Cafe Associates argues for a separate worksheet per type rather than one list with a type drop-down, because you deal with each type differently. That's a reasonable choice for a single project. For a program, a single sheet with a Type column filters better, since the whole point is to see all the entries that touch one workstream. Choose one and stick with it across projects.
- The version of RAID you use (assumptions or actions, dependencies or decisions) is written at the top
- Every entry has an ID, a type, one owner and a status
- Probability and impact use the same scale in every project
- Each entry has a review date, not just a raised date
- Escalation rules are written down and agreed with the steering committee
- One place holds the log, and everyone knows where it is
How Do You Run a RAID Log Across a Program?
A program needs two layers: a log inside each project and a thinner log above them. Atlassian's five steps (define scope, brainstorm, assign owners, review regularly, learn at the end) cover a single project well. The six steps below are our own program-level method, not a published standard, so adjust the thresholds to your governance.
Give every project the same log
Use the template above with the same columns, the same 1 to 5 scales and an ID prefix per workstream, such as PAY-R-03. Identical columns are what make a rollup a filter instead of a rewrite.
Write the escalation rules down
An entry moves up in one of four cases: it crosses a workstream boundary, its risk score passes an agreed threshold (for example 15 on the 25-point scale used above), it threatens a program milestone or budget tolerance, or it's overdue for its review date. Put the rules in the log's header so nobody argues about them later.
Run the first RAID session at kickoff
Atlassian suggests workshops, stand-ups or focused discussions with the team and stakeholders to generate the first list, because individual contributors miss things that others see. Include the dependencies between workstreams in the same session.
Review each log on a fixed rhythm
Atlassian recommends reviewing entries during status meetings, steering committee discussions or sprint planning. Workstream leads review their own log in their regular status meeting, and the program manager reviews the program log with the PMO before each steering committee.
Roll up what crosses a line
The PMO copies or links escalated entries and every cross-workstream dependency into the program log, keeping the original ID. The source log stays the record, and the program log is the view for the steering committee.
Close the loop at the end
Both Atlassian and Asana suggest using the log at the end of a project, for lessons learned or a post-mortem. For a program, do this at each phase gate and again at program close, and keep the closed entries.
Dependencies between workstreams belong in both the workstream log and the program log. The workstream that's waiting records it, so its lead sees it. The program log carries every dependency between workstreams, because that's the one view nobody inside a single workstream has.
How Do Items Move Between Risks, Assumptions, Issues and Dependencies?
Entries in a RAID log change type as the project learns more. A risk that happens becomes an issue, an assumption that turns out to be false becomes a risk or an issue, and a dependency that slips becomes a risk. Career Smarter's advice is to review the log at every progress meeting, close what's resolved, turn risks that happen into issues and check assumptions until they're confirmed. Rebel's Guide to Project Management adds that a risk that comes to pass gets a new entry in the issue log, referencing the original risk by ID.
| From | To | Trigger | What to do with the entry |
|---|---|---|---|
| Risk | Issue | The event happens | Create a new issue entry, reference the risk ID, close the risk |
| Assumption | Risk | You learn it might not hold | Keep the assumption, add a risk entry and link both |
| Assumption | Issue | It's proven false | Log an issue, update the plan and tell stakeholders |
| Dependency | Risk | The other team signals a delay | Add a risk entry for the slip and keep the dependency open |
| Dependency | Closed | The input is delivered | Record the delivery date and close it |
| Any type | Closed | The entry no longer matters | Record why it was closed, so the history is useful later |
That's why IDs really matter. Cafe Associates advises numbering every entry, because names alone get confusing and inconsistent when you refer back to them. Without IDs you can't link a risk to the issue it became, and you'll always lose the history.
RAID Log vs Risk Register, Issue Log and RACI Chart
A risk register covers possible future problems, an issue log covers current ones and a RACI chart says who owns the work. The RAID log combines the first two with assumptions and dependencies. Lark describes the same split: a risk register is proactive, an issue log is reactive and a RAID log covers both.
| Document | What it covers | Looks forward or back | Where it fits |
|---|---|---|---|
| RAID log | Risks, assumptions, issues, dependencies | Both | One working document for a project or workstream |
| Risk register | Risks only, usually with probability, impact, response and owner | Forward | Detailed risk analysis, often a tab or section of the RAID log |
| Issue log or register | Issues only, with severity and resolution steps | Current | Tracking problems to closure |
| PRINCE2 daily log | Informal items, minor risks, loose ends | Both | The project manager's working notes, with formal items moved to the registers |
| RACI chart | Who is responsible, accountable, consulted or informed | Not applicable | Assigning ownership of tasks and decisions |
PRINCE2 7 names a daily log, a lessons log, a risk register, an issue register and a quality register as its logs and registers, according to PRINCE2 study material. A RAID log isn't one of them, so teams on PRINCE2 usually treat it as a convenient combined view of those records, not a replacement for them.
The RACI chart answers a different question. A RAID log tells you what could go wrong or is waiting on someone. A RACI chart tells you who decides and who acts, and it doesn't track risks or schedules. Use both, and give the owner column of the RAID log the same names that are accountable in the chart. Our guide to the RACI chart for program managers has a program-level template.
Which Tools Can Hold a RAID Log?
A RAID log can live in a spreadsheet for one project, but programs outgrow it when several people need to update entries, filter by workstream and get reminded about review dates. These are the options the sources describe, and the limits that come with them.
- Excel and Google Sheets. The simplest start. Smartsheet publishes its RAID templates for both, and you can build the template above in a few minutes. Lark points out the downside: manual updates and limited real-time collaboration make it harder as projects grow.
- Smartsheet. Its free RAID downloads include an Agile version with a separate sheet for each RAID category and a Gantt-style timeline that shows how long items last and where they overlap. The help center describes the log as a tool with owner, priority, status and due date for each entry. Smartsheet Community threads describe the Excel template as hard to find in the template gallery and report that importing the file can lose the dropdown lists.
- Asana. Asana's template splits the log into two sections: risks, assumptions and dependencies identified during planning, and issues, actions, dependencies and decisions raised after kickoff. It uses custom fields, list view and task dependencies, which makes it a natural fit if the project already runs there.
- Jira and Confluence. Atlassian's guide recommends integrating the log with Jira and Confluence to centralize the information. Atlassian Community answers say there's no standard way to build a RAID log in Jira, and that teams use custom issue types or fields and embed Jira filters in a Confluence page. Expect to configure it yourself.
Whatever tool you choose, the tool matters less than the habits. Cafe Associates says not to worry about finding the most perfect template or filling in every column, and to work out what your team will actually use.
The Program Manager isn't a RAID log, and it doesn't replace one. It maps dependencies across Jira and Asana and watches milestones for risk, which covers the part of the log that goes stale fastest when it's kept by hand. For other tools that can hold the rest of a program, see our roundup of the best program management software.
Common RAID Log Mistakes
Most RAID logs fail in the same few ways, and most of them come down to ownership and upkeep, not format.
- Entries with no owner. One owner per entry is non-negotiable, and Atlassian calls assigning ownership one of the most important parts of the log. An entry nobody owns never moves.
- A log nobody reviews. The log's value drops fast once it's stale. Atlassian warns that outdated statuses have to be reconciled before the log is useful again. Put review dates in the log and the review itself in an existing meeting.
- Logging every worry. Atlassian notes that tracking every small question or task can bury the items that matter. Keep day-to-day tasks in your task tool and use a threshold for what gets an entry.
- Issues logged as risks, or the reverse. If it has already happened, it's an issue and probability doesn't apply. Mixing them up produces risk scores that look reassuring while the project is already slipping.
- Assumptions that are never checked. Atlassian says assumptions should be tracked and validated throughout the project. Give each one an owner and a way to find out whether it's true.
- Three copies of the same item. On a program, the same dependency often appears in two workstream logs and the program log. Keep one record, with an ID, and link to it.
FAQ
What is the purpose of a RAID log?
The purpose is to keep every open risk, assumption, issue and dependency visible with a named owner, so nothing depends on one person's memory. Atlassian adds that a new contributor can read it and pick up the context without searching old threads.
What does RAID stand for in PMO?
RAID stands for risks, assumptions, issues and dependencies. Some sources use actions or decisions for the last two letters, so check which version your PMO uses and write it at the top of the log.
What is the difference between RACI and RAID?
A RACI chart assigns responsibility for tasks and decisions: responsible, accountable, consulted or informed. A RAID log tracks what could go wrong, what you're assuming, what has gone wrong and what you're waiting for. They answer different questions and work well together. A RACI chart doesn't track risks, and a RAID log doesn't assign roles for tasks.
Is a risk register the same as a RAID log?
No. A risk register covers risks only. Asana describes it as the R of a RAID log, which also tracks assumptions, issues and dependencies. If your team already keeps a risk register, you can use it as the risk section of the log.
How often should you update a RAID log?
You should update a RAID log at every regular status meeting. Atlassian suggests status meetings, steering committee discussions or sprint planning. A log that's only updated when something goes wrong stops being useful, though a short review every week or two keeps it honest.
Who owns the RAID log?
The project manager usually maintains the log, and each entry has its own owner. On a program, each workstream lead maintains their project's log and the PMO or program manager maintains the program view.
Leave a Reply