01
A list does not establish order
A vulnerability inventory describes a state. By itself, it does not determine which service should be fixed first. The same weakness can affect an Internet-facing component, an isolated machine or an unused dependency. Prioritization begins with the link between the component, its use, exposure and the business service it supports.
02
Add evidence of exploitation
CISA publishes the KEV catalogue of vulnerabilities with known exploitation. Its official repository provides JSON and CSV data with change history. This signal can enrich triage, but it cannot replace a local inventory: the affected product and version must be checked. Absence from the catalogue is not evidence that a vulnerability is harmless.
03
Make the decision explicit
A useful ticket identifies the asset, version, access paths, impact, proposed action and accountable team. If patching risks a service disruption, discussion must also cover temporary controls and their expiry. Recording the decision distinguishes accepted risk from an overlooked issue. A score remains one signal among several.
04
Close with evidence
Closure should explain what changed: patched version, verified configuration, new control or removed exposure. An undated screenshot or a completed ticket may not preserve that information. Keeping the link between the original finding, change and validation turns a backlog into operational memory for security maintenance and accreditation.
Sources and scope
A method note based on the references below and the engineering approach presented on this site. Application suggestions are editorial synthesis, not certification by the cited organizations.
CISA — Known Exploited Vulnerabilities, données officielles ↗