Vulnerability management: a practical guide for IT teams and MSPs

Most organizations have some form of vulnerability management. A quarterly scan, a patching process of some kind, an annual penetration test for compliance. What most organizations don’t have is a programme rigorous enough to actually reduce their exposure.

A quarterly scan with a report nobody acts on is not vulnerability management. Neither is patching when things break. Neither is a single annual penetration test that satisfies a checkbox and then sits in a folder. Effective vulnerability management is a continuous, data-driven process of finding, prioritizing, and remedying weaknesses in an IT environment before attackers exploit them, and doing it fast enough that the exploitation window stays narrow.

According to the 2026 Kaseya State of the MSP Report, 53% of MSPs cite cybersecurity issues as a top business concern. Unpatched vulnerabilities are the most common reason those concerns escalate into incidents. Download the full report.

What is vulnerability management?

Vulnerability management is the ongoing process of identifying, evaluating, treating, and reporting on security vulnerabilities across an organization’s IT environment. It covers software vulnerabilities (missing patches, unpatched CVEs), configuration weaknesses (default credentials, unnecessary open ports, insecure service configurations), and asset visibility gaps (devices present in the environment that aren’t being monitored or managed).

The process is continuous because the vulnerability landscape is continuous. New CVEs are published daily. Assets change. Software is installed, updated, and removed. The environment at the end of this month is materially different from the environment at the start of it, and a vulnerability program needs to reflect that reality rather than providing a point-in-time snapshot that’s outdated before the report is distributed.

This is the distinction that separates a vulnerability management program from a vulnerability assessment. An assessment identifies what’s present at a moment in time. A program continuously identifies, prioritizes, remediates, and verifies across a changing environment.

The vulnerability management lifecycle

Every vulnerability management program, regardless of tooling or scale, follows the same operational cycle.

Discovery and inventory is the foundation. You can’t protect what you don’t know about. Complete asset discovery, including devices that weren’t formally enrolled, shadow IT, cloud instances, and IoT devices, is what makes scanning meaningful. Discovery that runs continuously rather than periodically is more effective, because new assets and new vulnerabilities appear between scan cycles, and a scan of an incomplete inventory produces an incomplete picture.

Scanning and assessment tests assets against databases of known vulnerabilities (CVEs) and configuration standards. The distinction between authenticated and unauthenticated scanning is critical. Unauthenticated scanning from the network edge sees what an external attacker sees. Authenticated scanning, where the scanner logs into systems to assess their internal state, provides significantly more complete results. Most serious vulnerability management programs run both.

Prioritization determines the order of remediation. Not all vulnerabilities are equal urgency, and the volume of findings in any real environment is large enough that prioritization quality matters more than total scanning coverage. The frameworks that work are covered in detail below.

Remediation is where the program delivers value. The most common remediation is patching, but vulnerabilities can also be addressed through configuration changes, compensating controls, or isolation of affected assets when immediate patching isn’t possible. Remediation should have defined SLA windows by risk tier, not a single uniform timeline that treats a critical CVE with an active exploit the same as a low-severity configuration finding.

Verification closes the loop. After remediation actions are taken, scanning should confirm that vulnerabilities have been effectively addressed. Patches that didn’t apply correctly, configurations that reverted, or compensating controls that didn’t work as expected leave organizations believing they’ve remediated something they haven’t. Verification is what converts remediation activity into confirmed risk reduction.

Reporting serves multiple audiences. Technical teams tracking remediation progress need granular, actionable data. Management reporting on security posture needs trend data that shows exposure over time. Compliance audiences need evidence of ongoing vulnerability management practice. A program that produces only one of these report types is undercutting its own usefulness.

Vulnerability scanning vs penetration testing

These two practices are complementary and frequently confused, and using one as a substitute for the other is a common program design error.

Vulnerability scanning is automated, broad, and continuous. It identifies known vulnerabilities across all assets in scope, generates a prioritized list of findings, and provides the operational data for remediation tracking. It doesn’t attempt exploitation. It tells you where weaknesses exist, not whether those weaknesses are actually exploitable by a skilled attacker in your specific environment.

Penetration testing is manual or semi-automated, narrow, and periodic. A skilled tester attempts to exploit vulnerabilities, including chains of lower-severity issues that individually look manageable but combine to create meaningful access, to demonstrate real-world attack paths. Penetration testing validates whether your defenses hold against a skilled attacker, not just whether vulnerabilities exist.

Both are valuable, and they answer different questions. Vulnerability scanning is the continuous operational program that keeps exposure current. Penetration testing, typically conducted annually or before significant architectural changes, answers whether the operational program is actually working. Using a pentest as a substitute for continuous scanning is a common substitution error, the point-in-time nature of a test means it misses vulnerabilities introduced after the test date, which in a typical environment is most of them within 90 days.

rioritization: how to decide what gets fixed first

The goal of prioritization isn’t the lowest total CVE count. It’s reducing the vulnerabilities most likely to be exploited before you can patch them all, because in any real environment, you can’t patch them all simultaneously.

The two variables that matter most are exploitability and asset criticality. A CVSS score is a useful starting point but an incomplete signal on its own. A CVSS 9 vulnerability for which no public exploit exists is less urgent than a CVSS 7 vulnerability that CISA’s Known Exploited Vulnerabilities (KEV) catalog lists as actively being exploited in the wild. The KEV catalog is the most authoritative public reference for active exploitation status, and any vulnerability on it should be treated as a Tier 1 item regardless of its CVSS score.

A practical four-tier framework:

Tier 1, patch within 24 to 72 hours: Critical CVSS vulnerabilities on internet-facing or high-privilege assets; any entry in the CISA KEV catalog; vulnerabilities confirmed as being actively exploited based on threat intelligence.

Tier 2, patch within 7 days: High CVSS vulnerabilities; vulnerabilities with published proof-of-concept exploits; any vulnerability on assets holding sensitive data or enabling privileged access.

Tier 3, patch within 30 days: Medium-severity vulnerabilities on standard endpoints.

Tier 4, address in maintenance cycle: Low-severity vulnerabilities without active exploitation evidence.

Vulnerabilities that can’t be patched within tier timelines (business-critical application compatibility constraints, client change-approval processes) should be formally documented with compensating controls applied and aging alerts set. An undocumented “we’ll get to it” is an exposure that grows without anyone tracking it.

Vulnerability management for MSPs

MSPs managing vulnerability programs across multiple client environments need the same core capabilities as single-organization IT teams, with three additional requirements: multi-tenancy, per-client reporting, and a prioritization layer that can surface the most urgent items across a combined estate.

The per-client prioritization challenge is where scale makes a real difference. An MSP supporting 40 client environments running a quarterly vulnerability scan may surface several hundred high-severity CVEs across the combined estate. Without a framework that immediately identifies which findings are CISA KEV entries and which assets are highest criticality, the report is overwhelming and the program defaults to “patch whatever is easiest.” With one, the first-day list is manageable: a specific set of critical findings requiring 24-to-72-hour remediation, sorted by client, with everything else triaged into weekly and monthly queues.

The practical infrastructure for MSP-scale vulnerability management includes standardized scanning policies applied consistently across client environments with per-client customization for scan timing, scope, and credentials; per-client vulnerability dashboards giving account managers visibility into current exposure and remediation velocity; client-facing reports suitable for QBR conversations that translate CVE lists into business-context risk language; and SLA-linked remediation tracking that demonstrates patching velocity and provides evidence that agreed timelines are being met.

VulScan, part of the Kaseya family through RapidFire Tools, provides network vulnerability scanning purpose-built for MSPs, with automated discovery and CVE identification across client networks. Kaseya VSA 10 and Datto RMM handle the patch deployment side, turning identified vulnerabilities directly into remediation workflows. IT Glue holds the asset context and documentation that makes prioritization against asset criticality accurate rather than guesswork.

Explore how Kaseya VSA 10’s patch management integrates with vulnerability discovery.

Common failure modes

Vulnerability management programs fail in predictable ways. Knowing the patterns makes it easier to avoid them.

Scanning without acting. Vulnerability reports that generate findings but don’t feed a remediation workflow have no security value. A long list of CVEs with no assigned owners and no remediation deadlines is documentation of risk, not reduction of it.

CVSS-only prioritization. A CVSS score measures potential severity, not active exploitation likelihood. Treating a CVSS 9 vulnerability with no public exploit as more urgent than a CVSS 7 with a CISA KEV listing is backwards. Exploitability data from the KEV catalog and threat intelligence feeds must be part of the model.

Out-of-scope assets. Vulnerability management that scans the corporate network but misses cloud instances, remote devices, or OT and IoT infrastructure has gaps that attackers will find because attackers scan comprehensively. Scope must reflect the actual environment, not the environment as it was documented two years ago.

No remediation ownership. Vulnerabilities without assigned owners don’t get fixed. Every identified vulnerability needs a named owner, a risk-tier SLA, and a tracking mechanism. Ownership without a deadline is the same as no ownership.

No verification. Confirming that a patch was deployed is not the same as confirming that a vulnerability was remediated. Verification scanning after remediation is what turns activity into confirmed risk reduction.

Kaseya Intelligence: from detection to autonomous action

Traditional vulnerability management tools identify gaps and surface recommendations. The operational bottleneck is always the same: a technician has to review the finding, prioritize it against everything else in the queue, and act on it at a pace that doesn’t match the speed at which vulnerabilities are discovered and targeted.

Kaseya Intelligence draws on more than three exabytes of aggregated and anonymized data and 17 million-plus managed endpoints, moving from surfacing vulnerability data to autonomously executing remediation actions: patching, isolating, and validating outcomes without requiring manual intervention at each step.

For MSPs managing vulnerability programs across dozens of client environments, the shift from recommendation to autonomous action is what makes the program scalable. A team managing 40 clients can’t manually triage and action every Tier 1 finding within 72 hours during a Patch Tuesday week. With automated patch deployment policies that execute against tier-based criteria without requiring individual technician approval at each step, the 72-hour window is met by the system rather than missed by the team. Explore Kaseya Intelligence.

Vulnerability management done well is unremarkable. The patches go out. The findings get worked through the tiers. The verification scans confirm remediation. The quarterly reports show a trend line moving in the right direction. The clients whose environments are managed this way don’t have the kinds of incidents that are caused by known, patchable vulnerabilities being left open for months. The ones that aren’t managed this way discover, through incidents, exactly which of the failure modes above their program had.