Risk is a topic that I like to talk about a lot, mainly because I managed to get it âwrongâ for a very long time, and when I finally did realize what I was missing, everything else I struggled with fell into place around it. For me, therefore, Risk is the tiny cog in the big machine that if it is not understood, greased and maintained, will snarl up everything else.
Risk, in the early days of my career, was something to be avoided, whatever the cost. Or rather, it needed to be Managed, Avoided, Transferred or Accepted down to the lowest possible levels across the board. I wasnât so naive as to think all risks could be reduced to nothing, but it had to be reduced, and âacceptingâ a risk was what you did once it had been reduced. Imagine my surprise that you could âacceptâ a risk before you had even treated it!
There are many areas of risk that everyone should know before they start their risk management program in whatever capacity they are in, but here are my top three:
Accepting the risk
If you want to know how not to accept a risk, then look no further than this short music video (which I have no affiliation to whatsoever, honestly). Just accepting something because it is easy, and you get to blame your predecessor or team is no way to deal with risks. Crucially, there is no reason at all why high-level risks cannot be accepted, as long as whoever does it is qualified to do so, cognizant of the potential fallout, and senior enough to have authority to do so. Certain activities and technologies are inherently high risk; think of AI, IoT or oil and politics in Russia, but that doesnât mean you should not be doing those activities.
A company that doesnât take risks is a company that doesnât grow, and security risks are not the only ones that are being managed daily by the company leadership. Financial, geographic, market, people, and legal risks are just some of the things that need to be reviewed.
Your role as the security risk expert in your organization is to deliver the measurement of the risks clearly as possible. That includes ensuring everyone understands how the score is derived, the logic behind it and the implications of that score. Which brings us neatly onto the second âTop Tipâ:
Measuring the risk
Much has been written about how risks should be measured; quantitatively or qualitatively, for instance, or even financially or reputationally. Should you use a red/amber/green approach to scoring it, or a percentage, or figure out of five? What is the best way to present it? In Word, Powerpoint or Excel? (Other popular office software is available.)
The reality is that, surprisingly, it doesnât matter. What matters is that you choose an approach and give it a go; see if it works for you and your organization. If it doesnât, then look at different ways and methods. Throughout it all, however, it is vital that everyone involved in creating, owning and using the approach knows precisely how it works, what the assumptions are, and the implications of decisions being made from the information presented.
Nothing exemplifies this more than the NASA approach to risk. Now you would think that NASA, having the tough job of putting people into space via some of the most complicated machines in the world would have a very rigorous, detailed and even complicated approach to risk, after all; peopleâs lives are at risk here. And yet, their risk matrix comprises of a five by five grid with probability on one axis and consequence on the other. The grid is then scored Low-Medium or High:
Seriously. Thatâs it. It doesnât get much simpler than that. What there is, however, is a 30-page supporting document explaining precisely how the scores are derived, how probability and consequence should be measured, how the results can be verified, and so on. The actual simple measurement isnât what is important. It is what is behind it that is.
Incidents and risk
Just because you understand risk now, doesnât mean you are going to be able to predict all of the things that might happen to you. âBlack Swanâ events (so-called from Nicholas Nasim Talebâs book of the same name), are events that cannot be predicted until after the fact when it was apparent they were going to happen.
By this very fact, creating a risk register trying to predict unpredictable, potentially catastrophic, events, seems a little pointless. That, however, is not the way an excellent approach to risk works. Your register allows you to update the organizational viewpoint on risk continuously. This provides supporting evidence of not only your security functionâs work in addressing said risks but also allowing you to help define a consensual view on the risk appetite of the business as a whole.
When a Black Swan event subsequently occurs (and it will), the incident response function will step up and address it as they would any incident. As part of the documented procedures they follow (you have these, right?) a set of learning points and advisories would be produced, including areas to look out for in the future. This output must be reviewed and included in the risk register as appropriate. The risk register is then reviewed annually (or more frequently as required), and controls updated, added or removed to reflect the current risk environment and appetite. Finally, the incident response team will review the risk register, safe in the knowledge it contains fresh and relevant data, and ensure their procedures and documentation are updated to reflect the most current risk environment.
Only by having an interconnected and symbiotic relationship between the risk function and the incident response function will you get the most benefit from understanding and communicating risks to the business.
So there you have it, three things to remember about risk that will help you not only be more effective when dealing with the inevitable incident but also help you communicate business benefit and support the demands of any modern business.
Risk is not a dirty word.
