Vulnerability management: the full cycle and how to prioritise

Vulnerability management is the continuous process of finding the security flaws in your systems, deciding which to fix first and checking that they are actually closed. It is not just about installing updates: the real work is in the sorting, because no team can fix everything at once. Here is the cycle, the tools for prioritising and what the rules expect.

A vulnerability is a weakness in software, hardware or a configuration that an attacker can exploit. Once disclosed, it usually gets a CVE identifier (Common Vulnerabilities and Exposures), assigned by the CVE programme and its numbering authorities, and is covered by security advisories such as those CERT-FR, the French national CERT, publishes on a rolling basis.

Vulnerability management organises the response: knowing what you own, detecting the flaws that affect it, ranking them, treating them and checking the result. It differs from two related practices:

• patch management, which deploys vendor updates: NIST describes it in SP 800-40 as "preventive maintenance", a normal cost of running technology rather than a one-off project. It is one possible treatment, not the only one;
• penetration testing and cyber security audits, which look for flaws by hand at a point in time. They complement vulnerability management, which runs continuously.

The OWASP guide makes the point: vulnerability management should be broken into short, repeatable cycles tailored to the organisation. The same steps come up everywhere.

1. Inventory your assets

You cannot protect what you do not know about. Servers, workstations, network gear, applications, cloud services, but also technical equipment and tools installed outside IT: everything belongs in the information system map, with its version, owner, internet exposure and criticality. Shadow IT and forgotten devices are the usual blind spots, as the supermarket refrigeration cyberattack showed in October 2026.

2. Detect vulnerabilities

Three sources work together: scanners, which compare installed versions with vulnerability databases; monitoring of security advisories (CERT-FR, vendors, public databases); and one-off findings from penetration tests and outside reports. For software you buy, a software bill of materials (SBOM) tells you quickly whether a vulnerable component is inside.

3. Prioritise

The decisive step, covered below: combining the flaw's severity, whether it is exploited or likely to be, and the importance of the affected asset.

4. Treat

Three options: remediate (apply the patch or change the configuration), mitigate when no patch exists or it cannot be deployed straight away (remove internet exposure, disable the vulnerable feature, isolate the device), or accept the risk. Acceptance is decided by the asset owner, recorded as an exception with a review date, and assessed as residual risk.

5. Verify and report

A new scan confirms the flaw is gone. Persistent gaps, delays and exceptions feed the security metrics, then the cycle starts again.

A scan of a mid-sized estate easily returns thousands of findings. Sorting them by severity score alone means fixing first flaws that may never be exploited in your environment. Four free public tools help aim better.

CVSS: technical severity

The Common Vulnerability Scoring System, maintained by FIRST, the global forum of incident response teams, scores each flaw from 0 to 10. Version 4.0, released on 1 November 2023, separates the base score (the flaw's characteristics) from threat, environmental and supplemental metrics, hence the CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE labels. In practice most tools only show the base score: it describes the flaw in the abstract, not the risk it poses to your organisation.

EPSS: probability of exploitation

The Exploit Prediction Scoring System, also run by FIRST, estimates for each CVE the probability that it will be exploited in the next 30 days. The model is recalculated daily and its data is freely downloadable. It helps rank flaws of similar severity.

The KEV catalogue: what is already exploited

Since directive BOD 22-01 of November 2021, the US Cybersecurity and Infrastructure Security Agency (CISA) has maintained the Known Exploited Vulnerabilities catalogue. A flaw is added if it has a CVE identifier, reliable evidence of active exploitation and clear remediation guidance. US federal agencies must fix these flaws within set deadlines, two weeks by default for recent ones. Any organisation can use it as the list of what cannot wait.

SSVC: a decision tree

SSVC (Stakeholder-Specific Vulnerability Categorization), created by Carnegie Mellon University's Software Engineering Institute with CISA, replaces the score with a decision. From five questions (is it exploited, what technical impact, can the attack be automated, how important is the asset to the mission, what impact on the public), it reaches four outcomes: track, track closely, attend to it sooner than usual, or act as soon as possible with leadership involved.

A simple rule to start with

Without complex tooling, your security policy can set three levels: immediately for a KEV-listed flaw, or one CERT-FR reports as exploited, on an exposed or critical asset; soon for a severe flaw on an exposed asset, or one with a high probability of exploitation; normal cycle for the rest. Each organisation sets its own deadlines according to its resources and obligations.

Flaws are a major way in. According to Verizon's 2025 Data Breach Investigations Report, as reported by CyberScoop, vulnerability exploitation was the initial access vector in 20% of the breaches studied, up 34% year on year. Edge devices and VPNs made up 22% of the targets of these exploits, against 3% the year before, and their flaws took a median of 32 days to fix, with only about 54% fully remediated during the year. In France, the 2025 barometer of CESIN, the French association of information security experts, ranks flaw exploitation second among the attack vectors cited by affected companies (41%), behind phishing (55%).

Volumes are soaring. NIST says CVE submissions grew by 263% between 2020 and 2025. Its National Vulnerability Database (NVD), which enriches each CVE with the data scanners rely on, has not kept up: in April 2024 the SANS Internet Storm Center reported that, since 12 February, enrichment of new CVEs had nearly stopped, leaving tools blind to part of the recent flaws. Since 15 April 2026, NIST only prioritises enrichment for KEV-listed flaws, flaws in software used by the federal government and flaws in software deemed critical.

Europe is organising. ENISA, the EU cybersecurity agency, opened its own database, the EUVD, on 13 May 2025, as provided for by the NIS 2 directive. It reuses CVE identifiers, adds its own and offers views of critical flaws, exploited flaws and those coordinated by the European CSIRTs network. The practical lesson: do not depend on a single data source, and check what your detection tool relies on.

• NIS 2. Article 21 of the directive requires essential and important entities to take risk management measures, including security in the acquisition, development and maintenance of systems, "including vulnerability handling and disclosure". For certain digital entities (cloud providers, data centres, managed service providers among others), Implementing Regulation (EU) 2024/2690 spells it out in point 6.10 of its annex: obtain information on vulnerabilities, run regular scans, address critical flaws without undue delay, link the process to change, patch and incident management, and document the reasons when a flaw is not fixed. Our article on the NIS 2 directive covers the wider picture.
• ISO 27001 and ISO 27002. Control 8.8 of ISO/IEC 27002:2022, "management of technical vulnerabilities", asks organisations to obtain information on vulnerabilities, evaluate their exposure and take appropriate measures. An ISO 27001 auditor checks that it is applied and evidenced.
• Cyber Resilience Act. For manufacturers of digital products, the CRA requires vulnerability handling throughout the support period and, since 11 September 2026, reporting of actively exploited vulnerabilities. For buyers, it is leverage to require a clear policy from suppliers, as part of third-party risk management.