There’s been a bit of debate lately between the quantitative and qualitative camps of the risk management world. The good news is that both camps recognize the need for an organized way to approach risk, rather than the “wave your hands and prognosticate” approach that’s been so popular over the years.
I’ve spent a lot of time looking at risk over the past seven years or so, and as an emergency responder have spent about 17 years of my life making risk decisions in high-stress environments on a regular basis. I’ve been looking at risk from both the IT security perspective and the Enterprise Risk Management (ERM) perspective. I’m a firm believer that you need a risk management framework, and a firm believer that most of them suck ass. Don’t even get me started on the COSO ERM framework.
The problem with most risk management frameworks is that they either focus on checklists that don’t reflect reality, or the kind of quantification that magically turns guesses into statistically (in)significant numbers. Quite a few were written by big consultancies just to drive huge and endless risk assessment projects.
Your risk management framework should help you make an informed risk decision, without becoming a giant hellish time-suck. Here are a few key things I look for when evaluating a risk framework:
- It’s driven by the risk tolerance decided by executive management: Face it, unless you’re on the Board of Directors, you work for someone else (the Board technically works for the shareholders, but we know that’s a load of crap in modern business). It’s up to the Board and executive management to define the risk tolerance of the enterprise. If they don’t do this, it’s impossible for anyone else to make an informed risk decision.
- It combines quantitative and qualitative risk in a consistent manner: One of the biggest failings of any risk framework is either ignoring the quantitative or the qualitative, or forcing false numbers onto qualitative assessments and tolerance. The best risk registers I’ve seen combine quantitative and qualitative measurements together in a scaled approach. For example, we can list out from acceptable to unacceptable the amount of credit risk our organization is willing to accept, and rate ranges on that scale from one to five. We can also describe something qualitative, like our reputation, and apply the same one to five scale rating. Put them in a grid and we can now directly compare the two.
- It allows domain experts to evaluate risks in their domain: I despise any risk model that has someone other than a domain expert decide how to evaluate risks in their domain. I spent thirteen years with Rocky Mountain Rescue; I can make a risk decision (often quantitative) involving a complex rescue on a cliff face in the blink of an eye that would take a physicist months, and they’d still probably get it wrong. Your infosec grunts can probably make great risk decisions in their domain, but probably suck at risk outside their area of expertise. Your risk model should reflect the skills of domain experts, not those of a person writing a checklist.
- It supports communication between domain experts and the business: Just as you don’t want a risk manager overriding the risk analysis of a domain expert, you don’t want a domain expert making enterprise risk decisions outside their domain. That genius infosec dude (or chick) has no idea how much credit or legal risk is acceptable. One problem with domain experts is seeing the big picture; they often struggle to place their risk within the context of the overall enterprise. The framework should support communications between the two- so the higher ups understand the relative risk from within a particular domain, without having to know the particulars of that domain. Domain experts can make optimized on the job decisions, yet understand where they fit in within the overall enterprise.
Essentially, we’re solving four key problems:
- Having no executive guidance on what level of risk is acceptable.
- Relying too much on either the quantitative or the qualitative, to the exclusion of the other.
- Not allowing domain experts to make the risk decisions they’re best at.
- Not effectively communicating this risk so management can make informed decisions, nor giving domain experts the ability to place their risk in context.
Oh, and there’s one more: making this all so fracking complicated that no one can possibly understand it and still get their job done.
Have I found a framework I like? Absolutely, because I wrote it. If you’re a Gartner client go take a look at the Gartner Simple Enterprise Risk Management Framework. I designed it to be a practical tool that meets the requirements i talked about above- practical, driven from the top, decisions made by the experts, and consistent communications from top to bottom. And less than twenty pages, which I think is a record in the world of risk.
I wish I could post it here, but it’s not my property. I know a lot of you have access and I’d be interested in your feedback.
But whatever framework you use, let’s just remember the basics. Risk is decided at the top, not everything is quantitative, not everything is qualitative, and the best risk decisions are made by domain experts, who are worthless if they can’t communicate to the rest of the business.
Comments