Vulnerability Management as a Service: The MSP Playbook for 2026

Most MSPs got into vulnerability management the same way. A vendor rep showed up with a free trial of a scanner, the account manager signed off on a licence, and someone ran the first scan against three client networks. The PDF that came out was 200 pages of CVEs. Nobody knew where to start. The PDF went into a folder. Rinse, repeat.

The problem is not the scanner. The problem is that vulnerability management is a programme, not a task — and without a programme, you just have an expensive PDF generator.

In 2026, this matters more than it ever has. Cyber insurers now routinely require quarterly scan evidence before renewing policies. SOC 2, NIST CSF, and ISO 27001 all include continuous vulnerability identification as a control requirement. And your SMB clients are getting asked about this by their enterprise customers in procurement questionnaires. The window for “we run scans when something looks wrong” is closed.

The MSPs who figure this out first own a recurring revenue line that’s hard to displace. Here is how to build it.

Vulnerability Management Is Not Patch Management

The first thing to get straight with clients — and with your own team — is that vulnerability management and patch management are not the same thing.

Patch management is about keeping software current. Most MSPs already do this. Vulnerability management is about identifying, prioritising, and tracking the full risk surface: unpatched software, yes, but also misconfigured services, exposed credentials, weak cipher suites, deprecated protocols, and assets nobody knew were on the network.

A patch management tool tells you what needs updating. A vulnerability management programme tells you what is exploitable, in what order you should fix it, and whether you actually fixed it. That difference is what clients pay a premium for — and what separates a VMaaS offering from a commoditised patching contract.

What the Programme Actually Looks Like

A defensible VMaaS practice has four repeatable steps:

1. Discovery and inventory. You cannot protect what you cannot see. Before the first scan, you need a current asset inventory: servers, workstations, network devices, cloud workloads, remote access points. Many SMBs have never done this properly. Running a discovery scan before the vulnerability scan is both a billable deliverable and a forcing function that surfaces shadow IT.

2. Authenticated scanning. Unauthenticated scans find what’s visible from the network. Authenticated scans — where the scanner logs in to each asset — find what’s actually installed and misconfigured. The gap between the two is significant. For clients in regulated industries (HIPAA, PCI DSS, NIST 800-171), authenticated scanning is the baseline expectation, not the premium tier.

3. Risk-based prioritisation. A typical SMB network scan returns hundreds of findings. Triaging by CVSS score alone is how you end up patching a theoretical RCE on an internal dev box before you address an actively exploited vulnerability on a public-facing web application. Good prioritisation layers CVSS base score with EPSS (the probability that a vulnerability will be exploited in the wild), asset criticality, and network exposure. Your clients do not need to understand this methodology — they need to see a short list of what to fix this week, this month, and next quarter.

4. Remediation tracking and evidence. This is where most MSP programmes fall apart. Fixing things is only half the job. The other half is proving that you fixed them — for the insurer, for the auditor, for the client’s enterprise customer who sent a security questionnaire. Every closed finding needs a timestamp, a remediation note, and a re-scan confirmation. That paper trail is what turns vulnerability management from a cost centre into a defensible risk reduction programme.

Tooling: What to Actually Use

The commercial scanner market is dominated by three vendors: Tenable (Nessus / Tenable.io), Qualys, and Rapid7 (InsightVM). All three have MSP-oriented licensing programmes with per-asset pricing and multi-tenant management consoles.

For MSPs starting out, Tenable Nessus Essentials (free up to 16 IPs) is a sensible way to build operational competence before committing to a commercial licence. Greenbone Community Edition (formerly OpenVAS) is the strongest open-source alternative for uncapped asset scanning, though the management interface requires more operational investment.

The tool matters less than the programme. A disciplined team running Nessus Essentials with a proper triage and tracking workflow will deliver better outcomes than a team running InsightVM without one.

What you will need alongside the scanner:

• A ticketing system or dedicated VM workflow to track open findings (ConnectWise Manage, Halo PSA, or a dedicated GRC tool)
• An asset inventory that maps findings to business owners and criticality tiers
• Report templates tailored to three audiences: the technical team (full finding list), the client’s IT lead (prioritised action list), and the client’s board or compliance officer (executive risk summary)

Building Your Delivery Model

Structure the service around a predictable cadence. For most SMB clients, this means:

• Monthly authenticated scans of the full asset inventory
• Weekly unauthenticated scans of internet-facing assets (public IPs, web applications, VPN endpoints)
• Quarterly executive risk report — trend data, remediation rate, year-over-year comparison
• On-demand scan following significant changes: new system deployments, M&A, major patching cycles

The monthly and quarterly cadences are what the insurer and auditor want to see. The weekly internet-facing scan is what actually catches the things that get exploited in the wild — attackers are not waiting for your quarterly cycle.

Each client engagement should begin with a baseline scan and a remediation planning session. This is a billable workshop, not a loss-leader. You are setting the risk baseline, agreeing criticality tiers for their assets, and establishing the SLA for remediation by severity (critical: 7 days, high: 30 days, medium: 90 days). Documenting those SLAs is important — it gives the client skin in the game and gives you a defensible position when findings age out.

Pricing: Per Device or Per Client?

Both models work. The right choice depends on the size variance across your client base.

Per-device pricing (typically £3–£8 per managed asset per month) scales naturally with client size and is easy for clients to understand. The risk is scope creep when asset counts balloon after a discovery scan surfaces assets the client didn’t know existed.

Per-client flat-fee tiers work better when your client base is homogeneous in size. A typical structure:

Tier	Scope	Price (monthly)
Foundation	Up to 50 assets, monthly scan, quarterly report	£400–£600
Professional	Up to 200 assets, weekly internet scan, monthly report	£800–£1,200
Enterprise	Unlimited assets, continuous monitoring, dedicated vCISO review	£2,000+

Do not bundle vulnerability management into your base managed service contract. It is a distinct deliverable with distinct labour costs. If it is already included, you have a clear line item to unbundle and reprice at the next renewal.

Getting the Evidence Right

The evidence layer is what separates a VMaaS practice that satisfies auditors from one that creates audit findings.

For each client, you need a retrievable record of:

• Every scan run: date, scope, authenticated/unauthenticated, tool version
• Every finding: CVE ID, severity, affected asset, date discovered
• Every remediation: date closed, method (patch version, configuration change, compensating control), re-scan confirmation
• Every exception: findings accepted as risk with a named approver and review date

This is not a spreadsheet problem at scale. Managing exception registers and remediation timelines across twenty clients in spreadsheets is how things get missed. The operational leverage comes from centralising this in a tool that generates audit-ready exports on demand — which is exactly what GetCybr’s GRC automation is built for.

The Cyber Insurance Angle

Underwriters are increasingly specific about what they want to see. The CISA Known Exploited Vulnerabilities (KEV) catalogue is now a standard reference point — several insurers explicitly ask whether clients have a process for remediating KEV entries within 14 days. That is a defensible SLA to build into your Professional tier.

When a client renews their cyber insurance, your vulnerability management programme should be the reason their premium does not increase. That is a concrete business outcome you can point to at every QBR. “We ran 12 scans this year, closed 94% of critical and high findings within SLA, and your insurer renewed at the same rate as last year” is a compelling story. It is also the kind of outcome-based framing that makes clients resistant to switching to a cheaper MSP who does not provide it.

Common MSP Mistakes

Running scans without acting on findings. Scan data that does not drive remediation is worse than no scan — it creates liability. If you can see a critical vulnerability and cannot show that you acted on it, you have a problem in the event of a breach.

Using CVSS score as the only prioritisation signal. A CVSS 9.8 vulnerability on a test machine with no network access is not your most urgent problem. Prioritisation has to account for exposure and exploitability.

Not including network devices. Routers, switches, and firewalls are frequently excluded from scans for operational reasons. They are also frequently the most exposed assets on the network. Build authenticated scanning of network infrastructure into the programme from day one.

Failing to re-scan after remediation. A finding is not closed until a re-scan confirms closure. “We applied the patch” is not the same as “the vulnerability is gone.” Some patching operations fail silently. The re-scan is the control.

Skipping the client conversation. Vulnerability management only works with client cooperation. They own the assets and the remediation timelines. A programme that treats the client as a passive recipient of PDF reports will stall when critical findings require application downtime or budget approval. Build the remediation planning session into the onboarding and the QBR cadence.

What to Do Next

If you have an existing scanning licence and no structured programme around it, start there. Formalise the cadence, build the report templates, and add the remediation tracking workflow. That alone will differentiate your offering from most of your competitors.

If you are starting from scratch, begin with Tenable Nessus Essentials on two or three friendly clients, build the programme, and document the delivery model before you sell it. Sell the programme, not the scan.

Either way, the next step after you have a repeatable service is integrating it with your compliance reporting — because clients who buy VMaaS are almost always also working toward a compliance framework, and the vulnerability programme is a core evidence source for SOC 2, NIST CSF, ISO 27001, and cyber insurance audits alike.

GetCybr’s vCISO platform connects vulnerability management data directly to your compliance evidence library — so every closed finding automatically maps to the relevant framework controls and is available for audit export without manual assembly.

If you want to see how that works in practice, book a demo and we will walk you through a live client workflow.