What Is Vulnerability Management?

Vulnerability management is the programme that runs after the scan: assigning findings to owners, tracking them to closure, handling the ones that cannot be fixed, and demonstrating that the whole thing is working.

The scanning and prioritisation side is covered under vulnerability assessment. This is the part that determines whether any of that produces change, and it is where most programmes stall.

Findings need owners, not distribution lists

A report sent to a team is not an assignment. Each finding needs a named person accountable for resolving it and a date by which it should be resolved, tracked in whatever system that team already works from.

Where findings live only in the security tool, they are the security team's backlog rather than the owning team's. That distinction predicts closure rates more reliably than severity does.

The exception process is the programme

Some vulnerabilities cannot be remediated on any reasonable timeline: the vendor has no fix, the system cannot be taken down, the application breaks under the patched library, the device is medical equipment under a regulatory certification.

A programme without a route for those either stops functioning or starts lying. What is needed is a documented exception: the reason, the compensating control, an owner, an expiry date, and an approval at a level appropriate to the risk. Exceptions that never expire are just unremediated findings with paperwork.

Verification, because reported is not fixed

Remediation marked complete and never rechecked is a common source of quiet failure. Patches roll back, systems get rebuilt from old images, configuration changes are reverted during troubleshooting.

Rescanning to confirm closure, rather than accepting a ticket status, is what makes the numbers mean something. It also regularly finds that a fix applied to one instance was never applied to the other six.

What the scanner cannot reach

Devices that cannot be scanned safely, systems nobody has credentials for, equipment owned by other departments, and anything a third party operates on your behalf. Those gaps are not recorded as findings because they produce no findings.

Reconciling the scanned inventory against the asset inventory is how they surface. It is usually where the most serious exposure sits, precisely because nothing has been looking at it.

Reporting that leadership can act on

Raw counts are not informative and move with scanner coverage rather than with risk. Ageing — how long critical findings have been open — and trend over time say something.

So does the proportion of findings closed within their target window, broken down by owning team, because that identifies where the process is failing rather than merely that it is.

Meeting development teams where they work

Findings in application dependencies and container images arrive in volume and belong to development teams who work from their own backlog. Delivered as a security report they compete with feature work and lose; delivered as issues in the repository, with the offending dependency and the version that fixes it, they get handled like any other defect.

The same principle applies to infrastructure findings. The closer a finding sits to the tooling the owning team already uses, the shorter its life — which is an argument about integration rather than about severity scoring.

Where to start

Take your oldest open critical findings and establish who owns each one. Where the answer is unclear or is the security team, that is the reason they are still open.

See a healthcare remediation programme and vulnerability assessment. GuardsArm delivers vulnerability scanning.