Vulnerability Management: From Discovery to Remediation

Almost every SME that commissions its first vulnerability scan ends up in the same place: a report with hundreds of lines, a lot of red on page one, and nobody with time to read it through. The problem is rarely the tool that produced the report. It is what happens next. Vulnerability management is an operational cycle that starts with the scan and only closes when someone confirms the flaw is genuinely gone.

A report is not yet vulnerability management

A vulnerability scan tells you what a tool found, at one moment in time, against the systems you pointed it at. That is the starting line. Management begins when that list turns into decisions: what gets fixed this week, what waits for the next maintenance window, what is accepted deliberately with the reasoning written down, and who owns each line.

The difference shows up a month later. If you rerun the scan and the same findings come back untouched, what you have is a recurring report. If the list shrinks and whatever remains has an owner and a date, you have a process.

No inventory, no cycle

You cannot fix what you do not know you have. In a company of 10 to 50 employees, the real asset list is almost always longer than the documented one:

• On-premise servers and cloud instances, including the one spun up for a test and never switched off.
• Desktops and laptops, with the operating system and software actually installed on each.
• The corporate website, the shop, the customer portal and any published API.
• Cloud services bought by a department without going through IT.
• Firewalls, routers, NAS boxes, printers and cameras sitting on the network.

Each asset needs two facts beyond its name: who uses it, and what happens to the business if it stops working for two hours. With that, you can prioritise without reopening the argument every time.

Triage: from hundreds of findings to a work list

The score attached to a finding measures the technical severity of a flaw in the abstract, knowing nothing about your company. Your real priority depends on context, and three questions sort almost any list:

1. Is it reachable from the internet? The same flaw weighs far more on a published service than on an internal machine with no direct exposure.
2. Is there known, circulating exploitation? A vulnerability with public exploit code in active use gets handled before one that scores higher on paper but has no practical exploit.
3. What sits behind the affected system? Personal data, invoicing, admin credentials or a route into the internal network change the order completely.

With those three answers, a list of hundreds becomes something workable: a handful touched this week, a mid-sized group queued for the next maintenance window, and a long tail reviewed in batches. That reduction is the part no tool does for you.

Every line needs an owner and a date

A finding assigned to "systems" is not assigned. It needs a named person and a committed date, even when all that person does is raise a ticket with the provider who maintains the ERP or the hosting. That detail is what separates a list that shrinks from one inherited quarter after quarter.

In an SME, a good share of the fixes depend on third parties: the vendor of your management software, the firm running your servers, the firewall manufacturer. Record their response times too, because they are part of your exposure window even when the work is not yours to do.

Patch windows, and what to do when there is no patch

Patching on a schedule, with an agreed window and a rollback plan, avoids the other classic failure: pushing an update on a Friday afternoon and spending the weekend restoring service. A calendar that works in small companies pairs a monthly window for routine work with an exception route, lighter on approvals and faster to trigger, for anything that cannot wait.

Sometimes there is simply no patch: discontinued software, a bespoke application whose developer is long gone, a production machine that cannot be rebooted. In that case the answer is mitigation:

• Isolate the system in a network segment separated from everything else.
• Restrict access to the addresses and users that genuinely need it.
• Put a second authentication factor in front of the service.
• Increase monitoring on that asset and actually review its logs.

A mitigation is documented with a review date. Without one, it becomes a permanent exception nobody remembers approving.

Verifying the fix: nothing closes by email

A finding is not resolved because someone replies "already patched". It is resolved when a fresh scan of the same asset stops finding it. Plenty of real situations live between those two states: a patch applied to the wrong server, a service that was never restarted, a setting the update quietly reverted to its default.

That verified close is what separates a vulnerability management service from a one-off review. It is also what leaves you usable evidence when a large client sends a security questionnaire asking how often you review your systems and how long you take to fix what you find. An annual security assessment complements the cycle with a wider view, without replacing it.

Cadence matters more than the tool

Your exposed surface changes on its own: a release ships, a new service gets signed up, someone opens a port to debug an issue and forgets to close it. That is why a monthly cycle with verification is worth more than a two-hundred-page annual report, however thorough the report may be.

If you also ship software frequently, periodic scanning leaves gaps between releases, and it pays to back it with continuous pentesting, which tests each deployment instead of waiting for the next snapshot of the system.

How to start without blocking the team

1. Close out the inventory of what is exposed to the internet. It takes an afternoon and it orders everything else.
2. Run a first scan and keep only what is externally reachable and known to be exploited.
3. Give those lines an owner and a date, including the ones that depend on a supplier.
4. Set the monthly maintenance window and the urgent exception route.
5. Scan again, and close only what no longer appears.

From the second cycle onwards the volume drops and the work stops feeling like an emergency. That is the goal: a vulnerability list that behaves like predictable maintenance, rather than an alarm that goes off the day someone else finds them first.