A scanner is not vulnerability management. It is the easiest part of it: a program that produces lists. The real work starts after the list, and that is exactly the part missing in most SMEs that show us their scan report.
We know the pattern well. The IT partner or an auditor delivers a PDF report, forty pages, traffic-light colours, a few hundred findings. Everyone is briefly alarmed, someone promises to look into it. Then the report moves into a folder, day-to-day business takes over, and by the next scan there are a few findings more. The scanner was never the problem. It delivered.
The most concrete version of this comes up in our assessments again and again: the scanner has been running for years, cleanly configured, monthly run, the report goes automatically to a shared mailbox. Ask who reads that mailbox and the room goes quiet. The scanner did its job the whole time. It is just that nobody had the mandate to do anything with the result. The company pays for visibility and gets nothing from it, because nobody sits between seeing and acting.
Vulnerability management in an SME does not mean owning this report. It means that someone decides what matters in it, that the relevant gaps get closed on a fixed rhythm, and that you can say why the rest stays open. That sounds unspectacular. It is unspectacular. But it is the part that protects you.
What comes after the scan
The term sounds like a product you buy. It is a loop, though: find, assess, decide, implement, verify. The scanner covers exactly the first step.
Assessing means: what does this gap mean for us, not for the world? Deciding means: patch, switch off, isolate, or consciously carry the risk. Implementing means: someone does it, in a maintenance window, without surprising production. Verifying means: the next scan confirms the gap is closed, not just the ticket status.
None of these stations needs a framework or a certification. Each one needs an owner. That is the difference between companies with a scanner and companies with vulnerability management: in one, the scan produces reports, in the other, decisions.
One precondition tends to get skipped: you can only assess what you know. A scanner checks the systems you point it at. The server from the old project contract, the NAS in the side room, the firewall of the former service provider show up in no report if nobody knows they exist. That is why the asset inventory comes before vulnerability management. Without it, every claim of completeness is an assumption.
Why the report alone protects nobody
Scan reports sort by severity, usually by CVSS score. That looks objective. Read as a priority list, it leads you astray.
A gap with a score of 9.8 on a system with no outside connection is a smaller problem than a 6.5 on the VPN gateway that faces the internet. The score does not know your network. It does not know what is reachable from outside, what is business-critical and where your customer data sits. Only you know these three things, and they decide the order.
Prioritisation is therefore the actual core of the work, and for an SME it condenses into two questions: is the affected system reachable from outside? And is the gap already being actively exploited out there? Whatever answers both with yes moves to the front and gets closed quickly. The large remainder runs along in the normal patch rhythm, without rush.
The pace for the front group has changed, though. We described in Attackers at AI speed why the window between the publication of a gap and its exploitation is shrinking. What follows from that is not panic, just a split into two speeds: a fast beat for what is exposed, a more leisurely one for everything else. One beat for everything would be either too slow for the exposed systems or needlessly expensive for the rest.
You probably already own the scanner
The usual reflex when the topic comes up: start a project, evaluate tools, collect quotes. Before you do that, it is worth looking at the licences you already pay for.
If you have Microsoft 365 Business Premium in the house, you have Defender for Business with it, and it brings the core capabilities of vulnerability management: it inventories the devices, shows missing updates and vulnerable software, and sorts the recommendations (source: Microsoft Learn, What is Microsoft Defender for Business). This is not niche knowledge, but it is remarkable in how many environments this view has never been opened.
That shifts the question from "which scanner do we buy?" to "who looks into what we have, and what happens with what they see?". In our experience, buying a second scanner while the first one runs unwatched is one of the more common forms of security theatre in miniature. More visibility of the same unclosed gaps protects you no better.
The same question belongs with your IT partner, if one manages the environment. Many contracts cover the scanning but not the deciding and implementing. The partner sends the report, the SME assumes the partner takes care of it, the partner assumes the SME decides. In this gap between two assumptions, findings sit for months, and the contract mentions it nowhere. A short conversation about who does what after the report costs nothing and clarifies more than any new licence.
Honestly, the built-in approach has limits. Defender sees endpoints and Windows servers well. The firewall, the hypervisor, the NAS and the self-hosted web application need a different look. But the order is right this way: first use what is paid for, then close the coverage gaps deliberately. It is the same logic with which we consolidate security tools: fewer tools that someone operates beat more tools that nobody looks at.
The bottleneck is operations
When it fails, it rarely fails on the tool. It fails on operations.
Patching is change work. It needs maintenance windows, restarts and the willingness to impose an inconvenient date on the business now and then. Add the fear that the ERP will not start after the update, and that fear is not irrational, anyone who has run systems long enough has a story like that. Whoever gives the job to internal IT "on the side" has in effect decided that it stays undone as soon as something more urgent comes up. And something more urgent reliably comes up.
This is solvable without your own security team, but not without a decision: someone owns the loop. Internal or external, with a fixed rhythm, with the mandate to enforce maintenance windows, and with the duty to report on the status. We described what this division of roles can look like without a dedicated team in IT security without a security team. Vulnerability management is one of the jobs that must be filled there, no matter by whom.
Ownership has a second, often forgotten part: the reporting line upwards. Management does not have to read a scan report, and it should not. It needs three numbers in plain language: how many exposed systems have open critical gaps, how long closing takes on average, and which exceptions are consciously carried. Whoever sees these three numbers quarterly can steer and shares the risk decisions, instead of hearing them for the first time after an incident. That is, incidentally, also the evidence of due care when someone later asks whether the company had its vulnerability management under control.
Operations also include the exceptions. The legacy system that cannot take the patch will exist at your company, as it does almost everywhere. Consciously leaving a gap open is legitimate if it is documented and the system is isolated or watched more closely in return. What is not legitimate is the silent leaving-open that only surfaces after the incident, when someone asks why the server from 2016 was still on the network and who decided that. Nobody wants to answer that question with "it just happened that way".
Three questions for your last scan report
Whether vulnerability management runs at your company or just a scanner shows in three questions.
- Who read the last report, and what was decided as a result? If the answer is "nobody" or "nothing", you are producing paper, not security.
- Which of the top findings affect systems reachable from outside? If nobody can say that without looking it up, the connection between the report and your reality is missing.
- What has verifiably been closed since the last report? Gone in the next scan counts, a completed ticket alone does not.
If these three answers stand, you have vulnerability management, no matter what your tool is called and what it cost. If they do not, a new tool will not help either. Then you need someone with the mandate, the rhythm and the backing of management. This is exactly the operating role we take on in our Security Management, including the uncomfortable conversations about maintenance windows. If you want to know what that could look like at your company, get in touch for an intro call, no strings attached.
And in case you just went and checked: when did someone at your company last switch something off or patch something because of a scan report?
