RAID Log

Published by Dan on

Blank RAID Log template

Introduction to RAID Log

A RAID Log (Risks, Assumptions, Issues, and Dependencies Log) is perhaps the most important part of any project’s governance. It’s the master document containing all governance information for your project or programme. Recording and maintaining all the elements of a RAID log must be a top priority of your project.

Our free RAID log combines four separate logs into one, and more information about each section can be found on the relevant web page below:

Risk Registerhttps://freepmotemplates.com/risk-register/

Assumptions Loghttps://freepmotemplates.com/assumptions-log/

Issues Loghttps://freepmotemplates.com/issue-log/

Dependency Loghttps://freepmotemplates.com/free-dependency-log/

Points of interest

These relate to the blue boxes in the template – please delete them

Dashboard Tab

1) Dashboard – The dashboard contained in this document will auto-populate as you fill in the document. There is plenty of information in this document to create detailed dashboards – I’d be happy to help create some for you so please get in touch here if needed.

2) Formatting – Be sure to format the document to your brand colours and replace the freepmotemplates.com logo with your own on all sheets.

Risk Register

1) ‘Project’ Column – If you’re working on one specific project then remove this column. Or you can change it to read ‘area’ or ‘project stage’ etc.

2) Scoring Matrix – We’ve included a basic scoring matrix as part of our template. However, many organisations will have their own guidance on how to assess the priority of risks so please replace our version if this is the case.

3) Updates – The blue section of the Risk Register is for updates. Risks should be reviewed frequently and updates submitted here.

4) ‘Status’ Column – Be sure to always fill this column in as it feeds into the dashboard

Assumptions Log

1) ‘Project’ Column – If you’re working on one specific project then remove this column. Or you can change it to read ‘area’ or ‘project stage’ etc.

2) ‘Impact is assumption is incorrect’ Column – Try to include as much information as possible here, but giving a vague answer (such as ‘expensive’) is better than nothing

3) ‘Criticality that assumption is valid’ Column – This will be derived from point 3 above and is a simple high, medium, or low selection. This allows you to filter the document by criticality

4) ‘Actions to validate’ Column – These are the steps that the owner of the assumption will take to validate whether the assumption is true or not

5) Updates – The blue section of the Assumptions Log is for updates. Assumptions should be reviewed frequently and updates submitted here.

6) ‘Assumption Valid’ Column – Fill in the column When you know whether the assumption is valid or not

Issues Log

1) ‘Project’ Column – If you’re working on one specific project then remove this column. Or you can change it to read ‘area’ or ‘project stage’ etc.

2) Scoring Matrix – Your organisation may have a preferred way to rate issues. Feel free to message me if you need a template scoring matrix

3) Financial implications – You should attend to understand the financial implications of each given issue. If you’re uncertain, then simply put Low, medium, or high. This may not be appropriate for every organisation, so please delete if not relevant.

4) Updates – The blue section of the Issue log is for updates. Issues should be reviewed frequently and updates submitted here.

5) ‘Status’ Column – Be sure to always fill this column in as it feeds into the dashboard

Dependency Log

1) ‘Project’ Column – If you’re working on one specific project then remove this column. Or you can change it to read ‘area’ or ‘project stage’ etc.

2) ‘Expect dependency date’ Column – This is the date you expect the dependency to be fulfilled or realised.

3) ‘Impact if dependency isn’t realised in time’ Column – Try to include as much information as possible here, but giving a vague answer (such as ‘expensive’) is better than nothing

4) ‘Criticality of dependency’ Column – This will be derived from point 4 above and is a simple high, medium, or low selection. This allows you to filter the document by criticality

Process Recommendations

It’s important to review all elements of the RAID log on a regular basis. However, it’s best not to do all 4 parts in one go, or in one meeting, as there is a lot of information. Instead, split each section and tackle over the course of a week or two.


Got a recommendation? Then please get in touch with me here to let us know! We’re always looking to improve our documentation.