I've written about my version of what a fully featured enterprise risk management (ERM) system should, or at least could, look like. During a recent conversation with some colleagues, I was reminded that most people's primary problem with ERM is still the same 'hours in the day' (aka resources & funding) problem.
There is so much I could say about software and frameworks, and perhaps I'll write about that in another article, but in terms of finding the resources that you know you need, here are a few thoughts.
Finding Funding
I've written a book on Business Cases for Risk Management, but if you are already across business cases, NPV, DCF, etc then I'll cut to the chase. The heart of it is to write a business case using the 8-step problem-solving template/process (attached). It has always worked for me. It looks simple but works either as a template for a document (change the headings at the end of it all to turn it into a business case), as a facilitated workshop, or as a one-pager to cover a big idea.
Figure 1: 8-Step Business Case Model
Apples For Apples
In terms of implementing an ERM system, especially a software platform, the ISO31000 models are a great place to start. The main one to look at is the 'Process,' and if you can get your organization to sign off on ISO31000 (at least the process), then you can do an 'Apples for Apples' comparison of risks. Having a consistent (and internationally recognized) framework means that when it comes to prioritizing resources, the executive team should be able to compare any two or more risks, to see where the resources are best applied.
The principles and framework are great, especially as audit and training need analysis tools, but the process is crucial.
Figure 2: ISO31000 Principles
Figure 3: ISO31000 Framework
Figure 4: ISO31000 Process
The Rock Pool Of Risk
As a mental model, I think of ERM as a topographic feature, and in my mind at least, I picture it as a tidal rock pool. I possibly need to invent a better analogy than a rock pool (I'm open to suggestions here) but it works for me.
Many people think that ERM means assessing all the facilities/businesses/assets to identify their risks and then aggregate them. That's a long slow death by a thousand cuts and doomed-to-failure approach. If you think of an enterprise as an ecosystem, let's imagine you're exploring a tidal rock pool. It's an uneven surface with lots of high and low points — holes where you could twist an ankle or rocks that you could trip over.
Figure 5: Tidal Rock Pool
For me, ERM isn't about identifying every hole or trip hazard, as it is about leveling the surface to be ALARP (and maybe think about ESIEAP as part of that). It's about:
Setting a standard (i.e., What level of risk should/can/must we have across the organization). Think, for example, of cybersecurity and IT interfaces with the internet. There is no point having 2048 bit encryption on our VPNs and then allowing one or two offices to use 128-bit encryption. What level do we want the surface to be in the rock pool?
Do a quick scan of the lumps and hollows. Start with the end in mind by creating a benchmarking or KPI framework.
Moving the rocks into the holes. Ie. Moving resources from places where risk is being over-treated to sites where risk is undertreated. Aka making better use of existing resources.
Applying the resources intelligently via standards and risk postures to the places that need them most. E.g., bringing the buckets of sand any shallow depression and bringing even more sand (resources) if it turns out that the sand is falling into a hidden crevice. The alternatives are: bringing truckloads of sand (wasteful), adding sand willy-nilly (random), or worse yet, spending resources to measure the depth of every hole (trying to do risk assessments on everything all the time). This approach also makes it easier to budget because you can work out a 'base standard' (for any given threat/risk/hazard profile). You'll know the worst-case cost to remediate the risks.
In the end, ERM doesn't mean perfection or treating every risk. It means (IMO) a level playing field in terms of risk exposures.
Training Changes Culture
I mentioned this in other articles but have attached a graphic. Happy to expand on it, but the short version is that training is the surest way to change organizational culture in a meaningful way. The process is:
Training Needs Analysis - start with the end in mind
Training changes
Behavior shapes
Attitudes in the collective equal organizational
Culture drives
Performance
The nice aspect of how this works is that if you give people new skills via training, they have a bigger toolbox of options when dealing with challenges. Hence, they are more likely to choose a better tool/idea/process to deal with a situation.
But the main driver of change comes after that. Cognitive dissonance theory refers to the state of discomfort people feel when two or more modes of thought contradict each other. In this context, what it means is that we strive to believe that we are doing the right thing. When we carry out a certain behavior we want to believe that it is because it is a 'right' behavior.
For example, if you want people to work more safely at heights, you give them training for safe working at heights and supply scaffolding and harnesses, etc so that they can apply the training. Where in the past, they might have been quite comfortable working at heights without a safety harness, they will now (thanks to the marvels of cognitive dissonance) believe it is appropriate to always use the safety equipment. They are even likely to berate or cajole other employees into using the safety equipment if they see someone else not using the equipment that they are.
The same principle applies for any training. Computer programming, spreadsheeting, negotiating, leadership, etc. We will use whichever tools we have been given that are effective, and then choose to believe that it is the proper way to do things.
Eventually this changes our attitudes, and collectively when enough individual attitudes have been changed, so then is the collective culture changed.
Figure 6: Training, Behavior, Attitude, Culture
I've posted a few articles on this topic here at juliantalbot.com, but my vision for the sort of enterprise risk management solution that I'd like to (and will one day) build is at https://www.juliantalbot.com/post/the-future-of-management. I've created a short video there, which might be an inspiration for designing a video that you could share with management to shape their thinking.
The 4As and 4Cs
A big part of the problem with ERM at most organizations is that there is no consistent way for documenting risk, findings, and treatments.
Below are a couple of graphics that cover some ideas for documenting risk treatments (4As) and identifying risk issues (4Cs).
Figure 7: 4Cs (Condition Criteria Cause Consequence)
Figure 8: 4As (Actionable Achievable Appropriate Agreed)
Figure 9: Example of the 4Cs in a paragraph
Figure 10: Example of the 4As in a paragraph
Not only are they useful for preparing reports but incredibly helpful if you're reviewing someone else's work. It's my version of the 'instant expert.' Suppose you read a risk report with the 4As and 4Cs in mind. In that case, you can assess the quality of the document and identify any weaknesses in a matter of minutes. You will quickly get to the heart of the matter if you have the Criteria, Condition, Cause, and Consequence stated in some fashion. And if they aren't all there, you'll have found an immediate area to be worked on
I've attached the 4As and 4Cs as a powerpoint file here in case you'd like to use it in your own risk presentations.
CASE (the Consequence Asset Source Event) of Risk Identification
In a similar vein, the CASE risk statement model is an excellent way to identify risks. Not saying it's the only way, but if your organization wants to manage risks consistently at the enterprise level, this sort of model is pretty much essential.
I've written about it at https://sectara.com/news/how-to-write-risk-statements and have been evolving a better version, which I'm happy to share if you would like. The short version is that acronym or CASE has grown from the need to consider at least four characteristics when analyzing a risk:
Consequence – what is the likely impact of this risk?
Asset – what asset(s) are actually at risk?
Source – what are the hazards or threat actors that might lead to the risk manifesting?
Event – what particular type of incident is being considered?
Much of the problem I see with risk management is that you can't deal with a risk of 'cyber' or 'capability' because they mean different things to different people. CASE is a way of making things explicit. Not the only way, but it works for me.
An example of applying it to a cybersecurity risk might be as follows. Instead of saying something vague and hard to quantify like "loss of client data in a cyber attack" you could expand is to "Failure to protect client data (Asset) from criminal hacker groups (Source) using phishing attacks (event) against our staff, resulting in fall in our share price (Consequence)."
The above risk statement using CASE makes it relatively easy to assess the consequence, likelihood, and impact on objectives and to devise treatment. Compare that to the lazy approach of listing something vague like 'risk of cyberattack'. Cyberattack could mean about 20 different risks. And hence is impossible to assess or mitigate effectively.
Some More Information
I've posted many more articles at https://www.srmam.com/read-chapters. They are mostly focussed on security risks, but the models and concepts are applicable to all types of risks. The Stroud Matrix might be a useful concept at the enterprise level. Feel free to download and use any of the graphics at https://www.srmam.com/download-images if they are helpful.
Software
A friend and I are starting humbly with a security SaaS offering, which we will eventually build into a true ERM offering. But there are many modules to create before we get to that point. And we want to be sure that the system is robust, so we're taking an incremental approach. There is a fully-featured free version, and any security folk might find useful or just if you're curious https://sectara.com/. You'll also find a few of my articles there.
Scrapping The Risk Matrix
Many risk practitioners are calling for the scrapping of the risk matrix. The risk matrix defines risk levels based on assessed levels of likelihood and consequence and pre-defined risk criteria.
The problem is that the assessments of probability and consequence are wrong or misleading. They are either plucked out of thin air or are not presented with information about the explicit risk or underlying probability distributions. And the main problem with risk matrices isn't that they are inherently flawed as some people would argue.
The main problems with risk matrices are:
a) People don't specify the risks being assessed (eg: using CASE)
b) Risks are rarely capable of generating a single consequence.
You already know how to address issue a) but issue b) requires a new way of using risk matrices. Think of how you might overlay a probability distribution on a risk matrix.
The probability of an event can, and should, be expressed as a number from 0 to 1 (or a percentage). But then if/when that even occurs, can we really think of a risk as having a single and certain consequence? I'd suggest that even the most basic level of analysis will infer some sort of probability distribution in terms of what happens.
In this diagram for example, I've mapped a theoretical range of consequences for an organization where losing 100% of net worth is what they consider an existential threat. Risk A has a 60% likelihood of happening and will most likely take 70% of their net wealth. But, if it happens, it will cost at least 40% and has a slight change of being an existential threat. In reality the curve might extend beyond the 1.0 in terms of consequence but by then it's a moot point.
Figure 11: The 10 x 10 Probability Distributed Risk Matrix
Don't scrap the risk matrix just yet. People are used to it. It facilitates conversations that need to be had. It can be used as the starting point of getting accurate with risk analysis. The next link is a short article by a friend which has a couple of good ideas in it: https://www.bryanwhitefield.com.au/blog/from-guestimate-to-estimate-as-simple-as-123 If you use risk matrices, you might find these articles have a few ideas that might be useful to shape corporate thinking https://www.juliantalbot.com/post/how-to-use-a-risk-matrix and https://www.juliantalbot.com/post/2018/07/31/whats-right-with-risk-matrices
Causal Chains
I'm focussing on 'Causal chains' and 'root cause analysis' (especially of near-miss events) these days, but everything is important.
That is in itself an entire other article but the short version is that in every fatal or significant mishap that I've looked at, multiple things had to 'go wrong' or barriers had to fail. It's not just Swiss Cheese were the holes line up but, in the end, a series of events that have to occur.
I'm yet to find this concept better illustrated than in this presentation by Brian Appleton (Technical Adviser to the Enquiry) on the Piper Alpha Accident.
If you're not familiar with the Piper Alpha incident, it is an iconic but tragic lesson from history that took the lives of 167 men in 1988, and ultimately changed the way we manage safety in virtually every industry. A dozen things had to go wrong before that oil fire started and then turned into a gas explosion as in the above video. The video below is the presentation by Brian Appleton. It's a great example of enterprise risks, especially if you look at the broader picture of causes and consequences in terms of the company, and the industry.
You can find more background online and video of the change from an oil fire to a catastrophic gas explosion on Youtube.
Other Reading
There are some outstanding books that might help (apart from my own, of course :-) You've no doubt read a few of these but just in case not.
Thinking, Fast & Slow by Kahnemann - an excellent primer on shaping thoughts and one of my top three 'must read' books for every homo sapien
Anti-Fragile by Taleb. A great concept but a bit overblown. His best-known book is Black Swan, but for my money, he covered that better in a single chapter in a better book, Fooled by Randomness.
Managing the Unexpected: Sustained Performance in a Complex World is a great book on managing risk in complex organizations. They focus a lot on culture, which is the missing link in a lot of organizational risk management and cover a vast body of research and leave you with some practical ideas. This book is helpful with the TBAC model.
And Finally
Sorry. That turned into a long article. In terms of getting more resources for enterprise risk management (or anything in life), the best suggestion I can offer, out of all of this, is to read Pre-Suasion by Robert Cialdini. I highly recommend it and would suggest it as the next step on your journey. https://amzn.to/2GR1c7V
I hope all this helps but happy to explain more if any of that doesn't make sense.
