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.
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:
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.
Look at your own risk event library and check whether any of the events have the following words in them:
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:
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.
As a final check consider using the concept of the risk story:
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:
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.
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:
David Bergmark consults on a variety of market and enterprise risk management issues and is actively involved in the development and implementation of Protecht's risk management software (ERM and ALM). David started out in the audit division of Price Waterhouse in 1990, handling clients such as Macquarie Bank and Bankers Trust. By 1994 he was Risk Controller for Carrington Securities - a financial markets trading company. In 1996 David left Carrington to head up the Risk Management Department at IBJ Australia Bank (IBJA) where he was responsible for the development of all risk disciplines at the bank – market, credit, liquidity and operational.