This article discusses how HIPAA Security Rule
Risks ("Risks") can be categorized and dissected. In previous articles we have focused on Risk Assessments which, generally speaking, require an organization to identify Risks and subsequently identify the controls ("Controls") required to mitigate Risks to levels that are "reasonable and appropriate." This article assumes that you already understand the basic Risk Assessment process and focuses on a more granular examination of the component parts of a Risk.
Before we start analyzing what constitutes a Risk we need a working definition of the term. There are many potential valid definitions for a Risk but for our purposes we will use the definition proposed by the National Institute of Standards and Technology
("NIST"): "The net mission impact to your organization considering (1) the probability that a particular Threat ("T") will exercise (accidentally trigger or intentionally exploit) a specific Vulnerability ("V"); and (2) the resulting Impact ("I") to your organization's mission should this occur. So a Risk can be calculated, in terms of a pseudo-mathematical formula, as follows: Risk = (T) x (V) x (I), expressed as a series of subjective probabilities.
Although a Risk can be expressed in what appears to be a mathematical formula that is not how it works in practice, nor is it the way NIST recommends that it be calculated. Taking a literal mathematical approach has proven to be an impossible task (although several have tried) and therefore a more subjective nuanced methodology has evolved. To calculate a Risk you first identify T/V pairs and then assign a subjective probability (e.g. low, medium, high) that the "T" will actually exploit the "V". Once you have assigned that probability (which like all probabilities in the equation represent nothing more than an educated guess) you then determine the Impact ("I") that the exploitation will have on your organization's mission (e.g. again low, medium, or high).
A Risk then is a function of these two subjective probabilities. For example, a high probability of exploitation "times" a high Impact to your mission would "likely" result in you assigning a high probability to this Risk. The word "likely" is emphasized because it does not necessarily follow that this particular Risk would result in a "high" probability. Why? Because there may be, in practice often are, other subjective factors at play. In short, the best we can do when attempting to "calculate" a risk is a heuristic approach. It is by definition an explorative, iterative, trial and error based approach. In order not to miss the forest for the trees, you must recognize that from a compliance perspective it is not the "probability" that you have assigned to the Risk that matters, rather what counts is the Controls you put into place to reduce the probability of the Risk to a level that is "reasonable and appropriate."
Most people quickly grasp the NIST Risk calculation methodology as an academic matter. However, this is far from understanding what a Risk is. From our perspective, Risk is not something that you learn about in a HIPAA Compliance Management Program (or an MBA program) but rather something that is learned through viscerally through experience. In other words, you don't understand Risk when you are playing with other people's money ("OPM"). You can only acquire that "gut" understanding of Risk when you personally have some skin in the game (e.g. your career/family's future is on the line). In short, when you have skin in the game Risk ceases to be an academic exercise. It is something that must be managed given what it is at stake. Risk is that knot in the stomach that struggling entrepreneurs face on a daily basis.
So if you have a title that requires you to manage Risk, then the only way to be successful is to understand the visceral reality of Risk. More and more, all knowledge workers are going to become risk managers because that is the nature of global economic competition. It is brutal and getting more so with each passing day. If your organization is exposed to significant Risk and that Risk materializes because of something you could have done, then you are likely to feel the hammer when it metaphorically comes crashing down on your head. You won't be alone, the executive management team will likely also feel the hammer, but that will be little consolation.
Now that you understand what it is we mean by Risk we can begin to dissect a Risk at its most granular level. First, we believe that Risks can be categorized as follows: (1) financial Risks; and (2) reputation Risks. Ultimately the latter collapses into the former so that the consequences of a Risk being realized can be expressed as a function of money. That being said, we do understand that there are any number of ways to categorize Risks (e.g. financial, reputation, safety, political, systemic, etc.). For our purposes the categories enumerated above suffice.
According to NIST a Risk has the following component parts:
- A Threat/Vulnerability Pair;
- An Impact to your organization's mission.
That's it. As discussed above, a Risk is calculated as a function of these two components. The subjective value placed on the Risk will vary with each organization due to size, resources, etc. Once a Risk is identified then the objective shifts to finding a Control that addresses or "plugs" the Vulnerability. So in essence the Risk does no disappear, it simply gets "plugged;" hopefully to a level that reduces said Risk to a level that is "reasonable and appropriate." Again what is "reasonable and appropriate" will vary by organization.
The real conundrum in the process (i.e. there are many but this is the essential one) is identifying T/V pairs coupled with applying the necessary Controls to reduce the Risk to the level required by the Security Rule
. In Expresso
, we have taken the mystery out of this process because Expresso
comes pre-populated with Risks and the corresponding Controls necessary to reduce said Risks to the desired level. Obviously, your organization still needs to apply the Controls (that is done in the Security Rule's Risk Management implementation specification) but that mystery of developing T/V pairs and assigning Controls has been virtually eliminated, at least with respect to the Security Rule.
Now, if you really want to fight the "bad guys" effectively then the Security Rule
("Rule") represents nothing more than a "floor" of what you are required to do. You could be in full compliance with the Rule and still experience a significant breach; however, if you are in full compliance then your fine from HHS should be dramatically reduced. Further, any downside risk from a legal action should also be reduced. Why? Because by implementing the "floor" your counsel can make a compelling "good faith" argument that you have done everything required of you as a reasonable actor (despite the fact that you may not have done everything you could have done).
Hopefully this article has provided you some insights into how a Risk functions under the Rule and a better understanding of its components. If you want more information please register for July webinar on this same topic.