Vulnerability Management

A scanner will hand you eleven thousand findings. The useful question is which nine of them an attacker could actually reach and use this week.

The problem with raw scanner output

Vulnerability scanning is cheap and easy. Vulnerability management (deciding what to fix, in what order, and then confirming it actually got fixed), is neither, and it is where the value is.

CVSS scores alone are a poor guide. A critical-rated vulnerability on an internal system that requires local access and has no public exploit matters less than a medium-rated authentication weakness on your internet-facing VPN portal. Prioritising by score means working through the list in roughly the wrong order.

How we prioritise

We weight findings by what determines real risk:

  • Exploitability: is there a working public exploit, and is it in active use? A vulnerability on CISA's Known Exploited Vulnerabilities catalogue is in a different category from one that is theoretical.
  • Exposure: internet-facing, internally reachable, or requires access you would already have lost.
  • Asset criticality: the same flaw on a domain controller and on a meeting room display are not the same problem.
  • Compensating controls: what else would have to fail for this to be exploited.

The output is a short, ordered list your team can realistically work through, not a spreadsheet that gets opened once and never again.

What the service includes

Continuous scanning

Authenticated scanning of internal estate and unauthenticated scanning of your perimeter, on a schedule rather than annually. Authenticated scanning is considerably more accurate: it reads installed versions rather than inferring them, which removes most false positives.

External attack surface monitoring

Scanning tests the assets you already know about, and the forgotten host is rarely on that list. We track what your organisation actually exposes and flag additions, which is frequently how that host is found in the first place. More detail on external attack surface monitoring.

Remediation tracking

Findings tracked to closure against agreed SLAs, with verification that fixes worked. "Patched" and "reboot pending so the patch is not yet active" look identical in a change record and completely different to an attacker.

Patch and configuration advice

Plenty of findings are not fixed by a patch. They are fixed by turning a feature off, changing a default, or removing something that should not be reachable. Where a patch does exist we tell you what it breaks and what order to apply it in, and where no patch is coming, which is normal for end-of-life software and embedded systems, we give you the compensating control that makes the risk survivable until it can be replaced.

Reporting that means something

Trend over time, mean time to remediate, ageing of open findings, and progress against SLA. Metrics a board can actually govern with, and evidence for Cyber Essentials, IASME and client audits.

Where this sits alongside testing

Vulnerability management and penetration testing solve different problems and neither substitutes for the other. Scanning gives breadth and frequency: it finds the missing patch across two hundred machines. Penetration testing gives depth: it finds the logic flaw and the attack chain no scanner can conceive of. Annual testing with nothing in between leaves eleven months of drift; continuous scanning with no testing means you never learn what a capable attacker would actually do.

Talk to us about testing

Tell us what you need looked at and we will tell you what the work actually involves, what it costs and when we can do it. CREST accredited, and the testing is done by the person you speak to.

Your details are handled by a real person, never fed into AI.

Common questions

Is this the same as a penetration test?

No. Scanning is automated, broad and frequent, matching against known signatures. Penetration testing is a human attempting to compromise systems, including chaining minor issues into serious ones. Compliance requirements that specify penetration testing will not normally accept scan output instead.

How often should we scan?

Perimeter weekly at minimum, internal estate monthly, and ad hoc after significant change. The critical requirement is speed of response to newly published vulnerabilities in internet-facing software: that window is now frequently measured in days.

Do you fix the findings, or just report them?

We prioritise, provide specific remediation guidance and verify fixes. The patching itself is normally done by your IT team or provider, who have the change control and access. We can work directly with them, which usually removes a great deal of back-and-forth.

Will scanning disrupt anything?

Authenticated scanning is generally low-impact, but some legacy and embedded systems respond badly to being scanned. We identify those during onboarding and handle them with adjusted profiles or exclusion, particularly in manufacturing environments.

Related

Ready to talk?

Scoping conversations are free and there is no sales team to get past. Tell us what you're dealing with and we'll tell you honestly what you need.