Vulnerability management is the discipline of finding weaknesses in your environment and closing them before somebody else uses them. Almost every organization does the finding. Rather fewer do the closing at a rate that keeps pace with the finding, and the gap between those two rates is the backlog that eventually shows up in an audit or an incident.
This article describes the full lifecycle, the places it usually breaks, and what has to be in place for it to be a program rather than a recurring report.
The lifecycle
Six stages, run continuously rather than in a campaign: discover, assess, prioritize, remediate, validate, monitor. The stages are unremarkable. What distinguishes organizations is which ones they actually complete.
Most complete discovery and assessment. Many complete prioritization. Fewer complete remediation at the rate new findings arrive. Very few complete validation, which is the stage that proves a fix worked. And monitoring, the stage that catches regression, is the one most often assumed rather than performed.
Discover: knowing the surface
Discovery covers scanning, but scanning is not the whole of it. A scan tells you about the assets it was pointed at. The vulnerabilities that cause incidents are disproportionately on assets nobody pointed a scanner at: the forgotten test environment with production data, the appliance whose management interface is reachable, the departmental cloud subscription, the supplier connection.
So discovery has two halves. Authenticated scanning of the known estate, which produces depth, and asset discovery across the network and the cloud tenancies, which produces coverage. An organization with excellent depth and poor coverage will report a healthy posture and be wrong.
Coverage also has to include the software inside the applications. Dependencies and libraries carry vulnerabilities that no host scan will surface, which is why software composition matters wherever the organization builds or maintains anything.
Assess: what the finding actually means here
A raw finding is a statement about a piece of software, not about your organization. Assessment is the step that translates one into the other, and it is where a scanner's output becomes usable.
The questions are practical. Is the vulnerable component actually reachable, and from where. Is the vulnerable function actually in use. What compensating controls sit in front of it. What would an attacker gain by using it, given where that asset sits and what it can reach.
Two findings with identical severity scores can differ by orders of magnitude once those questions are answered. Skipping this step is what produces the unmanageable backlog: everything is critical, so nothing is.
Prioritize: severity is not the same as urgency
This is the stage that most changes outcomes, and the one most often delegated to a number.
A severity score describes how bad a vulnerability would be if exploited. It says nothing about whether anyone is exploiting it. Sorting a queue by severity alone reliably puts theoretical problems above the ones currently being used against organizations like yours.
The correction is to bring real world exploitation into the ordering. CISA maintains a catalog of vulnerabilities with confirmed exploitation and is explicit about how to use it: organizations should use the KEV catalog as an input to their vulnerability management prioritization framework. As an input, not as the whole ordering. A vulnerability on an internet facing system, with known exploitation, and no compensating control, is a different class of problem from one that is merely severe.
The other input is your own environment: asset criticality, data sensitivity, exposure, and whether the system is one the business cannot tolerate losing. That information comes from the work described in cybersecurity risk assessments.
Remediate: patching, and the things that are not patching
Most remediation is patching, and patching is an operational discipline with its own planning problem. NIST devotes a publication to it, filed under the keywords enterprise patch management; patch; risk management; update; upgrade; vulnerability management. The framing is deliberate: patching is a risk management activity that happens to be delivered through operations, not a maintenance chore that happens to reduce risk.
The practical obstacles are consistent across organizations. Patching requires downtime that has to be scheduled against the business. It carries its own risk of breaking something. It depends on a vendor having shipped a fix. And it is nobody's whole job.
A working program answers each of those in advance rather than per incident: a standing maintenance window, a tested rollback, a defined emergency path for the cases that cannot wait, and a named owner. The parts that are not patching matter too, because a large minority of findings are configuration rather than version: an exposed management interface, a default credential, a permissive rule, a deprecated protocol still enabled. Those are covered in security hardening and configuration management.
Where remediation is genuinely not possible, for a system that cannot be patched or a fix that does not exist, the answer is a compensating control and a recorded acceptance, not silence.
Validate: the stage almost everyone skips
An item is not closed because a change was made. It is closed when the change has been shown to have worked, which in practice means rescanning the asset, or retesting the specific condition, and recording the result.
Skipping validation produces a particular and expensive failure: a remediation queue that empties on paper while the environment stays vulnerable. Patches that did not apply, that applied to the wrong host, that were reverted by a subsequent deployment, or that required a restart nobody performed are all common and all invisible without validation.
Monitor: catching the regression
Environments move. A hardened image drifts, a new host is built from an old template, a container is rebuilt from a stale base, a rule is relaxed during an incident and not restored.
Monitoring is what turns a point in time result into a maintained state. It is the same discipline described in continuous security and compliance monitoring, applied to this particular surface, and it depends on the telemetry discussed in security monitoring and incident detection.
Exceptions, and why they are the real health indicator
Every environment has vulnerabilities that will not be fixed on schedule. That is not a failure. Pretending otherwise produces a program that lies.
What matters is the shape of the exception register. A healthy one has an owner per entry, a stated compensating control, an expiry date, and evidence that expired entries are actually revisited. An unhealthy one is a list of permanent exclusions whose original reasoning has left the organization.
If you assess one thing about a vulnerability management program, assess this. The scan results tell you about the tooling. The exception register tells you about the management.
Scanning without breaking things
A recurring objection to authenticated scanning is that it has caused an outage, and the objection is usually founded. Scanners probe services in ways ordinary traffic does not, and fragile systems do fall over.
The answer is not to scan unauthenticated, which trades an outage risk for a blindness that lasts. It is to treat scanning as a change: a maintenance window for the first authenticated pass against a sensitive system, a documented owner contact, throttling on constrained networks, and an agreed exclusion list for equipment that genuinely cannot tolerate it, with a compensating review in its place.
Operational technology and medical devices deserve particular care. Those estates frequently cannot be scanned in the usual way at all, and the correct treatment is passive discovery plus vendor advisories rather than an aggressive probe that risks patient or plant safety. Recording that decision, with its reasoning, is what keeps it a considered exclusion rather than a hole.
Metrics worth reporting
Counts of vulnerabilities found are a measure of scanning, not of security. More useful: the age of the oldest open critical finding, the proportion of critical findings remediated inside the agreed window, the proportion of the estate covered by authenticated scanning, the number of exceptions past review, and the proportion of closed findings that were validated.
Those five are readable by an executive and checkable by an auditor, and all of them get worse when the program stops working, which is precisely what a metric is for.
Running it as a service
Vulnerability management is one of the clearest cases for a managed service, because it fails through discontinuity rather than through difficulty. Nothing in the lifecycle is conceptually hard. All of it stops the moment the responsible person is busy with something more urgent, and there is always something more urgent.
LABUSA runs discovery, prioritization, remediation tracking and validation as part of the managed cybersecurity service, within the wider cycle set out in the managed cybersecurity lifecycle. Where the first requirement is a point in time picture rather than an ongoing service, that is an assessment, delivered through cybersecurity and risk management.
Sources
- CISA, Known Exploited Vulnerabilities Catalog.
- NIST, Guide to Enterprise Patch Management Planning, SP 800-40 Rev. 4.
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024.