Try the app for free improves on the tried and true RAID log by rebuilding it on a modern SaaS platform. Use it alongside your task management platform to ensure your plan goes to plan.

About the book

The Ultimate Guide to RAID Log
by Kim Essendrup

This book will introduce you to RAID logs and help you learn how to use them so your projects can immediately benefit.

© Copyright 2022 Kim Essendrup

Excerpts from the Ultimate Guide to RAID Log may not be copied, reproduced or distributed without author’s permission


Below are the typical columns in the Risk log of a RAID log. 

Column Description
ID Unique ID for tracking and reference
Title, in a “problem statement” Use a problem statement form: as a result of <definite cause>, <uncertain event> may occur, which would lead to <effect on objectives>                                                                                                                       
State State of the Risk. Usually a picklist denoting the lifecycle, including:

  • Raised (but still needs to be managed)
  • Open/Monitoring (response plan created)
  • Issue (the risk actually happened)
  • Closed (the risk no longer applies)
Description Detailed description of the risk and its potential impacts and influencing factors
Date Raised Date the risk was added to the log. This is good for tracking new vs old risks
Source Source of the risk – the person who raised it or the forum it was raised in. This is handy when someone says, “where did this come from?”
Category Categorization field for grouping risks for effective planning and management. 
Probability of Occurrence Numeric value representing the probability that the risk could happen. Can be a percentage, or a numerical scale (1-5)
Impact of Occurrence Numeric value representing the impact of the risk, should it occur. You could use a monetary value, but assigning an accurate financial value can become quite involved, so it is usually more expedient to assign a numerical scale (1-5 or 1-100) with a definition of each level or a percentage.
P*I Multiple Probability and Impact to arrive at a P*I score, or Risk Score which can be used to stack-rank your risks in order of importance. 
Owner The Owner is the person responsible for managing the risk. Most of the time, that will be the PM. But it could also be the technical lead, the Product Owner or Sponsor. The PM should keep on top of the Risk because they are accountable for the success of the project, but the Risk Owner is the one Responsible on the RACI. 
Trigger Date The date on which (or by-which) the risk would become an issue if it happens. After this date, the risk is immaterial. 
Response  This is a text description of how you will respond to the risk.
Response Strategy Picklist describing the strategy used to respond to the risk. This is optional if you have done a good job documenting the Response. It’s more important to understand these options when documenting your detailed response than actually documenting the strategy. Picklist options are:

  • Avoid
  • Mitigate
  • Transfer
  • Accept
  • Escalate
Response Update A text field with the latest update on the risk so you can see how your response is coming along. These can be timestamped entries or just the latest update
Date Updated Date the last time the risk was reviewed or updated
Date Closed Date the risk was closed or canceled
Reason Closed Picklist or text describing the reason the risk was closed 

  • Risk passed the trigger date and did not occur
  • Project ended
  • Risk occurred and was converted to an Issue


Here are some additional columns that can be used to extend your Risk log in certain circumstances. 

Column Description
Contract / Charter Reference Remember that any planning assumptions and constraints are inherently risks to your project if they don’t hold true. So, adding those to your Risk log is a great way to start planning. This column is a reference back to the contract or planning documents, like the charter, where the assumption or constraint was documented. This can be handy if the risk turns into an issue as it can have contractual implications -for you, your suppliers or clients. 
Impact Category Some organizations like to be more specific with the Risk Impact and categorize risks by the constraints they may impact. Typical Impact Categories may include:

  • Scope
  • Schedule
  • Budget
  • Quality
  • Resource
  • Production operations
Date Proximity Similar to the Trigger Date, many PMs like to measure the date proximity of a potential risk so they can focus more attention on those that are impending.
Escalations If you need to create a paper-trail for who you escalated the risk to, when, and their response, then a special Escalations column can be useful. 
Response Status Red/Amber/Green indicator showing the status (on-track, at risk, off-track) of the risk response plan. When this is red, it means that the plan to mitigate the risk is going off track. This can be really useful for very critical risks. 
Residual Probability Residual probability is the probability the risk will occur AFTER the response strategy is implemented. It is typically more efficient to simply update the Probability of the risk after implementing your response, but sometimes it is nice to demonstrate the effective impact of your response, and thus the value of your risk planning
Residual Impact Like Residual Probability, Residual Impact is the measure of expected impact after the response strategy. Like Residual Probability, it is more efficient to simply update the Risk Impact score after implementing these measures, but it can be nice to break it out if you have to demonstrate the value of your risk planning. 
Residual P*I Residual Probability * Residual Impact
Residual Risk description Explains what risk remains after your risk response is implemented. Even when Residual Probability and Impact are not used, it can be useful to describe what risk is remaining after your response actions, especially for more serious risks. 
Financial cost of impact Typically used only for the most impactful risks where EMV is used, this represents the total financial impact if the risk were to occur. If you use this field, then you should have an explanation ready for how you came up with this number. 
Expected Monetary Value (EMV) Probability as a percentage * Financial Cost of Impact. This represents the Expected Monetary Value of the risk, which can be useful for more advanced financial analysis. 
Internal Only (team only) Flag Flag indicating if this RAID item should be kept internal to your team. 

Instead of a flag, you can create data classification picklist of increasing sensitivity, such as “My-eyes only,” “Internal Team Only,” “Internal Org Only” or “All Stakeholders(default)” to allow for easy filtering 


Together, we can run or rescue any project