# Vulnerability Management: A Process That Works in Practice

How to set up vulnerability management that holds: sources, triage with CVSS and exploit data, SLAs by severity, SBOM, coordinated disclosure and the duties the CRA adds.

Source: https://zyberum.com/insights/vulnerability-management-process · Updated: 2026-10-07

Vulnerability management is a loop: know what you have, learn what is wrong with it, decide what matters, fix it in time, prove it is fixed. Most companies have the middle part, a scanner that produces findings. What is missing is usually the beginning (an inventory that is complete) and the end (deadlines that are kept and measured). This is how to build the whole loop, for your own IT and, if you make products, for the products you ship, where the Cyber Resilience Act now makes it a legal duty.

## Step 1: Know what you have

You cannot manage vulnerabilities in systems you do not know about. The inventory has two layers:

- **Assets.** Servers, cloud accounts, workstations, network devices, OT controllers, and for manufacturers every product version still in support. Each with an owner.
- **Components.** The software inside each asset. For products this is the **SBOM**, the software bill of materials, in CycloneDX or SPDX. The CRA requires one for every product (Annex I Part II (1)), covering at least the top-level dependencies; BSI TR-03183 Part 2 describes a useful level of detail. Without an SBOM the next Log4j means grepping through build servers for a week.

## Step 2: Collect from every source

Vulnerabilities arrive through several channels and the process has to accept all of them:

| Source | Typical volume | Note |
|---|---|---|
| Network and host scanners | High | Many duplicates and false positives, needs tuning |
| Dependency and container scanning against the SBOM | High | Automate in CI, match against NVD and vendor feeds |
| Penetration tests | Low, high value | Verified, exploitable, with reproduction steps |
| Vendor advisories and CERT feeds | Medium | Needs the inventory to know whether you are affected |
| External reports (researchers, customers) | Low | Needs a published contact and a disclosure policy |
| Incidents | Rare | Every incident ends in at least one vulnerability record |

The external channel matters more than its volume: a `security.txt`, a reporting address and a coordinated vulnerability disclosure policy as described in ISO/IEC 29147 are what turn a researcher's finding into an e-mail instead of a blog post. The CRA requires exactly this policy from manufacturers (Annex I Part II (5)).

## Step 3: Triage, not just CVSS

CVSS tells you how severe the vulnerability is in isolation. It does not tell you whether anyone is exploiting it or whether your instance is reachable. Triage combines four inputs:

1. **CVSS base score** for the technical severity.
2. **Exploitation evidence**: is the CVE in the CISA KEV catalogue, does it have a high EPSS probability, is there a public exploit?
3. **Exposure**: internet-facing, reachable from the office network, or on an isolated segment?
4. **Asset criticality**: what runs on it, what data it holds, what it controls.

A practical rule: anything exploited in the wild on an internet-facing system goes to the top regardless of its CVSS score. A CVSS 9.8 on an isolated test bench goes down. Write the rule down, so two people reach the same priority.

## Step 4: SLAs by severity

A deadline turns a list into a process. The numbers below are a common scheme, not a legal requirement; the right ones are those you can measure and keep.

| Priority after triage | Fix or mitigate within |
|---|---|
| Actively exploited and reachable from the internet | 48 hours |
| Critical | 7 days |
| High | 30 days |
| Medium | 90 days |
| Low | Next planned release |

"Mitigate" counts: a firewall rule, a disabled feature or a configuration change that removes reachability can stop the clock while the real fix goes through testing. The record stays open until the fix is in.

## Step 5: Fix, verify, communicate

The fix is applied by the asset owner, not by the security team. The security team verifies: rescan, retest or, for pentest findings, a retest by the testers. For products, the fix becomes a security update, and the CRA requires that updates are distributed securely, without delay and free of charge, together with an advisory that tells users what was fixed (Annex I Part II (4), (7), (8)). For your own IT, communication is internal: which systems were affected, what was done, whether logs showed exploitation.

## Step 6: Measure

Three numbers show whether the process works: the share of findings fixed within SLA, the mean time to remediate per severity, and the number of findings that come back after being closed. Report them monthly to management. They are also the evidence that NIS2 and ISO 27001 auditors ask for.

## What the CRA adds for manufacturers

For every product with digital elements sold in the EU, the Cyber Resilience Act (Regulation (EU) 2024/2847) turns this process into an obligation. The essential vulnerability handling requirements in Annex I Part II are, in short: identify and document vulnerabilities and components including an SBOM; address and remediate vulnerabilities without delay; test the product's security regularly; publish information about fixed vulnerabilities once the update is available; have a coordinated vulnerability disclosure policy; provide a contact for reports; distribute updates securely; and provide security patches free of charge with advisories.

Two more rules sit in the articles. The support period during which vulnerabilities must be handled has to reflect the expected product lifetime and is at least five years unless the product is clearly used for a shorter time (Article 13(8)). And an actively exploited vulnerability has to be reported through ENISA's single reporting platform: early warning within 24 hours of becoming aware, notification within 72 hours, final report after the fix is available (Article 14). The reporting obligations apply from 11 September 2026. ISO/IEC 30111 is the standard that describes the internal handling process and is a good template for the documentation a notified body or market surveillance will ask to see.

## Where it usually fails

- **No owner.** Findings assigned to "IT" are assigned to nobody.
- **Severity equals CVSS.** Teams drown in Highs that no one can exploit and miss the Medium that is being exploited.
- **The SBOM is generated once.** It has to be regenerated with every build, or it describes a product that no longer exists.
- **Exceptions without expiry.** A risk acceptance needs a date and a name.
- **No retest.** "Patched" and "fixed" are different states.

We help manufacturers set up vulnerability handling for the CRA, from the SBOM pipeline to the disclosure policy and the 24-hour reporting procedure, and we test the result. See [Cyber Resilience Act](/cyber-resilience-act) or book a [free CRA consultation](/contact?meeting=consult&interest=cra).

## FAQ

**Is vulnerability management the same as running a scanner?**

No. The scanner is one source of input. Vulnerability management is the process around it: knowing what you have, deciding what matters, fixing it within a defined time, verifying the fix and reporting on it. Without the process the scanner produces a list that grows every month.

**Which SLAs are right for us?**

Ones you can keep. A common scheme is seven days for critical, 30 for high, 90 for medium and the next planned release for low, with 48 hours for anything that is internet-facing and actively exploited. Start there, measure how often you miss, and adjust the process before you adjust the numbers.

**What does the Cyber Resilience Act add for manufacturers?**

A legal duty to run this process for every product with digital elements: identify and document vulnerabilities including an SBOM, fix them without undue delay, provide free security updates for the support period, have a coordinated vulnerability disclosure policy, and report actively exploited vulnerabilities to ENISA and the CSIRT within 24 hours of becoming aware.

## Sources

- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Art. 13, 14 and Annex I Part II](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [ISO/IEC 30111:2019 Vulnerability handling processes](https://www.iso.org/standard/69725.html)
- [ISO/IEC 29147:2018 Vulnerability disclosure](https://www.iso.org/standard/72311.html)
- [FIRST: CVSS v4.0 Specification Document](https://www.first.org/cvss/v4.0/specification-document)
- [FIRST: Exploit Prediction Scoring System (EPSS)](https://www.first.org/epss/)
- [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [BSI TR-03183 Part 2: Software Bill of Materials (SBOM)](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2.pdf)

## Related

- [CVSS](https://zyberum.com/glossary/cvss)
- [SBOM](https://zyberum.com/glossary/sbom)
- [Responsible Disclosure](https://zyberum.com/glossary/responsible-disclosure)
- [The CRA 24-Hour Reporting Duty: What Manufacturers Must Do](https://zyberum.com/insights/cra-vulnerability-reporting-24-hours)
- [CVSS 3.1 Calculator](https://zyberum.com/tools/cvss-calculator)
- [Make your products CRA-compliant, without slowing development.](https://zyberum.com/cyber-resilience-act)

---
Zyberum GmbH. Canonical page: https://zyberum.com/insights/vulnerability-management-process