Services / Continuous Operations
Vulnerability Management
A patch SLA you can evidence, and a backlog that actually goes down.
The problem
A scanner produced 4,000 findings. Nobody has looked at them since. The auditor wants to see a remediation SLA and evidence that you meet it, and your engineers want to know which twelve of the four thousand actually matter this week.
The method.
Scan the estate that exists, not the one you documented
Authenticated scanning of servers and endpoints, cloud workload and container image assessment, and continuous external attack surface discovery so internet-facing assets nobody registered are scanned too. Coverage is reconciled against the asset inventory, because an unscanned asset is not a clean asset.
Prioritise by exploitability and exposure, not by CVSS alone
A CVSS 9.8 in a library that is never loaded, on an internal host with no path from the internet, outranks nothing. Priority is driven by whether the vulnerability is known-exploited (CISA KEV), its EPSS probability, whether the asset is internet-facing, and whether it touches personal or regulated data. This is what turns 4,000 findings into the dozen that matter this week.
Set an SLA per severity and wire it to the tracker
Critical and known-exploited: the shortest SLA. High: a defined window. Medium and low: the next maintenance window. Findings become tickets in the tracker engineering already uses, with the SLA clock attached, because a vulnerability that lives only in a scanner console is a vulnerability nobody will fix.
Manage exceptions instead of pretending they do not exist
Some things cannot be patched: a legacy dependency, a vendor appliance, a system awaiting decommission. Each gets a documented exception with a compensating control, a named accepting owner and an expiry date. Auditors accept a well-managed exception; they do not accept a silently overdue finding.
Verify the fix and report the trend
Re-scan to confirm remediation rather than trusting the ticket. Report on SLA compliance, mean time to remediate by severity, and the age of the open backlog, which is the metric that tells you whether the process is working or merely running.
What is vulnerability management?
Vulnerability management is the continuous process of discovering vulnerabilities across all assets, prioritising them by real risk, remediating them within defined service levels, documenting exceptions with compensating controls, and verifying fixes by re-scanning. It is a process, not a scanner: the scan produces findings, the process produces reductions.
How should vulnerabilities be prioritised?
By exploitability and exposure, not by CVSS score alone. The decisive factors are whether the vulnerability is known to be exploited in the wild (the CISA KEV catalogue), its EPSS exploit-probability score, whether the affected asset is reachable from the internet, and whether it holds personal or regulated data. This is what reduces thousands of findings to the handful that require action now.
What patching SLA do auditors expect?
Auditors do not mandate a specific number; they require that you define an SLA per severity, that it is proportionate to your risk, and, most importantly, that you can evidence meeting it. A documented 30-day critical SLA that is consistently met is stronger than a 7-day SLA that is routinely breached, because the second one is a policy commitment in breach.