How to Evaluate a Managed Vulnerability Program Without Mistaking It for Another Scanner

Nina Okonkwo August 8, 2026

Editorial note: This is independent educational content. It does not present the publisher as a vulnerability-management provider, cybersecurity operator, assessor, or compliance authority. Provider capabilities cited below are examples of individual offerings, not endorsements or evidence of market-wide performance.

Vulnerability management as a service can sound like a simple purchase: connect a scanner, receive a dashboard, and let a provider handle the rest. In practice, VMaaS is not a standardized product. It is an operating model in which an external provider runs some or all of a recurring vulnerability-management program.

That distinction matters. A scanner can identify technical weaknesses, but it does not automatically determine business priority, assign accountable owners, coordinate approved changes, manage exceptions, or demonstrate that remediation worked. Those activities require technology, repeatable processes, organizational context, and decisions that often remain under the customer’s control.

A useful evaluation therefore starts with five questions:

Which assets and assessment methods are in scope?
Which lifecycle steps will the provider perform?
Which decisions and remediation duties remain with the customer?
How will findings become owned, verifiable work?
How will the service demonstrate reduced exposure rather than increased finding volume?

The answers reveal whether a proposal describes a managed program, managed scanning, or something in between.

What vulnerability management as a service actually means

Vulnerability management as a service generally means outsourcing some or all of an ongoing program for discovering, assessing, validating, prioritizing, treating, verifying, and reporting security weaknesses. Providers may also call it managed vulnerability management or Managed VM, but those labels do not reliably indicate scope.

One provider might administer scanners, analyze results, and send prioritized recommendations while the customer performs every production change. Another might create tickets, coordinate remediation workflows, or deploy specifically authorized changes. A third might focus almost entirely on public-facing assets. Buyers must evaluate the contracted activities rather than rely on the service name.

Concise definition

VMaaS is the outsourced operation of some or all of a continuous vulnerability-management program—not merely access to a cloud-hosted scanner.

A practical way to understand the service is to separate it into three layers.

1. Security technology

The technology layer can include scanners, agents, network probes, cloud connectors, application-security tools, asset databases, risk-prioritization systems, ticketing integrations, and reporting platforms. The exact combination depends on the assets and weakness types included in the contract.

Technology generates observations and supports workflow automation. It does not independently supply complete asset context, authorize downtime, determine whether an operational risk is acceptable, or decide whether a production change fits the customer’s governance process.

2. Provider-operated processes

The provider may configure and run assessments, review scan failures, validate selected findings, add threat context, recommend treatment, create tickets, monitor deadlines, escalate overdue work, rescan affected assets, and prepare operational or executive reports.

This process layer distinguishes a managed program from a software subscription. For example, SentinelOne describes its VMaaS model as a lifecycle involving onboarding, asset discovery, scanning, prioritization, remediation coordination, and validation rather than as a single scanning event (SentinelOne’s VMaaS lifecycle overview).

That example establishes what one provider describes, not a universal service definition. Every lifecycle activity still needs to appear in the proposal, statement of work, or contract schedule.

3. Customer-owned operational decisions

Even when direct remediation is available, the customer must define the provider’s authority and the controls governing its actions.

Retained authority is not necessarily a flaw in the service model. A provider may not possess the institutional knowledge needed to decide whether an application can restart during business hours, whether a legacy dependency can tolerate an upgrade, or whether a compensating control makes delayed remediation acceptable.

Continuous lifecycle versus individual assessment

A vulnerability assessment is generally a snapshot or scheduled exercise. It identifies weaknesses within a defined scope at a particular time. Vulnerability management is the recurring process that takes those observations through prioritization, treatment, verification, reporting, and improvement.

“Continuous” does not mean every asset is tested every minute. It describes an operating cycle that responds to changing assets, software, threats, and business context. Different activities can have different cadences: asset discovery may run frequently, intrusive application testing may be scheduled, and executive reporting may be monthly or quarterly.

Optional capabilities must remain explicit. Direct patch deployment, configuration changes, application testing, external attack-surface monitoring, automated penetration testing, and round-the-clock human analysis are not universal VMaaS features. If any capability is material to the purchase, it belongs in the scope and service levels—not in an assumption inferred from marketing language.

How VMaaS differs from scanners, assessments, penetration tests, patch management, and MDR

VMaaS overlaps with several security products and services, but it should not be treated as interchangeable with them.

Scanner versus VMaaS

A vulnerability scanner examines assets and produces technical findings. Depending on its capabilities, it may identify known vulnerabilities, missing updates, outdated software, weak configurations, or other detectable conditions.

A managed program adds recurring operations around those results: scanner administration, coverage monitoring, validation, contextual prioritization, owner assignment, remediation workflows, escalation, verification, and reporting. The scanner is an input to the program, not the entire program.

A tool-only deployment can still support an effective internal program. The difference is that the customer must supply the people, governance, workflow, and accountability.

Vulnerability assessment versus VMaaS

A vulnerability assessment answers, “What weaknesses can we identify in this scope now?” VMaaS should also be able to answer:

Which findings matter most?
Who owns each one?
What treatment is appropriate?
Which deadlines and escalation paths apply?
Was the treatment completed?
Does retesting show that the weakness remains?
Which recurring problems require systemic correction?

An assessment can be part of VMaaS, but it does not provide the complete management cycle by itself.

Penetration testing versus VMaaS

Penetration testing uses expert-led or automated techniques to attempt exploitation, investigate attack paths, or demonstrate how weaknesses can be combined within a defined scope. Vulnerability management generally seeks broader, repeatable discovery and treatment across an environment.

The two are complementary. Scanning may locate widespread known weaknesses efficiently, while a penetration test may expose exploitable chains, control failures, or business-logic issues that broad scanning does not reveal. Orca Security similarly describes vulnerability management as a recurring, broad process and penetration testing as a defined exercise involving attempted exploitation (Orca Security’s comparison).

Buying VMaaS should not lead an organization to cancel penetration testing without determining which assurance objectives would be lost.

Patch management versus VMaaS

Patch management distributes, installs, and tracks software updates. It is one treatment mechanism within vulnerability management.

Not every vulnerability is resolved by a patch. Treatment can also involve:

Changing a configuration
Removing or disabling a service
Isolating an asset
Updating a library or container image
Applying a temporary workaround
Using a web application firewall or intrusion-prevention rule as a compensating control
Restricting access
Accepting residual risk through an approved exception

Conversely, not every patch-management action starts with a vulnerability finding.

External attack-surface management versus VMaaS

It does not necessarily cover internal endpoints, private networks, cloud configurations, applications, code dependencies, remediation governance, or the complete verification cycle. An externally focused service can be a component of VMaaS, but buyers should not infer full internal coverage from claims about public attack-surface visibility.

MDR versus VMaaS

VMaaS focuses on identifying and treating weaknesses before or independently of an incident.

There can be useful overlap. MDR analysts may observe exploitation attempts, while vulnerability-management teams can use that intelligence to adjust priorities.

Comparison	Vulnerability scanner	Vulnerability assessment	Penetration test	Patch management	MDR	VMaaS
Primary purpose	Detect supported technical weaknesses	Identify and classify weaknesses in a defined scope	Attempt exploitation and investigate attack paths	Deploy and track updates	Detect and respond to threats and incidents	Operate contracted parts of the vulnerability-management lifecycle
Cadence	Scheduled or recurring	Point-in-time or periodic	Time-bounded	Recurring and release-driven	Ongoing monitoring	Recurring lifecycle
Typical output	Technical findings	Assessment report	Exploit evidence and attack-path findings	Deployment and patch-status records	Alerts, investigations, and response actions	Prioritized work, ownership records, exceptions, verification, and reporting
Remediation role	Usually limited	Usually recommends action	Usually recommends action	Implements one treatment type	May contain active threats	Contract-dependent, from advice to authorized implementation
Verification practice	A rescan may be available	Sometimes included	Retesting may be separate	Confirms deployment, not necessarily removal of exposure	Verifies response actions rather than vulnerability closure	A capability buyers should require, but some managed-scanning services exclude it

The table describes typical distinctions, not universal terms. Providers can bundle adjacent services, so every capability requires scope confirmation.

The VMaaS lifecycle, from onboarding to verified remediation

A credible managed service should explain what happens after signature in operational terms. The lifecycle commonly includes onboarding and scoping, discovery, assessment, validation, prioritization, remediation coordination, verification, reporting, and continual improvement.

Onboarding and scoping

Onboarding establishes the operating boundary. Before scanning begins, the parties should confirm:

Included business units, subsidiaries, locations, and environments
Authoritative and provisional asset inventories
Asset owners and technical support teams
Required credentials and responsibility for protecting them
Agents, appliances, network probes, and cloud connections
Permitted and prohibited assessment techniques
Maintenance constraints and approved assessment windows
Ticketing, ITSM, CMDB, and reporting systems
Escalation contacts and communication channels
Applicable contractual and data-handling constraints
Known fragile, unsupported, or safety-sensitive systems

A focused initial scope can be appropriate, particularly for critical systems, provided expansion is planned and exclusions remain visible. The NCSC says vulnerability management involves IT operations, security, and risk teams, and organizations may need to involve senior leaders Vulnerability management | Guidance | National Cyber Security Centre.

Asset discovery

Discovery may combine agents, authenticated network scanning, unauthenticated scanning, cloud-platform connections, CMDB imports, endpoint-management data, container and registry integrations, DNS information, and external attack-surface techniques.

No individual method guarantees a complete inventory. Agents can miss unmanaged devices. Network scans may not reach segmented or intermittently connected systems. Cloud connections can be limited to selected accounts. CMDB records can become stale.

The provider should therefore report both discovered assets and discovery uncertainty. Unknown ownership, duplicate records, inaccessible networks, stale assets, failed connections, and conflicting identifiers are operational issues to resolve—not noise to hide.

Assessment

Assessment methods should match the contracted asset classes. Depending on scope, the service may identify:

Known CVEs
Missing security updates
Unsupported or outdated software
Insecure configurations
Weak network services
Outdated libraries and dependencies
Cloud configuration problems
Container-image weaknesses
Application vulnerabilities
Exposed public services

Application testing, source-code analysis, dependency analysis, container scanning, and cloud configuration assessment are distinct methods. None should be presumed merely because “applications” or “cloud” appears in a proposal.

Analyst validation and enrichment

Human analysis can add value by reviewing significant findings, investigating suspected false positives, checking whether detection evidence is credible, adding business context, and escalating urgent exposures.

The provider may validate only selected severity levels or asset classes. Buyers should ask which findings receive analyst review, what evidence is examined, and whether validation is performed before or after a ticket is created.

Validation does not mean zero false positives. Nor does it necessarily prove exploitability in production. The expected evidence level should be defined, such as:

Scanner evidence
Package or software version
Configuration observation
Safe manual verification
Controlled exploitation where separately authorized

Risk prioritization

Validated findings should be ranked using technical severity, exploitation evidence, exposure, asset importance, existing controls, and business impact. Priority should then translate into a treatment deadline and escalation path rather than remain only a dashboard score.

Remediation coordination

A managed finding becomes operationally useful when it turns into owned work. Depending on scope, the provider may:

Assign an owner or route the issue to an ownership queue
Create or update a ticket
Include affected assets and detection evidence
Recommend a patch, configuration change, or mitigation
Set a due date based on customer policy
Track dependencies and maintenance constraints
Escalate overdue or actively exploited issues
Record an exception when immediate treatment is not possible

Treatment can include patching, reconfiguration, isolation, temporary workarounds, virtual patching, compensating controls, service retirement, or documented risk acceptance. The appropriate choice depends on the system, available fix, operational context, and authorized decision-maker.

Verification

A ticket marked “done” records a workflow state. It does not demonstrate that exposure was removed.

Verification should use rescanning or another suitable retest to determine whether the weakness remains detectable. One affected asset may have been corrected while another was missed. If the organization selects a compensating control, the record should distinguish that treatment from patching the underlying vulnerability.

Follow-up scanning is commonly described as the verification step in vulnerability-management workflows, including Sophos’s lifecycle explanation (Sophos’s vulnerability-management workflow).

Reporting and continual improvement

Operational reports should show coverage gaps, failed assessments, urgent findings, ownership status, aging, exceptions, and verified closure. Executive reports should emphasize meaningful exposure and process bottlenecks rather than raw technical volume.

Continual improvement asks why findings recur. Repeated insecure images may point to a build-process problem. Recurring configuration drift may suggest that deployment templates need review. Persistent overdue tickets may indicate unclear ownership or inadequate change capacity rather than poor scanning.

Example: an actively exploited internet-facing vulnerability

Consider a vulnerability confirmed as actively exploited and detected on a public, business-critical service.

A defensible workflow would be:

Confirm that the asset and vulnerable component are genuinely affected.
Determine whether the service is internet-accessible and whether existing controls alter exposure.
Notify the asset owner and designated security contact.
Recommend a temporary mitigation if an approved fix cannot be applied immediately.
Create a critical ticket containing evidence, affected assets, required actions, and the applicable deadline.
Coordinate the authorized change with the responsible IT or application team.
Rescan or retest after treatment.
Escalate unresolved assets, failed changes, or exceptions to the designated risk authority.

The provider can operate much of this workflow, but only the contract and responsibility model determine who may change production.

Risk-based prioritization: deciding what must be fixed first

A flat “patch everything” queue is operationally weak. Remediation capacity is limited, and findings vary in exploitability, exposure, business consequence, and treatment difficulty. Severity-only ranking is also incomplete because technical impact does not directly express whether exploitation is likely or what the affected asset means to the organization.

CVSS is an input, not the decision

The Common Vulnerability Scoring System provides a standardized way to describe technical severity. It can help compare the intrinsic characteristics of vulnerabilities, but it is not a complete measure of organization-specific risk.

A high-severity vulnerability on an isolated laboratory system may not warrant the same response as a lower-scoring weakness exposed on a public identity service. Severity still matters; it needs context.

EPSS and known exploitation

EPSS estimates the likelihood that a published vulnerability will be exploited in the wild during the model’s defined future window. CISA’s Known Exploited Vulnerabilities catalog serves a different purpose: it identifies vulnerabilities confirmed as exploited in the wild. A vendor-authored overview explains how CVSS, EPSS, and KEV can contribute different signals to risk-based prioritization (overview of CVSS, EPSS, and KEV).

Because that overview is not the primary specification for those systems, buyers should confirm model definitions, update cadence, and catalog status through the authoritative sources used by the provider.

A defensible priority model can combine:

CVSS or another technical-severity measure
EPSS or other exploitation-likelihood information
CISA KEV status
Current threat intelligence
Evidence of exploitation attempts
Internet or partner-network exposure
Asset criticality
Data sensitivity
Business or safety impact
Identity privileges and attack-path relevance
Existing preventive or compensating controls
Availability of a suitable fix
Remediation effort and operational disruption

No single factor settles every case. KEV status can justify urgent attention, but the team still needs to determine whether the organization runs the affected product and component. An EPSS value can help allocate scarce effort, but it remains probabilistic.

A qualitative example

Suppose the queue contains:

An actively exploited vulnerability on a public system supporting a critical customer process
A higher-CVSS vulnerability on an isolated, low-value test asset with limited connectivity

The first finding may deserve immediate mitigation even though its technical score is lower. Its known exploitation, exposure, and business importance create greater urgency.

That does not make the second finding harmless. It can remain scheduled for treatment under the applicable policy. Risk-based prioritization determines order and urgency; it does not erase lower-priority obligations.

Treat proprietary scores carefully

A provider’s proprietary risk score may combine useful signals and simplify a large queue. Buyers should not assume it is objectively superior merely because it is proprietary or presented with greater numerical precision.

Ask:

Which data sources influence the score?
How frequently are those sources updated?
How are internet exposure and asset importance represented?
Can customer risk appetite change the ranking?
Can the customer define critical applications, data, or identities?
How are compensating controls reflected?
Can an analyst override the score?
Is the override reason recorded and reviewable?
Can users see the factors contributing to a priority?
How does the model handle missing context?

A score that cannot be explained may be difficult to defend during an incident, audit, or disagreement over remediation order. The model should support accountable judgment rather than replace it.

Risk-based prioritization remains imperfect. Threat intelligence can be incomplete, asset data can be stale, and exploitation forecasts can be wrong. Its purpose is to allocate limited remediation capacity more rationally—not to predict every attack.

Who does what: the shared-responsibility model

Remediation responsibility is one of the most important contractual distinctions in VMaaS. “Remediation support” can mean advice, ticket creation, workflow orchestration, direct implementation, or post-change verification. Those are separate deliverables.

A responsibility matrix should identify who performs the work, who approves it, who must be consulted, and who remains accountable.

Lifecycle activity	Provider	Security team	IT operations	Development or application team	Asset owner	Executive or risk authority
Define scope and policy	Advises and documents contracted scope	Leads security requirements	Identifies operational constraints	Identifies application scope	Confirms business assets	Approves risk posture where required
Discover assets	Runs contracted methods and reports gaps	Reconciles security inventory	Supplies infrastructure records and access	Supplies application and service data	Confirms ownership	Reviews material blind spots
Run assessments	Operates approved tools and scans	Oversees policy and exceptions	Supports access, credentials, and scheduling	Supports application testing	Coordinates business constraints	—
Validate findings	Reviews selected findings	Interprets and challenges results	Confirms versions and configurations	Confirms code or dependency details	Supplies business context	—
Prioritize	Adds threat and exposure context	Owns risk methodology	Advises remediation feasibility	Advises application impact	Defines business criticality	Resolves major priority conflicts
Create remediation work	Creates or updates tickets if included	Sets deadlines and escalation rules	Accepts infrastructure assignments	Accepts application assignments	Ensures accountable ownership	—
Approve production change	Acts only under delegated authority	Advises on security impact	Commonly owns infrastructure approval	Commonly owns application approval	Accepts business disruption	May approve exceptional changes
Implement treatment	Advises, orchestrates, or changes systems only if authorized	May implement security controls	Commonly patches and reconfigures infrastructure	Commonly fixes code and dependencies	Coordinates service impact	—
Accept residual risk	Records the exception	Evaluates security implications	Documents operational constraints	Documents technical constraints	Sponsors acceptance where policy requires	Formally approves according to policy
Verify closure	Rescans or retests if contracted	Reviews evidence	Confirms operational state	Confirms application state	Confirms service outcome	Reviews significant unresolved risk
Report and improve	Produces service reporting	Owns program improvement	Addresses process bottlenecks	Addresses recurring engineering causes	Reviews business exposure	Provides oversight

This is a typical allocation, not a universal one. A co-managed service might use the customer’s scanners and ticketing platform. A broader service might deploy selected changes. GuidePoint, for example, describes fully or partially administered, co-managed, remote, on-premises, and staff-augmentation arrangements (GuidePoint’s VMaaS delivery models).

Questions for direct provider remediation

If the provider may change production, the agreement should answer:

Which systems and change types are permitted?
Who approves each category of change?
What testing evidence is required?
Which customer backup and recovery requirements apply?
What rollback information must accompany the change?
Which assessment or change windows apply?
How is segregation of duties handled?
What emergency authority, if any, is delegated?
Who can stop work if adverse effects appear?
Who must be notified?
What logs and evidence must be retained?
Who coordinates service recovery if a change fails?

These are due-diligence questions, not universal procedures. The customer should align the answers with its own change-management, resilience, safety, and operational requirements.

Exception governance

Some findings cannot be resolved immediately. A fix may be unavailable, a vendor may no longer support the system, or the organization may decide that immediate treatment creates an unacceptable operational consequence.

Every delayed or accepted risk should record:

An accountable approver
The affected assets and finding
The reason for delay or acceptance
Any compensating controls
The planned treatment, if one exists
A review date
An expiration or reassessment point
Conditions that trigger earlier review

The NCSC states that decisions not to update should be treated as organizational risk decisions rather than left implicitly with a technical team.

Outsourcing operations does not outsource accountability. Weak asset ownership, insufficient remediation capacity, and slow approval processes can prevent a well-operated service from reducing exposure.

Contract negotiations should force direct answers:

Who can change production?
Who coordinates response to an outage associated with remediation?
Who tests patches and application behavior?
Who approves emergency changes?
Who approves exceptions?
What happens when no patch exists?
Who selects and validates compensating controls?
Who verifies closure?
Who resolves a disagreement over priority?

Choosing between in-house, tool-only, managed scanning, co-managed, and fully managed models

The right model depends on internal expertise, desired control, environment complexity, remediation capacity, and governance maturity. “More managed” is not automatically better.

Model	Internal expertise required	Operational control	Provider involvement	Remediation ownership	Customization	Governance burden
Internally operated program	High	Highest	Minimal	Customer	High	Entirely internal
Tool-only subscription	High	High	Software support and updates	Customer	Often high	Customer designs and operates the program
Managed scanning	Moderate	High	Scanner setup and operation	Usually customer	Moderate	Customer owns prioritization and treatment governance
Co-managed VMaaS	Moderate	Shared	Runs defined lifecycle functions	Shared or customer-led	Often flexible	Shared, with clear interfaces required
Fully managed VMaaS	Lower for routine operations, but governance expertise remains necessary	Lower day-to-day control	Operates more of the lifecycle	Contract-dependent	May be standardized	Provider runs operations; customer retains oversight and approvals

Internally operated program

An internal model offers maximum control and customization. It can suit organizations with experienced security engineering, reliable asset data, established workflows, and sufficient remediation capacity.

Its challenge is not merely buying tools. The organization must maintain scanning infrastructure, tune assessments, track failures, interpret findings, integrate workflows, manage exceptions, verify treatment, and report results.

Tool-only subscription

A tool-only approach can fit a mature team that already knows how to operate the lifecycle. It preserves control and may integrate closely with internal engineering practices.

The subscription does not replace program ownership. If findings accumulate without context, owners, deadlines, and verification, the organization has purchased detection capacity rather than vulnerability management.

Managed scanning

It can be useful when the main gap is tool operation.

However, it may stop before contextual prioritization, remediation coordination, exception governance, and verified closure. Buyers should determine whether the deliverable is a scan report or an operated treatment workflow.

Co-managed VMaaS

A co-managed service lets the provider run selected functions while internal teams retain tools, institutional context, remediation control, or specialized expertise.

For example, the provider might administer scans, validate significant findings, and create prioritized tickets. Internal security defines policy, IT deploys infrastructure fixes, and developers correct application issues. This model can balance external capacity with internal knowledge, but only if handoffs are explicit.

Fully managed VMaaS

A fully managed offering may administer discovery, scanning, validation, prioritization, workflow creation, reporting, and verification. It can reduce routine operational load and create more consistent processes.

“Fully managed” still does not necessarily mean the provider deploys every fix. Those retained duties should be listed rather than hidden behind the label.

Fit and caution signals

Outsourcing may fit when an organization has:

Limited vulnerability-management specialists
Fragmented tools
Hybrid or cloud complexity
Inconsistent asset discovery
Recurring reporting obligations
An immature operating process
Too little capacity for scanner administration and finding analysis

Proceed cautiously when the environment includes:

Highly specialized or unsupported technology
Strict production-change controls
Fragile or safety-sensitive systems
Unclear asset ownership
Inadequate remediation capacity
Extensive custom workflows
Restrictions that prevent provider access

Four example operating choices

Small security team: Managed scanning or co-managed VMaaS may remove routine scanner administration and triage while internal IT retains patch deployment. The key test is whether the service creates actionable work rather than periodic reports.

Regulated hybrid organization: A co-managed model may preserve internal governance and production control while the provider supplies assessment operations, evidence trails, and recurring reporting. Regulatory and contractual requirements should be evaluated separately by qualified internal or external authorities.

Cloud-native engineering company: A co-managed service can connect cloud accounts, registries, CI/CD workflows, and development tools while engineering teams retain code and infrastructure-as-code remediation. The provider should fit the development workflow rather than impose a disconnected queue.

Fragile legacy environment: The organization should ask candidates how they test assessment profiles, define exclusions, control assessment intensity, monitor adverse effects, stop activity, and coordinate recovery. The answers should be evaluated against the organization’s own operational and safety requirements rather than treated as standardized VMaaS practice.

The VMaaS buyer checklist: scope, integrations, SLAs, security, and cost

A useful request for proposal or contract schedule should turn broad service language into testable commitments.

Define the asset scope

Ask whether the service includes:

Employee endpoints and remote devices
Servers and network equipment
Internal and public networks
Public domains, hosts, and services
Cloud accounts, subscriptions, and projects
Virtual machines and workloads
Containers and registries
Web applications and APIs
Code and third-party dependencies
Identities and privilege-related exposures
Subsidiaries and acquired environments
Third-party-managed assets
Unsupported legacy systems

For every exclusion, identify who will cover it and how the exclusion will appear in reporting.

Define assessment methods

Confirm which methods are included:

Credentialed scanning
Unauthenticated scanning
Agent-based assessment
Network probes or appliances
External discovery
Cloud configuration assessment
Container and registry scanning
Application scanning
Source-code or dependency analysis
Safe validation or exploitation testing

Do not treat these methods as interchangeable. Ask what each method can observe, what access it requires, which asset classes it supports, and whether it is standard or separately priced.

Address fragile-system and scan-safety questions

For systems that may react poorly to assessment activity, ask:

How does the provider identify potentially sensitive systems before scanning?
Can assessment profiles be tested in a representative non-production environment?
How are rate limits or other intensity controls selected?
Which checks require explicit approval?
How are adverse effects monitored during an assessment?
Who can invoke a stop condition?
What communication path applies if a system becomes unstable?
How are disrupted assessments and recovery actions documented?
How are excluded checks and resulting visibility gaps reported?
Who accepts the residual risk created by an exclusion?

The contract should record the agreed answers. It should not assume that one assessment profile is appropriate for every asset.

Specify cadence and coverage language

Document the frequency of:

Asset discovery
Vulnerability scanning
Cloud and agent data collection
Threat-data updates
Analyst review
Reporting
Retesting
Exception review

Clarify whether “continuous” or “24/7” describes automated data collection, platform availability, alerting, human analyst coverage, or a combination. A portal that is always available is not the same as continuous human review.

Define meaningful SLAs

For actively exploited or critical findings, request separate commitments for:

Initial validation
Customer notification
Escalation
Ticket creation
Remediation guidance
Follow-up contact
Rescanning or retesting

Avoid collapsing these steps into one response-time promise. Fast notification is useful, but it does not establish that the finding was assigned, treated, or verified.

Also define what pauses an SLA. Missing credentials, inaccessible assets, absent owners, and customer-deferred changes should be recorded explicitly rather than silently omitted from performance reporting.

Evaluate integrations

Assess integration with:

Ticketing and ITSM platforms
CMDBs and asset repositories
Cloud platforms
Endpoint-management systems
CI/CD pipelines
Development tools
Existing scanners and vulnerability platforms
Reporting and business-intelligence systems

Confirm whether each integration is one-way or bidirectional, standard or custom, and included or separately priced. Ivanti, for example, describes built-in workflows and bidirectional integrations for assignments and remediation tickets, but that is a provider-specific capability rather than a universal feature (Ivanti’s workflow and integration description).

Require coverage-quality reporting

Ask how the provider handles:

Failed authenticated scans
Expired or rejected credentials
Inaccessible assets
Duplicate records
Stale inventory
Scanner errors
Unsupported systems
Unmapped ownership
Newly discovered assets
Assets that disappear between assessments

Coverage reporting should make that distinction visible.

Conduct provider-security due diligence

The provider and its technology may receive sensitive infrastructure data or privileged access. Due diligence questions should cover:

Data residency and retention
Encryption in transit and at rest
Tenant isolation
Privileged-access controls
Personnel access
Audit logs
Subcontractors
Incident-response procedures
Credential storage and rotation
Compromised scanner, agent, connector, or account scenarios
Breach notification terms
Secure deletion
Administrative-session monitoring

Ask how the provider and customer would detect, contain, and investigate compromise of a scanner credential, agent, connector, or management account. Responsibilities should be explicit on both sides.

Make remediation language precise

Separate these deliverables:

Recommendation: The provider explains what should change.
Orchestration: The provider initiates or coordinates a workflow.
Patch deployment: The provider installs an approved update.
Configuration change: The provider modifies a system or control.
Compensating control: The provider recommends or implements an interim safeguard.
Exception handling: The provider records and tracks accepted or delayed risk.
Validation: The provider retests after treatment.

A contract promising “remediation assistance” without defining these activities leaves the most important responsibility ambiguous.

Model total cost

Do not compare subscription charges alone. Include:

Onboarding and implementation
Asset or application limits
Additional assessment types
Appliances, agents, or infrastructure
Standard and custom integrations
Analyst-hour allowances
Retained internal security labor
IT and developer remediation effort
Operational disruption and maintenance windows
Governance and audit effort
Contract changes as the environment grows
Switching and offboarding costs

Treat downstream costs as scenarios to model rather than guaranteed savings or losses. For example, estimate the internal effort required to reconcile assets, reroute tickets, investigate false positives, and prepare evidence under each proposed service model.

Plan the exit before signing

Offboarding terms should cover:

Export of findings and historical status
Export formats and field definitions
Open tickets and ownership records
Exception and risk-acceptance records
Verification evidence
Integration removal
Credential revocation
Agent and appliance removal
Evidence-retention periods
Provider data deletion
Assistance during transition

Pilot against acceptance criteria

A pilot should test the operating model, not simply whether the scanner finds vulnerabilities. Agree in advance on criteria such as:

In-scope asset coverage
Critical-asset identification
Authenticated-scan success
Visibility of failed or inaccessible assets
Quality of analyst validation
Actionability of recommendations
Accuracy of ownership routing
Ticketing integration
Urgent escalation quality
Rescanning and verified remediation
Reporting usefulness

Use representative assets, including at least one difficult environment or workflow.

How to measure VMaaS performance—and recognize its limits

Raw vulnerability counts are weak standalone measures. A higher count can mean the service discovered previously invisible assets or improved authenticated coverage. A lower count can mean remediation succeeded, but it can also mean scans failed or scope narrowed.

Closed-ticket totals are equally ambiguous. A ticket may close because a patch was scheduled, an asset disappeared from inventory, an exception was approved, or someone changed the workflow state. None of those events alone demonstrates that the exposure was removed.

Build a practical dashboard

A useful VMaaS dashboard can include:

Percentage of in-scope assets discovered
Coverage of critical assets
Authenticated-scan success
Number and age of inaccessible assets
Vulnerability age
Time to verified remediation
Exploitable-risk backlog
Recurring and reopened findings
SLA attainment
Exception volume and age
Configuration or policy drift

Microsoft identifies measures such as asset coverage, backlog trends, remediation time, and resolution within SLA as useful vulnerability-management indicators (Microsoft’s vulnerability-management metrics overview).

Segment the dashboard by:

Asset criticality
Internet exposure
Known exploitation
Business unit
Vulnerability age
Environment
Owner
Treatment status

Measure the complete workflow

Track time between:

Discovery
Validation
Owner assignment
Mitigation or remediation
Verified closure

These intervals reveal where the process stalls. A provider may validate quickly while tickets wait for ownership. IT may deploy patches promptly while rescanning is delayed. A business unit may repeatedly miss deadlines because it lacks an approved maintenance opportunity.

Measure recurring misconfigurations and reopened findings as well. Recurrence can indicate an unresolved build or configuration problem. Reopened findings can expose partial remediation, verification failures, or unstable asset records.

Treat compliance reporting as supporting material

Some providers describe VMaaS reporting as supporting programs associated with PCI DSS, HIPAA, ISO 27001, or NIST guidance by producing scan records, remediation histories, exception records, or verification evidence (example of provider-described compliance reporting).

That description is a provider claim, not an authoritative interpretation of any framework. Whether particular evidence satisfies a PCI DSS, HIPAA, ISO 27001, NIST-related, contractual, or regulatory requirement depends on the applicable version, scope, control design, implementation, evidence rules, and relevant assessor or authority. Buyers should obtain framework-specific advice rather than infer compliance from the VMaaS label.

Recognize the limits

VMaaS cannot guarantee:

Complete asset discovery
Zero false positives
Prevention of attacks
Automatic risk reduction
Successful remediation
Safe changes in every environment
Continuous human analysis
Compliance
Elimination of every vulnerability

Results depend on accurate inventory, assigned owners, provider access, remediation capacity, change governance, business cooperation, and regular review.

Quarterly service reviews should examine:

Scope changes
Unresolved exceptions
Failed and unauthenticated scans
SLA trends
Priority-model tuning
Integration health
Recurring findings
Ownership gaps
Upcoming migrations, acquisitions, or retirements

Frequently asked questions

Does vulnerability management as a service include patching?

Sometimes, but not universally. A provider may offer recommendations, create tickets, orchestrate patch workflows, deploy specifically authorized changes, or only verify changes implemented by the customer.

The contract should state who tests, approves, deploys, reverses, and verifies each change. If direct patching is included, the customer should define the applicable change-management, recovery, authorization, and escalation requirements. Customers commonly retain authority over production changes and formal risk acceptance unless those duties are explicitly delegated.

What is the difference between VMaaS and a vulnerability assessment?

A vulnerability assessment is generally a point-in-time or periodic exercise that identifies and classifies weaknesses in a defined scope. VMaaS operates some or all of the recurring management cycle around those findings.

That cycle can include discovery, assessment, validation, prioritization, assignment, remediation coordination, exception management, rescanning, reporting, and improvement. Rapid7 similarly describes assessment as a component within the broader vulnerability-management cycle (Rapid7’s assessment and management comparison).

How does VMaaS prioritize vulnerabilities?

A mature service should combine technical severity with exploitation likelihood, confirmed exploitation, threat intelligence, internet exposure, asset criticality, data sensitivity, business impact, existing controls, and remediation feasibility.

Buyers should ask how those inputs are weighted, updated, and explained. Customer-specific asset context and risk tolerance should be able to affect the ranking. Analyst overrides should be documented. No risk score is perfectly predictive, so prioritization should guide accountable decisions rather than operate as an unquestioned automatic verdict.

Can VMaaS make an organization compliant with PCI DSS, HIPAA, ISO 27001, or NIST guidance?

VMaaS should not be purchased on that assumption. A service may generate assessment records, remediation histories, exception records, coverage reports, and verification evidence, but the relevance and sufficiency of that material are specific to the applicable requirement and scope.

The customer should have qualified legal, compliance, audit, or framework specialists determine what is required. A provider’s statement that its reports “support compliance” does not establish that the organization has identified, implemented, and demonstrated every applicable obligation.

What should a VMaaS pilot measure?

A pilot should measure whether the service can operate effectively in the customer’s real environment. Useful criteria include:

In-scope and critical-asset coverage
Authenticated-scan success
Visibility of failed scans and inaccessible assets
Quality of analyst validation
Actionability and prioritization of findings
Correct owner assignment
Ticketing and workflow integration
Urgent escalation quality
Time from discovery to validated, owned work
Successful retesting and verified remediation
Clarity of operational and executive reporting

The pilot should include representative complexity, not only easy-to-scan systems. Its acceptance criteria should be agreed before work begins so the decision is based on observable performance rather than presentation quality.

Conclusion

VMaaS should be purchased as an accountable operating model, not as a promise that another scanner or dashboard will solve vulnerability risk. The right engagement defines what is in scope, who owns each lifecycle step, how priorities are calculated, what remediation assistance means, how urgent findings are escalated, and how treatment is verified.

Buyers should compare service models against their internal expertise, operational control, remediation capacity, and governance requirements. The strongest evidence of value is not finding volume. It is coverage of critical assets, visibility into assessment failures, aging of exploitable risk, quality of ownership workflows, disciplined exception handling, and verified remediation.