Vulnerability management: prioritising when everything is critical

Scanning is easy. The programme is what happens to the output. A first authenticated scan of a mid-sized estate routinely returns tens of thousands of findings, several thousand rated high or critical, against a team that can realistically remediate a few dozen a week. Everything that matters is in how you choose.

Coverage before severity

Before tuning prioritisation, establish what you are not scanning - because unscanned systems produce no findings and therefore look perfect. The gaps are consistently:

• Systems missing from the asset inventory entirely.
• Unauthenticated scanning only, which sees a fraction of what an authenticated scan sees and produces a falsely reassuring result.
• Container images scanned at build but never re-scanned once running.
• Cloud services and their configuration, which need a different class of tooling.
• Third-party and open-source dependencies inside your own applications.
• Network devices, printers and building systems - rarely patched, frequently exposed.

Report scan coverage next to remediation figures, always. "97% of criticals remediated" means very little if it covers 60% of the estate, and an assessor will ask for the denominator.

Prioritising by exploitability, not just severity

CVSS base scores describe theoretical severity in isolation. They do not tell you whether anyone is exploiting the vulnerability, or whether it is reachable in your environment. Better inputs:

• Known exploited catalogues (such as CISA's KEV) - vulnerabilities with confirmed real-world exploitation. This is the single highest-value filter available, and the list is short enough to act on.
• EPSS - a probability that a vulnerability will be exploited in the near term. It reorders a CVSS-sorted list dramatically, because most high-CVSS issues are never exploited at scale.
• Exposure. Internet-facing outranks internal; internal outranks an isolated segment.
• Asset criticality from your business impact analysis.
• Compensating controls - a vulnerability behind strong segmentation and monitoring carries different urgency.

A practical rule that survives contact with reality: anything on a known-exploited list, on an internet-facing asset, jumps the queue regardless of its CVSS score.

Setting SLAs you can actually meet

Common starting points - critical 7-15 days, high 30, medium 90, low next cycle or accept - with tighter windows for internet-facing assets and actively exploited issues, sometimes 48 hours.

The important discipline is that your published SLA becomes the standard you are audited against. An organisation meeting a 30-day critical SLA consistently is in far better shape than one that publishes 7 days and misses it routinely. Set what you can achieve, measure it, then tighten.

Emergency patching needs its own path: a defined trigger, an accelerated change route, and an accepted level of testing. Deciding this during an active exploitation event guarantees a bad outcome.

The findings you will not fix

Some vulnerabilities cannot be remediated in a reasonable timeframe - unsupported systems, vendor-dependent fixes, applications that break on patching. These belong in the exception process with a documented risk acceptance, compensating controls and an expiry date, not in a backlog that silently ages.

Watch for the honest failure mode here: a backlog of thousands of untriaged medium findings is not a risk decision, it is an absence of one. Either triage them, accept them explicitly as a class, or tune them out of reporting with a documented rationale.

Metrics worth reporting

• Scan coverage - percentage of the inventory scanned, and authenticated versus not.
• Mean time to remediate by severity, trended.
• SLA compliance rate, which is the metric auditors actually want.
• Open criticals over SLA, with age - the number that should be reported to leadership.
• Recurrence. The same vulnerability reappearing points at a rebuild process reinstating an unpatched image, which is a different problem entirely.

What auditors ask for

A documented policy with defined SLAs; scan reports across the period showing coverage; evidence of remediation within SLA for a sample; the exception register for what was not fixed; and evidence that results are reported to management. The request that catches people out is the historical one - proving remediation happened on time months ago, which requires the ticket trail to have been kept.

Key takeaways

• Report coverage beside remediation - unscanned systems look perfect.
• Prioritise by known exploitation and exposure, not CVSS alone.
• Publish an SLA you can meet; it becomes your audit standard.
• Untriaged backlogs are not risk acceptance - decide explicitly and document it.