A number is not yet a risk.

What a CVE actually is

CVE stands for Common Vulnerabilities and Exposures. A CVE number like CVE-2026-12345 is an identifier and nothing more: it says a vulnerability was reported and catalogued. It says nothing about whether the product runs in your environment, whether it is reachable, whether it is being exploited, and what happens if it is.

This is exactly where most vulnerability processes fail. They produce lists instead of decisions. A list of 4,000 open findings is not evidence of working vulnerability management — it is evidence that none exists.

The four measures that only mean something together

1. 1
   CVSS — how bad would it beThe score from 0 to 10 describes technical severity under laboratory conditions. It is independent of your environment and stays the same for years. On its own it is a poor way to prioritise: there are far more vulnerabilities rated CVSS 9 than there is capacity to close them all at once.
2. 2
   EPSS — how likely is itThe Exploit Prediction Scoring System estimates the probability that a vulnerability is actually exploited in the next 30 days. The value changes daily. The vast majority of CVEs are never exploited — EPSS is what makes the small minority visible.
3. 3
   KEV — is it already being exploitedThe catalogue of known exploited vulnerabilities lists what is demonstrably under attack in the wild. If a vulnerability is on that list and runs in your environment, the discussion about prioritisation is over.
4. 4
   Your environment — does it affect you at allThe measure no external service knows: whether the product runs in your environment, in which version, reachable from outside or on the internal network, and what data sits behind it. Without an inventory of your systems, every vulnerability assessment is a guess.

What the frameworks require

Vulnerability management appears in every major framework — with different sharpness and different evidence.

• ISO/IEC 27001:2022, Annex A 8.8 — information about technical vulnerabilities of the systems in use must be obtained, the exposure evaluated and appropriate measures taken. The evidence is the documented decision path, not the scan list.
• NIS2 / Section 30 BSIG, measure 5 — security in acquisition, development and maintenance, explicitly including vulnerability handling and disclosure. What is required is a procedure, not a tool.
• DORA, ICT risk management — detection of anomalous activities and vulnerabilities, plus a testing programme that includes vulnerability assessments and scans.
• Section 75b SGB V, annexes 1 to 5 — operating systems and applications kept current, and security updates applied, graded by practice size.

A procedure that holds up in an audit

Four steps that together produce the evidence an auditor wants to see.

1. 1
   Know what you runA maintained inventory of systems, versions and owners. Without it everything else is busywork. It is the first thing the auditor asks for.
2. 2
   Subscribe to sources instead of searchingAdvisories for exactly the products you use — not the full stream of every publication. Whoever reads everything reads nothing.
3. 3
   Assess with a deadline, not with a feelingDecide in advance which combination of severity, exploitability and reachability triggers which deadline. That decision is itself evidence — and it protects you on the day a deadline slips.
4. 4
   Justify exceptions and time-limit themWhatever is not fixed needs a justification, a compensating measure and a review date. An open-ended exception is a nonconformity in an audit.

Vulnerability advisories

We follow the advisories anyway and classify them: what is relevant, who it affects and what to do. Tell us if you would like to receive that classification. The catalogue itself is publicly available at cvedetails.com.