What are the stages of the vulnerability management lifecycle?

Asset inventory, discovery and assessment, prioritization, remediation, verification, and reporting. The cycle then repeats continuously rather than running as a project. The stages that get most attention are discovery and remediation; the stages that most often determine whether the program works are inventory at the start and verification at the end.

Is vulnerability management the same as patch management?

Patching is one remediation option among several. A vulnerability can be remediated by a patch, by a configuration change, by removing the affected software, by isolating the system, or by accepting the risk with a documented expiry. Patch management is the operational discipline of deploying updates; vulnerability management is the decision process about what needs to change and in what order.

Should I patch everything with a CVSS score above 7?

That rule generates a queue most organisations cannot clear, and it spends effort on vulnerabilities that will never be attacked. CVSS measures the severity of the impact if a vulnerability is exploited. It says nothing about whether anyone is exploiting it. Combining it with CISA's KEV catalogue, which lists confirmed exploitation, and EPSS, which estimates near-term exploitation probability, produces a much smaller queue with far better coverage of what actually gets attacked.

What is the difference between an authenticated and an unauthenticated scan?

An unauthenticated scan probes from the network and infers what is running from banners and responses, which is the attacker's view and is shallow and prone to false positives. An authenticated scan logs in with credentials, or an installed agent reads the system directly, and enumerates installed packages, versions and configuration. Authenticated scanning finds far more and produces far fewer false positives, at the cost of managing scanning credentials, which are themselves a high-value target.

How long should remediation take?

Set the target from exploitation evidence and exposure rather than from severity alone. A common shape is days for anything on the KEV catalogue on an internet-facing system, a couple of weeks for high-probability findings on exposed assets, a monthly cycle for internal systems, and the next scheduled maintenance window for everything else. The US federal standard is a useful reference point. BOD 22-01 set a flat clock of two weeks for KEV entries with CVEs assigned in 2021 or later and six months for older ones; BOD 26-04, issued on 10 June 2026, revoked it and replaced the flat timelines with deadlines derived from risk factors including whether the asset is publicly exposed and whether the CVE is on KEV, running from three days for the most dangerous combinations to deferral for the lowest.

What do I do about a vulnerability with no patch?

Reduce exposure while you wait. Remove the service from the internet, restrict access by network rule to the addresses that need it, disable the vulnerable feature or module, add detection for the exploitation pattern, or take the system out of service if it is not essential. Record it as an accepted risk with a named owner and a review date, and make sure the review actually happens when the patch ships.

The Vulnerability Management Lifecycle: From Scan to Verified Fix

Every organisation runs a vulnerability scanner and every organisation has a backlog. The scanner reports tens of thousands of findings, the team fixes some of them, the number goes up again next month, and nobody can say whether the program is working.

The problem is rarely the scanner. It is that the six stages around the scan are uneven: the asset inventory is incomplete, so findings exist on systems nobody knows about; prioritization is by severity, so the queue is unclearable; remediation has no owner outside the security team; and verification never happens, so findings marked fixed reappear.

This guide covers the lifecycle stage by stage, with the prioritization math in the middle, because that is the stage where most programs are losing.

Scope: CVSS Explained owns the scoring system, EPSS Explained owns the exploitation probability model, The CVE System Explained owns identifiers, and KEV Catalog Explained owns the exploited-in-the-wild list. This page owns the process that consumes all four.

The six stages

Stage	The question it answers	The usual failure
Inventory	What do we have?	Incomplete, and unaware that it is
Discovery	What is wrong with it?	Unauthenticated scanning that sees a fraction
Prioritization	What do we fix first?	Sorting by CVSS and producing an unclearable queue
Remediation	Who fixes it, and by when?	No owner outside security, no SLA
Verification	Did the fix work?	Skipped, so findings recur
Reporting	Is the program improving?	Counting open findings, which measures the scanner

1. Inventory

A vulnerability program can only cover the assets it knows about, so the inventory is the ceiling on everything downstream.

What belongs in it: servers and workstations, network devices, cloud instances and managed services, containers and the images they come from, SaaS applications, code dependencies, and the things people forget, meaning build agents, test environments, appliances, printers, cameras and whatever the marketing team stood up on a corporate card.

The hard part is that the inventory is never finished. Cloud resources appear and disappear in minutes, containers live for hours, and a static asset list is stale the day it is written. Practical approaches:

Multiple discovery sources reconciled, since each one is blind somewhere. Cloud provider APIs, EDR enrolment, identity provider device records, DHCP and DNS records, network scans, and the CMDB all disagree, and the disagreements are the interesting part.
Ownership recorded per asset. A finding with no owner cannot be assigned, and it will sit in the queue until it is closed as stale.
Criticality recorded per asset. Prioritization needs it, and there is no way to derive it from a scan.
Exposure recorded per asset. Whether the thing is reachable from the internet changes the risk of every finding on it by an order of magnitude.

2. Discovery

Finding what is wrong takes more than one technique, because each sees a different slice.

Network scanning, unauthenticated. Probes services, reads banners, infers versions. This is the attacker's outside view and is worth having for exactly that reason. It also produces the most false positives, since a back-ported security fix in a distribution package leaves the version string looking vulnerable when it is not.

Authenticated or agent-based scanning. Logs in, or runs locally, and reads the installed package list and configuration. Far more complete and far more accurate. The cost is credential management: scanning credentials are privileged accounts that touch every system in the estate, which makes the scanner itself a high-value target that deserves the controls in Privileged Access Management Explained.

Software composition analysis. Dependencies in application code, where most modern vulnerability exposure now lives. This produces an SBOM, and the SBOM is what lets you answer "are we affected" on the day a widely used library has a critical finding, without spending three days grepping repositories.

Container and image scanning. In the registry and in the pipeline, because a running container cannot be patched in place: the image is rebuilt and redeployed.

Cloud posture assessment. Misconfigurations are the cloud equivalent of vulnerabilities and no CVE covers them. Cloud Misconfigurations covers that class.

Penetration testing and bug bounty. Finds logic flaws and chained weaknesses no scanner produces. Different tool for a different question, covered in Bug Bounty Getting Started.

3. Prioritization

This is where the program is won or lost.

Sorting by CVSS base score and treating everything at or above 7.0 as mandatory generates a queue with tens of thousands of items for a mid-sized estate. Most of those will never be exploited by anyone. Meanwhile a medium-severity finding on an internet-facing system with a public exploit and active scanning is buried somewhere in the middle of the list.

The three inputs are different questions:

CVSS asks how bad it would be if this were exploited. It is a severity model.
EPSS asks how likely exploitation activity is in the next 30 days, expressed as a probability from a model trained on observed exploitation. It is a likelihood model.
KEV asks whether exploitation has already been observed. It is evidence rather than a model, and where an entry exists it outranks the other two.

To those, add the two facts only you have:

Exposure. Internet-facing, internally reachable, or isolated.
Asset criticality. What breaks, and who is affected, if this system is compromised.

A workable ranking, in order:

On KEV, and internet-facing. Emergency. Days, not weeks.
On KEV, internal. Next cycle at the latest, and sooner on a critical system.
High EPSS, internet-facing. Elevated probability of near-term exploitation on a reachable target.
Critical CVSS on a critical asset, even with low EPSS, because impact matters where the asset does.
Everything else, on a routine cycle.

The reason this beats severity sorting is arithmetic. The proportion of published vulnerabilities that ever see exploitation is small, and a severity-only rule cannot distinguish that small set from the rest, so it spends the team's capacity uniformly. Adding exploitation evidence concentrates the same capacity where attacks happen.

Two cautions. EPSS moves: a score is a snapshot, and a proof of concept published on Tuesday changes it. Re-score continuously rather than at ticket creation. And EPSS says nothing about your environment, so a high score on a system nobody can reach still ranks below a moderate score on a public one.

4. Remediation

Patching is one option. The full set:

Patch or upgrade. The default.
Configuration change. Disable the vulnerable feature, module or protocol. Often faster than a patch and sometimes permanent.
Compensating control. Restrict access by network rule, put the service behind authentication, take it off the internet, add a virtual patch at a WAF, or add detection for the exploitation pattern. Reducing exposure while waiting for a vendor is a legitimate outcome rather than a failure.
Removal. The software nobody uses is the easiest fix in the catalogue.
Accepted risk. With a named owner, a stated reason, and an expiry date that triggers a review.

What makes this stage work is boring process. Findings route to the team that owns the system rather than accumulating with the security team. SLAs are agreed in advance and tied to the prioritization tiers. Maintenance windows exist. There is a documented emergency path for the KEV-on-internet-facing case that does not require waiting three weeks for a change advisory board.

The most common structural failure here is a security team that owns the findings and has no authority over the systems, filing tickets into queues that nobody is measured on. The fix is organisational: remediation targets belong to the owning teams, with security reporting on compliance.

5. Verification

A ticket closed is a claim. A rescan is evidence.

Verification catches several distinct failures. Patches that were installed and require a reboot nobody performed. Fixes applied to one of six hosts in a load-balanced pool. Configuration changes reverted by the next configuration management run. Container images rebuilt without pulling a fresh base layer. And plain optimism, where the ticket was closed because the change was scheduled rather than completed.

Verification also produces the metric that says most about program health: the recurrence rate. A finding that is fixed and returns points at a process problem, usually a gold image or a base container that still contains the vulnerable package, so every new instance ships it again. Fixing the image fixes the recurrence permanently, and no amount of remediation on the instances will.

6. Reporting and metrics

Counting open findings measures how much the scanner found, which is mostly a function of how much you scanned. Better questions:

Mean time to remediate, split by priority tier. This is the program's speed.
SLA compliance, the percentage of findings closed inside their tier's target. This is the program's reliability.
Coverage, the percentage of known assets scanned in the last cycle, and the percentage scanned with credentials. This bounds everything else.
Recurrence rate, findings that return after being verified fixed. This points at images and pipelines.
Aging distribution, how long open findings have been open per tier. A stable count with a growing age is a program falling behind while looking flat.
KEV exposure, the count of assets carrying an entry from the catalogue. Small enough to be actionable and the closest available proxy for real risk.

Report the trend rather than the snapshot, and report it to the teams that own the systems as well as to the executives, because the owning teams are the only ones who can move it.

Where programs stall

No inventory. Everything downstream inherits the gap, and the systems missing from the inventory are disproportionately the neglected ones.

Prioritization by severity. Produces an unclearable queue, which produces learned helplessness.

Security owns remediation. A team with no change authority filing tickets is a reporting function.

No exception process. So exceptions happen informally and invisibly, and nobody revisits them.

Scanning credentials treated casually. A privileged account on every host, often with a static password, sometimes in a config file.

No verification. The backlog contains work already done and work never done, mixed together, and nobody can tell which is which.

The verdict

The lifecycle is not complicated: know what you have, find what is wrong, fix the things most likely to be attacked first, prove they are fixed, and measure the speed rather than the count.

The single change that most improves an existing program is replacing severity-based prioritization with evidence-based prioritization. KEV first, then exploitation probability weighted by exposure, then impact on critical assets. That turns a queue nobody can clear into a queue that maps onto what attackers actually do, and it makes the rest of the lifecycle worth running.