In our day-to-day lives, the term “risk” can mean anything from buying a house to choosing food from a menu. However, when it comes to an organizational setting, we cannot afford ambiguous language. A risk is not the same thing as an issue, vulnerability, or failed control—and a misunderstanding can lead to negative consequences within an organization. Therefore, it is critical to understand the true meaning of each term. For more in-depth definitions of these and other compliance-related language, take a look at our last article, “When a Risk is not a Risk.”
In our experience, the greatest term confusion in the compliance industry exists between risks, issues, vulnerabilities, and failed controls where incidents are usually reported separately. Below are a few explanations that will help with their differentiation:
Risks
Risk is a future event that is likely to have an impact on an organization. It is commonly expressed as risk = likelihood * impact. Likelihood is bound by a time period, and impact is based on a specific value that matters to someone. If either likelihood or impact (time and value) is zero, risk does not exist.
For example: Imagine a ten-year-old, 80-ft Leyland Cypress tree that has shallow roots and is exposed to high winds. The likelihood of the tree falling on a nearby house is high. The impact of the tree falling on a house is high. But is this a risk?
- If the house is yours, the risk exists for you, but not for me.
- If the house is mine, the risk exists for me, but not for you.
- If the house is on Mars, the risk does not exist for either of us.
Therefore, the answer to whether or not the tree poses a risk is contextual, not absolute. Risk is also subjective, dependent on experience, exposure, and conception. What a risk is to some might not be a risk to others. For example, some people are scared to fly, some are uncomfortable, and others fall asleep during takeoff.
In an organizational setting, risks are bound by risk appetite and tolerance limits in order to provide a consistent context and approach to risk management. An organizational governing body has already established the level of impact severe enough to affect the organizational mission—which means the governing body has outlined when a risk should require executive-level attention, decision-making, and accountability. Risks with an impact lower than the risk appetite are considered operational matters to be evaluated against other opportunities and handled by management.
When reporting risks to a governing body, keep in mind that a risk has not occurred yet, and determine whether its impact will exceed the risk appetite once it occurs (e.g. in 3, 5 or 10 years). If this is the case, the goal is to discuss offensive or defensive planning, both of which are future investments (beyond current operational funding). For such a discussion, it is crucial to explain the opportunity and/or opportunity cost (the answer to the “So what?”) and ensure a clear understanding of risk acceptance.
Issues
Even though issues cannot be risks, risks can become issues. It is important to understand the difference between issues and risks to facilitate appropriate immediate actions vs. strategic positioning. Issues that are happening now require direct attention and action, not future planning.
When reporting issues to a governing body, keep in mind that reported issues already occurred, and their impact has exceeded or is expected to exceed the organizational threshold (usually the same as the risk appetite). The goal is to explain the current and anticipated damage to the organization, provide the status of mitigation efforts and, if required, ask for additional funds.
As with risks, issues with an impact below the organizational risk appetite should be handled as operational matters by management.
Vulnerabilities
Since a vulnerability is a weakness that could be exploited in the future and requires risk analysis, it is often identified as a risk—but it is not. A vulnerability is a current weakness, and it exists regardless of a threat, exploit, value, likelihood or impact. A risk, on the other hand, does not require an existing weakness but it does need all the other elements to exist.
A vulnerability may become a risk if a threat is likely to exploit the vulnerability and cause an impact (to a specific value that someone cares for). However, it is more common for a collection of vulnerabilities to become a risk. In such a case, it is necessary to understand the risk’s probable impact on a specific target and explicitly state it.
Example: The amount of vulnerabilities is important in a specific context, but as a number it does not provide sufficient information about the impact on a business. Thus, instead of saying that a company has 5,000 vulnerabilities, it is better to highlight the specific business process material to the company and be clear in terms of revenue, efficiency, customer satisfaction, cost, etc. State the mitigation plan and ask for a required investment.
Failed Controls
The context of “failed controls” is related to IT and security where a “control” is a very specific procedure. For example, a control might be: “All application accounts must be disabled within 48 hours of employment termination.” The “failed control” might mean that out of 1,000 accounts, 10 were not disabled within 48 hours. Even though the success rate is 99% and the failure rate is 1%, the control might still be marked as failed. If the account removal is the only control that prevents access to the application, the failure rate might be of greater interest. However, IT and security teams usually have multiple layers of controls; in addition to the one above, the organization could have another control requiring access removal from the network within five hours of HR’s termination trigger.
In this common IT and security situation, “non-compliance” should be separated from other events and treated per organizational expectations. However, as with vulnerabilities, a systematic failure of one control or a set of controls may exceed organizational risk appetite and become a risk. At that point, the governing body must be informed, and the organization should create a plan for mitigation or accept the risk.
CONCLUSION
In an organizational setting, risk has a specific meaning: It is an event that has not yet occurred and has a likely impact. Differentiation between risks, issues, vulnerabilities and failed controls can help IT and security teams with tactical prioritization that will efficiently allocate resources and strategic planning that will maximize the value of those resources.
