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.

Photo of multi-level 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.

Payment-supplier-fraud-invoiceCriminal 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 credentialsthis 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

Protecht-ERM-Risk-Taxonomy-Risk-Library-1As 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:

New call-to-action

ASIC Report Whitepaper: A Regulatory Spotlight on Non-Financial Risk
Whitepaper

A Regulatory Spotlight on Non-Financial Risk

Download Now

Related Articles

feature image
ERM Risk Controls Risk Manager Risk Management Software Videos Webinars

Controls Assurance Webinar

Awesome Controls Assurance: The Confidence to Go Faster This event was done live on Oct.22nd 2019. Access the recording here. “The greatest potential...
Read more
feature image
Videos Risk Libraries Risk Management Framework Risk Taxonomy

Disparate and Disconnected Risk Processes and Information? Solving the Problem with Risk Taxonomies

This is part 2 of our video series on "Disparate and Disconnected Risk Processes and Information". In this video, David Tattam talks about what makes...
Read more
feature image
Enterprise Risk Management Risk Analytics ERM Risk Management Software Videos

Webinar Recording - Understanding RiskInMotion

How to bring all your risk information into one dashboard Have you ever been told that your risk reporting is static, backward-looking or too...
Read more