Managed Vulnerability Management Services
Discover, prioritise and remediate vulnerabilities across your infrastructure before they become security incidents. We run the programme day to day — the scanning, the triage, the patching decisions and the evidence — so your team gets a short, ordered list of work instead of a report nobody has time to read.
What we find when we look at an existing programme.
Almost every organisation that contacts us already has a scanner, so the tool is rarely the issue. The findings count sits somewhere between eight and forty thousand, several thousand are labelled critical, and nobody internally can say which twenty to fix first. Once a list reaches that size it stops being a work queue and becomes background noise. Severity inflation does the rest: when four thousand items are marked critical, the word carries no information and people disengage from the whole report.
Scanning on its own does not reduce risk, and it is worth being blunt about that. A scan produces knowledge. Risk falls when something changes on a machine — a patch, a configuration, a firewall rule, a decommission. Every disappointed vulnerability management programme we have inherited had a working detection capability and nothing downstream of it. The scanner was doing exactly what it was bought to do.
Asset data is the quiet cause of most of the bad reporting. A scan covering seventy per cent of the estate gives you a confident-looking report about the wrong things, and the unmanaged remainder is reliably where the worst findings live — the server with no owner, the test box holding production data, the machine decommissioned on paper but still powered on and domain-joined. Duplicates are the other half: one host appearing three times through agent, scanner and cloud connector inflates every count and makes trend reporting meaningless. On a recent onboarding the client believed they ran 412 servers; discovery found 487.
Patch deployment success rates disappoint more often than the tooling implies. A job reporting ninety-six per cent success routinely leaves the vulnerability count barely moved. The usual causes are a pending reboot, a superseded update that did not update the specific vulnerable component, a fix undone by a re-image, or a second unmanaged copy of the application sitting under a user profile. If nobody re-scans to confirm closure, the programme is reporting job execution rather than risk.
Third-party software is where most of the remaining exposure sits. Windows Update or Intune generally handles the operating system in the estates we walk into. Browsers and their extensions, PDF tooling, Java runtimes, archive utilities, conferencing and remote access clients, the CAD or plotting package one department depends on — these are frequently managed by nothing at all, and often account for the majority of high-severity exposure while the patching dashboard shows green.
Underneath it is ownership, and specifically the disagreement between security and IT operations. Security is measured on closing findings quickly. Operations own uptime, a change advisory board, a maintenance window and the memory of the last patch that took out a line-of-business application. Both positions are defensible, and where the handover between them is not written down, findings simply age while each side assumes the other has it. Nobody is being negligent; the work has no home.
- Thousands of open findings with no defensible order of work
- Severity inflation making 'critical' meaningless to the people doing the fixing
- Incomplete and duplicated asset data producing confident but wrong reporting
- Patch jobs reporting success while the findings stay open
- Third-party applications managed by nothing in particular
- No written handover between security and IT operations, so findings age
How we run the programme week to week.
Discovery first, and it takes longer than clients expect. We reconcile what the scanner sees against your CMDB, Active Directory computer objects, Intune enrolment, cloud subscriptions and DHCP leases, and merge duplicate asset records across agent, scanner and connector sources. The gaps between those sources are the interesting part, and they are usually where the aged, exposed systems are. You cannot prioritise an estate you have not finished mapping, and you cannot report a trend on a count that changes every time coverage does.
Then data quality. Credentialed scanning is not optional — an unauthenticated scan infers patch level from banners, so it misses real findings and reports fixed ones. We build and test authentication records for Windows, Linux, network devices, databases and cloud accounts, and we treat the authentication failure count as a work queue rather than a footnote, because it is routinely in the hundreds and nobody reads it. Asset tagging by site, function, criticality and owner comes next, since tags are what every scan job, patch job, dashboard and permission set later depends on.
Prioritisation is where a managed service earns its cost. We do not hand over a list sorted by CVSS. CVSS describes theoretical severity, not your risk: a 9.8 on an isolated internal test box matters less than a 7.5 on an internet-facing gateway with a working public exploit. We combine severity with exploit availability, evidence of active exploitation, internet reachability and business criticality. A four-thousand-item critical list typically collapses to a few dozen. We also group by fix rather than by finding — one Java runtime upgrade can close several hundred entries, and presenting that as one task rather than several hundred is the difference between it happening this week and never.
Remediation only works if the security and operations disagreement is settled in advance rather than relitigated every cycle. We agree SLAs by risk band, hand operations a short defensible list instead of a raw export, run a genuine pilot ring so there is evidence a patch is safe before it reaches the estate, and provide a written exception route so 'not that one' is a legitimate answer with an owner and a review date. Where we have sat between the two teams, remediation rates improved because the friction went, not because anyone worked harder.
Where we deploy, it is usually Qualys Patch Management for third-party applications and Intune for the operating system and Microsoft estate, with jobs scheduled in each region's local time so a global business is not rebooting Sydney mid-afternoon. Rings and rollback positions are defined before the first job runs. One patch that breaks a business application costs a year of goodwill with the IT team, so we would rather be slightly slower and predictable.
Validation closes the loop, and it is the step most programmes skip. A ticket marked resolved is not evidence. We re-scan after each cycle, confirm the finding has actually gone, and where it has not we diagnose which of the usual causes applied instead of redeploying the same patch at it. Reporting then goes out in two formats: a working queue for operations, and a trend view for management — mean time to remediate, SLA performance, exposure on internet-facing critical assets. Raw open counts are deliberately not the headline, because that number moves for reasons that have nothing to do with risk.
- Asset discovery reconciled across CMDB, AD, Intune, cloud and network sources
- Credentialed coverage verified and authentication failures worked as a queue
- Prioritisation on exploitability, exposure and criticality, not a severity sort
- Findings grouped by fix, so one action closes many entries
- Agreed SLAs, pilot rings and a written exception route to keep both teams aligned
- Re-scan validation with root cause when a fix did not stick
Everything in the engagement, set out up front.
The service is run as an ongoing programme with named engineers, not a monthly report generated from a dashboard.
Platform deployment and tuning
Qualys VMDR or Microsoft Defender Vulnerability Management configured against your estate, with agents, authentication records, scan profiles and asset tagging built properly and revisited as the estate changes.
Continuous asset discovery
Ongoing reconciliation against your inventory sources so new cloud instances, forgotten servers and unmanaged endpoints surface rather than sitting outside the scan scope indefinitely.
Engineer-led triage
Every cycle reviewed by a person before it reaches you. False positives suppressed and tracked so they do not return, duplicates merged, and findings grouped into fixes.
Risk-based prioritisation
A ranked work queue built from CVSS, exploit availability, active exploitation intelligence, internet exposure and asset criticality — not a severity column sort.
Patch deployment
Optional managed deployment through Qualys Patch Management and Microsoft Intune, including third-party applications, with pilot rings, local-time scheduling and rollback plans.
Cyber Essentials remediation support
Scanning aligned to the 14-day high and critical patching requirement, with a clear pre-assessment gap list and support working through it before the assessor sees it.
Validation re-scanning
Confirmation that remediated findings have genuinely closed, catching pending reboots, superseded updates and fixes undone by re-imaging.
Exception management
Documented exceptions with reason, compensating control, owner and review date, so unpatchable systems are a managed decision rather than an unexplained gap.
Operational and executive reporting
A working queue for IT and a trend view for leadership, insurers and auditors, covering exposure direction, mean time to remediate and SLA performance.
What you receive.
- Reconciled asset inventory with tagging by site, function and criticality
- Tuned scanning platform with verified credentialed coverage
- Weekly prioritised remediation queue with named owners
- Monthly management report with exposure trend and SLA performance
- Cyber Essentials 14-day patching evidence pack
- Validated closure record for every remediated finding
- Maintained exception register with review dates
- Quarterly programme review with your IT and security leads
Built for organisations that need the work done properly.
Organisations with a scanner they are not getting value from
An existing Qualys, Tenable or Defender deployment that produces data nobody trusts or acts on. We take it over, fix the configuration and turn it into a working process.
IT teams without capacity to triage
Internal teams who know the findings need attention but cannot spend two days a month working through raw scan output alongside everything else they are responsible for.
Businesses facing Cyber Essentials or ISO 27001 assessment
Organisations that need evidence of consistent patching and technical vulnerability management, rather than a report produced the week before the assessor arrives.
Multi-site and multi-entity organisations
Groups made up of several businesses or regions needing separated reporting and local-time patching windows from a single platform, rather than a tool per entity.
Regulated firms with evidence obligations
Financial services, healthcare suppliers and legal firms who have to demonstrate to a regulator, client or insurer that known weaknesses are being closed on a defined timescale.
Organisations replacing a passive reporting service
Businesses currently receiving a monthly scan PDF from a provider with no triage, no prioritisation and no follow-through on whether anything was fixed.
What changes once the work is done.
Figures shown on this page are illustrative of what we typically see across client programmes. What your environment does depends on its starting point, and we will tell you what we think is realistic after a scoping conversation rather than before it.
A findings list that is actually workable
Grouping by fix and filtering by real exploitability turns tens of thousands of entries into a weekly batch a team can complete.
Sharply reduced vulnerability age
Aged findings are the ones attackers rely on. Clearing the backlog systematically brings average age down from years to days and keeps it there.
Third-party software brought under control
The applications outside Windows Update stop being the largest source of exposure, usually within the first two patching cycles.
Cyber Essentials without the annual scramble
The 14-day requirement is met by routine rather than by a rush, and the evidence exists before anyone asks for it.
Internal time returned to the IT team
No more days spent exporting, deduplicating and interpreting scan output before any remediation work can begin.
Evidence that holds up under scrutiny
A consistent record of scanning, remediation timescales and managed exceptions ready for auditors, insurers and client due diligence.
One engagement, and the five reasons programmes fail.
The starting position. A UK professional services group, around 900 users across five offices, on-premise Windows Server, Azure workloads and a largely remote workforce. Roughly 34,000 open findings in an existing Qualys subscription, about 4,100 rated critical, and an average vulnerability age of 379 days. Agents had gone out through a single Intune device group. Authentication worked on domain-joined Windows and failed silently everywhere else. A client due diligence questionnaire had asked how quickly they closed critical vulnerabilities and nobody could answer.
The first six weeks. Unglamorous work: finish the agent rollout, build and test authentication for the Linux and network estate, merge duplicate asset records, correct tagging so reporting could be split by office and criticality, and reconcile against Azure and Active Directory — which surfaced 63 machines nobody had counted. Only then did prioritisation get re-run. Filtering the criticals to findings with a known working exploit on an asset that was internet-facing or business-critical produced a list of 71 rather than 4,100. That is the whole point of the exercise: 71 items is a plan.
Where the friction was. Security wanted the list closed in a fortnight; operations had a change board, a fortnightly window and the memory of a patch that had taken down a case management system. We agreed SLAs by risk band, ran a 30-machine pilot ring, moved third-party applications to Qualys Patch Management with per-office local-time jobs, and tightened Intune compliance policies, which surfaced about 40 devices that had been quietly failing to apply updates for months.
Where it landed. Open findings fell just over 60 per cent in three months, driven mostly by grouped third-party fixes and duplicate removal rather than patching effort. Average age went from 379 days to 13. The 71-item list cleared in five weeks. Worth noting: the first two patch cycles reported 96 per cent deployment success and closed only around 70 per cent of the associated findings — pending reboots and two applications installed under user profiles outside the managed path. We only knew because we re-scanned. The client passed Cyber Essentials at the next assessment with no pre-assessment remediation. Their IT manager's summary was that the useful change was not the numbers, it was that the monthly report finally contained things he could act on.
Why programmes fail. Five recurring causes, and only one is technical. Ownership: if the handover between security and operations is not written down, findings age while both sides assume the other has it. Asset visibility: partial coverage produces a confident report about the wrong estate. Unmanaged third-party patching: the operating system tooling says green while the exposure sits in software nothing manages. Severity inflation: four thousand criticals is not a priority list, it is a reason to stop reading. And measuring the wrong thing: raw open counts move whenever coverage changes, whereas mean time to remediate, SLA performance and exposure on internet-facing critical assets show whether risk is actually falling.
A scanner addresses none of those five. It addresses detection, which was never the hard part. That is the honest case for a managed service — not better tooling than you could buy yourself, but the process around it running every week, because consistency is what reduces exposure.
- No written ownership or handover between security and IT operations
- Incomplete asset visibility producing confident reports about the wrong estate
- Third-party application patching left to nobody in particular
- Severity inflation making 'critical' meaningless to the people doing the work
- Reporting on raw counts rather than remediation speed and exposure trend
Questions we are asked most often.
How often should vulnerability scans run?
For most organisations, authenticated scans weekly against servers and endpoints, with external perimeter scans daily or continuously. Weekly is frequent enough to catch newly disclosed issues and patch regressions, without producing so much data that nobody reads it. Where an estate is largely cloud-hosted and changes several times a day, agent-based continuous assessment through Qualys VMDR or Defender Vulnerability Management is more sensible than a scheduled scan window, because the picture is stale within hours otherwise.
What is the difference between vulnerability scanning and vulnerability management?
Scanning is a technical activity that produces a list. Vulnerability management is the process that decides what on that list matters, who fixes it, by when, and how you prove it was fixed. Plenty of organisations we speak to have scanning and no management: the tool runs, the report lands in an inbox, and the same findings are still there twelve months later. The scanner is maybe fifteen per cent of the work.
Do you support Qualys environments already in place?
Yes, and it is the most common way we get involved. We take over an existing subscription, review how asset tags, authentication records, scan schedules and option profiles have been configured, and fix the parts producing bad data. Typically the first job is authentication: unauthenticated scans miss most of the real findings and generate a lot of speculative ones, so credentialed coverage is where we start before touching anything else.
Can you help with Cyber Essentials remediation?
Yes. Cyber Essentials and Cyber Essentials Plus have a specific requirement: high and critical severity patches applied within 14 days of vendor release, across operating systems, browsers, third-party applications and firmware where applicable. We scan against that definition specifically, produce a list of what will fail the assessment, and work through it with your IT team. Third-party applications — the PDF readers, Java runtimes, browser extensions and remote access tools — are almost always what causes a fail, not Windows Update.
How quickly should critical vulnerabilities be remediated?
Our default recommendation is 14 days for critical and high, 30 days for medium and 90 days for low, with a shorter 72-hour or 7-day track for anything externally exposed and known to be exploited in the wild. Those are starting points to be adjusted against your change control and business risk, not a rule handed down. What matters more than the exact number is that the target is agreed, written down and reported against, so overdue items are visible rather than quietly accumulating.
Is CVSS score enough to prioritise remediation?
No. CVSS describes the theoretical severity of a vulnerability, not the risk it presents in your environment. A CVSS 9.8 on an internal test server with no sensitive data and no route in from outside is less urgent than a CVSS 7.5 on an internet-facing gateway with a working public exploit. We prioritise using CVSS alongside exploit availability, threat intelligence on active exploitation, whether the asset is externally reachable, and how important the system is to the business. That combination usually reduces a 'critical' list of several thousand to a working list of a few dozen.
Do you apply the patches yourselves or does our IT team?
Either. Some clients want us to identify, prioritise and track while their own team or existing IT provider deploys. Others want us to run deployment too, usually through Qualys Patch Management or Microsoft Intune, particularly for third-party applications where their existing tooling has no coverage. Both work — what does not work is leaving remediation ownership vague, so we agree it explicitly before the first cycle.
How do you deal with vulnerabilities that cannot be patched?
They get recorded as formal exceptions with a stated reason, a compensating control where one exists, an owner and a review date. Legacy line-of-business applications tied to an unsupported runtime are the usual case. Isolating the host, restricting inbound access, tightening account privilege and increasing monitoring around it are all reasonable interim positions. What auditors and insurers object to is not the existence of an unpatched system, it is the absence of any evidence that anyone considered it.
Will scanning affect the performance of our production systems?
Authenticated scans are light on modern hardware, but the honest answer is that older network equipment, industrial devices and some legacy appliances can respond badly to aggressive scanning. We start conservatively, tune the option profile for those asset groups, and schedule scans against known-fragile systems in agreed windows. In several years of delivery the issues we have seen have been with unusual embedded devices rather than mainstream servers and workstations.
What reporting do we actually get?
Two views, because two audiences need different things. An operational view for the IT team: what is due, what is overdue, what changed since last cycle, exportable to whatever ticketing system you use. And a management view: exposure trend over time, mean time to remediate, SLA performance, and open exceptions. The second is what gets used in board packs, insurance renewals and ISO 27001 or Cyber Essentials evidence, and it is the one most in-house scanning setups never produce.
Qualys VMDR and Patch Management
How we deploy, tune and operate Qualys day to day, including third-party patch deployment.
Vulnerability Management as a Service
The full lifecycle service: discovery, prioritisation, remediation tracking and reporting.
Microsoft Defender
Defender Vulnerability Management and endpoint protection across a Microsoft estate.
Cyber Essentials support
Certification support including remediation against the 14-day patching requirement.
Our security services
Where managed vulnerability management sits alongside our wider security services.
Talk to a consultant
Request a vulnerability assessment or a review of your existing deployment.
Worth a conversation?
If you have a scanner that is not earning its keep, a findings list nobody is working through, or a Cyber Essentials assessment coming up, book a scoping call. We will look at what you currently have and tell you honestly what we would change first.
Book a consultation