What continuous vulnerability management actually means
Continuous vulnerability management means deciding, every day, which of the vulnerabilities in your estate are worth acting on today, not scanning more often. The distinction matters because the list of what is dangerous changes daily even when your systems do not. In 2025, 49,972 CVEs were published. Fewer than four in a thousand are known to have been exploited.
Getting that ratio right is the whole job.
The arithmetic nobody puts in the proposal
Three numbers, all checkable:
Every mark is roughly 50 CVEs; the whole field is the 2025 population. The four in purple are the exploited share. Severity-ordered patching works this field left to right.
The KEV catalogue held 1,685 entries in total as of 27 August 2026, covering every year since the catalogue began. 352 of them, 21%, are linked to known ransomware campaigns.
If you patch by CVSS severity alone, you are working a queue of thousands to reach the couple of hundred that attackers actually use. If you patch only what is in KEV, you are working from a list that is deliberately conservative and always slightly behind. Neither is a strategy on its own, and a provider who describes one of them as “risk-based” is describing a filter, not a process.
Why “continuous” is about the decision, not the scan
Here is the part that quarterly scanning cannot solve.
Of the 245 vulnerabilities added to the KEV catalogue during 2025, 55 were disclosed before 2024. The oldest was CVE-2007-0671, a Microsoft Office flaw from 2007, added in August 2025, eighteen years after disclosure.
Nothing on the estate changed across that span. The vulnerability became urgent because the outside world moved.
Nothing changed on the estates running that software. What changed was the outside world: someone weaponised it, or a toolkit picked it up, or a ransomware crew added it to their kit. A vulnerability you correctly deprioritised in March can be the one being exploited at scale in September, and no scan of your own systems will tell you that, because your systems did not change.
That is the argument for continuous management, and it is not the argument usually made. The usual pitch is “scan more often so you find new things faster”. The real case is that your risk picture moves when your estate is completely static, so the assessment has to be continuous even when the scanning is not.
What continuous actually requires
Six things. A provider missing any of them is selling periodic scanning with a subscription attached.
1. Asset discovery that runs by itself. You cannot manage vulnerabilities on assets you do not know about, and the assets you do not know about are disproportionately the exposed ones: a forgotten subdomain, a test environment someone left public, a device that rejoined the network. If the asset list is a spreadsheet someone maintains, the process has already failed. This is also CAF outcome A3.a and it is one of the framework’s binary outcomes: an incomplete inventory is Not Achieved, with no partial credit.
2. Assessment against current threat intelligence, not just current scan data. Two different feeds. The scan tells you what is present; the intelligence tells you what is being used. Continuous means the second one is re-evaluated against your estate constantly, which is how an eighteen-year-old Office bug surfaces as urgent without anything on your network changing.
3. Prioritisation with more than one input. A defensible model combines at least: exploitation status (KEV, or the vendor’s equivalent), exploitation likelihood (EPSS), technical severity (CVSS), and, the one most providers skip, your own asset context. A critical vulnerability on an internet-facing system holding regulated data is not the same finding as the same CVE on an isolated test box, and any tool that scores them identically is giving you a sorted list, not a priority.
4. Remediation timescales that are written down. See the next section; this is where most programmes are quietly non-compliant.
5. Verification that the fix worked. A finding is not closed when a ticket is closed. It is closed when a re-scan confirms it. Ask any provider what proportion of their findings are verified as remediated versus marked remediated. The gap between those two numbers is the honest measure of a programme.
6. A trend you can show a board. Not a count of open findings, which mostly measures how hard you looked. Time-to-remediate, percentage inside SLA, and recurrence rate.
The deadlines that actually apply to you
This is the section worth the most to most readers, because two different UK standards give two different answers and almost everyone assumes the easier one covers them.
Cyber Essentials requires critical and high-severity updates to be applied within 14 days. That is the number everyone knows, and for certification it is the number that counts.
The NCSC’s own best-practice timescales are shorter, and they vary by exposure:
Passing Cyber Essentials on patching means meeting the NCSC’s air-gapped timescale for your internet-facing systems. The purple band is the gap a flat 14-day SLA leaves open on exactly the systems attackers reach first.
Read those two together and the implication is uncomfortable: passing Cyber Essentials on patching means meeting the NCSC’s air-gapped timescale for your internet-facing systems. You are compliant. You are also three times slower than the NCSC’s own guidance on exactly the systems attackers reach first.
That is not an argument against Cyber Essentials; it is the right floor, and the 14-day rule has done more for UK baseline security than any other single control. It is an argument against treating certification as the ceiling. If your remediation SLA is a flat 14 days across the estate, you have adopted a compliance deadline as an engineering standard, and those are different things.
The NCSC is also explicit that all of the above is for business-as-usual only. When a vulnerability is being exploited at scale, “the timelines above are too long”.
What to measure
Four metrics. Everything else is decoration.
- Mean time to remediate, split by exposure tier: internet-facing separately from internal, because a single blended figure hides the problem
- Percentage remediated inside SLA, which is the number that shows whether the SLA is real
- Recurrence rate: findings that come back are a build or image problem, not a patching problem, and no amount of remediation effort fixes them
- Coverage: the proportion of known assets actually being assessed. A programme reporting 100% remediation on 60% of the estate is reporting on the easy 60%
If a monthly report gives you a finding count and a severity pie chart, it is telling you how hard the scanner worked, not how exposed you are.
Where it is mandated
Vulnerability management is not optional in most UK compliance regimes, and the wording differs in ways that matter:
- Cyber Essentials and Cyber Essentials Plus: critical and high-severity updates within 14 days, evidenced. The most common single cause of a Cyber Essentials Plus failure.
- The NCSC Cyber Assessment Framework, outcome
B4.d: “You manage known vulnerabilities in network and information systems to prevent adverse impact on your essential function(s).” Note the framing: manage, not patch. Accepted risk with a documented rationale can satisfy it; an unexamined backlog cannot. If you are going through GovAssure, this sits alongsideA3.aasset management, and the two are assessed together in practice. - ISO 27001: technical vulnerability management is a named control, and auditors increasingly ask for the timescales and the evidence of adherence rather than the policy document.
Continuous versus periodic, honestly
Periodic scanning is not useless, and anyone telling you otherwise is selling something. It is genuinely sufficient in some situations. The distinction:
| Periodic scanning | Continuous management | |
|---|---|---|
| Tells you | Where you stood on the scan date | What is dangerous now |
| Catches newly weaponised old CVEs | No | Yes |
| Handles unknown assets | Only if they existed at scan time | Continuously |
| Effort profile | Spike after each scan | Steady |
| Honest fit | Small, static, mostly internal estates | Internet-facing services, regulated data, change-heavy environments |
If your estate is a dozen laptops and a Microsoft 365 tenant that has not changed in two years, quarterly scanning plus automatic updates is a reasonable answer and you should not be sold anything more. If you run internet-facing services, deploy regularly, hold regulated data, or answer to a supply-chain assurance regime, the periodic model leaves a gap that is measured in months.
A related question, whether you also need penetration testing, is a different one, and we have covered it separately in penetration testing versus vulnerability scanning. Short version: management tells you what is exposed, testing tells you what an attacker can do with it. They answer different questions and neither substitutes for the other.
Questions worth asking a provider
What are your remediation SLAs, by exposure tier? A single flat number means exposure is not part of the model.
What proportion of findings do you verify as remediated by re-scan, rather than mark as remediated?
How does asset context change a score? Ask them to walk through the same CVE on an internet-facing server and an isolated test box.
What happens when a vulnerability already in my estate is added to KEV? The answer should be a process, not a next-scheduled-scan date.
What is my coverage percentage, and how do you know what you are missing?
Who fixes it? Assessment and remediation are frequently sold together and delivered separately. Establish which you are buying.