Skip to content

Field note

Prioritise Patches with KEV, EPSS and CVSS

Start with the affected asset and exploitation evidence, then decide the action.

Published17 Oct 2026

Updatedyesterday

Read time4 min. 799 words.

When a vulnerability report contains hundreds of findings, sorting by severity alone rarely produces a workable maintenance schedule. The service owner needs to know which asset is affected, whether the vulnerable function is reachable, what evidence of exploitation exists and what action will reduce exposure.

KEV, EPSS and CVSS answer different parts of that question. Keep their meanings separate and use them to support a recorded decision, rather than adding the numbers into an arbitrary combined score.

Know what each signal says

CISA's official KEV data repository mirrors its Known Exploited Vulnerabilities catalogue. Use a matching entry as a prompt to examine the affected product and the catalogue's required action alongside the vendor advisory. Absence from the catalogue is not evidence that exploitation is impossible.

FIRST's EPSS estimates the probability that a published CVE will be exploited in the wild over the next 30 days. It publishes a probability and a percentile rank, updated daily. A percentile is a position among scores, not the probability that your organisation will be attacked.

CVSS describes vulnerability characteristics and severity, with metrics that can incorporate threat and environmental context. A base score alone does not describe your asset's value, exposure or available compensating controls.

Retain the date and source of these values. A patch decision made last month should not appear to have used today's threat information. Refresh the queue when material exploitation evidence or a vendor fix changes.

Establish whether the finding applies

Before ranking it, confirm the asset, product, installed build and vulnerable component. Read the vendor's affected-version and configuration conditions. A scanner may identify a package that is present but not used in the relevant way, or miss a bundled component outside its usual inventory.

Record the service's reachability: internet-facing, limited to a partner network, available only to administrators or reachable from ordinary internal endpoints. Verify the relevant route rather than relying on the label “internal”. Also consider the privileges and data available if the component is compromised.

Keep uncertain applicability visible with an owner and a short investigation deadline. Uncertainty should not silently become “not affected”, particularly for an exposed service with known exploitation evidence.

Turn evidence into an action order

An illustrative queue might look like this:

Confirmed affected public gateway with a KEV entryUrgent vendor-directed remediation and exposure reduction
High-impact internal service with elevated EPSSPrompt patching after checking reachable attack paths
Severe library finding with uncertain application useTime-bounded investigation while planning a compatible update
Fixed package still reported by a scannerVerify installed build and running state, then document the result

These are examples of reasoning, not fixed categories or service-level promises. A critical business dependency may require a carefully managed change even when urgency is high. Record the temporary measure and a deadline for the complete fix.

Do not let a low EPSS estimate postpone a requirement that already applies to the organisation. The Cyber Essentials patch-evidence guide covers assessment-driven deadlines and evidence. Prioritisation helps arrange work within obligations; it does not cancel them.

Give every exception a useful explanation

If a patch cannot be installed immediately, describe the reason, the interim control, its evidence and the person accepting the remaining risk. “Business critical” explains why a service matters, but not why it should remain exposed indefinitely.

Check that a proposed mitigation addresses the relevant path. A firewall restriction may reduce reachability, but it does not remove a vulnerable component from hosts that remain reachable. A feature-disablement workaround must match the vendor's documented conditions and be verified on the actual service.

Keep the vendor's eventual fix in the queue even after applying a temporary measure. Track whether a reboot, service restart or configuration change is required to complete remediation.

Verify the result and refresh the queue

Close a finding using package or firmware evidence, the running state and an appropriate follow-up check. Record scanner discrepancies instead of suppressing them without context. Confirm that the business service still works after the change.

Review open urgent items and expired exceptions regularly. Escalate missing owners, blocked maintenance and assets that cannot be updated. The useful management report is a short list of unresolved exposure and decisions required, supported by the underlying technical evidence.

That gives the team a patch order it can explain: what is affected, why it matters now, what will change and how completion will be demonstrated.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?