A RAID log tracks the risks, assumptions, issues, and dependencies that could affect your project

A RAID log is a simple document or spreadsheet that your project team updates regularly to record four specific things: risks that might happen, assumptions you are making, issues that are happening right now, and dependencies — things your project needs from other teams or outside sources. The name comes from those four letters: Risks, Assumptions, Issues, Dependencies.

The purpose is to keep problems visible so they do not surprise you later. Instead of discovering mid-project that a vendor is slow or a team member is overbooked, you write it down when you first notice it, assign someone to watch it, and check on it every week. This gives you time to plan around the problem or fix it before it derails your timeline.

Most teams keep their RAID log in a shared spreadsheet or in their project management software. It lives alongside your task list and timeline, and you review it in your regular team meetings. The log is not a place to dump every worry — it is a working document that tracks only the things that could actually change your project's outcome.

Key Takeaways

  • A RAID log records risks (things that might happen), assumptions (things you believe are true), issues (problems happening now), and dependencies (things you need from outside your team).
  • Each entry should have an owner — a specific person responsible for monitoring it and reporting back to the team.
  • You review and update the RAID log in regular team meetings, usually weekly, and remove items once they are resolved or no longer a threat.
  • The log prevents surprises by making problems visible early, when you still have time to respond.
  • A RAID log works best when it stays short and focused on items that actually matter to your project's success.

The four categories and what goes in each one

Risks are things that might happen but have not happened yet. Examples: a vendor might miss a deadline, a team member might leave, a new requirement might arrive late, or a tool you are counting on might not work the way you expect. You write down the risk, estimate how likely it is, and describe what would happen to your project if it occurred.

Assumptions are things your plan depends on that you have not confirmed yet. Examples: you assume the client will approve the design by a certain date, you assume a third-party API will be available, you assume a team member will be available full-time, or you assume the budget will not be cut. Assumptions are worth tracking because they often turn out to be wrong, and discovering that late costs time.

Issues are problems that are already happening right now. Unlike risks, these are not theoretical — they are real obstacles you are dealing with. Examples: a team member is sick and unavailable, a vendor delivered something broken, a requirement changed mid-project, or you discovered a technical problem that will take longer to fix than expected. Issues need immediate attention and a plan to resolve them.

Dependencies are things outside your team's control that your project needs. Examples: another team needs to finish their work before you can start yours, you are waiting for a client decision, you need access to a system that another department controls, or you need budget approval from finance. Dependencies are worth tracking because delays in other teams can delay you, and knowing about them early lets you plan around them.

How to set up and maintain a RAID log

Start with a simple spreadsheet or table with columns for the category (Risk, Assumption, Issue, or Dependency), a description of the item, the owner (the person responsible for it), the status, and the date it was added. Some teams add a column for priority or impact, and some add a target resolution date. Do not overcomplicate it — the goal is to make it easy to update and easy to scan in a meeting.

Assign an owner to every entry. The owner is not necessarily the person who will fix the problem — they are the person who watches it, gathers information about it, and reports on it in team meetings. This prevents items from being forgotten. Without an owner, a risk stays on the list forever and nobody takes action.

Review the log in your regular team meetings, usually weekly. Go through each item, ask the owner for an update, and decide whether the item is still active or whether it can be closed. If a risk did not happen and is no longer likely, remove it. If an issue is resolved, mark it closed. If an assumption was confirmed, move it off the list. A RAID log that never shrinks becomes noise that people stop reading.

Keep the log visible and accessible. If it lives in a shared folder or in your project management tool, team members can add items between meetings. Some teams have a standing agenda item at the start of each meeting: "Any new risks, assumptions, issues, or dependencies to add?" This catches problems early, when they are still small.

The difference between a RAID log and a risk register

A risk register is a more formal document that focuses only on risks. It usually includes more detail: a description of the risk, the probability it will occur, the impact if it does, a mitigation strategy (what you will do to prevent it), and a contingency plan (what you will do if it happens anyway). Risk registers are common in larger projects, especially in industries like construction or finance where risks are high-stakes.

A RAID log is broader and lighter. It tracks risks alongside assumptions, issues, and dependencies, and it does not require as much detail. It is designed for teams that need to stay aware of multiple types of problems without spending hours on documentation. Most small to medium projects use a RAID log. Larger or more regulated projects might use both — a RAID log for day-to-day team awareness and a risk register for formal risk management.

Common mistakes when using a RAID log

The biggest mistake is adding too much. Teams sometimes treat the RAID log like a dumping ground for every possible worry, every assumption, every external dependency. This makes the log too long to review in a meeting and too noisy to be useful. Keep only the items that could actually change your project's outcome. A minor assumption that does not affect your timeline or budget does not need to be tracked.

Another mistake is not assigning owners. When nobody is responsible for an item, it sits on the list untouched for weeks. The team assumes someone else is watching it. In the next meeting, nobody has an update, and the item stays on the list. Assign an owner at the moment you add the item, and make sure that person knows they are the owner.

A third mistake is never closing items. If your RAID log has 30 items and only 2 are new this week, the log is not working. You should be closing items regularly — risks that did not happen, issues that are resolved, assumptions that were confirmed. If the log never shrinks, people stop reading it because they assume nothing ever changes.

When a RAID log is most useful

RAID logs work best on projects with multiple moving parts, external dependencies, or uncertain timelines. If your project depends on another team finishing their work first, a RAID log makes that dependency visible and keeps it on the radar. If you are working with a new vendor or a new technology, a RAID log lets you track risks and assumptions about how well they will work.

RAID logs are less useful on very small projects with one or two people and no external dependencies. If you are the only person working on something and you control all the inputs, you probably do not need a formal log — you already know what could go wrong. But the moment you add a second team member or an external dependency, a RAID log becomes valuable because it keeps everyone on the same page about what could derail the project.

RAID logs are also useful when you are working with stakeholders who need to understand project risks. Instead of saying "there might be problems," you can show them the log: here are the specific risks we are tracking, here is who is watching each one, and here is the status. This builds confidence that you are managing the project thoughtfully.

Frequently Asked Questions

What is the difference between an issue and a risk in a RAID log?

A risk is something that might happen in the future — it has not occurred yet. An issue is a problem that is happening right now. If you think a vendor might miss a deadline, that is a risk. If the vendor tells you they will miss the deadline, that is an issue. Issues need faster action because they are already affecting your project.

How often should I update a RAID log?

Most teams update their RAID log weekly, usually during a team meeting. The owner of each item reports on the status, and the team decides whether to keep, close, or escalate the item. Some teams update more frequently if the project is moving fast or if there are active issues that need daily attention.

What should I do if an item stays on the RAID log for months?

If an item has been on the log for a long time with no change, either close it or escalate it. If it is a risk that never happened and is unlikely to happen, remove it. If it is an issue that has not been resolved, it may need more resources or a different approach — bring it to your project manager or stakeholder for a decision.

Can I use a RAID log for personal projects?

Yes, though it is usually more useful for team projects. If you are managing a personal project with external dependencies — waiting for someone else's approval, relying on a vendor, or dealing with uncertain timelines — a simple RAID log can help you stay organized and catch problems early.

Should I share my RAID log with stakeholders?

Yes, sharing the RAID log with stakeholders is a good practice. It shows that you are aware of risks and managing them actively. You do not need to share every detail, but showing stakeholders the high-level risks, active issues, and key dependencies builds trust and keeps them informed about what could affect the project.