CVSS Isn't a Risk Score: How to Actually Prioritise Vulnerabilities

Your vulnerability scanner reports 12 Critical, 47 High and 183 Medium vulnerabilities.

Which one do you fix first?

The obvious answer might be:

Start with the Critical vulnerabilities.

But that is not necessarily the right approach.

CVSS is an important part of vulnerability management, but CVSS alone does not tell you which vulnerability represents the greatest immediate risk to your organisation.

To prioritise vulnerabilities effectively, you need to look beyond technical severity and consider the likelihood of exploitation, whether attackers are already exploiting the vulnerability, how exposed the affected system is, and how important that system is to your business.

Three useful sources of vulnerability intelligence are CVSS, EPSS and the CISA Known Exploited Vulnerabilities (KEV) Catalogue.

They answer different questions.

What CVSS actually tells you

The Common Vulnerability Scoring System (CVSS) provides a standardised way of describing the technical severity of a vulnerability.

The CVSS score considers factors including:

• Attack Vector
• Attack Complexity
• Privileges Required
• User Interaction
• Scope
• Confidentiality
• Integrity
• Availability

These characteristics help determine how serious the technical consequences of exploiting a vulnerability could be.

A CVSS score of 9.8, for example, tells you that a vulnerability has characteristics that make it technically very severe.

What it doesn't tell you is whether attackers are currently interested in exploiting it.

It doesn't know whether the vulnerable system is exposed to the internet.

It doesn't know whether the affected server contains sensitive customer information.

And it doesn't know whether your organisation has compensating controls that make exploitation significantly more difficult.

In other words:

CVSS describes vulnerability severity. It does not, by itself, describe your business risk.

That distinction is important.

CVSS, EPSS and CISA KEV answer different questions

A useful way to think about the three metrics is:

None of these should be considered in isolation.

Together, however, they can provide a much better picture of which vulnerabilities deserve attention first.

What is EPSS?

The Exploit Prediction Scoring System (EPSS) estimates the probability that a published vulnerability will be exploited in the wild within a given time period.

This makes it fundamentally different from CVSS.

CVSS asks, in effect:

How severe could exploitation be?

EPSS asks:

How likely is exploitation?

Imagine two vulnerabilities:

Vulnerability A

• CVSS: 9.8 Critical
• EPSS: very low
• Not in CISA KEV

Vulnerability B

• CVSS: 7.5 High
• EPSS: very high
• Not in CISA KEV

It is entirely possible that Vulnerability B deserves more immediate attention.

That doesn't mean the 9.8 vulnerability isn't important. It means that technical severity and exploitation likelihood are different things.

EPSS is a probability estimate, not a prediction of the future with certainty.

A high EPSS score doesn't mean:

"This vulnerability will be exploited."

It means:

"Based on available data, this vulnerability has a higher estimated probability of exploitation."

That distinction matters when using EPSS as part of a wider risk-based prioritisation process.

What is the CISA Known Exploited Vulnerabilities Catalogue?

The CISA Known Exploited Vulnerabilities (KEV) Catalogue adds another important piece of information.

The distinction is simple:

EPSS predicts exploitation. KEV records vulnerabilities for which exploitation has been observed in the wild.

That makes KEV particularly useful for vulnerability prioritisation.

If a vulnerability appears in the CISA Known Exploited Vulnerabilities Catalogue, there is evidence that attackers are actually exploiting it.

For an organisation looking at hundreds of vulnerabilities, that can significantly change the order in which remediation should take place.

However, KEV still needs to be considered in context.

A vulnerability being actively exploited does not automatically make it the highest priority in your environment if you don't use the affected software, the vulnerable system is isolated, or strong compensating controls prevent realistic exploitation.

The key is to combine threat intelligence with knowledge of your own environment.

A practical example

Imagine your vulnerability scanner identifies three vulnerabilities:

These numbers are purely illustrative, but they demonstrate the principle.

Which one should you fix first?

Vulnerability C immediately deserves serious attention because exploitation is known to be occurring in the wild.

Vulnerability B also deserves significant attention because its high EPSS score indicates a substantial estimated likelihood of exploitation.

Vulnerability A remains technically critical and may become the highest priority if, for example, it affects an internet-facing system or a particularly important business asset.

The point isn't to create a mathematical formula that automatically produces the answer.

The point is to avoid assuming:

Highest CVSS = highest risk.

Your environment changes the answer

A vulnerability doesn't exist in isolation.

The same vulnerability can represent very different levels of risk depending on where it exists and what it protects.

Is the system exposed to the internet?

An internet-facing server is generally more accessible to attackers than an isolated internal system.

How important is the asset?

Consider whether the vulnerable system provides access to:

• Active Directory
• Email
• Customer data
• Financial systems
• Production systems
• Backups
• Critical business applications

A vulnerability on a forgotten test server is not necessarily equivalent to the same vulnerability on a domain controller.

How realistic is exploitation?

Consider what an attacker needs to exploit the vulnerability.

Does exploitation require:

• Authentication?
• Local access?
• User interaction?
• A particular configuration?
• Multiple prerequisites?

The answers can significantly affect the practical risk.

What controls are already in place?

You may also have compensating controls such as:

• EDR
• Network segmentation
• Web application firewalls
• MFA
• Access restrictions
• Application allow-listing
• Monitoring and alerting

These controls don't necessarily eliminate the vulnerability, but they can change the likelihood or impact of successful exploitation.

Attack paths can change the priority

Another reason not to look at vulnerabilities individually is that attackers don't necessarily exploit them individually.

They can chain vulnerabilities and weaknesses together.

For example:

Vulnerability A

Allows initial access.

↓

Vulnerability B

Allows privilege escalation.

↓

Weak configuration C

Allows lateral movement.

↓

Active Directory compromise

Individually, none of these weaknesses might look catastrophic.

Together, they could provide an attacker with a path from an internet-facing application to control of the organisation's domain.

This is one area where penetration testing can complement vulnerability management.

A vulnerability scanner might tell you:

"This server has a vulnerability."

A penetration tester can investigate:

"Can this vulnerability actually be exploited, and can it be chained with other weaknesses to reach something valuable?"

That additional context can be extremely useful when deciding what to fix first.

A practical risk-based prioritisation model

There is no universal formula that will produce the perfect remediation order for every organisation.

However, a simple model can help.

Highest priority

Known exploited + exposed + critical asset

A vulnerability that is actively being exploited, affects an internet-facing system and provides access to an important business asset should normally receive urgent attention.

Very high priority

High EPSS + exposed + exploitable + important asset

A vulnerability with a high estimated exploitation probability becomes particularly concerning when attackers can realistically reach the affected system.

High priority

High CVSS + realistic exploitation + important asset

A severe vulnerability affecting an important system should still be prioritised, even when there is currently little evidence of active exploitation.

Medium priority

Significant vulnerability but limited exposure or strong compensating controls

The vulnerability shouldn't be ignored, but other vulnerabilities may represent greater immediate risk.

Lower priority

Low likelihood + limited impact + difficult exploitation

These vulnerabilities can generally be addressed through normal remediation cycles, assuming there are no other factors that increase their risk.

These aren't rigid rules.

They are a starting point for deciding where limited remediation resources should be spent.

Don't blindly follow EPSS either

EPSS is extremely useful, but it isn't a crystal ball.

Predictions can change.

New exploit information can change the probability.

Attack techniques evolve.

And your own environment may make exploitation considerably more or less realistic than a generalised prediction suggests.

The same applies to KEV.

A vulnerability being listed in KEV is important threat intelligence, but it doesn't mean every organisation is equally exposed.

If the affected software isn't present in your environment, there is nothing to remediate.

The important thing is to combine external vulnerability intelligence with your own asset and vulnerability data.

Vulnerability prioritisation should be dynamic

The risk associated with a vulnerability can change over time.

Imagine this sequence:

Day 1

CVSS: 8.2
EPSS: 2%
Not in KEV

↓

A working exploit is published

EPSS increases significantly.

↓

Active exploitation is observed

The vulnerability is added to CISA KEV.

↓

You discover an internet-facing system is affected

The priority becomes urgent.

This is why vulnerability management shouldn't be:

Scan once → produce spreadsheet → patch when convenient.

Effective vulnerability management requires continuous monitoring.

The priority assigned to an outstanding vulnerability today may not be the priority you would assign it next month.

What should SMEs actually do?

You don't need a huge security team to start taking a more risk-based approach.

At a minimum, you should:

1. Maintain an accurate asset inventory.
2. Regularly scan for vulnerabilities.
3. Track CVSS scores.
4. Monitor EPSS.
5. Check whether vulnerabilities appear in CISA KEV.
6. Identify internet-facing assets.
7. Identify business-critical systems.
8. Prioritise remediation using the combined information.
9. Rescan after remediation.
10. Periodically reassess outstanding vulnerabilities.

For an SME, the process can be summarised quite simply:

Know what you have → know what's vulnerable → understand what's being exploited → understand what's important → fix the highest-risk problems first.

Remediation isn't complete until you've verified it

There is one final step that is often overlooked.

Verification.

"We've patched it" isn't necessarily the same as:

"The vulnerability is gone."

Depending on the vulnerability, verification might involve:

• Rescanning the affected system
• Checking the installed software version
• Validating configuration changes
• Manually confirming remediation where appropriate

The vulnerability management lifecycle should therefore look something like this:

Discover → Assess → Prioritise → Remediate → Verify → Monitor

And then repeat.

Where penetration testing fits

Vulnerability management and penetration testing are complementary.

Vulnerability management provides breadth and continuous visibility.

It can help identify weaknesses across large numbers of systems and keep track of emerging vulnerabilities.

Penetration testing provides depth and human-led investigation.

A tester can examine whether vulnerabilities can actually be exploited, identify attack paths and determine whether apparently separate weaknesses can be chained together to produce a much more serious outcome.

A scanner might identify ten vulnerabilities.

A penetration test might demonstrate that three of them can be chained together to obtain privileged access to a critical system.

That context can make a significant difference to remediation priorities.

The bottom line

Don't confuse severity with risk.

CVSS is valuable for understanding the technical severity of a vulnerability. EPSS adds an estimate of how likely exploitation is, while CISA KEV provides evidence that a vulnerability is already being exploited in the wild.

But the final question is always about your organisation:

What is exposed, what is valuable, and what could an attacker realistically do?

Effective vulnerability management combines vulnerability intelligence with knowledge of your own environment.

The goal isn't simply to reduce the number of Critical and High vulnerabilities in a dashboard.

The goal is to spend limited time and resources fixing the vulnerabilities that represent the greatest risk to your organisation.