From Vulnerability Backlogs to Defensible Decisions: What Should Organisations Fix First?

• CVSS Base is a severity measure, not a complete organisational risk assessment.
• EPSS is a dynamic exploitation forecast, not severity and not a complete risk score.
• KEV is evidence of known exploitation, but it is not an exhaustive record of every exploited vulnerability everywhere.
• Presence, reachability, consequence and compensating controls remain local questions.
• Dynamic intelligence needs provenance and timestamps; model or scoring version may matter as well.
• The output of prioritisation should not have to be another blended number. A more useful output is often: what action, by when, owned by whom, based on which evidence?

CVSS solves a real problem. It gives practitioners a common language for describing vulnerability severity.

The mistake is treating CVSS Base as something it is not. FIRST's current CVSS v4 guidance is explicit: Base measures the intrinsic severity of a vulnerability independently of threat and the local computing environment. Threat and Environmental metrics exist to enrich that system-agnostic view with changing threat conditions and deployment-specific context.1

Operationally, however, vulnerability queues often collapse back to a simpler rule:

9.8 before 8.9. Critical before High. Then work down the list.

There are good reasons for doing this. A single field is easy to automate, explain and turn into an SLA. The problem begins when an administrative threshold is mistaken for a boundary in attacker behaviour.

In August 2026, I examined every CVE added to CISA KEV during the complete seven-day period from 18 to 24 August. Eight of the nine vulnerabilities had a CVSS v3.1 Base score of at least 9.0. The ninth, CVE-2026-73570, had a Base score of 8.9 even though exploitation had already been confirmed for KEV purposes.2

That result is not an argument that CVSS failed. In fact, severity was heavily concentrated at the top of the scale: eight of nine were Critical. The narrower point is more useful. A hard category threshold is not an exploitation threshold. Nothing special happens in the real world when a score moves from 8.9 to 9.0.

EPSS is not a more modern replacement for CVSS. It measures something else.

FIRST defines EPSS as a data-driven estimate of the probability that exploitation activity associated with a published CVE will be observed in the wild over the next 30 days. Scores are updated daily. FIRST also states plainly that EPSS is not a complete risk score: it does not know whether the CVE affects your environment, what the consequence would be, or which compensating controls you have in place.3

The same nine-CVE KEV cohort illustrates the difference. All nine vulnerabilities were already known exploited, yet the EPSS snapshot used in the study ranged from 1.506% to 72.695% — a spread of more than 48 times.2

There is no contradiction. KEV and EPSS refer to different evidence and different time semantics:

• KEV: sufficient evidence exists that exploitation has occurred;
• EPSS: given the model's current inputs, what is the probability of observed exploitation activity over the next 30 days?

FIRST's own guidance makes the operational consequence clear: a low EPSS score on a KEV-listed vulnerability is not evidence against known exploitation. Direct exploitation evidence and a forecast should not be treated as interchangeable inputs.3

A threshold is a workload rule, not a truth label

The study also tested illustrative current EPSS thresholds of 5%, 10% and 20%. They retained 6, 5 and 3 of the nine already-KEV-listed vulnerabilities respectively.2

Those are not EPSS “miss rates”. The cohort was selected after known exploitation, and the EPSS values were a later cross-sectional snapshot. The exercise shows something more modest: a forecast threshold and confirmed-exploitation status remain semantically different even when viewed at the same time.

That distinction matters in production. An EPSS threshold can be a sensible way to control workload where remediation capacity is finite. FIRST recommends choosing thresholds in terms of coverage, effort and organisational risk tolerance rather than treating one value as universal.4

The threshold tells your team which work enters a queue under a policy. It does not turn every vulnerability below it into “safe”.

CISA KEV is valuable precisely because it carries different semantics. CISA adds vulnerabilities based on evidence of exploitation.5

For a European organisation, that makes KEV a strong technical input. It does not make CISA's federal remediation regime an EU legal requirement, nor does absence from KEV prove absence of exploitation. KEV should be handled as what it is: an authoritative CISA determination for the vulnerabilities that meet its criteria, not a complete global ground truth.

Europe now has an additional public source. ENISA's European Vulnerability Database (EUVD), established under Article 12 of NIS2, aggregates vulnerability information including severity, mitigation information and exploitation status.6

The useful design principle is not “choose the European feed” or “choose the American feed”. It is preserve source, provenance and meaning.

CISA's public SSVC/Vulnrichment data separates properties such as Exploitation, Automatable and Technical Impact.7

In the nine-KEV cohort, all nine records were marked Exploitation: active and Technical Impact: total, while two were Automatable: no.2

Known exploitation therefore did not imply that exploitation was considered automatable.

This is more than a terminology point. If a vulnerability-management platform compresses several properties into one generic field called “exploitability”, an analyst may lose the reason a vulnerability was escalated. Keeping exploitation state, attack automation and impact separate makes the decision easier to reconstruct later.

External vulnerability intelligence becomes an organisational decision only when it is joined to local evidence.

1. Is the vulnerable product and version actually present?

A CVE in a scanner feed is not the same as a vulnerable instance in production. The decision needs asset identity: product, version, component and, where relevant, whether the vulnerable feature is enabled.

This is where weak asset inventories quietly undermine sophisticated prioritisation models.

2. Is the vulnerable path reachable?

Internet exposure, authentication boundaries, segmentation, feature configuration and trust relationships can materially change the attack path.

“Internal only” is not enough evidence on its own. Reachability should be reasoned from the actual path an attacker would need, not from a network label.

3. What do we know about exploitation now?

This is the point to combine evidence without collapsing it:

• credible active-exploitation reporting;
• KEV or EUVD exploitation status;
• vendor or CSIRT warnings;
• public exploit or proof-of-concept information;
• EPSS probability and observation date;
• SSVC decision points where they are useful.

The word “now” matters. Several of these fields are dynamic.

4. What would exploitation mean for this asset?

CVSS describes the vulnerability. Your organisation must describe the consequence.

That may include confidentiality, integrity and availability, but also service criticality, downstream dependencies, safety consequences, regulated data, customer impact or public-service disruption.

The same CVE on an isolated laboratory host and on an internet-facing identity platform is not the same organisational risk.

5. What is the risk of remediation itself?

“Patch immediately” is not a context-free rule either. A patch may require downtime, break a dependency, be unavailable, or need testing against a safety- or availability-sensitive environment.

Commission Implementing Regulation (EU) 2024/2690, for the categories of NIS2 entities within its scope, requires security patches to be tested before production use and allows a documented decision not to apply a patch where the disadvantages outweigh the cybersecurity benefits.8

That provision is not a universal rule for every European organisation. Methodologically, however, it captures something important: remediation risk and compensating measures belong in the decision record, not in an undocumented side conversation.

When teams have several metrics, the next temptation is to blend them.

A common example is multiplying CVSS by EPSS or assigning weights to several inputs until one ranking number appears.

The result may be convenient and still have no clear meaning.

FIRST explicitly warns against multiplying EPSS by CVSS. EPSS is a calibrated probability. CVSS Base is an ordinal severity ranking, not a calibrated probability or loss measure. Multiplying the two does not produce an interpretable probability × severity risk quantity.3

There is a governance problem too. Suppose the final score is 7.43. What drove it? Known exploitation? Internet reachability? Critical business impact? A daily EPSS movement? A high Base score on an asset the organisation does not even run?

Once those signals are blended beyond recognition, the organisation may still have a ranking, but it has lost the evidence chain behind the ranking.

On 24 August 2026, I submitted a proposal to Latvia's Ministry of Defence and National Cyber Security Centre (NKDC) to consider a limited pilot of a risk-based vulnerability-prioritisation and decision-evidence profile. The proposal did not call for a national vulnerability score or a central database of organisations' detailed asset and vulnerability data. Its narrower purpose was to test whether a consistent minimum decision record could make triage faster and easier to audit.

I would reduce that record to the following fields:

Most of that record can be populated automatically. Human judgement is needed where context, exceptions and risk acceptance begin.

A row that says priority = 17 still does not tell an operations team what to do.

A more useful output is an action class:

I would not attach a universal 24/72-hour or 7/30-day table to those classes. Different assets, regulations, safety constraints and maintenance models require different response windows. The organisation or applicable sectoral regime should define the SLA bands and then test whether they produce sensible outcomes in practice.

Vulnerability intelligence moves.

EPSS is updated every day. FIRST moved production scoring to EPSS v5 on 15 June 2026, and its historical-data guidance warns that time series crossing model-version boundaries reflect methodology changes as well as changes in vulnerability inputs.9

Exploitation status, vendor guidance and catalog membership can also change long after a CVE is first published.

This means EPSS = 0.12 is not enough for an audit trail. A useful record should be able to answer:

• which source produced the value;
• when it was observed;
• which model or scoring version applied where relevant;
• what decision the value influenced at that time.

Without those fields, a future analyst may see a different score and be unable to reconstruct why the original decision was reasonable.

NIS2 Article 21 requires appropriate and proportionate cybersecurity risk-management measures. The listed measures include vulnerability handling and disclosure, as well as policies and procedures to assess the effectiveness of cybersecurity controls.10

For the specific categories of relevant entities within its scope, Commission Implementing Regulation (EU) 2024/2690 goes further into vulnerability and patch management, including evaluation of exposure, coordinated patching, compensating measures and documented non-patching decisions.8

Neither source says that organisations must patch every CVSS 9+ vulnerability before every 8.9, or use an EPSS threshold of 10%, or import KEV due dates into European law.

That absence is not a gap that needs to be filled with a universal score. Risk-based regulation necessarily leaves organisations with a harder task: understand their own assets, exposure and consequences, then be able to show why a decision was proportionate.

A Latvian policy exchange illustrates the same distinction. In letter No. 1/13-12.1NV/152 of 1 September 2026, responding to my proposal for a prioritisation-methodology pilot, NKDC stated that vulnerability-remediation priorities should be based on current risk assessment and may change as the threat environment changes; the regulated entity remains responsible for cyber-risk management. NKDC did not at that time see a need to change the legal framework or allocation of responsibilities.

That was not an endorsement of the proposed decision-card model. It was nevertheless a useful boundary: a methodology can structure evidence, but it should not transfer accountability from the organisation to a score, a feed or a public authority.

Much of vulnerability management should be automated aggressively:

• vulnerability-feed ingestion;
• asset-to-CVE matching;
• KEV/EUVD and threat-intelligence enrichment;
• daily EPSS updates;
• SLA and review-date tracking;
• exception-expiry alerts.

The dangerous point is where automation stops collecting evidence and quietly becomes the risk owner.

Human accountability should remain explicit when an organisation:

• accepts residual risk;
• approves an exception to a normal remediation window;
• chooses a temporary control with material business consequences;
• declares a vulnerability not applicable despite strong external signals;
• decides that patching risk currently outweighs the security benefit.

Automation should make those decisions faster to support and harder to lose — not harder to attribute.

A prioritisation decision starts a treatment process; it does not prove that the risk was removed.

A defensible lifecycle preserves the chain:

external signal → local context → decision → remediation or mitigation → verification → residual risk → reassessment.

There is one additional boundary worth making explicit. Patching a vulnerability does not establish that the vulnerable asset was not compromised during the exposure window.

For a known-exploited, reachable vulnerability, the decision may therefore create two parallel work items:

1. close or mitigate the vulnerability;
2. decide whether compromise assessment is necessary for the period before closure.

Those are different questions, and mature programmes should not allow the first to silently close the second.

Vulnerability management becomes weaker, not stronger, when every available signal is forced into a single number.

CVSS, EPSS, KEV, EUVD and SSVC are not competing attempts to say the same thing. They carry different information. The useful system is the one that preserves those distinctions, then joins them to local presence, reachability, consequence, controls and remediation risk.

A good prioritisation process does more than tell a team what sits at the top of a queue. It allows the organisation to answer a harder question months later:

Why did we fix this vulnerability immediately, defer that one, and what evidence did we actually have when we made the decision?

If the organisation cannot reconstruct that answer, a sophisticated ranking engine has not yet become a defensible risk-management process.

Additional primary material: Zigmārs Ancveirs, Proposal to evaluate and pilot a unified, risk-based vulnerability prioritisation and decision-evidence methodology, submitted to the Latvian Ministry of Defence/NKDC, 24 August 2026; NKDC response No. 1/13-12.1NV/152, 1 September 2026 (author’s document archive).