Risk Management Tools – Risk Register

Time and again I get asked about my template for a risk register. Most people know that my approach is somewhat different to those that have traditionally been used.  Don’t get me wrong – I am not talking about a register that is completely different to those that are commonly used, however, there are a few aspects about my register that I have developed that you might find useful.

I’m going to unpack it below so that you can build it your way for your brand, knowing the categories and information that you need for each column, or you can download your very own ready-made Paladin Risk Management risk register.

Risk #	This is the unique identifier or number you apply to the risk using the organisation’s own conventions.
Risk Owner	The owner of the risk will be by name or by position. My Risk Tip #7 explains more about this.
Risk Description (What is the event/incident we are trying to prevent from happening?)	The risk description needs to be a short statement of the event/incident that we are trying to prevent from happening.  What we don’t want to see are essays like this: Insufficiently detailed or targeted management procedures limit access to financial management information at key decision points. The inability to access specific financial information about reasons for expenditure in the context of budget from the financial information system (FIMS) … and it goes on and on and on. My Risk Tip # 8 discusses capturing the right risks in your risk register.
Risk Causes	It is critical after identifying the risk to then identify those factors that could potentially cause the risk event to occur.  Causes tend to fall into categories, for eg: People: training, skills, experience, fatigue Systems: IT, mechanical Infrastructure: Buildings, utilities External: Weather events, external behaviours Once causes have been identified, the next step – the identification of controls aligned to the causes – becomes a lot simpler.
Controls aligned to causes	In most risk registers I have seen, current controls are captured as a block, usually in a free-text field.  In my view, this does not allow for the alignment of the controls to a specific cause.  I have found, however, that directly aligning controls to causes allows me to identify where there may be control gaps. When developing controls, they need to be specific so there can be no confusion.  Describing controls in a manner such as: Training; Policies and procedures; Induction; Physical security; and Processes is not helpful in terms of the next step, which is to determine their effectiveness.  To that end, controls should be described as follows: Annual fraud control training programSeparation of duties Fraud component of induction packageUnauthorised external device auditsPenetration testing program
Control Owner	The person nominated as responsible and accountable for the implementation and ongoing review of the control for the organisation
Control Effectiveness	This is one of the most important columns in that it provides an assessment of the effectiveness of the controls linked to the causes of the risk.  This is then used to determine the likelihood of the risk. Measuring control effectiveness is explored in detail in Risk Tip #2.
Control Criticality	Control criticality accounts for the fact that not every control will have the same impact in terms of managing the risk.  The table I use to determine criticality is shown below:
Risk Consequence/s (What is the impact on X,Y,Z Organisation should this risk eventuate)	In this column, I provide a descriptive overview of the consequences that may arise if the risk was to materialise.  This gives a view of the range of consequences as opposed to the level of consequence.  Examples include: Potential negative impact on XYZ’s reputationPotential legal action against the companyPotential scrutiny by regulatorsCould lead to business disruptionCould lead to death/injuryPotential for additional costs to rectify issue
Controls aligned to Consequences	Controls aligned to Consequences.  In this column we are detailing the controls that are specifically aimed at reducing the consequence should the risk materialise.  In my experience, in the majority of cases, organisations cannot do anything to reduce the consequence level of a risk i.e. if it happens, it is going to be that bad.  The controls that are available to reduce consequence are as follows: Negative impact to reputationCrisis Management PlanFinancial impactInsurance (list specific policy)Disruption to operationsBusiness Continuity PlanDisaster Recovery Plan Crisis Management Plan
Control Owner	The person nominated as responsible and accountable for the implementation and ongoing review of the control for the organisation.
Control Effectiveness	This is one of the most important columns in that it provides an assessment of the effectiveness of the controls linked to the causes of the risk.  This is then used to determine the likelihood of the risk. To learn more about measuring control effectiveness head to my Risk Tip #2.
Control Criticality	This requires the use of the same criticality matrix.
Risk Assessment with current controls   – Likelihood – Consequences – Risk Rating	Likelihood. This is an evaluation of the likelihood of the incident/event occurring based on control effectiveness of the controls against the causes.  This is a significant departure from the traditional method of basing likelihood on time, frequency and/or probability.  There’s plenty more on this at my Risk Tip #1. Consequences. These columns are where we record the consequence level for the risk, derived from out consequence matrix.  It is critical that we capture the consequence against all impact categories which will assist us in making decisions in relation to whether further treatments may be required and also to conduct a cost-benefit analysis on those proposed treatments. Risk Rating. The risk rating will be derived from the likelihood rating and the highest consequence rating of the ratings against each of the impact categories.
Additional Treatments	After assessing whether the risk is acceptable or not against the organisation’s pre-determined criteria, decisions are taken as to whether further treatments are required.  These will the be subject to a cost-benefit analysis.  Guidance on the wording of risk treatments can be found here at Risk Tip #9.
Treatment Owner	A person accountable for the development and implementation of the treatment/s is identified in this column.
Treatment Timeframes	The timeframes for the treatment to be completed are captured in this column.
Residual (target) Risk Level	In this column we are determining what the level of risk will be when all our current controls are effective, and treatments have been implemented and are also effective.  Post mitigation assessments of likelihood, consequence and risk level (residual risk).
Risk and treatment status	This column will be a free-text field that allows for status updates to be recorded.  It can also be used to capture details of any change to the level of risk and the reasons behind it.  This forms an important part of the audit trail for the risk.

So, below is the compilation of all of those elements for the risk register format I use when I am developing risks into an organisation.  Next month I will provide an example of the Control Summary Sheet that I use.