01The Lifecycle: From Inventory to Verification
Vulnerability management is a continuous process, not a one-off project. It starts with a complete asset inventory, because only known systems can be assessed – including cloud resources, containers and internet-facing services. This is followed by regular, ideally authenticated scans from inside and outside, risk-based prioritization of the findings, remediation through patches, configuration changes or compensating controls, and verification via re-scan. Only this closed loop, with documented turnaround times, makes the process manageable and auditable.
02CVSS 4.0: Rating Severity Correctly
FIRST's Common Vulnerability Scoring System has been available in version 4.0 since November 2023 and comprises four metric groups: Base, Threat, Environmental and Supplemental. The Threat metric “Exploit Maturity” reflects whether exploit code is available or the flaw is already being actively exploited; the CVSS-B/-BT/-BE/-BTE nomenclature makes transparent which groups have been factored into a score. FIRST itself makes clear that CVSS measures technical severity and should not serve as the sole measure of risk. Anyone who patches solely by Base score treats many vulnerabilities as highly urgent that are never exploited – and overlooks actively attacked ones with medium scores.
03EPSS and CISA KEV: Exploitation Data Instead of Gut Feeling
FIRST's Exploit Prediction Scoring System (EPSS) is a machine-learning model that estimates daily, for every published CVE, the probability of active exploitation within the next 30 days; the scores are freely available via CSV and API. The Known Exploited Vulnerabilities (KEV) catalog of the US cybersecurity agency CISA, by contrast, lists vulnerabilities whose exploitation has already been proven. In practice, three signals complement each other: CVSS answers how severe an exploitation would be, EPSS how likely it is, and KEV whether it is already happening. KEV-listed findings on reachable systems belong at the top of the queue regardless of their Base score.
04Patch SLAs: Deadlines by Risk, Not One-Size-Fits-All
Robust SLAs define binding remediation deadlines per criticality and exposure, along with an exception process including documented risk acceptance. CISA's directive BOD 26-04 (June 10, 2026, replacing BOD 22-01) serves as a suitable reference model: it derives deadlines from four criteria – reachability from the internet, KEV status, automatability of the attack and technical impact – and tiers them from 3 days (including a forensic review where a KEV entry is combined with full system control) through 14 and 60 days up to remediation with the next regular upgrade. The directive is binding only for US federal agencies, but as a risk-based deadline model it also offers companies a well-founded point of reference.
05Zero-Days: Acting Before a Patch Exists
A zero-day is a vulnerability that is being exploited or is publicly known before the vendor provides a patch – leaving defenders “zero days” of lead time. Since classic patching is off the table, compensating measures come into play: virtual patching blocks exploitation attempts in front of the application via WAF or IPS rules without changing the code; OWASP's Virtual Patching Cheat Sheet explicitly classifies the approach as an interim solution that does not replace the actual fix. Added to this are workarounds from vendor advisories, network segmentation and the temporary deactivation of exposed features. The prerequisite is systematic advisory monitoring – for example of vendor bulletins, the warning and information service of CERT-Bund/BSI, and the KEV catalog.
06Anchoring in the ISMS and Key Metrics
ISO/IEC 27001:2022 anchors the topic in Annex A control 8.8 (“Management of technical vulnerabilities”): information about technical vulnerabilities must be obtained, the organization's own exposure must be evaluated, and appropriate measures must be taken. NIS2 (Directive (EU) 2022/2555) likewise requires, in Art. 21(2)(e), security measures in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. The process is steered via metrics such as the mean time to remediate (MTTR) per criticality class, the SLA compliance rate, scan coverage of the inventory, the age of open – in particular KEV-listed – vulnerabilities, and the recurrence rate after verification. These figures belong in the ISMS's regular management reporting.
