Vulnerability Management Is a Decision, Not a Dashboard

Vulnerability management is the continuous process of finding security weaknesses, deciding which ones matter, fixing them, and checking the fix held. Most businesses that say they “do” it actually mean something much smaller. They bought a scanner, glance at the dashboard occasionally, and treat a shrinking red number as proof of progress.

A dashboard is not a programme

A scanning tool finds flaws. It does not decide which ones matter, chase the fix, or check the patch actually worked six weeks later. That work is vulnerability management, and it is a process a person runs, not a feature a vendor ships. Buy the best scanner on the market. You still have nothing until someone owns what happens after it finds something.

NCSC’s own definition backs this up. Its guidance calls for organisations to “understand, and validate on a regular basis, which vulnerabilities are present in your technical estate”, and to actively cut the impact of what cannot be fixed straight away. Validate is doing a lot of work in that sentence. A scan result nobody checks against reality validates nothing at all.

What the process actually involves

Strip away the marketing and NCSC’s guidance boils down to five repeating steps. Identify every asset and who owns it. Scan and assess against known flaws. Triage each finding by real business impact. Remediate through a patch or a compensating control. Then verify the fix, and revisit the whole process as the estate changes.

Miss the last step and the programme quietly rots. Nobody notices the new cloud service or forgotten test box that joined the network six months ago.

The CVSS trap

A vendor advisory lands with a severity number attached. It is tempting to let that number make the decision for you. NCSC disagrees openly. A score “may help inform prioritisation”, but “it’s essential that you consider business impact and risk for your organisation” alongside it. A critical score on an isolated test box is not the emergency a medium score on your public login page is.

We have already documented what happens when a business skips that step. A vendor rated an actively exploited bug as medium severity, while independent scoring put it near the top of the chart, covered in our piece on trusting vendor severity ratings. A prioritisation process that only reads the vendor’s number inherits every blind spot the vendor has. Having a shared reference for how CVSS scoring actually works gives the team a starting point for weighing severity beyond one number.

The deadlines almost nobody hits

Here is what surprises most business owners: NCSC does not leave the timeline vague. Its baseline policy sets internet-facing services at 5 days. Operating systems and applications get 7 days, and internal or air-gapped systems get 14 days, applied “regardless of the vulnerability severity”. Ask most SMEs how their patch cycle actually runs and the honest answer is monthly, or whenever IT finds a gap in the diary. That gap between guidance and practice is precisely where breaches happen.

When a flaw is under active exploitation and lands on CISA’s Known Exploited Vulnerabilities catalogue, the clock compresses hard. An internet-facing system where exploitation can be automated, and hands over full control, gets under 24 hours. The same without automation gets 48 hours. A non-internet-facing system with automatable exploitation gets 72 hours. NCSC’s own words leave no ambiguity: “every hour that passes without the update being applied increases the chance of a compromise”.

Somebody has to own “not yet”

Sometimes a patch genuinely cannot go on this week. A legacy system might break, or a vendor might not have shipped a fix. NCSC’s answer to who signs off on that gap is unambiguous. “The decision not to fix an issue is, at root, a senior-level business risk decision, not an IT problem”. If a patch quietly slips and nobody above IT ever agreed to that risk, the business has a governance failure dressed up as a technical delay.

Put it on a risk register that a director actually reads on a fixed schedule, then review it every quarter rather than once a year. The excuse stops being invisible once someone senior has to look at it.

Legacy systems: the excuse that never expires

Every estate has one system too old to patch cleanly. NCSC’s advice is not to wait for a full replacement before doing anything. Segregate it from the rest of the network, watch it more closely than everything else, and keep patching the systems that can be patched on schedule regardless. One stuck legacy box is not a reason to let the whole programme drift, since attackers rarely limit themselves to your oldest system.

Where this sits next to an assessment, a pentest, and CTEM

A vulnerability assessment is a project that ends in a report. A penetration test goes further, with a person actively trying to exploit what the report found. Vulnerability management is neither. It is the standing process that decides when to run both, and tracks what they turn up for years. It makes sure fixes land, instead of gathering dust in a spreadsheet.

Continuous threat exposure management, or CTEM, widens that same idea further still, adding exposed assets and misconfigurations to the picture and a step that checks whether each finding is genuinely exploitable before it reaches the fix queue.

Run any one of these alone and you get a gap. Vulnerability management without independent testing misses the chained misconfigurations only a determined person finds. A test without ongoing management catches a snapshot and lets everything drift afterwards. Already scanning, but want an honest outside read on what it might be missing? Get in touch with Aardwolf Security. We will tell you plainly whether a test would add anything right now.

Frequently asked questions

Is buying a vulnerability scanner the same as having vulnerability management?

No. The scanner is one tool inside the process. Vulnerability management is the ongoing work of triaging what it finds, chasing fixes, and checking they held.

What is a realistic patch deadline for a small business?

NCSC’s baseline is 5 days for internet-facing services, 7 days for operating systems and applications, and 14 days for internal systems. That tightens sharply when a flaw is under active attack.

Who should sign off when a patch cannot go on time?

Someone above IT. NCSC treats it as a business risk decision, rather than a purely technical one, and it belongs on a register a director actually reviews.

Does vulnerability management replace penetration testing?

No. It handles known, disclosed flaws efficiently, but rarely catches a chain of small misconfigurations. Those only become dangerous when a person deliberately strings them together.

How is this different from continuous threat exposure management?

CTEM covers a wider surface, including misconfigurations and exposed assets. It adds a step that validates whether a finding is genuinely exploitable in your specific environment before it reaches the fix queue.