A vulnerability queue can contain a high-severity issue on an isolated test system and a lower-scored issue on a public service. Sorting by one number cannot describe every difference between them. Severity, exploitation evidence, and local business context are separate inputs.
CVSS, EPSS, and CISA's Known Exploited Vulnerabilities catalog contribute different information. Understanding their roles helps a team explain why one remediation is scheduled ahead of another.
Severity describes technical characteristics
CVSS provides a structured way to communicate vulnerability severity. Version 4.0 includes Base, Threat, Environmental, and Supplemental metric groups, with defined roles in scoring and context. A Base score alone does not describe an organization's complete risk. FIRST's CVSS v4.0 user guide explains the model.
An illustrative vulnerability affecting a service's confidentiality has different business consequences depending on whether that service holds public catalog data or customer records. The published score can describe technical impact while the organization supplies information about the affected asset.
Prediction differs from observed exploitation
EPSS estimates the probability that a published vulnerability will be exploited in the wild over the next 30 days. It is a forecast, not a measurement of whether a particular company has been attacked. FIRST's EPSS documentation describes that purpose.
CISA's KEV catalog identifies vulnerabilities with evidence of exploitation in the wild under its inclusion criteria. Catalog membership does not establish that the vulnerability was exploited in the reader's environment. Conversely, absence from the catalog is not proof that exploitation is impossible or has never occurred. CISA's catalog supplies the observed-exploitation signal.
Add the local facts needed for a decision
Record affected versions, enabled features, reachability, required privileges, business function, and compensating controls. Verify that the component is actually deployed rather than merely present in an unused build dependency. Document uncertainty where configuration or inventory evidence is missing.
For a synthetic comparison, one issue affects a public authentication gateway while another affects a disabled component in an internal test image. A defensible queue records why their exposure and consequences differ instead of silently changing a score to force an ordering.
Preserve the reason for the priority
Record the source data, local evidence, owner, decision date, and planned action. Reassess when exploitation information changes or when the service becomes reachable through a new configuration. A previously justified deferral can become inappropriate when its assumptions change.
The resulting priority is an operational decision supported by several inputs. It is not a mathematical guarantee about the next incident. Keeping those inputs visible lets engineering and business owners review exceptions, challenge missing evidence, and understand why a patch or mitigation requires attention.
Sources
FIRST and CISA references are linked at the relevant definitions above. The gateway and test-image comparison is illustrative and does not prescribe a universal remediation deadline.
