Security analyst reviewing a Qualys vulnerability management dashboard
Technology Partner — Qualys

Qualys Vulnerability Management Services

We deploy, tune and operate Qualys VMDR and Patch Management for UK organisations day to day. Most of the work is unglamorous — fixing authentication, tagging assets properly, grouping findings by fix and proving a patch actually landed — and that is the part that moves the numbers.

Open findings reduced
60%+
Average vulnerability age
379 → 13 days
Credentialed scan coverage
98%
Illustrative figures
The challenge

What we usually find in an existing Qualys subscription.

The common mistakes are consistent enough that we have a checklist. Authentication configured for domain-joined Windows and nothing else, so Linux, network devices and databases report a fraction of their real findings. Cloud Agents pushed through one Intune device group and never chased, leaving a third of the estate uncovered while the console still looks busy. Default asset tags, which means no report can be split by site, entity or criticality. Option profiles left as the out-of-the-box template. Exclusions added during a go-live to stop a noisy device and never reviewed two years later.

Then there is the false positive handling. Where nobody has been suppressing and documenting properly, the same disputed findings resurface every cycle, the IT team learns that the report contains things that are not true, and after three or four months they stop reading it. Trust in the data is much harder to rebuild than it is to protect, and once it is gone the subscription is producing nothing of value.

Scanning alone does not reduce risk, and this is worth saying plainly because a lot of budget gets spent on the assumption that it does. A scan produces knowledge. Risk falls when something is changed on a machine — a patch, a configuration, a firewall rule, a decommission. Every organisation we have worked with that was disappointed with its vulnerability tooling had a detection capability and no remediation process. The scanner was doing its job; nothing downstream of it was.

Asset data is the quiet cause of most bad reporting. If the scanner covers seventy per cent of the estate you get a confident-looking report about the wrong things, and unmanaged assets are reliably where the worst findings live — the server nobody owns, the test box with production data on it, the machine that was decommissioned on paper and is still powered on and domain-joined. Duplicate asset records are the other half of this problem: one host appearing three times through agent, scanner and cloud connector inflates every count and makes trend reporting meaningless.

Finally, patch deployment success rates disappoint far more often than vendors imply. A job that reports ninety-six per cent success routinely leaves the vulnerability count almost unchanged, because pending reboots, superseded updates, user-profile installs of the same application and re-imaged devices all break the link between 'deployed' and 'fixed'. If you are not re-scanning to confirm closure, you are reporting on job execution, not on risk.

  • Authentication working on Windows only, quietly failing everywhere else
  • Agent coverage gaps hidden behind a busy-looking console
  • Default tagging, so no report can answer a business-unit question
  • Unsuppressed false positives destroying the IT team's trust in the data
  • Duplicate asset records inflating counts and breaking trend reporting
  • Patch jobs reporting success while the finding stays open
Our approach

How we actually run Qualys.

We start with a two-week data quality pass before anyone looks at a finding. Authentication records built and tested per platform, with the authentication failure report treated as a work queue rather than noise. Agent deployment completed and agent check-in age monitored as a metric in its own right. Duplicate asset records reconciled across agent, scanner and cloud connector sources. Asset tags rebuilt around entity, site, function, criticality and owner, because tags are what every scan job, patch job, dashboard and permission set hangs off later. Get the tag structure wrong and you rebuild the subscription in eighteen months.

Prioritisation then runs in two stages. TruRisk and exploit intelligence narrow the field; local context decides the order. Internet-facing first, then anything holding or reaching sensitive data, then business-critical systems, then the rest. We group by fix rather than by finding, which is the single change that has the biggest effect on throughput — one Java runtime upgrade routinely closes several hundred individual entries, and presenting that as one task rather than several hundred is the difference between it happening this week and never.

Remediation is where security and IT operations usually disagree, so we plan for it rather than discovering it. Security wants the critical list closed this week. Operations own uptime, a change advisory board, a maintenance window and the memory of the last patch that broke a line-of-business application. Both positions are reasonable. What resolves it is agreeing SLAs by risk band up front, giving operations a short defensible list rather than a raw export, running a genuine pilot ring so there is evidence the patch is safe, and having a written exception route so 'we cannot do that one' is a legitimate answer with an owner and a review date rather than an argument. Where we have sat in the middle of that relationship, the remediation rate improved because the conflict stopped, not because anyone worked harder.

Deployment through Qualys Patch Management is used mainly for third-party applications — browsers, PDF tooling, Java, archive utilities, collaboration and remote access clients — with Intune or Configuration Manager kept for the operating system and Microsoft estate. Jobs are ring-based: pilot group, early adopters, then the estate, with a rollback position defined before the first job runs. Schedules are set in local time per region using tags, so a global estate is not patching one country in the middle of its working day.

Every cycle finishes with a validation re-scan. Job status is not evidence. We confirm the finding has gone, and where it has not, we find out which of the four usual causes applied and fix that instead of redeploying the same patch. Reporting then goes out in two formats: a working queue for the IT team, and a trend view — mean time to remediate, SLA performance, exposure on internet-facing critical assets — for management, insurers and assessors. Raw open-vulnerability counts are deliberately not the headline, because that number moves whenever scan coverage changes and tells a leadership team almost nothing.

  • Two-week data quality pass: authentication, agent coverage, duplicates, tagging
  • TruRisk and exploit intelligence first, local exposure and criticality second
  • Findings grouped by fix, so one action closes many entries
  • Agreed SLAs, pilot rings and a written exception route to keep security and operations aligned
  • Qualys Patch Management for third-party software, Intune for the Microsoft estate
  • Validation re-scan every cycle, with root cause when a fix did not stick
What's included

Everything in the engagement, set out up front.

What a Qualys engagement covers. Named engineers run it; it is not a dashboard handed over with a login.

Deployment and configuration review

Agents, scanner appliances, authentication records, option profiles, exclusions and tag structure built or rebuilt, with authentication failures treated as a tracked work queue.

Asset discovery and reconciliation

Scanner data reconciled against AD, Intune, cloud subscriptions and your CMDB, with duplicate records merged so counts and trends mean something.

Engineer-led triage

Every cycle reviewed by a person. False positives suppressed with a documented reason so they do not return, duplicates merged, findings grouped into fixes.

Risk-based prioritisation

TruRisk and exploit intelligence combined with internet exposure, data sensitivity and business criticality to produce a short list rather than a severity sort.

Qualys Patch Management

Third-party application patching with pilot rings, tag-driven local-time scheduling and a defined rollback position, alongside your existing Intune or SCCM estate.

Validation re-scanning

Confirmation that findings closed, and diagnosis when they did not — pending reboot, superseded update, unmanaged copy of the application, or re-imaged device.

Exception register

Documented reason, compensating control, owner and review date for anything that cannot be patched, so unpatchable systems are a decision rather than a gap.

Compliance evidence

Scan coverage against defined scope, remediation timescales against SLA and open exceptions, in the form Cyber Essentials, ISO 27001, PCI DSS and DSPT assessors ask for.

Multi-entity and global operation

Tag-driven separation by business unit and region, local-time job scheduling and scoped permissions, so one subscription serves several businesses without merging their data.

Deliverables

What you receive.

  • Configuration review report with prioritised remediation of the subscription itself
  • Reconciled asset inventory with a documented tag structure
  • Verified credentialed scan coverage figure, reported monthly
  • Weekly prioritised remediation queue grouped by fix, with named owners
  • Patch job design: rings, local-time schedules and rollback positions
  • Validated closure record for every remediated finding
  • Maintained exception register with review dates
  • Management report: mean time to remediate, SLA performance and exposure trend
Who it suits

Built for organisations that need the work done properly.

Organisations with Qualys already in place

The most common way we get involved. We take over an existing subscription, fix the parts producing untrustworthy data, and turn it into a weekly process.

IT teams without capacity to triage

Teams who know the findings need attention but cannot lose two days a month to exporting, deduplicating and interpreting scan output.

Regulated organisations

Legal, healthcare and financial services firms who have to evidence remediation timescales to an auditor, insurer or client, not just show that scanning happens.

Estates with a third-party patching gap

Organisations where the operating system is patched properly and everything else — browsers, runtimes, utilities, remote access tools — is not managed by anything.

Multi-domain and global enterprises

Groups of several businesses needing separated reporting, scoped permissions and local-time patching windows from a single platform rather than a tool per entity.

Businesses replacing a passive reporting service

Where the current provider sends a monthly scan PDF with no triage, no prioritisation and no check on whether anything was actually fixed.

Outcomes & benefits

What changes once the work is done.

Figures below come from client engagements and are indicative of what we typically see. What your estate does depends on its starting point, and we will give you a view on that after scoping rather than before it.

Open findings down over 60% in three months

Achieved mainly through grouped third-party fixes and removing duplicate asset records, not through the IT team patching harder.

Average vulnerability age from 379 days to 13

Aged findings are the ones with mature, publicly available exploits. Clearing the backlog in defined batches is what shifts this number and keeps it down.

Data the IT team will act on

Disputed findings suppressed with a documented reason and validation re-scans behind every closure. Once the report is trustworthy, the arguments about it stop.

Third-party software brought under management

Applications outside Windows Update stop being the largest source of exposure, usually inside two patching cycles.

Evidence that survives an assessment

Scope, timescales and exceptions documented, so Cyber Essentials, ISO 27001 and insurance questions are answered from a report rather than an assurance.

One platform across several businesses

Tag-driven separation and local-time automation let a group run vulnerability management centrally without each entity needing its own tooling and process.

One engagement, in detail.

The starting position. A UK professional services group, roughly 900 users across five offices, a hybrid estate of on-premise Windows Server and Azure workloads, and a largely remote workforce. Qualys had been in place for two years. The console showed around 34,000 open findings, about 4,100 of them critical, and the average age of a known vulnerability was 379 days. A client due diligence questionnaire had asked how quickly they remediated critical vulnerabilities and nobody could answer it. Their view was that Qualys was not working. Our view, after two days of looking, was that Qualys was working and nothing around it was.

What was actually wrong. Cloud Agents had been deployed through a single Intune device group, so around a third of endpoints were uncovered. Authentication succeeded on domain-joined Windows and failed silently on the Linux and network estate — the authentication failure count had been in the hundreds every scan for eighteen months and nobody had looked at that report. Sixty-three machines existed in Azure and Active Directory that were not in the scanner at all. Several hundred assets were duplicated across agent and scanner records, inflating every count. Tags were at their defaults, so the reports could not be split by office or criticality, which is precisely the question their board kept asking.

The first six weeks. Unglamorous work: complete the agent rollout, build and test authentication for Linux and network devices, merge duplicates, reconcile the asset list, and rebuild tagging around office, function and criticality. Only then did we re-run prioritisation. Filtering the 4,100 criticals to findings with a known working exploit on an asset that was either internet-facing or business-critical produced a working list of 71. That number is the point of the exercise. Seventy-one items is a plan; 4,100 is a reason to give up.

Remediation and where the friction was. Security wanted the 71 closed in a fortnight. IT operations had a change board, a fortnightly maintenance window and a bad memory of a patch that had taken out a case management system. We agreed SLAs by risk band, ran a 30-machine pilot ring for the third-party patch jobs, and moved browsers, PDF tooling, Java and remote access clients to Qualys Patch Management with jobs scheduled per office in local time. Operating system patching stayed in Intune, with compliance policies added to surface devices that were quietly failing to apply updates — there were 40-odd of those, and they had been invisible.

Where it landed. Open findings fell by just over 60 per cent within three months, mostly from grouped third-party fixes and duplicate removal rather than raw patching effort. Average vulnerability age went from 379 days to 13. The 71-item list cleared in five weeks. The first two patch cycles reported 96 per cent deployment success and closed only about 70 per cent of the associated findings; the gap was pending reboots and two applications installed under user profiles outside the managed path. We found that because we re-scanned, and fixed the cause rather than redeploying. The client passed Cyber Essentials at the next assessment with no pre-assessment remediation work. 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 do something about.

  • Detection was never the problem — process, ownership and data quality were
  • Fixing authentication and duplicates moved the numbers before any patching happened
  • 4,100 criticals became a defensible list of 71 once exposure and exploitability were applied
  • 96% deployment success closed only 70% of findings until reboots and rogue installs were addressed
  • Agreed SLAs and a pilot ring ended the security versus operations stand-off
Frequently asked questions

Questions we are asked most often.

We already own Qualys. What usually needs fixing first?

Authentication, in almost every case. An unauthenticated scan infers patch level from banners and service responses, so it invents findings that were patched months ago and misses the ones that matter. We check the authentication records against a sample of hosts, look at the scan results for 'authentication failed' counts — which nobody reads and which are frequently in the hundreds — and rebuild the records for Windows, Linux, network devices and databases before we touch anything else. Second job is usually asset tagging, because untagged assets make every report unanswerable at business-unit level.

Agents or network scanners?

Agents for anything that roams or is off-network — laptops, remote users, cloud instances that come and go. Scanner appliances for network devices, printers, hypervisors, storage and anything that will not take an agent. Most estates need both, and the mistake we see is picking one and pretending the gap does not exist. The other practical point is agent health: a Qualys Cloud Agent that has not checked in for 45 days still shows an asset record with old data, so an estate can look covered while a chunk of it is reporting history.

Is TruRisk enough on its own to decide what to fix?

It is a much better starting point than raw CVSS, because it factors in exploit maturity and threat activity. But it does not know which of your servers processes payroll, which subnet is reachable from the internet through a firewall rule someone added in 2021, or which application the finance team cannot afford to have restarted. We use TruRisk as the first filter and then apply local context — exposure, data, business criticality, change risk — before anything reaches a work queue.

Why do patch jobs report success when the vulnerability is still open?

Usually one of four reasons. The device is pending a reboot and the fix is not active. A superseded update was installed but the specific component was not updated. The patch applied and was then removed by a re-image or a driver rollback. Or the vulnerable copy of the software is not the managed one — a portable Java or an old Chrome install under a user profile that the deployment tool never sees. This is why we validate by re-scan rather than by job status. Deployment success rates in the high nineties with a vulnerability count that barely moves is a common and misleading combination.

Can Qualys Patch Management replace what we do in Intune or SCCM?

It can, but in most environments we run them alongside each other rather than ripping anything out. Intune or Configuration Manager keeps the operating system and the Microsoft estate; Qualys Patch Management handles third-party applications, which is where the coverage gap normally is. Splitting it that way is less disruptive and means the team keeps using tooling they already know. Where the internal team has no patching platform at all, Qualys can do both.

How do you handle global estates and multiple business units?

Asset tags drive everything. We build a tag structure by entity, site, function and criticality, then attach scan jobs, patch jobs, dashboards and user permissions to those tags. Patch jobs are scheduled in local time per region so nobody in Sydney gets rebooted mid-afternoon, and each business unit sees its own data while the group security function sees the whole picture. It is a day of design work up front that saves a permanent argument about whose numbers are whose.

Will scanning break anything?

Mainstream servers and workstations, no. The problems we have actually encountered were with older network equipment, building management devices, medical and industrial kit, and a couple of legacy appliances with fragile TCP stacks. We start conservatively, keep those asset groups in their own option profile with reduced intensity, and agree the windows in advance. Being honest about the exceptions is more useful than claiming scanning is universally safe.

Does Qualys give us the evidence auditors ask for?

It gives you the raw material. Turning it into evidence takes a little work: scan coverage against a defined asset scope, remediation timescales against an agreed SLA, and a documented position on anything unpatched. Assessors for Cyber Essentials Plus, ISO 27001 and DSPT tend to ask the same three questions — what is in scope, how quickly do you fix, and what about the things you have not fixed. A dashboard screenshot answers none of them.

Want a straight assessment of your Qualys setup?

We will review your existing subscription — authentication, agent coverage, tagging, duplicates and patch job outcomes — and tell you what we would change first and what difference we think it would make. If the answer is that your setup is fine, we will say that too.

Book a scoping call