Vulnerability management is the continuous process of discovering an organization's security weaknesses, deciding which ones really matter, fixing or containing them and verifying that they were closed. It is not a scan, it is not an annual report and it is not the task of applying updates. The patch is one of the possible outputs of the process. The process is what decides which of the 190 vulnerabilities published today deserves someone stopping what they are doing.
It is worth taking seriously for a concrete reason: for the first time since the report has existed, vulnerability exploitation is the most common way in. The Verizon 2026 DBIR places it at 31% of initial access, compared with 20% the previous year, ahead of stolen credentials.
And while that was rising, the ability to respond went down. The same report measured how long organizations take to fix a vulnerability already known to be exploited: the median went from 32 to 43 days. Of the vulnerabilities in the known exploited catalog, only 26% were fully fixed across the 13,000 organizations studied. The previous year it was 38%.
What does the vulnerability management cycle include?
Five stages that repeat forever. The key word is repeat: a cycle that runs once a quarter and stops there is not management; it is an old snapshot.
| Stage | What is done | The typical mistake |
|---|---|---|
| 1. Discover | Know what you have: servers, computers, applications, cloud, network devices, whatever a department installed without notice | Scanning only what is already in the inventory, which is exactly what is already being monitored |
| 2. Prioritize | Rank findings by real risk for this company, not by the severity score | Going after everything “critical” at once and finishing nothing |
| 3. Remediate | Patch, change a configuration, retire the system or contain it with another control | Assuming that remediating and patching are synonyms |
| 4. Verify | Recheck that the fix was applied, that the service was restarted and that the finding disappeared | Closing the ticket when the patch was downloaded, not when the system was clean |
| 5. Measure | Track how long the organization takes to close by risk level and what percentage remains open | Reporting how many vulnerabilities were found, which says nothing about risk |
Stage five is what turns this into a measurable discipline. Without it, nobody can answer the only question a CEO asks: if something serious comes out tomorrow, how many days will it take us to close it?
Why is patching no longer enough?
Because the patch is still necessary and is no longer sufficient, for four reasons that add up.
Volume. In the first half of 2026, more than 35,000 new vulnerabilities were published, an average of close to 190 per day (public metrics from the CVE program). NIST itself acknowledged that vulnerability submissions grew 263% between 2020 and 2025 and changed the way it works in April 2026 to analyze first those that are being exploited. If the organization that catalogs vulnerabilities had to prioritize, it is odd to expect a team of three people to handle them all.
Speed. Here is the real mismatch. The average organization remediates in 43 days. On the other side, a paper by the Cloud Security Alliance published in April 2026, The Collapsing Exploit Window, documents that today functional attack code can be generated for a newly published vulnerability in 10 or 15 minutes and for about one dollar. The same work notes that 32.1% of the new attacks tracked in 2025 appeared on the day of publication or earlier.
What cannot be patched. There is always a part of the inventory where patching is not a short-term option: the system that supports production and can only be stopped in December, the legacy application the vendor no longer maintains, the medical or industrial equipment certified as is, and the cloud service where someone else applies the patch and you can only wait. For all of that, you need something else.
The patch does not close what already happened. Updating the software removes the door, not whoever already came in through it. If the vulnerability was open for six weeks on a device exposed to the internet, after patching there is still a pending question, and that question is answered by detection, not by the patch.
How do you prioritize when you can't fix everything?
With three data points that almost no one looks at together, and that together reduce the list from thousands to dozens.
The first is technical severity, the CVSS score from 0 to 10. It is the most widely used data point and the most misleading, because it describes the vulnerability in the abstract and says nothing about whether anyone is using it.
The second is real exploitation. The CISA KEV catalog lists the vulnerabilities that have been seen used in real attacks. There are hundreds, not tens of thousands. When something enters that list, it stops being a scanner finding and becomes a task with a deadline. The EPSS system, which estimates the probability that a vulnerability will be exploited in the next 30 days, serves the same filtering function.
The third is business context, and it is the one no vendor can give you: where that system is, whether it faces the internet, what data it touches, whether it has two-factor authentication in front of it, whether there is a backup, and what stops if it goes down. The same vulnerability on a test server and on the customer portal is not the same vulnerability.
The practical rule of the four answers
Before moving a finding to the front of the line, ask four questions. If all four answers are yes, it gets fixed this week, not in the next cycle.
- Is it in the known exploited catalog, or is there already public attack code?
- Is the affected system accessible from the internet or from a third party's network?
- Does it touch personal data, money or a process that cannot stop?
- If someone exploited it today, would we see it, or would we find out from the customer?
The fourth question is the one that usually changes the conversation in the committee. A vulnerability with no monitoring on it is not a pending risk; it is an invisible risk.
What do you do when the patch is not available or cannot be applied?
A compensating control is applied, which is the elegant way of saying that if you can't close the door, you put someone in front of it. The four usual options:
- Reduce exposure. Take the service off the internet, restrict it to a list of known addresses or put it behind a VPN. It is the most effective measure and almost always the cheapest.
- Disable the vulnerable feature. Many security advisories indicate which specific module, port or feature can be turned off while the fix arrives.
- Virtual patching. A rule in the firewall or in the intrusion prevention system that blocks the specific attack attempt without touching the application. It buys weeks.
- Enhanced monitoring. Increase logging on that system and alert the SOC that the asset is under watch. It is the minimum acceptable when none of the previous three is possible.
A compensating control is always temporary and always has a review date. When it doesn't, it becomes the permanent configuration and nobody remembers why it exists.
How is it different from a scan or a pentest?
They are three different things and are contracted for different reasons. Vulnerability scanning is an automated tool that compares what it finds against a database of known flaws: it is fast, it is cheap, it can be run every week and it produces a long list. The pentesting is a manual exercise in which a specialist tries to chain several weaknesses together until achieving something real, and finds what no scanner sees, such as a business logic flaw. Vulnerability management is the process that surrounds both: it receives their findings, prioritizes them, assigns them, follows up on them and measures how long it took to close them.
Put another way: the scanner and the pentest produce findings, and findings do not reduce risk. What reduces it is what the organization does with them, which is exactly what is measured with response time and the percentage of critical findings that remain open after thirty days.
Frequently asked questions
How often should you scan?
What is a zero-day vulnerability and does it change the priority?
Is CVSS useful, then?
Who should own the process in the company?
What about vulnerabilities in my cloud software providers?
The list is not the problem
Almost every company we review has the scanner. Very few can say how many days it takes them to close something serious, how many critical findings have been open for more than a month and who signed off on the risks they decided to accept. That difference, between having the list and having the process, is all of vulnerability management.
At ZetTateK we build that process and sustain it: continuous discovery, prioritization based on real exploitation and context, and a SOC 24/7 that monitors what is still open while it is being fixed. If you want to know where to start, the free security assessment tells you what you have exposed today. The other terms in this article are in the cybersecurity glossary.
Patching is a task. Managing vulnerabilities is deciding, every day, what gets fixed first and what gets monitored in the meantime.
