Skip to content
Cyber Security Firms

Vulnerability Management Services: What You Are Buying

Every provider in this market says it manages your vulnerabilities. Almost none of them will apply a patch, and the distance between those two sentences is where most programs stall for a year.

Intermediate23 min readUpdated
Vulnerability Management Services: What You Are Buying

Three providers quote for the same paragraph. The first is a scanner license with a monthly PDF attached to it. The second is a scanner license, an analyst who reads the output before you do, and a ticket in your tracker for each finding that is worth somebody's afternoon. The third does all of that and then signs into your servers on the second Tuesday of the month and installs the patches itself.

The quotes are three, five and eleven times apart. All three proposals use the phrase vulnerability management services, and all three are accurate descriptions of what that phrase means somewhere in this market.

One question separates them, and it is not in any of the three proposals unless you ask: who applies the patch, and who approves the outage it needs. Everything else in the purchase, the price, the onboarding timeline, the headcount you still need internally, follows from the answer.

What Managed Vulnerability Management Includes and Excludes

Five things appear in almost every engagement worth buying.

Asset discovery and inventory. The provider finds what you actually have, which is reliably more than what is in your asset register. Everything downstream is a function of this list, and a service scanning an inventory you supplied without checking it is measuring your paperwork.

Scanning on a defined cadence. Authenticated where credentials exist, unauthenticated at the perimeter, across networks, endpoints, web applications, cloud accounts and containers depending on what you bought.

Triage and prioritization. A human decides which findings are real, which are false positives, and which order the real ones get worked in. This is the part you are paying a service rate rather than a license fee for.

Tracking to closure. Each accepted finding becomes a ticket with an owner and a deadline, and the provider verifies closure with a rescan rather than taking your word for it.

A named analyst and a reporting rhythm. Somebody who knows your estate, a monthly or quarterly review, and a report an auditor can read.

What the fee does not cover is where the money goes wrong:

  • Applying the patch. The federal version of this service says it in the plainest available language: the Department of Justice offers scanning, analysis and reporting to government customers and states that it does not provide patching or flaw remediation, only collaboration so that scan outputs support your remediation. Commercial providers behave the same way by default. Patching as a managed service exists, it is a separate line item, and it is priced per endpoint.
  • Approving the outage. Somebody inside your business has to say that the payroll server can reboot on Thursday night. No provider can make that call.
  • Accepting the risk. When a finding will not be fixed, a person with authority has to sign that decision. Outsourcing the work does not outsource the accountability, and one federal rule spells that out: where a covered financial institution uses a service provider to fill its Qualified Individual role, it must still retain responsibility for compliance with the rule.
  • Assets you do not own. Your Salesforce tenant, your payroll platform and your suppliers' systems cannot be scanned by you and cannot be authorized by you.
  • Flaws nobody has published. A scanner matches against a database of known issues, so a zero day is invisible to it by definition until the entry exists.
  • Detection and response. Finding a hole is a different purchase from watching for someone climbing through it, which is what managed detection and response covers.
  • The reason the flaw was there. A service that reports the same unpatched library every quarter is describing a broken build process, and fixing that is consulting work.

What Is the Difference Between Vulnerability Scanning and Vulnerability Management?

A scan is one verb. Management is the loop the verb sits inside, and the loop is where the cost and the value both live.

Vulnerability scanning produces a list. Vulnerability management decides what the list means, gets the important part of it fixed, proves the fix worked, and does it again next month with the new findings that arrived in the meantime. CIS Critical Security Control 7 frames the whole thing as one obligation, to continuously assess and track vulnerabilities on all enterprise assets so as to minimize the window of opportunity for attackers. The window, not the list, is the thing being managed.

The step buyers underestimate is the decision, because patching is only one of the available answers. NIST's guide to enterprise patch management sets out four risk responses to a software vulnerability: accept it, mitigate it, transfer it, or avoid it by removing the software or decommissioning the asset. Only patching and upgrading eliminate the flaw outright, and NIST is direct that immediate patching is sometimes not viable, listing missing patches, incompatibility and validation requirements among the reasons.

That has a practical consequence for how you buy. If three of the four responses are business decisions rather than technical ones, then a service that only produces findings has handed you a decision queue, not a solution. NIST's own recommendation is to stop treating unpatchable systems as exceptions and to give them a maintenance group of their own, with defined outage restrictions and defined alternative mitigations, because an asset that cannot be patched still has maintenance needs. Ask a prospective provider where those systems go in their model. The ones who have thought about it answer immediately.

What a Managed Vulnerability Management Engagement Looks Like End to End

Nothing in the sales material tells you that the service you buy in January is not protecting anything in January. Discovery takes weeks, credentialed scanning needs service accounts your team has to create, and the first scan of an estate nobody has scanned properly returns a number so large that the first month is spent arguing about it.

The first ninety days of a managed vulnerability management engagement
  1. Scope agreed in writing. Address ranges, cloud accounts, domains, subsidiaries, and an explicit list of what is out
  2. Discovery scan and inventory reconciliation. The count of live assets is almost never the count in the asset register, and the difference is the first finding
  3. Scanner and agent deployment, credentialed scanning configured. Service accounts and firewall rules are your work, and they are the usual reason onboarding slips
  4. Baseline scan and first triage. A first credentialed scan of a mid-sized estate returns thousands of findings, and most of them will never be worked
  5. Prioritization workshop. Which assets matter, which outage windows exist, which findings get accepted rather than fixed, and who signs that
  6. First full remediation cycle, then a rescan that proves what actually closed
  7. Steady state. The number worth reporting is not how many findings were found, it is how many are still open past their deadline
A quarter from signature to a metric worth putting in front of a board.

After onboarding the engagement becomes a monthly rhythm, and the rhythm only works if three parties know which part is theirs. This is the thing no provider publishes and every buyer needs before the contract is signed.

The monthly loop, and who owns each step
ProviderYour IT teamSystem ownerScan runs, findings triaged and false positives removedTickets raised, each ranked with a deadlineOutage window requested for the affected systemWindow approved, or the risk accepted in writingPatched, ready for verificationRescan confirms closure, or reopens the ticket

Two lanes in that diagram are yours. A provider that cannot tell you which of its customers' steps are theirs and which are yours has not run this at your size, and the gap shows up in month three when tickets sit open because no one was named.

A long shelf of identical closed boxes with three of them pulled forward past the edge

How Vulnerability Management Providers Differ From Each Other

Five shapes sell this work. None is better in the abstract, and the right one depends on whether you have an IT team that can act on tickets and whether you already own a scanner.

Provider shapeStrengthWhat to watch
Scanner vendor's own managed serviceThe people know the platform better than anyone, and the tooling is includedLock-in. The service and the license are one purchase, so leaving means replacing both at once
Co-managed specialist, platform agnosticWorks inside the scanner you already bought, and will argue for the right tool rather than theirsDepth on your specific platform. Ask how many customers they run on it
Managed security provider add-onOne supplier, one invoice, and findings that flow into the same team that watches your alertsAttention. Vulnerability management is often the least profitable line and gets the newest analyst
Consultancy building your programFixes the process, not just the findings, and leaves you able to run itCost and duration. This is a project with an end date, not a subscription
Staff augmentationAn operator inside your team, using your tools, on your ticketsYou are still the program. This buys hands, not a method
Scan reseller with a portalPriceWhether a person reads the output before you do. This is where the market's bad reputation comes from

Two questions separate any two proposals faster than a feature grid.

Who does the triage, and how many hours a month do they spend on us? Ask for the answer in hours, by name, and in the contract. The difference between a good and a useless service in this category is almost entirely whether a human filtered the findings before they reached you. A portal with a login is not triage.

Who owns the scanner tenant? If the provider holds the license, the configuration, the scan history and the exception list, your remediation record leaves with them. Twelve months of trend data is the thing an auditor asks for, and it is the thing you cannot rebuild after a switch.

Independence matters here in a narrower way than it does for penetration testing services, where the firm that built the system should not be the one grading it. A provider that finds vulnerabilities and also sells the remediation is not automatically conflicted, because you can see whether the finding was real. The conflict to watch for is softer: a provider whose contract is renewed on a clean dashboard has a quiet reason to close tickets as accepted risk. That is why the risk acceptance signature belongs on your side of the table, and why a virtual CISO or an internal owner needs to hold it.

How Vulnerability Findings Get Prioritized

Every provider promises risk-based prioritization. The useful version of that promise has a rubric behind it that you can audit, and the best public one is free.

Severity is not urgency. CVSS scores how bad a flaw would be if exploited. It says nothing about whether anyone is exploiting it, and a program that works its queue in CVSS order spends its scarce maintenance windows on flaws nobody has ever attacked. The corrective signals are exploitation and exposure. FIRST publishes the Exploit Prediction Scoring System, a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days, refreshed daily for every CVE and free to pull into a dashboard. CISA publishes the harder fact: the Known Exploited Vulnerabilities catalog held 1,699 entries on September 9, 2026, of which 358 are tied to known ransomware campaigns. Those are the flaws confirmed to be in use, and the number is small enough to work through.

CISA also publishes the deadlines, which is the part no commercial provider will give you. Binding Operational Directive 26-04, issued in June 2026, tells federal agencies to set remediation urgency from four questions about each finding: is the asset publicly exposed, is the CVE in the KEV catalog, can an adversary automate the exploit, and does exploitation give partial or total control. The sixteen answers produce five outcomes.

Publicly exposedIn the KEVAutomatableTechnical impactRemediation deadline
YesYesYesTotal control3 days and a forensic triage
YesYesYesPartial control3 days
YesYesNoTotal control3 days and a forensic triage
YesYesNoPartial control14 days
YesNoYesTotal control3 days
YesNoYesPartial control14 days
YesNoNoTotal control14 days
YesNoNoPartial control60 days
NoYesYesTotal control3 days and a forensic triage
NoYesYesPartial control14 days
NoYesNoTotal control14 days
NoYesNoPartial control14 days
NoNoYesTotal control60 days
NoNoYesPartial control60 days
NoNoNoTotal controlFix on system upgrade
NoNoNoPartial controlFix on system upgrade

Read the pattern rather than the rows. An internet-facing system with a flaw that is being exploited and hands over control gets three days and a check for whether somebody already came through. A flaw on an internal system that nobody is exploiting and that cannot be automated waits for the next scheduled rebuild. Federal timelines are stricter than most private companies can sustain, and the shape of the decision transfers exactly. Two of the four inputs, exposure and technical impact, come from your own architecture, which is why an asset inventory that records what is internet-facing is worth more to this program than a faster scanner.

The case for taking those deadlines seriously has gotten sharper. The 2026 Verizon Data Breach Investigations Report found that nearly a third of all breaches, 31 percent, now start with vulnerability exploitation, which has passed stolen credentials as the leading entry point.

What Drives the Price of Vulnerability Management Services

There are two meters running, and most proposals blend them into one number so that they cannot be compared.

The first is licensing, priced per asset, per IP address or per application, and it scales with the size of your estate. The second is service, priced in analyst hours, and it scales with how much thinking you are buying. A quote that halves the second meter while matching the first looks competitive and delivers a portal.

What moves the total:

  • The count of assets under management, which is the discovery result, not the number you guessed at during the sales call. Expect it to be higher.
  • Whether scanning is authenticated. Credentialed scans find far more, cost more to set up, and require service accounts your team maintains.
  • What is in scope beyond servers and laptops. Web applications, cloud configuration, containers and the build pipeline are usually separate modules.
  • Cadence. Monthly, weekly and continuous are three different prices, and continuous scanning of a large estate produces a volume of findings that needs the analyst hours to match.
  • Analyst hours for triage and the monthly review. The single most useful line to have itemized.
  • Whether remediation is included, and for which asset classes. This is the largest swing in the whole quote.
  • Compliance evidence. Reports formatted for an auditor, scan attestations and retention of historical results carry real work.

Questions to Ask Before You Sign a Vulnerability Management Contract

Eight questions do most of the filtering, and every one of them can be sent by email before a call is booked.

Two answers should end a conversation. A provider that will not commit to a triage turnaround in writing is selling a scanner with a phone number. And a provider whose remediation report counts tickets closed without distinguishing patched from accepted is measuring its own activity rather than your exposure.

Contract Terms That Matter in a Vulnerability Management Agreement

The statement of work is where the money you spent turns into something you can hold somebody to. These are the clauses worth an hour of argument.

Scope, itemized, with exclusions. Address ranges, cloud accounts, domains, subsidiaries, and what is deliberately out. Vague scope is resolved in the provider's favor at renewal.

Scan cadence per asset class, in writing. Monthly for the internal estate and weekly for the perimeter is a different contract from quarterly everything, and both get described as "regular".

Triage service levels with deadlines. Time from scan completion to prioritized findings, plus a shorter clock for anything appearing in the KEV catalog. Without this the service has no measurable promise in it.

Who remediates, per asset class. The clause that decides the entire economics of the engagement. Get it explicit even when the answer is that you do everything.

Verification. Rescans included, targeted at the finding, with a defined turnaround, and results retained as evidence rather than overwritten.

False positive handling. Who investigates, what the burden of proof is, and how long a suppression lasts before it is reviewed again.

Tooling ownership and exit. Whose license, whose tenant, and what you receive on termination: the asset inventory, the full finding history, the exception register and the configuration. Agree the export format now, not during a notice period.

Credentials and data handling. Scanning accounts are privileged accounts. Set out how they are stored, rotated and revoked, who at the provider can use them, where scan results are held, and what is destroyed at the end. A scan result set is a map of exactly how to get in.

The risk acceptance path. Who at your company can accept a finding, in what format, and for how long before it is reviewed again. Never leave this to the provider's dashboard.

Reporting and audit support. Formats, cadence, retention period, and whether an auditor's follow-up questions are inside the fee or billable.

What happens when a finding is already being exploited. A scan that turns up an actively exploited flaw on an exposed system is closer to an incident than to a ticket. Agree the escalation path now, and check whether your provider or an incident response retainer picks up the phone at that point, because the two contracts often assume the other one covers it.

A wall calendar page with a small number of dates marked

Do You Need a Managed Vulnerability Management Service?

For some readers the cadence is set by somebody else. Companies covered by the FTC Safeguards Rule must run continuous monitoring or, absent that, conduct vulnerability assessments at least every six months and whenever there is a material change to operations. Merchants and service providers under PCI DSS requirement 11.3.2 need an external scan by an Approved Scanning Vendor at least once every three months, and only a passing report counts.

For everyone else it is a question about whether you have the people, not whether you have the risk.

How to Measure Whether the Service Is Working

Ask for these four numbers in month four, and again in month twelve. A provider that cannot produce them from its own platform is not running a program.

Coverage. What percentage of discovered assets were successfully scanned with credentials in the last cycle. This is the number that quietly decays as new systems appear, and a coverage figure below the high nineties makes every other metric optimistic.

Time to remediate, split by urgency band. Not an average across everything, which hides the failures. Median days to close for the flaws that were exposed and exploited, separately from the rest.

Open past deadline, as a trend. The count of findings that blew their own deadline, month over month. A program that is working shows this falling even while total findings rise, because total findings track how much you can see.

Recurrence. How often a closed finding comes back on the same asset. Recurrence is a build and configuration problem wearing a vulnerability costume, and it is the metric that tells you to fix a process rather than buy more scanning.

Two more things belong in the report if you will ever face an auditor. A record of accepted risks, each with a name and a review date, and scan evidence retained long enough to cover the audit period. Both matter for a SOC 2 audit, where the question is not whether you had vulnerabilities but whether your stated process ran the way you said it did.

Key takeaways

  • Vulnerability management services cover discovery, scanning on a cadence, triage, tracking to closure and reporting. Applying patches, approving outages and accepting risk usually stay with you.
  • Managed does not mean fixed. Read the statement of work for the verb attached to remediation: recommend, guide and support all mean your team is patching.
  • Onboarding takes about a quarter. Discovery, credentialed scanning setup, a baseline scan and the first remediation cycle all happen before the service produces a number worth reporting.
  • Severity is not urgency. CVSS rates impact, EPSS estimates the probability of exploitation, and CISA's KEV catalog lists what is confirmed to be in use, at 1,699 entries in September 2026.
  • CISA's BOD 26-04 gives a free, public rubric: exposure, KEV status, exploit automation and technical impact set deadlines from three days to fix on next rebuild.
  • Two meters set the price, licensing per asset and service hours for triage. Comparing on price per asset rewards whoever plans the least human attention.
  • Own the scanner tenant and the finding history, or your remediation record and twelve months of trend data leave with the provider.
  • The FTC Safeguards Rule requires vulnerability assessments at least every six months absent continuous monitoring, and PCI DSS requires a passing external ASV scan every three months.
  • Measure coverage, time to remediate by urgency band, findings open past deadline, and recurrence. Total findings found is a measure of visibility, not of progress.

Common questions

What are vulnerability management services?

An ongoing engagement in which a provider discovers your assets, scans them on an agreed cadence, filters and ranks the findings, raises tickets with owners and deadlines, and verifies closure with a rescan. The output is a managed queue of prioritized work plus reporting an auditor can read. In most contracts the work of applying fixes remains with your team.

What is the difference between vulnerability scanning and vulnerability management?

Scanning is the automated step that produces a list of known flaws. Management is the loop around it: deciding which findings are real, choosing a risk response, getting the work done, proving it closed, and repeating on a cadence. CIS Control 7 frames the goal as minimizing the window of opportunity for attackers rather than producing lists.

Does a managed vulnerability management provider patch my systems?

Usually not, unless you bought remediation as a separate service. The federal equivalent states the boundary plainly: the Department of Justice service provides scanning, analysis and reporting and does not provide patching or flaw remediation. Managed patching does exist commercially, it is priced separately per endpoint, and it needs your outage approvals regardless.

How much do vulnerability management services cost?

There is no credible published benchmark, so treat any confident single figure as marketing. Price is set by two meters: licensing that scales with the number of assets under management, and service hours that scale with triage, review and reporting. Normalize competing quotes to the same asset count, cadence and module list, then compare the analyst hours underneath.

How long does it take to onboard a vulnerability management service?

Plan a quarter. Scope and discovery take two to three weeks, scanner deployment and credentialed scanning another two to four depending on how fast your team creates service accounts, then a baseline scan, a triage pass and a prioritization workshop before the first real remediation cycle. Steady state metrics start in month four.

What is vulnerability management as a service?

VMaaS is the same offering sold as a subscription, usually with the provider's tooling included rather than running on a scanner you already own. The trade is convenience against ownership: onboarding is faster because the platform is theirs, and leaving is harder because the license, the configuration, the exception list and the scan history are theirs too.

How often should vulnerabilities be scanned and remediated?

Cadence follows exposure. Internet-facing systems justify weekly or continuous scanning; the internal estate is commonly monthly. For remediation, adopt a published rubric rather than a flat rule. CISA's BOD 26-04 sets federal deadlines from three days for an exposed, actively exploited flaw that grants total control down to fixing on the next system upgrade for a low-risk internal one.

Can I use my own scanner with a managed provider?

Yes, and it is often the better structure. Co-managed and platform-agnostic providers work inside the tool you already license, which keeps the tenant, the configuration and the history on your side of the contract. Ask how many customers the provider runs on your specific platform, because familiarity with the tool is most of what you are paying for.

Should the same firm do vulnerability management and penetration testing?

It can, and it is worth keeping the decisions separate. The two answer different questions: scanning finds published flaws across everything continuously, while a penetration test is a person trying to chain weaknesses together inside a boundary you drew. A useful cross-check is to run the test findings against the scan output, because anything the scanner reported months earlier is a process failure worth more attention than the finding.

Is vulnerability management required by law?

Not in general, but it is required by specific rules. Companies covered by the FTC Safeguards Rule must run continuous monitoring or conduct vulnerability assessments at least every six months and after material changes. PCI DSS requires a passing external scan by an Approved Scanning Vendor at least once every three months. Most other obligations arrive through customer contracts and insurance questionnaires.

What metrics should a vulnerability management provider report?

Scan coverage as a percentage of discovered assets, median time to remediate split by urgency band rather than averaged, the count of findings open past their own deadline as a monthly trend, and the recurrence rate for findings that come back on the same asset. Ask separately for a register of accepted risks with a named owner and a review date on each.

On this page
Reviewed by

Daniel Reyes

  • CISSP
  • 12 years in security operations
  • Austin, TX

Daniel Reyes is a CISSP who spent twelve years in security operations, most recently leading a detection and response team for a mid-sized healthcare group in Texas. He reviews every resource and breach report on Cyber Security Firms for technical accuracy before it publishes.

Most of the people he has trained arrived having been told too much: a dozen acronyms, six vendors, and no clear idea which risk was theirs. His approach is to explain what an attack actually does before naming the tool that stops it, on the basis that most breaches start with something a reader could have recognised.

Read the full bio and how we research →