I was first introduced to the concept of the "risk equation" back in 1999 while working for one of the Big N audit firms. It was expressed to me in quite simple terms:
Risk = Threat x Vulnerability x ImpactAs part of the discussion around "risk" back in those days we also had to talk about what those terms really meant. Broken down, "threat" was really more a matter of "threat frequency" - as in, how likely an attacker would hit your environment. Similarly, "vulnerability" was really more about "probability of compromise" and how likely it was that an attacker would be successful. If you're thinking that this sounds an awful lot like FAIR, then you're right. In retrospect, it's definitely very much inline with that thinking.
All of that said, there's one key factor that was always present in these conversations; at least, it was until recently. "Impact" has always been expressed in some form of value, and typically as a monetary representation. The source of that monetary estimate varied widely, and to this day even continues to be a topic of intense discussion. Do you base your estimate on the asset value (whatever that might be), or on a set of related factors a la FAIR (Productivity, Response, Replacement, Competitive Advantage, Fines & Judgements, and Reputation), or do you use something else altogether?
This topic brings us to three key points:
1) "Risk" expressed in the absence of contextualized "impact" is not really "risk."
2) "Impact" needs to be represent a reasonable approximation of "value" to the business.
3) What's really important to the business may not be easily represented in monetary terms.
Does "Risk" Require "Impact"?
At it's most basic, "risk" is the potential for injury or loss. As such, "impact" absolutely has to be represented, otherwise you lose that foundational essence of loss. To talk just about "threats" and "vulnerabilities" (or, my preference, "weaknesses") does not provide a complete enough picture on their own. Just because there are bad people in the world does not immediately mean that you are bearing a reasonable potential for loss. Similarly, just because your environment may have weaknesses does not mean that we will necessarily sustain a meaningful (or material) loss.
As such, when we talk about "risk" it is imperative that we include some representation of "impact" in the discussion. If nothing else, "impact" provides the real-world context that is important when talking about the other major factors. I'm personally fond of the breakdown that FAIR uses, but there are certainly other equally useful methods (e.g., VERIS Framework uses a similar breakdown to FAIR, but then adds in an "Impact Qualification" field that let's a reporting organization qualify the loss as Insignificant, Distracting, Painful, Damaging, or Unknown).
The bottom line here is, quite simply: Any attempt to estimate risk that does not include an impact estimate is, by definition, not a "risk" estimate in that "risk" must represent the potential for loss or injury. This definition derives from standard dictionaries and is not coming from special "risk wizard handbook." Trying to alter the core meaning of this word is at best disingenuous or misinformed, and at worst it is intentionally misleading.
What's Really Important?
Now that we've established that "impact" is important, the next logical question is "What's really important?" In the end, as a community we seem to resort to using monetary value to represent importance, but it's not necessarily the right answer to this question. In fact, before getting into dollar figures, a very strong case can be made for using qualitative labels (with reasonable, non-monetary definitions) to survey key stakeholders to rank what they view as important.
Still, there is that question of "what" and how to pick it. Are we talking about assets? Data? Processes? It's an interesting question, and one that warrants serious discussion, and which may produce a wide range of answers that vary from organization to organization. One customer has suggested looking at business processes, and has had great success using that approach. He started by asking key stakeholders what processes the business used (e.g., accounts payable, accounts receivable, invoicing) and then went through a prioritization/ranking exercise to determine which processes were the most important to the business. It wasn't until after he'd completed these surveys that he then went about translating those processes into data, systems, and financial value.
The key to answering this "What's really important?" question, then, lies in understanding the business at it's most fundamental level. How does work get done? Answering that question will likely lead to an interesting set of answers and, ultimately, a healthier perspective than starting with technology and trying to tell the business that something has relatively value. Starting with how the business operates is a very sensible right approach to determining what is really important.
Estimating Value and Impact
Gauging what's important means trying to assess the value of a given resource. There are myriad ways to go about defining value as you assess what is more important. Impact may factor in, or it may not. In general, I typically think of "value" as being positive, whereas "impact" tends to reflect a negative (or loss). For example, an asset may hold a certain (positive) value for the business, but the impact of an incident affecting that asset may be a different number altogether. (confused yet?)
For assessing "what's really important?" I suggest starting with a simple qualitative approach. The approach can use ranges of impacts, or any other number of measurement units (e.g., asset value, relative perceived importance to the business, etc.). For example, consider these generic impact-like definitions: Note that these descriptions do not define the estimated impact (potential loss) that would stem from an incident affecting the resource, but rather provides a quick shorthand to quickly prioritize resources given their relative value to the business. Consider this initial valuation exercise as step 1, to be followed later by a formal analysis that will try to provide a more robust impact assessment. Remember, too, that you may be estimating the value of a process here, whereas in later analyses you will most likely be assessing the impact for data or systems. In a sense, we're starting with an enterprise risk management outlook to help prioritize business resources, followed by a more detailed operational risk assessment that gets into the details of a specific business resource. In the end, one of the big things to remember is that "value" and "impact" are often not the same thing, but rather different aspects of related topics. Whereas it's not unusual to see the terms used interchangeably, it may not be correct to do so. Starting with a business-oriented, value-based approach can help provide a useful top-level prioritization of business resources. However, that's not the end of the process, but rather the start. Once the high-level value of resources is understood, the next step is to then understand the operational risk affecting those resources, including the impact of various loss scenarios. Conclusion The original motivation for this article is the recent trend of removing "impact" from many "risk" discussions. By definition, "risk" relates to a potential loss, which means that impact must be accounted for in some manner. Beyond that, the discussion naturally turns to how you estimate impact, and more broadly to how you determine what's important. It's too common today to see a lot of security discussions driven from the threat or vulnerability (weakness) perspective, when instead we should be starting from the perspective of what's important to the business. One welcome change in the risk management community is a shift toward discussing operational risk management, which itself flows into enterprise risk management as an important sub-component. Shifting thinking toward operational risk helps us step back from the in-the-weeds mentality that has led to this skewed view of "risk," and instead helps us to look at where the real valuation of business resources lies. Business resources in this sense may (and probably should) be higher-level concepts like key business processes rather than technical assets. That said, we cannot just look at a resource's relative value to the business, but must also conduct a risk analysis that looks at the impact of given loss scenarios, which may represent a greater financial liability than the relative value of the resource (e.g., properly invoicing customers likely has a high value for the business, but compromise of the list of the customers may have a greater financial cost than the loss of ability to invoice for a week or two). Though loss scenarios may look at the business resource, it's more likely that it will look at subsidiary components of that resource, such as data, applications, and systems. I get excited any time we can move forward from a given position and improve upon the status quo. Similarly, I become rather distressed when I see discussions moving in a regressive directions. It's time to put hard brakes on the current trend of discussing "risk" without considering context-specific impact. At the same time, we have a great opportunity to move the state of the art forward, shifting our thinking to an operational risk management mindset, and better aligning our approaches with what the business deems to be important.
- Low: The business can survive without the resource for X days.
- Medium: The business can survive without the resource for Y (
