Why CVSS Scores Alone Can't Prioritise Your Vulnerabilities

Run a vulnerability scan across a typical organisation and the result is sobering: thousands, sometimes hundreds of thousands, of findings. No team can fix them all at once. Something has to decide what comes first.

For many organisations, that something is the Common Vulnerability Scoring System, or CVSS. Each vulnerability gets a score from 0 to 10, and teams work from the top down: criticals first, then highs, and so on. It feels rigorous and fair. But it leads teams to spend much of their effort on vulnerabilities that are unlikely ever to be exploited, while some that matter more wait in the queue.

What CVSS actually measures

CVSS is maintained by FIRST, the global forum of incident response teams, and is widely used across the industry. The base score describes the technical severity of a vulnerability: how it can be exploited, how complex an attack would be, whether privileges or user interaction are needed, and what the impact would be if it were exploited.

That is valuable information. But it is not the same as risk to your organisation. The base score does not tell you:

• Whether attackers are actually exploiting the vulnerability.
• Whether the affected system is exposed to the internet.
• Whether the system is critical to your business or holds sensitive data.
• Whether other controls already reduce the risk.

CVSS includes optional metrics for some of this context, but they are rarely used in practice.

The consequences of CVSS-only prioritisation

• Too many "criticals". A large share of published vulnerabilities score high or critical. When most of the list is urgent, nothing is.
• Effort spent on low real risk. A critical vulnerability on an isolated internal test server may matter far less than a medium one on an internet-facing system that attackers are actively targeting.
• Missed threats. Vulnerabilities with moderate scores are sometimes heavily exploited, for example as part of an attack chain.
• Backlogs that never shrink. Teams chase an impossible queue and lose confidence that their work makes a difference.

Better ingredients for prioritisation

Risk-based prioritisation combines severity with several other factors.

Is it being exploited?

Evidence of real-world exploitation is one of the strongest predictors of risk. Useful sources include:

• Known exploited vulnerability lists, such as the catalogue published by the US Cybersecurity and Infrastructure Security Agency (CISA).
• Exploit prediction scores, such as EPSS, also from FIRST, which estimates the likelihood that a vulnerability will be exploited in the near future.
• Threat intelligence relevant to your sector and technology.

Is it exposed?

A vulnerability on an internet-facing system, a remote access gateway or a widely used endpoint is far more reachable than one deep inside a segmented network.

Does the asset matter?

Systems that support critical services, hold sensitive data or provide privileged access, such as identity systems, deserve higher priority than low-value or isolated systems.

Are there compensating controls?

Network segmentation, application allowlisting, disabled features or strong monitoring may reduce the practical risk of a vulnerability that cannot be fixed immediately.

Putting it together

A practical approach many organisations use:

1. Fix first: vulnerabilities known to be exploited, on exposed or critical systems. These get the shortest deadlines, often days.
2. Fix soon: high-severity vulnerabilities on exposed or critical systems, and anything with a high likelihood of exploitation.
3. Fix in routine cycles: other vulnerabilities, addressed through regular patching.
4. Accept or mitigate: low-risk findings on isolated systems, or those that cannot be fixed, with documented risk acceptance and compensating controls.

The result is a much shorter list of genuinely urgent work, and more confidence that effort is going where it reduces the most risk.

Make remediation easier

Prioritisation is half the battle. The other half is making fixing easier:

• Group findings. One software update often fixes hundreds of findings. Give teams "apply this update" rather than a list of 400 vulnerabilities.
• Route work to the right owners through their normal work queues, with context explaining why it matters.
• Know your assets. You cannot prioritise by asset importance or exposure without an accurate, current inventory that includes owners.
• Tackle root causes. Unsupported software, missing automation and slow change processes generate recurring backlogs. Fixing them prevents future findings.

Measure exposure, not counts

Total vulnerability counts are a poor measure of progress, because new findings appear constantly. Better measures include:

• Time to fix exploited vulnerabilities on critical or exposed systems.
• Proportion of critical assets covered by scanning.
• Number of exposed systems with known exploited vulnerabilities.
• Trend in overall exposure over time.

How mature is your vulnerability management?

Updated October 2026: we have added a Vulnerability Management assessment. It covers asset discovery and coverage, vulnerability identification, risk-based prioritisation, remediation and patching, exceptions and compensating controls, and metrics, governance and disclosure.

For a broader view of security, the Enterprise Security assessment covers governance, identity, detection, incident response, data protection and culture.

Frequently asked questions

Should we stop using CVSS?

No. CVSS is a useful measure of severity and a common language across the industry. Use it as one input, combined with exploitation, exposure and asset importance.

What is EPSS?

The Exploit Prediction Scoring System estimates the probability that a vulnerability will be exploited in the near future, based on observed data. It complements CVSS by adding likelihood to severity.

How quickly should exploited vulnerabilities be fixed?

For exploited vulnerabilities on internet-facing or critical systems, many organisations aim for days rather than weeks, with emergency processes when needed. Set targets that reflect your risk appetite and capability.