Running a scanner and calling it "vulnerability management" is one of the most common — and most dangerous — shortcuts in enterprise security. A scan produces an inventory of flaws. Managing vulnerabilities means turning that inventory into reduced risk: prioritising what actually matters, fixing it, proving it was fixed and evidencing the whole cycle. The gap between the two is where breaches happen.
At a glance
- Scanning: detection. Produces a list of potential weaknesses.
- Management: the full loop — scope, prioritise by real risk, remediate, verify, evidence.
- Why now: exploitation windows have collapsed; a monthly list is not a strategy.
- Compliance: under ENS, NIS2 and ISO 27001, vulnerability management is also evidence, not just hygiene.
The common error: mistaking a list of flaws for reduced risk
A scanner is a detection tool. It tells you what might be wrong; it does not decide what to fix first, coordinate the fix, confirm it worked, or leave an audit trail. Treating the scan report as the deliverable leaves the real work — the risk reduction — undone.
Why "scan and done" is more dangerous than it used to be
The window between a vulnerability becoming public and being exploited has narrowed to hours in the worst cases. A list refreshed monthly, worked through whenever someone has time, cannot keep up with that pace. Management — a continuous loop with owners and deadlines — can.
CVSS helps, but it does not decide alone
A CVSS score measures theoretical severity, not your risk. A "critical" on an isolated internal box may matter less than a "high" on an internet-facing service that is being actively exploited. Real prioritisation combines severity with exposure and exploitation signals such as CISA's KEV catalogue and EPSS probability.
Perimeter devices: very little room to react
Internet-facing appliances — firewalls, VPNs, remote-access gateways — are attacked within hours of a flaw going public and often cannot be patched without downtime. They deserve their own fast lane in any serious process, with compensating controls ready when an immediate patch is not possible.
ENS, NIS2 and ISO 27001: vulnerability management is also evidence
NIS2, Spain's ENS and ISO 27001 all expect a managed, demonstrable vulnerability process — not a folder of scan exports. Auditors want to see prioritisation criteria, owners, remediation deadlines and verification. In other words, the management loop is itself the evidence.
What a serious vulnerability management process includes
Done properly, the process runs as a continuous loop: a clear asset inventory and scope; recurring detection tuned to the environment; prioritisation by real risk, not raw score; an operational backlog with named owners; remediation and compensating controls; verification that each fix actually closed the issue; and evidence fit for auditors and the board. Miss any step and the loop leaks.
Metrics that actually help steer risk
Useful metrics track flow, not volume: mean time to remediate by severity, the age of open critical findings, the share of exposed assets covered, and exceptions under governance. Counting total findings tells you how noisy your scanner is, not how safe you are.
Where the process usually breaks
The recurring failure points are the same everywhere: no clear ownership, reports too long to act on, weak prioritisation, no verification of closure, exceptions granted without governance, and no link to compliance. A managed SOC and a proper vulnerability management service exist precisely to close those gaps.
The bottom line: a scanner is a tool, not a strategy
Scanning tells you what might be wrong; management reduces the risk and proves it. If your programme stops at the scan report, that is the gap to close first. For regulated environments, our vulnerability management aligned to ENS builds the evidence in — and if you want a quick read on your external exposure, get in touch.