GRC Tuesdays: Risk Aggregation—Busting the Myths

Outside of the banking industry, where risk aggregation has a shared definition that includes one by the Basel Committee on Banking Supervision, I personally have come across many different meanings for “risk aggregation” and it really depends on what the final objective is.

In the list below, I have tried to summarize the most common definitions that I’ve encountered. I think it’s relevant to categorize them following a typical risk management cycle because the same term will be applied for very different meanings along this process.

1)Risk Aggregation during Identification Phase

Here, the intent is to be able to capture all the risks that can be associated to a “Master Risk” in order to re-create a complete chain of events.

For instance, what are all the risks that can lead to an inability to meet a customer demand? Power outage on the production chain, damaged ready-to-ship stock, quality defects on the final goods, and so on.

On a side note, this is where I believe a software solution helps. One would need to know all the related risks coming from all departments, which is quite complicated if not impossible. Being able to search by similarities makes it a lot easier and prevents risks falling through the cracks!

2)Risk Aggregation during Assessment Phase

This phase usually follows the one above but takes it one step further. Here, the intent is to drive the risk assessment of the “Master Risk” by consolidating the risk ratings of the “Underlying Risks” or children risks. Should the likelihood or the impact of one of these risks increase, for instance, then the “Master Risk” will be automatically impacted and its risk owner could be proactively notified.

This is particularly interesting if the owner of the master risk is not a business matter expert but rather a business owner. He or she may not even know the details of the underlying events or their context.

3)Risk Aggregation during Mitigation Phase

In some cases, mitigating one risk won’t be sufficient to prevent the events from unfolding. As a result, one must determine a global response strategy that will span across multiple risk events and target their root causes all at once. When doing so, it will be relevant to  sort the risks that have matching criteria (like aggregating by same drivers) and reviewing the completeness and effectiveness of the mitigation strategy with regards to this information.

Should the cost of the global response be higher than the sum of all risks?Will it be really worth it?

Having this information at hand before making a large investment would be interesting—if not career saving sometimes, right?

4)Risk Aggregation during Reporting Phase

This is the most common type of requirement that I encounter. Here, the intent is to consolidate the risk events by risk categories or business units. The intent is rather simple and straightforward but is the foundation of a sound risk management process—to display a total risk exposure per selected view.

The head of a business unit or legal entity might not intimately know all the individual risks recorded, but being able to view the potential total exposure and its likelihood will help in reporting this to the right level of authority. This could even be the Board should this exposure be above a set tolerance level.

Since an image is worth a thousand words, I just wanted to illustrate the purpose above. Of course, this is an example and this report is also often displayed in bubble charts, bar charts,  pie charts, and so on.