Vulnerability management as an operational function, not an annual project

Vulnerability management is a continuous operational function made up of five components that run afresh every month: current asset visibility, a fixed scanning cadence, prioritisation by exploitability in your own environment, a remediation SLA per risk class, and demonstrable evidence of the time from discovery to closed gap. In practice, in many organisations it becomes something else. It becomes an annual project in which a scanner runs, a report is delivered, a list of vulnerabilities is ticked off, and the work then stalls until the next cycle. The function and the project look alike in form, but they produce opposite results: the function reduces exposure durably, the project records exposure at the moment of the scan and then lets it climb until the next report.

This piece is about that difference. For anyone watching SIEM noise grow, the patch backlog expand and an external audit approach, it is more useful to set up vulnerability management as a function again than to buy yet another scanner. The reporting, dashboards and tooling around it matter only as long as the five components actually run.

Why is an annual scan not vulnerability management?

An annual scan tells you where you stood on the day it ran. After that your environment changes every week: a new application goes live, a server role is adjusted, a supplier rolls out a patch that breaks a dependency somewhere else, a cloud team spins up an environment that is not in the CMDB. Last year's scan says nothing about this week. It says nothing even about the day after it ran, because exploit code for known vulnerabilities circulates within days of publication in a considerable share of cases. Waiting for the next scheduled scan is then not caution; it is an assumption that attackers also keep to your calendar.

The NIST Cybersecurity Framework places this in the Identify and Protect functions for good reason, with explicit guidance in NIST SP 800-40 Revision 4 for designing a continuous patching process. The framework does not speak of an annual cycle. It speaks of continuous identification of assets, ongoing assessment of exposure, and repeatable improvements that are measurable over time. ISO/IEC 27002:2022 does the same in control 8.8 on the management of technical vulnerabilities: the standard requires that information about vulnerabilities is obtained in a timely manner, that exposure is assessed in your context, and that appropriate controls are put in place. Timely and appropriate are terms with a tempo. Once a year is not that tempo.

The difference also lies in what a scan produces. A scan produces a list. A function produces a difference over time. The list holds tens of thousands of findings, with a score per finding, and no ordering by what is actually exploitable in your environment. The function orders that same list against your assets, your attack paths and your exposure to the internet, and then tracks how long it takes for a finding in a given class to be resolved. That second number, the time to remediate, is the real steering instrument. Without it, no one knows whether the function is making measurable progress or losing ground.

What does an operational VM cadence need at a minimum?

A workable setup consists of five components that recur on a fixed cadence. None of these components calls for a new purchase. What they do call for is that they are genuinely owned, that the cadence holds, and that the outcomes land somewhere.

Asset visibility that matches the real environment. Not last quarter's CMDB, but a live picture of what is actually running, including cloud resources, shadow IT and exposed services. In most organisations the gap between the CMDB and reality is the first opening an attacker exploits. Without this component you are scanning a map that no longer holds.

A fixed scanning cadence, differentiated by risk profile. The external perimeter and internet-facing assets more often than internal office systems, critical production more often than secondary environments, and authenticated scans on the systems where that is worthwhile. The cadence need not be complicated. It does need to be explicit, because otherwise it drifts towards zero as soon as the team is under pressure.

Prioritisation by exploitability in your own environment. Not CVSS order as the only steering instrument. Alongside CVSS, FIRST also publishes EPSS, an estimate of the probability that a vulnerability is actually exploited in the coming thirty days. Combined with the CISA Known Exploited Vulnerabilities catalogue and with your own context (does it touch a crown jewel, is it reachable from the internet, is there a working compensating control), this produces an ordering that says where you start today. A high CVSS score on an internal test server with no network path drops down. A moderate score on an exposed service that is on the KEV list rises.

A remediation SLA per risk class, and one that is enforced. This is the component most often skipped and the one that makes the most difference. An SLA agrees in advance within how many working days a finding in a given class must be closed, who owns the closing, and what happens when the deadline passes. Without that agreement every finding is equally urgent on paper and equally deferrable in practice. With it, the conversation shifts from 'do we have to do this now' to 'we agreed this would be done within so many days, so what is the reason it is not'.

Demonstrable time to remediate, not just a count of findings. A report that only states there were X critical findings and Y were resolved misses the steering instrument. The report that says how long an average critical finding stayed open, how that changes per quarter, and in which class the SLA is systematically exceeded does provide steering. That is also the number an auditor, an insurer and the regulator ultimately want to see, instead of a snapshot.

What is not part of this is a second scanner, a separate exposure engine or a dashboard layer on top of what is already there. Those things can add value, but they are not the precondition. The precondition is that the cadence holds, that the owner is known, and that the outcomes land where they should. The Dutch National Cyber Security Centre stresses in its vulnerability management guidance that this is about an established capability, not a tool purchase. ENISA arrives at the same conclusion in successive Threat Landscape reports: the organisations that remediate quickly and demonstrably experience incidents differently from the organisations that scan quickly and demonstrably but close slowly.

How do you know whether the function is running or the project is in disguise?

There is a sober test, and it is not about the scanner. It is about the time to remediate. Ask three things within your own team. What was the average time between a critical vulnerability appearing and its closing, over the past three months. In which class was the SLA under pressure most often, and what was the reason. What percentage of the findings reported as closed returned in the next scan because the fix was incomplete. Three questions, three numbers. If none of the three can be answered, there is no function running. There is a scan-report cycle running, and that is something else.

A second test is about who guards the cadence. A function has an owner who holds the SLA up to the light every week, not someone who merely keeps the scanner running. If that role is not explicitly owned, the cadence falls to zero as soon as an incident, an audit or a release applies pressure. That is not a failure of the team. It is a design flaw: a function without an owner lives on spare capacity, and spare capacity disappears in a busy month.

A third test is about change. Vulnerability management collides with change management by definition, and in many organisations change wins. A critical patch waiting for the next four-week change window is, in practice, an accepted four-week exposure. A working function has an agreed exception path for the small share of findings that cannot tolerate that tempo, with the corresponding risk acceptance explicitly recorded. Without that path, the SLA is a paper agreement that always loses to the change calendar.

What this means for the conversation you hold internally

For the operational lead who opens this conversation internally: the useful summary is that vulnerability management is not a scanner issue and not an annual-project issue. It is a function with five components, each of which has an owner and a cadence. To your CISO, the message is that the steering information does not lie in the number of findings, but in the time to remediate per class and in SLA compliance. That is the number that shows whether the programme is making measurable progress or standing still, and it is precisely the number that, under NIS2 and in a DORA context, produces evidence going beyond a list of closed tickets.

To change management and operations, the message is that the SLA must be agreed in advance and not defended ad hoc. To the supplier doing the outsourced scanning work, the question is not 'how many vulnerabilities do we find' but 'how do I measure that the time to remediate in our environment shortens over time, and who is accountable if it does not'. To the board, when the question comes, the useful line is that you do not report how many findings there were, but how long they stayed open and in which direction that number is moving.

The logical next step is not a quote for a new platform, but a sober inventory of the five components against your current way of working. Do you have live asset visibility or an outdated CMDB. Do you have a differentiated scanning cadence or a single frequency for everything. Do you steer on CVSS or on exploitability in your own environment. Do you have an SLA per class that is enforced, or a list without deadlines. Do you measure time to remediate or do you measure count. Five questions, five answers. Wherever the answer is missing or 'no' lies the conversation you need to hold first, internally and possibly with someone who looks at it independently. Only once those five components are in place does tooling deliver something that rises above the existing process. The other way around, you buy a report and you keep an exposure.