Vulnerability Prioritization: CVSS vs EPSS vs CISA KEV

Direct answer: CVSS, EPSS, and CISA KEV answer different questions. CVSS describes technical severity. EPSS estimates the probability of observed exploitation activity for a published CVE in the next 30 days. CISA's Known Exploited Vulnerabilities catalog records vulnerabilities with evidence of exploitation and supplies remediation guidance and due dates for federal agencies. A defensible queue starts with affected assets and business context, then uses these signals together; no single score should automatically determine every patch decision.

This guide is written for a small organization that needs an accountable operating process, not a vague list of best practices. It is grounded in Common Vulnerability Scoring System v4.0 and cross-checked against Exploit Prediction Scoring System. Product interfaces, licensing, threats, and legal obligations can change, so verify current provider documentation and obtain qualified legal or regulatory advice when the decision requires it.

Use the three signals together: When teams compare CVSS vs EPSS vs KEV, they are combining severity, predicted exploitation, and evidence that vulnerabilities have been exploited in the wild. A high CVSS score can describe serious technical impact, while an EPSS score helps the security team prioritize CVEs by near-term real-world exploitation likelihood. The KEV Catalog identifies known exploited vulnerabilities, but it does not replace asset validation or a complete vulnerability risk assessment.

In a practical vulnerability management process, check the CVE in the NVD and authoritative vendor guidance, then capture CVSS and EPSS with their versions and timestamps. Use exploitability, internet exposure, service importance, and compensating controls to prioritize each vulnerability. This is why CVSS alone is insufficient: CVSS and EPSS answer different questions, and CISA KEV adds a high-confidence operational signal. The purpose is not to manufacture one perfect score; it is to place every applicable vulnerability in a defensible remediation lane.

What each signal tells you

CVSS v4.0 communicates vulnerability characteristics through Base, Threat, Environmental, and Supplemental metric groups. A Base score is useful for technical severity, but a generic score cannot know whether the vulnerable product is deployed, reachable, business-critical, or protected by compensating controls in your environment. Preserve the vector as well as the numeric score so reviewers can understand how it was derived.

EPSS is a daily, data-driven probability for a CVE, plus a percentile that shows its rank. It is not an impact score and does not know your asset context. CISA KEV is a curated catalog based on evidence of active exploitation, not a list of every exploitable vulnerability. Together, these signals separate intrinsic severity, estimated likelihood, and confirmed exploitation.

A practical prioritization order

First confirm that the vulnerable component and version exist. Next identify exposure: internet-facing, accessible from untrusted networks, reachable through email or documents, or restricted to a segmented environment. Elevate KEV-listed items affecting in-scope assets. Then use EPSS and trend changes to rank non-KEV vulnerabilities, while using CVSS metrics and your business impact to understand consequences.

Add exploitation prerequisites, privilege, user interaction, data sensitivity, safety, revenue dependence, and recovery difficulty. Vendor guidance and credible threat intelligence can change the order. A critical CVSS score on an absent product is not work. A lower-severity vulnerability on an exposed identity system may be urgent. Document the reason for the final priority so the decision survives staff changes.

Build service levels without false precision

Define remediation targets by decision band, not by CVSS alone. An emergency band can include applicable KEV entries, credible active exploitation, or vulnerabilities enabling direct compromise of crown-jewel systems. An accelerated band can combine high EPSS, reachable exposure, and serious impact. A normal band covers lower-likelihood or well-contained findings. A planned-risk band records accepted, mitigated, or not-applicable items with review dates.

Service levels must include triage, testing, deployment, and verification. A target such as forty-eight hours is meaningless if the asset owner is unknown or the change window cannot be obtained. Record exceptions with an approver, compensating control, expiry, and re-evaluation trigger. This turns prioritization into accountable risk management rather than score sorting.

Measure whether the queue works

Track time from detection to scope confirmation, from confirmation to mitigation, and from change to verified closure. Separate overdue KEV items, exposed critical systems, and exceptions nearing expiration. Measure false-positive or not-applicable findings so asset inventory problems become visible. Review a sample of closed tickets for proof that the vulnerable condition was actually removed.

Recalculate dynamic signals. EPSS can change as new evidence appears; KEV additions may reorder an existing backlog. Avoid rewriting history: retain the score and catalog state used for the original decision, then record the later change that caused reprioritization. That audit trail supports both learning and executive communication.

Implementation sequence and evidence

Use the following sequence as a working control record. Assign one accountable owner per step, keep the evidence in a location responders can reach, and date each artifact. A checkbox without evidence is only an assertion. Where a step changes production, use the organization’s change, backup, rollback, and approval process.

1. Validate the finding. Confirm the CVE, product, version, detection method, and quality of evidence. Evidence: Scanner evidence plus package, build, or configuration confirmation.
2. Map the asset. Link the finding to an owner, service, environment, and data classification. Evidence: An inventory record with accountable owner.
3. Check KEV. Determine whether CISA lists the CVE and read the required action and known ransomware field. Evidence: Catalog date, due date where relevant, and action text.
4. Read EPSS. Capture current probability, percentile, and change over time. Evidence: Timestamped API or feed value.
5. Interpret CVSS. Use the vector and environmental context, not only the Base number. Evidence: Recorded version, vector, and context adjustments.
6. Assign a decision band. Combine exploitation, exposure, impact, and control context. Evidence: A short rationale and service-level target.
7. Apply or mitigate. Patch, remove, isolate, disable, filter, or otherwise reduce the vulnerable path. Evidence: Approved change and implementation record.
8. Verify closure. Rescan and directly test the relevant version or configuration where safe. Evidence: Independent closure evidence and exception status.

How to verify the control is operating

Verification should sample the saved state and the real workflow. Review configuration or inventory evidence, trigger a controlled event where safe, confirm the responsible person receives and understands it, and inspect the resulting record. For higher-impact controls, have someone other than the implementer review closure. Recheck after material changes rather than relying indefinitely on the first successful test.

• Validate the finding: confirm the owner can produce scanner evidence plus package, build, or configuration confirmation and explain any exception.
• Map the asset: confirm the owner can produce an inventory record with accountable owner and explain any exception.
• Check KEV: confirm the owner can produce catalog date, due date where relevant, and action text and explain any exception.
• Read EPSS: confirm the owner can produce timestamped api or feed value and explain any exception.
• Interpret CVSS: confirm the owner can produce recorded version, vector, and context adjustments and explain any exception.
• Assign a decision band: confirm the owner can produce a short rationale and service-level target and explain any exception.
• Apply or mitigate: confirm the owner can produce approved change and implementation record and explain any exception.
• Verify closure: confirm the owner can produce independent closure evidence and exception status and explain any exception.

Record scope as carefully as the result. State which tenants, systems, locations, users, suppliers, or versions were examined; the time window; the method; and any blind spots. This makes a later reviewer less likely to mistake a narrow sample for organization-wide assurance.

Common failure modes

Patching by CVSS alone

It confuses generic technical severity with organizational risk and can crowd out exposed, exploited vulnerabilities.

Treating EPSS as a complete risk score

EPSS estimates exploitation likelihood; it does not supply your asset value, impact, exposure, or compensating controls.

Assuming KEV absence means safe

The catalog is evidence-based and intentionally selective. New or unobserved exploitation may not yet be represented.

Closing on deployment

A successful change job does not prove the vulnerable state is gone. Require verification and record residual exposure.

Questions teams ask

Should every KEV item be patched immediately?

First confirm it affects an in-scope asset. For applicable items, treat the catalog entry as a strong urgency signal and follow vendor or CISA remediation guidance; document any temporary mitigation and deadline.

What EPSS threshold should a small team use?

There is no universal threshold. Choose a cutoff based on capacity and desired coverage, then combine it with exposure and impact. Measure results and revisit the cutoff.

Can CVSS v3.1 and v4.0 scores be compared directly?

Do not treat them as interchangeable. Record the version and vector, and avoid using a raw numeric difference as proof that risk increased or decreased.

Ownership, cadence, and documentation

Assign one queue owner who maintains the decision rules and one service owner for every affected asset. Security can supply CVSS, EPSS, KEV, and scanner evidence, but the final priority also needs operations context: exposure, business impact, maintenance constraints, and recovery options. Record who can approve an exception and who validates closure independently for high-impact findings.

Preserve the timestamp and source for every dynamic signal. A ticket should show the CVE, affected version, CVSS version and vector, EPSS probability and percentile, KEV state, exposure, business service, decision band, due date, and rationale. When a signal changes, append the new observation instead of overwriting the evidence behind the original decision.

Review the urgent lane daily and the full queue weekly. Track time to scope, time to mitigation, time to verified closure, expired exceptions, and reopened findings. Use those results to tune service levels and repair inventory gaps; do not move thresholds merely to make an overdue chart look better.

Related EncryptCentral fundamentals

Use these implementation steps with the site’s existing explainers on security patches and software update cadence. Those pages cover the underlying concepts; this guide is the operating layer for ownership, evidence, and verification.

Decision

Adopt the smallest version of this process that changes a real decision, names an owner, and produces reviewable evidence. Expand it when risk, complexity, or obligations justify more control. Do not confuse a purchased tool, written policy, completed questionnaire, or successful job message with an operating outcome. The durable result is a verified change, an understood exception, and a next review date.

Primary references

• Common Vulnerability Scoring System v4.0 — FIRST
• Exploit Prediction Scoring System — FIRST
• Known Exploited Vulnerabilities Catalog — CISA