A CVSS score of 9.8 gets attention.

And it should.

Technical severity is an important signal for understanding what could happen if a vulnerability is exploited. The problem begins when that signal automatically becomes a business priority.

A score can describe the characteristics of a flaw very well while knowing almost nothing about the environment in which that flaw exists.

That is why, when I see a vulnerability accompanied only by a CVSS score, my next question is usually:

What information are we still missing before we can decide?

1. We are missing the importance of the affected asset

The same vulnerability can change dramatically in importance depending on where it appears.

It is not the same to find it on:

  • an isolated lab system;
  • an authentication server;
  • an application processing transactions;
  • an administrative workstation;
  • a platform supporting a critical operation;
  • a system scheduled for retirement.

CVSS does not know what that asset represents to the organization.

We need to understand its function, dependencies, owner, the information it processes, and the consequences of interruption or compromise.

Without that context, we are prioritizing a technical weakness without fully understanding the object we are protecting.

2. We are missing who can reach it

Reachability changes risk.

An asset may be:

  • directly exposed to the Internet;
  • behind an authentication layer;
  • segmented;
  • available only from an administrative network;
  • accessible by third parties;
  • connected to a zone that could be used to move toward more sensitive systems.

Two assets with the same vulnerability and the same CVSS score can have completely different attack surfaces.

That is why a vulnerability should not be analyzed separately from exposure.

3. We are missing whether anyone is trying to exploit it

Technical severity expresses possibility.

Threat information helps us understand probability and urgency.

Useful questions include:

  • is there known exploitation?;
  • are practical techniques or tools available?;
  • is activity being observed against similar vulnerabilities?;
  • is the vulnerability being used in real campaigns?;
  • is there relevant evidence for the organization’s sector or environment?

This does not turn prioritization into perfect prediction.

Threat is another signal that must be combined with context.

4. We are missing the controls around it

A vulnerability may remain technically present while its exposure is temporarily reduced by other controls.

For example:

  • segmentation;
  • filtering;
  • additional authentication;
  • access restrictions;
  • isolation;
  • monitoring;
  • disabling the vulnerable function.

But there is a critical difference between having a control and assuming that the control works.

When a compensating control changes priority, there should be enough evidence to trust it.

Otherwise, false confidence can be worse than recognizing the exposure.

5. We are missing how long it has been there

Time adds another dimension.

A newly identified finding is not the same as a priority finding that has remained open for months without a clear decision.

Age can reveal:

  • remediation blockers;
  • systems nobody wants to modify;
  • exceptions without expiration;
  • unclear ownership;
  • recurring problems;
  • or a gap between what the dashboard labels as important and what the organization can actually execute.

Time does not automatically turn a vulnerability into a critical one, but it can reveal accumulated risk debt.

6. We are missing whether a viable fix exists

A technical recommendation can be correct and operationally difficult.

Applying a patch may require:

  • compatibility testing;
  • maintenance windows;
  • coordination with suppliers;
  • backups and rollback plans;
  • updates to dependent components;
  • approval from a process owner.

There may also be no definitive fix yet.

Then the decision changes: mitigation, isolation, monitoring, temporary risk acceptance, or accelerated replacement may be required.

Priority needs to recognize execution reality.

7. We are missing what would happen if the asset were compromised

This is where the technical conversation must connect with the business.

What could be affected?

  • availability of a function;
  • integrity of information;
  • confidentiality of data;
  • authentication capability;
  • customer operations;
  • compliance;
  • recovery capability;
  • trust in a process.

A vulnerability becomes meaningful as risk when we can explain a plausible consequence in a specific context.

8. We are missing whether the data can be trusted

There is an assumption that often goes unnoticed: that the finding accurately represents the asset’s current state.

Before making decisions, it is worth checking:

  • when it was last assessed;
  • whether the assessment had the access level it needed;
  • whether the asset still exists;
  • whether the address or name maps to the correct system;
  • whether the vulnerability is still present;
  • whether inventory data are current.

A sophisticated prioritization model built on incomplete data is still poor prioritization.

From score to context

Once these pieces are combined, the question stops being:

“Which one has the highest CVSS?”

It becomes something more useful:

“Which combination of weakness, asset, exposure, threat, controls, and impact justifies attention first?”

That does not eliminate CVSS.

It puts it in the right place: a technical signal inside a broader decision.

We do not need a perfect model

There is a risk of responding to this problem by creating excessively complex scoring models.

More variables do not always produce better decisions.

A useful model should be clear enough for a team to explain:

  • why something is first;
  • what information changed its priority;
  • what action is expected;
  • who should execute it;
  • what happens if it cannot be done now;
  • and when the decision should be reviewed.

If nobody can explain why a risk has a particular score, the model can become another black box.

A practical conclusion

CVSS is valuable because it standardizes part of the technical conversation.

But an organization does not remediate scores.

It remediates problems that exist on specific assets, with specific exposure, inside specific processes, and under specific constraints.

The information missing between CVSS and the decision is precisely the context that turns a technical vulnerability into a risk priority.