At Protecht, we get to see a lot of risk event libraries. There continues to be some confusion as to what is actually a risk event that is worthy of its place in a central library of risks. We often see these libraries peppered with failed controls, impacts and causes rather than the true underlying risk event.
In this blog, we hope to provide some tips for you to do your own sanity check on the quality of risks in your risk registers or library.
Think about the output
It helps to first think about the output – what will our reporting to stakeholders at both management and Board level look like and be used for. If risk events are too broad, aggregation of supporting data such as incidents and internal audit findings connected to such broad risks will become less useful, as will any attempt to allocate a meaningful set of controls to the risk. Too specific with lots of detail, renders summation of the top risks in charts as too unwieldy and confusion as to what is the actual risk event.
Examples would be as follows:
Criminal activity – too broad.
In this example, there are too many sub risks with different controls that need to be assessed. If all internal audit findings and incidents relating to internal fraud were wrapped up to this ‘risk event’ the first thing any board member would ask is what type of criminal activity are we talking about? Rather than a risk event – this would be a good risk category, similar to other risk categories such as Employment Practices and Safety and Business Disruption.
Criminal activity such as internal fraud relating to payroll fraud and payments fraud resulting in financial loss and reputation damage – too detailed.
In this example, specific risks that will have different controls are rolled into one event and impacts are included in the risk event definition. It is too verbose.
More concise risk events would be:
- Supplier payments fraud
- Payroll fraud
- Fixed asset fraud
Each of these risk events will have different controls attached to them making it more meaningful for the business to assess them at this level. Note also how concise the definition is – there are no impacts, causes combined into the event definition and hence no confusion as to the underlying risk event. We also often seen failed controls making their way into the risk event libraries.
Check for failed controls
Look at your own risk event library and check whether any of the events have the following words in them:
- Failure to
- Inadequate
- Not properly
- Not accurately
The good news is you have probably identified a control that is important in mitigating a key risk. The bad news is you need to take it out of your risk event library, think about what the true risk event is and then use it as a control.
An example would be as follows:
Failure to check new supplier credentials – this is a very broad failed control – not a risk event. The most relevant risk event is Supplier Payments Fraud. Example key controls would be:
- Supplier details checked to ASIC ABN site prior to loading into payments system, evidence of check marked on supplier file.
- Supplier invoice approved by relevant manager, with ABN and other details matched to payments system details prior to purchase order being generated.
Note that the controls have more detail than the risk event. We look for at least one, preferably two of the three control characteristics in our control definitions - Authorisation, Evidence and Frequency. In doing so the control becomes more meaningful – attestations can be created around it and internal audit can reference it in their audit programs.
Consider the risk story
As a final check consider using the concept of the risk story:
- The risk of (risk event)…
- Is caused by (causes)…
- Resulting in (impacts)…
- And can be controlled by (controls)…
This story will not work well if your risk events are muddied with failed controls, causes or impacts as two lines of the story will start becoming repetitive.
Working with one of our first examples:
- The risk of “Criminal activity such as internal fraud relating to payroll fraud and payments fraud resulting in financial loss and reputation damage”
- Is caused by “human nature, greed”
- Resulting in “financial loss and reputation damage”…
At this point we can stop, as we have started repeating ourselves. The risk event does not work properly. If failed controls are in the risk event, the controlled by part of the story will repeat itself.
Managing a risk event library is hard work. We constantly need to remain vigilant of duplicate and corrupt risks making their way into the library, but in the end, it is a critical part of the risk teams function.
Next steps
Learn how you can keep your risk taxonomies consistent how you can use these to aggregate your risk information up to the highest level by watching our webinar recording:
