How to define risk appetite and tolerance

Clarifying two key cybersecurity terms.

Picking the right metrics for your security program is absolutely crucial for success, but unfortunately, many organizations get this fundamental step wrong.

Whether focusing on the number of “high and critical” vulnerabilities in the network or the mean time to remediation (MTTR) for these flaws or other alert triggers, security teams sometimes index on key performance indicators that don’t especially matter.

Building the right foundation requires clear terminology, and in some cases, a new way of looking at existing concepts. In this posts we will look specifically at two fundamental terms when it comes to cybersecurity risk management: appetite and tolerance.

Risk appetite

This is the baseline level of cybersecurity risk that an organization is willing to accept on an ongoing basis. Determined by the appropriate business leader (Chief Executive Officer, General Manager, Product Manager, etc.), it represents the “cost of doing business” related to potential cybersecurity loss events.

Risk appetite should be defined in fungible units. By this I mean things that can be traded between business units or even with other organizations. Things that meet this definition include:

• Dollars

• Euro

• Engineer-hours

Things that don’t meet this definition include:

• “High” or “low” risks

• Common Vulnerability Scoring System (CVSS) 10.0 (or any other rating) vulnerabilities

• Known exploited vulnerabilities (KEV)

• Probabilities of exploitation

• Compliance framework obligations

“Shouldn’t cybersecurity risk be defined in security terms,” you are probably thinking?

No.

Since security teams do not exist for their own benefit, and have very real costs of their own, communicating risk in security-specific terms makes it very difficult for business leaders to understand how to value their efforts.

And without any common denominator, it becomes impossible to weigh tradeoffs.

For example, how many “critical” vulnerabilities would a new tool need to mitigate or fix in order to justify a cost of $50,000 a year? It’s impossible to say without describing the risk mitigated in terms of dollars.

Many organizations, however, put out policies requiring all “critical” (according to CVSS) vulnerabilities to be fixed in 7 days, all “high” ones in 30 days, and so on. Unfortunately, this is a crude and ineffective way of communicating risk appetite.

Every salesperson or business unit leader has a dollar-amount quota to hit every quarter or year. So speaking in any other terms is an easy way to be misunderstood at best.

And ignored at worst.

Because it only makes to talk about risks over a given period of time, I describe risk appetite in terms of annual loss expectancy (ALE). ALE represents the expected dollar amount of loss resulting from malicious events impacting data confidentiality, integrity, and availability over a given year.

While predicting the exact frequency and impact of cyber losses for an organization over a given year is impossible, it is reasonable to do over a long period of time.

So an organization with a risk appetite of $100,000 of ALE would accept any of the following vulnerabilities indefinitely:

• 20 with an ALE of $5,000 each

• 2 with an ALE $25,000 each

• 1 with an ALE of $100,000

While optimally we wouldn’t need to accept any risk (cyber or otherwise), doing so is just part of life and there is no way around it. Understanding exactly how much risk the organization is willing to accept is thus critical to making decisions such as how to:

• Allocate resources

• Evaluate business units

• Hold employees accountable

There is no right or wrong risk appetite, except for perhaps a figure that exceeds the anticipated value generated by a business. In certain cases where a product or offering’s ALE exceeds the revenue it generates, shutting it down entirely can make business sense.

Risk tolerance

Related to appetite is tolerance. This is the velocity at which an organization must mitigate, transfer, or avoid risk exceeding the established appetite. Affirmatively accepting additional risk above the baseline is also an option, but doing so merely resets the appetite (temporarily or permanently).

Without specifying risk tolerance, anytime the organization exceeds its risk appetite, it would be immediately out of compliance with its own policy. And since security is a dynamic and constantly-evolving field, such a policy would quickly become a “dead letter” that no one in the organization abides by.

To address this, business leaders should specify risk tolerance in terms of how quickly the organization needs to return its risk appetite after exceeding it. Optimally, this would be communicated in terms of “excess” ALE.

For an example, let’s go back to our organization that has a risk appetite of $100,000 in ALE.

Assume that it has 20 previously-identified risks with an ALE of $5,000 each. This means it is exactly at its risk appetite. It also has a risk tolerance of $1,000 of ALE.

Unfortunately, the security team runs a scan and finds 5 additional vulnerabilities representing $10,000 ALE each. Now the organization is above its risk tolerance for about $137 ([5 vulnerabilities x $10,000 ALE each]/365.25 days a year) for each day in this current state. Within a little over 7 days (~7.3 days x ~$137/day =~$1,000), the organizational will violate its risk tolerance unless it does something.

To return its ALE to its risk appetite, the company must fix either of the below within approximately the next week:

• 10 of the first category of vulnerabilities (previously identified)

• 5 of the second category of vulnerabilities (newly identified)

Tackling either group will mitigate the same amount of risk. So what the organization should do is just pick the category of vulnerabilities that is easiest - and least costly - to fix, assuming both can be done within the same time frame.

Conclusion

Risks can come from all sorts of sources:

• Gullible employees

• Software vulnerabilities

• Generative AI tools that train on confidential data provided to them

The good news is that you can use risk appetite and tolerance - defined in ALE - to describe the risk posed by all of these things. And when you have a common denominator, you can make informed tradeoffs. Which is at the core of the Deploy Securely philosophy.