EPSS vs CVSS vs KEV: Building a Data-Driven Patch Prioritisation Model

Short answer: Use all three, for different jobs. KEV tells you a vulnerability is being exploited right now — patch those first, unconditionally. EPSS estimates the probability a vulnerability will be exploited in the next 30 days — use it to rank everything KEV does not cover. CVSS describes how bad exploitation would be if it happened — use it to weight impact, never as a queue on its own. A backlog sorted by "CVSS 7.0 and above" is not a prioritisation strategy; it is a list of most of the vulnerabilities that exist.

Record treatment decisions and residual risk in the Risk Register, and assess vendor-side exposure with the Vendor Risk Assessment tool.

Why CVSS-only prioritisation fails

CVSS is a severity scale. Its base score answers: if this were exploited, how bad would it be? It deliberately says nothing about whether anyone will actually exploit it.

Two well-established properties of the vulnerability landscape make severity-only queues unworkable:

• The majority of published CVEs score High or Critical. Sort by CVSS ≥ 7.0 and you have narrowed a five-figure backlog to a slightly smaller five-figure backlog. That is not triage.
• Only a small fraction of CVEs are ever exploited in the wild. Research from the EPSS special interest group and Cyentia has consistently placed this in the single-digit percentages. The overwhelming majority of what your scanner reports will never be weaponised against anyone.

The result is a queue that is simultaneously too large to complete and poorly correlated with actual risk. Teams work it top-down, never reach the bottom, and the vulnerability that gets exploited is frequently a CVSS 6.5 that scored below the cut line.

CVSS remains useful — it is the best available description of impact, and CVSS v4.0 improved the framework's expressiveness. It is simply the wrong sort field.

What each signal actually measures

EPSS is a machine-learning model trained on exploitation evidence and CVE characteristics. It is dynamic: a vulnerability with a low score on publication can spike within days when proof-of-concept code appears. That temporal behaviour is precisely what a static CVSS score cannot give you, and it is the reason EPSS should be re-pulled daily rather than snapshotted at scan time.

Two terms you need when setting an EPSS threshold:

• Coverage — of all vulnerabilities that were exploited, what share did your threshold catch?
• Efficiency — of everything your threshold flagged, what share was actually exploited?

Lowering the threshold raises coverage and lowers efficiency. There is no correct universal value; there is only the trade-off your remediation capacity can sustain.

KEV is CISA's Known Exploited Vulnerabilities catalogue — CVEs with confirmed, reliable evidence of active exploitation. It launched in November 2021 under Binding Operational Directive 22-01 with an initial set of 291 entries and has grown steadily; by mid-2026 it exceeds 1,300. It is deliberately conservative: inclusion requires evidence, so absence from KEV is not evidence of safety, merely absence of confirmation.

Note that CISA's approach to remediation timelines has been evolving away from BOD 22-01's flat due dates toward risk-based prioritisation — reporting indicates a successor directive (BOD 26-04, "Prioritizing Security Updates Based on Risk") issued in June 2026. Confirm the current directive text on CISA's site before citing specific obligations, particularly if you are a federal contractor bound by them; the direction of travel, however, matches what mature private-sector programmes have been doing for years.

The decision matrix

Combine the three into four tiers. Add a fourth dimension — asset exposure — because none of these scores knows whether the affected system is internet-facing or sitting on an isolated lab VLAN.

Three rules that make this work in practice:

1. KEV overrides everything. Do not let a KEV entry with a modest CVSS score fall below a CVSS 9.8 that nobody is exploiting. Confirmed exploitation beats theoretical severity every time.
2. Re-evaluate EPSS daily, not at scan time. A P4 becomes a P2 when a PoC drops. If your scanner enriches with an EPSS score captured at scan time, you are working from stale probabilities.
3. Exposure is a multiplier, not a tiebreaker. An internet-facing asset with no compensating control should escalate a tier. A segmented asset behind strong controls may drop one — but record that decision as a risk acceptance, not as a silent omission.

If you want a more formal decision framework, CISA's SSVC (Stakeholder-Specific Vulnerability Categorization) provides a documented decision tree over exploitation status, exposure, mission impact and safety impact. It is heavier to operate than the matrix above but produces defensible, auditable decisions — worth adopting if you are answering to a regulator.

Run the analysis yourself: a methodology

The signals below are most persuasive when you validate them against your own data snapshot. The reproducible method:

Data sources: - CISA KEV catalogue — the published JSON feed (fields: cveID, dateAdded, vendorProject, product, knownRansomwareCampaignUse). - FIRST EPSS — the daily scores CSV (fields: cve, epss, percentile). - NVD — CVSS base scores per CVE.

Proposed analyses (pick two or three, not all):

1. The CVSS blind spot. For every CVE added to KEV in the last 24 months, what share had a CVSS base score below 7.0 at the time of addition? This quantifies exactly how many confirmed-exploited vulnerabilities a "Critical and High only" policy would have deprioritised. This is the headline number.
2. EPSS as an early-warning signal. For CVEs added to KEV, what was their EPSS score 30 days before the KEV addition date? If a meaningful proportion already scored above 0.10, EPSS demonstrably provided lead time — the single most persuasive argument for adopting it.
3. Threshold trade-off curve. Plot coverage against efficiency across EPSS thresholds from 0.01 to 0.50, using KEV membership as the exploitation ground truth. Output: a defensible recommended threshold with the trade-off made explicit.
4. Ransomware subset. KEV flags entries with known ransomware campaign use. Compare the CVSS and EPSS distributions of that subset against the rest of KEV — do the scores distinguish the vulnerabilities that actually appear in ransomware operations?

Presentation: one chart (the threshold trade-off curve is the most reusable), one headline statistic in the opening paragraph, and a published methodology note stating the data snapshot date. Cite the snapshot date explicitly — these datasets change daily, and a reproducible date is what separates analysis from assertion.

Operationalising it

Enrich once, centrally. Pull KEV and EPSS daily into whatever holds your vulnerability data and join on CVE ID. Do not have three teams each maintaining their own lookup.

Set SLAs by tier, not by severity label. Then measure against them — mean time to remediate per tier is a far better programme metric than raw open-vulnerability count, which mostly tracks how many assets you scan.

Track exceptions as risk, not as backlog. Anything that cannot be patched within its SLA needs a documented compensating control, an owner and a review date in the Risk Register. An unpatched KEV entry with no compensating control and no acceptance is an undocumented accepted risk — the worst of both worlds.

Extend the model to third parties. Your vendors' unpatched KEV entries are your exposure too. Include KEV status in periodic vendor reviews and in questionnaires — see the vendor risk process.

Report the shape, not just the count. Leadership does not need to know you have 40,000 open findings. They need to know: how many KEV entries are open, how long the oldest has been open, and whether MTTR for P1 is inside SLA. Three numbers, monthly.

Honest limitations

• EPSS predicts observed exploitation, and observation is biased. Activity against monitored, internet-facing infrastructure is far better represented than exploitation inside enterprise networks. Low EPSS on an internal-only vulnerability class deserves scepticism.
• KEV is a lagging indicator. By the time a CVE is listed, exploitation is established. KEV tells you what to fix immediately; it cannot tell you what to fix first next month.
• Neither knows your environment. Compensating controls, segmentation, WAF rules and whether the vulnerable feature is even enabled are all invisible to these scores. Exposure context is yours to supply, and it is the part that most changes the answer.
• CVE coverage is not universal. Vulnerabilities without a CVE — in bespoke code, in some cloud services, in unpatched dependencies not tracked by an advisory — sit outside all three signals entirely.

The model above is a prioritisation aid, not an oracle. Its real value is that it is defensible: when something gets exploited, you can show the decision logic, the data it ran on, and the date it ran — which is a far better position than explaining why item 4,000 on a CVSS-sorted list was never reached.

Related: The ISO 27001, NIST CSF and SOC 2 Crosswalk · Third-Party Risk Management