Everybody's doing it, in some way, shape, or form. It's inherent in just about every decision in life. Yet, when you try to deconstruct it and look at how it works, as well as try to make it "better," you end up with some very interesting challenges. I'm talking, of course, about "risk management."
I don't think that anybody would argue that risk management is important. However, that's about where the consensus ends. How you go about doing risk management takes us down a lot of different roads, which diverge based on numerous variables such as the industry you're in, the size of your organization, the types of risk factors you're weighing, and your overall interest and willingness to formalize certain "things" (methods, metrics, etc.).
For this post, I want to key-in on one particular challenge: How to scale risk management practices to fit your organization. Researching risk management can take you down a seemingly-endless rabbit hole. This complexity is heightened by the fact that things are continually changing and evolving. The credit crisis triggered in 2008 continues to color our views on risk management, which combines with significant changes in approach that leave a lot in question. More importantly, much of the risk management conversation is being driven by major multi-national orgs in the financial services industry - orgs that have the deep pockets and financial incentive to invest heavily in these practices - but orgs that do not provide very good analogs for "the rest of us."
The Literature
There's no shortage of literature on the topic of risk management these days. I'm not going to pretend to even scratch the surface here, but did want to provide a couple key references.
First and foremost, there's a new joint paper out from the Society of Actuaries, Canadian Institute of Actuaries, and the Casualty Actuarial Society titled "A New Approach for Managing Operational Risk: Addressing the Issues Underlying the 2008 Global Financial Crisis." It's a great read and provides a lot of excellent background information. It's written from the perspective of the insurance industry and financial services, which means it has a distinct bias toward "enhanced" practices more suitable to those verticals. The paper describes what the call "Modern ORM," which is an evolutionary step beyond "Traditional ORM" (ORM, btw, being Operational Risk Management).
Beyond that, there are tons of other references you may want to consider, ranging from ISO 27005 and ISO 31000 to NIST RMF to CERT OCTAVE to FAIR to COSO ERM to this recent draft from the U.S. Dept. of Energy for the Electricity Sector.
Additionally, I'd be remiss if I didn't provide a pointer to the Society of Information Risk Analysts (SIRA), without whom this post would be very empty.
An Extremely Brief Primer
There's too much to cover, so allow me to just give you some broad brush-strokes...
1) Enterprise Risk Management (ERM) overarches everything. Underneath it you'll find various other "risk" areas, like ORM, Credit Risk, and Market Risk. Under ORM you'll find InfoRisk (aka "IT Risk" or "InfoSec Risk"). A lot of the focus in financial services today seems to be on ORM, as highlighted by the "Modern ORM" paper mentioned above, in large part because traditional approaches were flawed and contributed to the financial crisis.
2) There are tons of terms. Risk is defined by "Modern ORM" as "...a measure of adverse deviation from the expectation, expressed at a level of uncertainty (probability)." In FAIR, we define risk as "the probable frequency and probable magnitude of future loss." These two definitions are reasonably compatible. Beyond this, we then care about threats (or threat communities) - basically, bad actors who can inflict harm; and, we care about vulnerability, which represents the probability that a threat agent's actions will result in loss.
3) Frequency, Likelihood, Probability, and Possibility. Frequency is a number over time, and it often applies to multiple events over time (e.g. 3 times per year). Likelihood is probability, typically applied to a single event ("what's the probability that X will happen once in time period Y?"). Probability pertains to statistical distributions, which is where we then bring in all sorts of fancy-shmancy stats calculations. Possibility is binary: either it can or cannot happen. Put a single bullet into a revolver and a semi-auto handgun, and they both have a 100% possibility that pulling the trigger will fire the bullet. However, a standard 6-chamber revolver only has a 1/6 probability that the bullet will be fired, whereas the semi-auto has a 100% (1.0) probability of firing with a trigger pull (obviously, assuming everything is in working condition and the safety is off).
There's a lot more that could be said, but it's not necessarily relevant here.
Scaling To Your Needs
In thinking about how best to scale risk management practices I consider a number of different approaches. One place I started was with CMMI to see if there was a logical mapping that could be done in a useful way. The CMMI levels are generically listed as:
Level 1: Initial - Processes unpredictable, poorly controlled and reactive
Level 2: Managed - Process characterized for projects and is often reactive
Level 3: Defined - Process characterized for the organization and is proactive
Level 4: Quantitatively Managed - Process measured and controlled
Level 5: Optimizing - Focus on process improvement
While these levels are interesting and potentially useful in terms of defining a maturity model for risk management, they do not lend themselves to scaling practices. Let me explain... when I talk about "scaling" here, I'm not necessarily talking about getting a foothold and then expanding and refining those practices. Instead, I'm talking about taking the megalithic practices used within financial services, reducing them to the bare minimums that can then be used by SMBs and other businesses looking to get a start. In a way, there's a potential relationship to a maturity model, but for the purposes of this post I'm not really wanting to go that route (some day I hope to revisit the topic of an ERM maturity model, though).
Suffice to say, a maturity model is interesting, but not useful for scaling things down. The questions then remain: What's essential to RM practices? What are the minimum pieces necessary for smaller orgs to make use of what we've learned without being crushed by the load? As such, I've boiled things down to three (3) key steps.
Step #1: Know Thyself
First and foremost, you need to know what you have and what your tendencies are. What are your assets? Where are there? How are they protected? Who has access to them? What sort of incidents would be most disruptive or damaging to your business? Much of this information can be gathered informally, and stored in something as simple as a spreadsheet. If you can't articulate what's most important to your business, then you're not going to be able to do much with risk management. How you assess it can vary widely, but what's important is getting a good, comprehensive list on what's important, and then vetting that list to make sure you're not making unsupported assumptions about the values assigned.
Step #2: Vision & Strategy
Once you know what's important to your business you can then start articulating a vision and strategy. Your vision should be - quite literally - a mental image of how you want things to look. This should impact your strategy for making decisions. In essence, you take the list of assets you've gathered from Step #1 and think about what you're willing to do to protect them. Your vision should address the ideal, while your strategy tempers that vision with a touch of reality. Are there are things that you can do to help achieve that vision? Make a plan and start executing against.
Step #3: Find Your Balance
There is no shortage of "guidance" on risk management, risk assessment, risk analysis, and so on. It's overwhelming! And, frankly, much of it can be ignored unless you're a major multi-national financial services corporation. If your entire (non-financial services) company is less than 2,000 people, then I'm going to find it unlikely that it makes sense to have a 5-person team dedicated to deep risk analysis (I could be wrong). As you continue scaling things down, say to a 50-person company, the thought that even 1 person would be dedicated full-time to risk analysis seems unrealistic. And, yet, we know that these companies still need to follow reasonable risk management practices (PCI DSS tells me so!;).
The key, then, is finding a good balance. Building and maintaining an asset inventory that includes intellectual capital, applications, and people is a good starting point. Building some lightweight loss tables around those key assets is also a reasonable step. Again, if you know what's important to your business (Step #1), then it becomes much easier to think about how to best protect those assets and, more importantly, how to protect the business against an event leading to loss of that asset. The rest is a matter of finding reasonable balance in making decisions to protect the business. Maybe you'll decide to shoulder certain risks and then self-insure against possible losses. Maybe you'll decide to invest heavily in security measures to protect a data asset. Or maybe you'll decide to outsource everything so that you can make it Somebody Else's Problem (SEP).
And, that's it... sure, you can do more (LOTS more)... but is it necessary? That's up to you, and depends largely on what you find through these three steps. Maybe your business would greatly benefit from a dedicated risk analyst whose job entails running complex quantitative risk analyses. Or, maybe the mere thought of that is ludicrous and you simply need to make sure that decisions follow a reasonable process that accounts for potential negative (and positive) impact to key assets. Ultimately, it's up to you. However, having something in place is almost certainly better than nothing.
