Vulnerability Management: why severity alone is not enough to set priorities

Understand why severity and CVSS alone are not enough to prioritize vulnerabilities, and how exploitability, exposure, and context help determine what to address first.

ByLeonnes Cybersecurity | 18 August 2026

Lion Focus — risks ordered by level of exposure and business impact

Por/By: Lion Focus Insights

For a long time, one of the most practical ways to organize vulnerability remediation has been to start with critical findings, move on to high-severity ones, and continue down the list. There is nothing wrong with using severity as a starting point. When there are hundreds or thousands of findings and some criterion is needed, it provides an objective reference that is easy to understand.

The problem begins when it also becomes the endpoint.

Imagine a vulnerability with a CVSS score of 9.8 on an internal server that is segmented and has no direct Internet access. In another environment, there is a 7.5 vulnerability in a public-facing application. It can be reached externally and, on top of that, there is evidence that the vulnerability is being exploited in the wild.

If you could remediate only one of them today, would you necessarily start with the 9.8?

You would probably want to know a little more before answering.

And that “little more” is precisely what makes vulnerability prioritization interesting.

CVSS is not wrong

Discussions about prioritization sometimes cast CVSS as the villain, as if using severity were an outdated practice. That is not the point.

CVSS remains an important reference for representing the technical characteristics of a vulnerability in a standardized way. Attack vector, complexity, required privileges, user interaction, and potential impacts on confidentiality, integrity, and availability are all part of that assessment.

What it is not designed to do on its own is tell us which vulnerability represents the greatest risk to a specific organization.

FIRST, which maintains CVSS, makes this distinction clear: the CVSS Base Score measures severity, not risk. The Base Score represents intrinsic characteristics of the vulnerability, independent of the particulars of each environment.

That may sound like a conceptual distinction, but in practice it changes quite a lot.

In vulnerability assessments, it is relatively common to find that the highest-CVSS finding is not necessarily the one that draws the most attention. A less severe vulnerability may exist under conditions that are far more favorable to an attacker.

That is when other questions naturally start to appear.

Is the asset exposed? Can the vulnerability be exploited remotely? Are there specific conditions required for exploitation? Is exploit code available? Is there evidence of attacks using this vulnerability?

We are not discarding severity. We are adding context around it.

That is why a useful way to think about prioritization is to consider three dimensions:

Severity + Exploitability + Exposure

Not as a universal formula capable of calculating an organization’s entire risk, but as three pieces of information that help answer a much more practical question: where do we start?

Some information changes the queue considerably

Let’s go back to the two vulnerabilities from the beginning.

The first has a CVSS score of 9.8 but sits in an internal, segmented environment. The second has a score of 7.5, is exposed to the Internet, and we discover evidence of active exploitation.

The first vulnerability has not stopped being critical. Its CVSS score does not need to change either.

But we now know something about the second one that severity alone did not represent.

A clear example of this kind of information is CISA’s Known Exploited Vulnerabilities Catalog (KEV). The catalog includes vulnerabilities for which there is evidence of exploitation in the wild, and CISA recommends using it as one input to vulnerability prioritization.

That does not mean everything in KEV should automatically move ahead of every other vulnerability. Nor does it mean that something absent from the catalog is unimportant.

But if we are trying to decide what to address first, knowing that attackers are actually using a vulnerability is difficult to ignore.

There are also cases where we have no evidence of known exploitation but still want a better sense of whether exploitation is likely.

That is where the Exploit Prediction Scoring System (EPSS) comes in. Maintained by FIRST, it estimates the probability that a published vulnerability will be exploited in the wild within the next 30 days.

CVSS and EPSS are sometimes discussed side by side as if we need to decide which one is better. Perhaps that is the wrong question.

They tell us different things.

A vulnerability may have high severity and a low estimated probability of exploitation. Another may have lower severity while presenting signals that are much more relevant from a threat perspective.

And one important piece of the story is still missing: where the vulnerability is located.

The same vulnerability, three different situations

Consider the same critical vulnerability present on three assets.

One is an isolated lab server. Another is available only on the internal network. The third is a service published directly to the Internet.

The vulnerability is the same. The CVSS score is the same. If we look only at a scanner export, the three findings may end up almost side by side.

For an external attacker, however, these are not three equivalent situations.

When we analyze an exposure, one of the first things we want to understand is whether that path is actually available to an attacker. A service published on the Internet naturally deserves a different analysis from something that cannot be reached in the same way.

This also shows why Vulnerability Management and attack surface visibility increasingly intersect.

It is not enough to know that a vulnerability exists. Knowing where it exists and how that asset is exposed helps us understand the scenario more clearly.

And context can go further.

If we know that an asset supports a critical operation, contains sensitive information, or performs an important business function, that information may influence the decision. The same is true of compensating controls that make exploitation harder or reduce its potential impact.

That information will not always be available. In reality, it often is not.

And perhaps that is another important point: we do not need to wait for a perfect risk model before improving prioritization. If we can combine severity with information about exploitability and exposure today, we already have much more context than a queue based exclusively on CVSS.

As the organization matures and can incorporate asset criticality, controls, and potential business impact, the analysis can gain additional layers.

NIST addresses this relationship between cybersecurity risks, organizational priorities, and available resources. After all, setting priorities also means recognizing something very concrete: no organization has unlimited capacity to address everything at once.

The scanner is done. Now another part of the work begins.

This may be one of the less discussed aspects of Vulnerability Management.

Finding vulnerabilities has become relatively efficient. Depending on the environment, producing a very large list is not difficult.

The scanner finishes and there are 500, 2,000, 10,000 findings.

Now what?

If the answer is simply to sort the spreadsheet from Critical to Low and send it to the responsible teams, a considerable part of the problem remains.

Someone still has to decide what comes first.

This is where a 7.5 vulnerability can start to be more concerning than a 9.8. Or a finding that has been sitting in the backlog for weeks changes priority because an exploit appears. Or because it enters KEV. Or simply because someone discovers that the server everyone believed was internal is also responding on the Internet.

Situations like these show that priority is not a permanent characteristic of a vulnerability.

CVSS can remain exactly the same while everything around it changes.

That may be one of the most important differences between classifying a vulnerability and managing the exposure associated with it.

There is also a risk in the opposite direction. Once we start adding context, it is tempting to search for a new score that will solve the problem once and for all: combine CVSS, EPSS, KEV, exposure, criticality, and a few more variables, and expect the result to tell us exactly what to do.

Those models can be very useful. But they still need interpretation.

There is no score that perfectly understands every architecture, every control, every dependency, and every possible business consequence.

At some point, especially in the most relevant cases, someone still needs to analyze the evidence and make a decision.

That is not a weakness in the process. It is part of it.

So, what should come first?

Let’s return one last time to our 9.8 and 7.5 vulnerabilities.

With the limited information we had at the beginning, it probably would not be responsible to decide based only on the numbers.

Then we learn that the 7.5 is Internet-exposed and has evidence of exploitation. We now have concrete reasons to consider addressing it first.

If tomorrow we discover that the 9.8 sits on a critical asset, is reachable through another path, and is involved in a relevant attack chain, the decision may change again.

That is how it should work.

Vulnerability Management does not need to abandon severity. It simply needs to recognize that severity is one part of the decision.

In the end, when a team has thousands of vulnerabilities and capacity to address only some of them right now, knowing which one has the highest CVSS is useful.

But it is unlikely to be the only question the team will want to ask.