What is vulnerability management?

Vulnerability management is how IT and security teams find, evaluate, and fix weaknesses across their environments before attackers can take advantage of them. A solid vulnerability management program does more than run scans. It ties together asset visibility, risk-based prioritization, remediation, validation, and reporting so you can continuously reduce exposure instead of lurching from one quarterly panic session to the next.

What is a vulnerability?

A vulnerability is a weakness or error in software, hardware, a network, or a system. Vulnerabilities pose a threat to businesses because threat actors often leverage them to launch cyberattacks.

For example, in 2023, cybercriminals exploited CVE-2023-27350 in PaperCut print management software, allowing remote code execution on vulnerable, unpatched systems.

In 2025, NIST reported nearly 42,000 vulnerabilities in the National Vulnerability Database.

Quick definitions

Vulnerability

A vulnerability is a weakness in software, hardware, or configuration that could be exploited to compromise a system. 
Example: An outdated browser version with a known remote code execution flaw.

CVE

A CVE (Common Vulnerabilities and Exposures) is a standardized identifier for a publicly disclosed security flaw. 
Example: CVE-2023-27350 identifies the PaperCut vulnerability referenced above.

CVSS

CVSS (Common Vulnerability Scoring System) is a standardized way to rate the severity of a vulnerability, typically on a 0.0–10.0 scale. 
Example: A CVSS 9.8 vulnerability is generally treated as urgent.

Vulnerability assessment

A vulnerability assessment is a point-in-time review used to identify and evaluate weaknesses in your environment. 
Example: Conducting a quarterly review of your environment that includes asset discovery, vulnerability scanning, validation of findings, risk prioritization, and a remediation report.

Patch management

Patch management is the process of deploying software updates to fix bugs, close security gaps, and improve stability. 
Example: Installing the latest Chrome update across all endpoints.

Penetration testing

Penetration testing is a controlled, manual security exercise where trained testers simulate attacks to validate exploitable weaknesses. 
Example: A pentester chaining a weak configuration and an exposed service to reach sensitive data.

Zero-day

A zero-day is a vulnerability that is exploited before a patch is available or before defenders have had time to respond. 
Example: A newly disclosed flaw under active attack with no vendor fix yet.

Why vulnerability management matters

Vulnerability management may initially feel intimidating, but it’s a necessary step for business continuity, security, and operational sanity.

It minimizes cybersecurity risks and downtime

When you leave vulnerabilities unaddressed, you make life easier for attackers and harder for yourself. Vulnerability management helps you close those gaps before they lead to outages, ransomware, or frantic after-hours calls nobody wanted.

It gives you insight into your environment

A good vulnerability management process forces you to understand what’s in your environment, what’s exposed, what matters most, and where you’re falling behind. That visibility is useful well beyond security.

It supports compliance efforts

Vulnerability management also supports common compliance frameworks and audits because it helps you demonstrate that you identify, track, remediate, and verify security issues on a repeatable basis.

• SOC 2: Auditors commonly expect evidence of a documented vulnerability management process, remediation tracking, and timeliness.

• ISO 27001: Supports controls around risk treatment, vulnerability handling, and continuous improvement.

• HIPAA: Helps reduce risk to systems handling protected health information by showing ongoing security maintenance and remediation discipline.

It won’t satisfy every compliance requirement on its own, but it absolutely helps keep you out of the “Can you provide evidence of your process?” death spiral.

Vulnerability management lifecycle

Vulnerability management is best understood as a loop, not a one-and-done project:

Discover → Prioritize → Remediate → Verify → Report

• Discover: Build and maintain an asset inventory, then scan for known vulnerabilities.

• Prioritize: Rank findings using severity, exploitability, business criticality, and exposure.

• Remediate: Patch, reconfigure, isolate, or apply compensating controls.

• Verify: Rescan and confirm the issue is actually fixed.

• Report: Track SLAs, exceptions, trends, and coverage so the program improves over time.

The vulnerability management process

The vulnerability management process breaks down into six main steps. Below, each step is written as a practical how-to so it’s easier to follow, repeat, and pull into a real workflow.

1. Inventory the assets in your environment

Do this: Build a current inventory of endpoints, servers, network devices, cloud assets, and business-critical applications before you scan.

• Inputs: CMDB, EDR, MDM, Active Directory, cloud inventory, endpoint management platform, procurement records

• Recommended cadence: Update continuously if possible; formally reconcile weekly

• Expected output: Current asset inventory with owner, OS, installed software, IP/hostname, business criticality, and environment tag

• Success criterion: ≥95% of in-scope assets are inventoried and tagged with owner and criticality

If you don’t know what exists, you can’t know what’s vulnerable. That’s not security wisdom so much as a mildly annoying fact of life.

Roles

• Sysadmin: Maintains endpoint and server inventory

• SecOps: Defines in-scope asset classes

• App owner: Confirms business criticality for key systems

2. Conduct vulnerability scans

Do this: Run authenticated vulnerability scans on managed assets and unauthenticated scans where credentials are not possible.

• Inputs: Asset inventory, scanner targets, scanner credentials, network ranges, maintenance windows

• Recommended cadence: Weekly for internal assets; daily or continuous for internet-facing systems; after major changes

• Expected output: Scan report with detected CVEs, affected assets, versions, exposure details, and confidence level

• Success criterion: ≥95% authenticated coverage on managed assets; all internet-facing assets scanned on schedule

Authenticated scans generally provide deeper, more accurate results because they can inspect installed software and settings directly. PDQ’s own IT team uses both agent-based and agentless scanning because each sees different things; credentialed or agent-based visibility usually gives you more useful detail.

Roles

• SecOps: Owns scan configuration and scheduling

• Sysadmin: Provides credentials and access paths

• Network admin: Allows scanner reachability where needed

3. Assess the findings

Do this: Review scan results to separate meaningful risk from noise and identify what actually needs action.

• Inputs: Scan reports, software version data, asset criticality, exposure details, vendor advisories

• Recommended cadence: After every scan cycle; immediately for critical or internet-facing findings

• Expected output: Validated findings list, false-positive notes, grouped remediation candidates, and escalation flags

• Success criterion: High-confidence findings are triaged within one business day for critical items and within five business days for the rest

This is where you validate whether a finding is real, whether it’s already mitigated, and whether multiple CVEs can be resolved with one upgrade. Good tools help by grouping related vulnerabilities and surfacing the actual fix instead of handing you a terrifying spreadsheet of doom.

Roles

• SecOps: Validates findings and filters false positives

• Sysadmin: Confirms installed versions and technical feasibility

• App owner: Flags business impact or dependencies

4. Prioritize vulnerabilities by risk

Do this: Rank vulnerabilities based on severity and business impact, not just raw scan counts.

• Inputs: CVSS, EPSS, CISA KEV status, asset criticality, internet exposure, exploit availability, compensating controls

• Recommended cadence: During every triage cycle; reprioritize when KEV or exploit status changes

• Expected output: Prioritized remediation queue, SLA target, assigned owner, and exception candidates

• Success criterion: Critical and high-risk exploitable findings are assigned owners and due dates within one business day

CVSS is useful, but it’s not enough by itself. Risk-based prioritization should also consider:

• EPSS: The likelihood a vulnerability will be exploited in the next 30 days

• KEV: Whether CISA has confirmed active exploitation in the wild

• Business criticality: Whether the affected asset matters to the business

• Exposure: Whether the system is public-facing or heavily privileged

This is the natural home for tools that add contextual prioritization, such as PDQ’s risk-based views.

Roles

• SecOps: Sets priority based on threat and exploit context

• App owner: Weighs business criticality

• Sysadmin: Confirms remediation path and timing

Example CVSS-to-action matrix

Use CVSS bands as a baseline, then adjust based on EPSS, KEV status, exposure, and business criticality. NIST defines CVSS severity bands, while CISA KEV identifies vulnerabilities confirmed as exploited in the wild.

These SLA ranges are examples, not universal requirements. Your actual SLAs should reflect your risk tolerance, regulatory obligations, operational constraints, and business environment.

5. Remediate vulnerabilities

Do this: Fix prioritized vulnerabilities using the safest and fastest appropriate method.

• Inputs: Prioritized queue, patch catalog, deployment tool, configuration baselines, maintenance window, rollback plan

• Recommended cadence: Based on SLA; emergency cadence for critical and KEV items

• Expected output: Patch deployed, configuration changed, compensating control implemented, or approved exception recorded

• Success criterion: Remediation completed within SLA and documented in the change or ticketing system

Remediation options usually include:

• Patch or upgrade the affected software

• Change configuration to remove the weakness

• Disable or isolate the vulnerable service

• Apply compensating controls such as firewall rules, EDR prevention, or restricted access

• Grant a time-bound exception if no safe fix exists yet

This is also where patch management comes in.

Roles

• Sysadmin: Deploys patches or config changes

• SecOps: Confirms the remediation addresses the finding

• Change advisory / approver: Approves higher-risk production changes when needed

• App owner: Signs off on business-impacting remediation windows

Pre-remediation checklist

• Asset inventory current?

• Scanner coverage ≥95%?

• Authenticated scans enabled?

• Business criticality tagged?

• Maintenance window approved?

• Rollback plan tested?

• Ticket created and owner assigned?

• Validation rescan scheduled?

6. Monitor, validate, and rescan

Do this: Rescan affected assets after remediation and keep monitoring for new vulnerabilities.

• Inputs: Completed ticket, deployed patch/configuration evidence, scan schedule

• Recommended cadence: Rescan immediately after critical remediation; otherwise in the next scheduled cycle

• Expected output: Validation result, closed ticket, reopened ticket, or exception review

• Success criterion: Vulnerability no longer detected on rescan; exception formally documented if still present

A fix that isn’t verified is just optimism with paperwork. Validation closes the loop and makes your reporting defensible.

Roles

• SecOps: Runs validation and closes or reopens findings

• Sysadmin: Troubleshoots failed remediation

• App owner: Accepts residual risk only through documented exception review

Vulnerability management vs. patch management

Vulnerability management and patch management are related, but they are not the same thing.

Vulnerability management is the broader program:

• Find vulnerabilities

• Assess and prioritize them

• Decide what to do

• Remediate

• Verify

• Report and improve

Patch management is one remediation tactic inside that broader program:

• Test updates

• Approve them

• Deploy them

• Confirm installation

So yes, patch management is part of vulnerability management. But vulnerability management also covers scanning, prioritization, compensating controls, exceptions, validation, and reporting. If you’re searching for the difference, that’s the difference.

For a deeper comparison, see patch management vs. vulnerability management.

Authenticated vs. unauthenticated scans

Authenticated scans are usually better for managed systems because they see more and produce more accurate results; unauthenticated scans are still useful for external visibility and unmanaged assets.

• Authenticated scans use credentials or an agent to inspect installed software, services, and configurations more deeply.

• Unauthenticated scans show what an external observer can see, which is valuable for perimeter and exposure testing.

• Best practice is to use both where appropriate. PDQ’s internal IT team follows this approach because it improves visibility.

CVSS, EPSS, and risk-based prioritization

Use CVSS for severity, EPSS for likelihood of exploitation, and business context for impact.

• CVSS tells you how severe a vulnerability is on paper.

• EPSS estimates the probability of exploitation in the near term.

• Business context tells you whether the affected asset is important, exposed, privileged, or mission-critical.

• KEV status should override normal queues because it indicates known exploitation in the wild.

• Platforms with contextual risk scoring can reduce noise by grouping and prioritizing what actually matters.

If you’re looking at a hundred “highs,” this is how you avoid treating them all like they’re equally urgent. Because they’re not.

Automated vulnerability management

Arguably, one of the most useful applications of automation is vulnerability management.

Vulnerability scanners automatically examine devices in your environment for known weaknesses, often by checking for vulnerable software versions, missing patches, or risky configurations. Much like antivirus tools check for known bad signatures, vulnerability scanners check systems against known CVEs. Then, automated vulnerability patching tools make it easy to act on your findings.

IT automation helps most in these areas:

• Asset discovery

• Scan scheduling

• Finding grouping

• Risk-based prioritization

• Ticket creation

• Patch deployment

• Rescan and validation

• Reporting for audits and stakeholders

At PDQ, teams use reports and prioritized remediation data to hand off work from security to IT more cleanly. That kind of workflow matters, especially if your team is small and everyone is already doing four jobs.

Mini case study 1: PaperCut CVE-2023-27350

Example flow: detection → prioritization → remediation → validation

• Detection: Vulnerability scan identifies vulnerable PaperCut MF/NG versions associated with CVE-2023-27350 on internet-facing print servers.

• Prioritization: Treat as urgent due to remote code execution risk, public exposure, and CISA advisory context.

• Remediation: Upgrade PaperCut to the vendor-fixed version; If immediate patching is not possible, restrict external access to the PaperCut application server.

• Compensating control: Limit inbound access with firewall policy to trusted admin IPs only until patching completes.

• Validation: Run a rescan and confirm the vulnerable version is no longer detected.

• Output: Emergency ticket closed with patch evidence and validation scan attached.

Mini case study 2: Common Windows misconfiguration

Example flow: detection → prioritization → remediation → validation

• Detection: Authenticated scan flags a Windows endpoint or server with SMBv1 enabled or an overly permissive local security setting.

• Prioritization: Raise priority if the asset is legacy-critical, broadly reachable, or in a sensitive segment.

• Remediation: Disable SMBv1 using PowerShell: Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

• Alternative config fix: Apply a hardened local or domain policy, such as removing unnecessary local admin rights or enforcing stronger security baseline settings.

• Validation: Rescan the device and confirm the misconfiguration no longer appears.

• Output: Configuration change ticket closed with command log or GPO reference and validation evidence.

Metrics that matter

A vulnerability management program needs a few practical metrics, not a museum of dashboards no one checks.

MTTR by severity

Measure mean time to remediate by critical, high, medium, and low findings. 
Why it matters: Shows whether your team is actually meeting SLA targets.

% of assets with authenticated scans

Track how much of your environment gets deep scan coverage. 
Target: Aim for at least 95% of managed, in-scope assets.

% of KEV items remediated within SLA

Track how quickly you resolve CISA KEV-listed vulnerabilities. 
Why it matters: KEV items represent real, active threats, not theoretical ones.

Patch compliance by asset class

Measure current patch levels across workstations, servers, and critical systems. 
Why it matters: Highlights where remediation breaks down operationally.

False-positive rate

Track how often findings are closed as invalid or not applicable. 
Why it matters: High false-positive rates waste time and undermine trust in the process.

Useful benchmark ranges vary by environment, but mature programs generally aim for:

• Critical MTTR: 24–72 hours

• High MTTR: 7–14 days

• Authenticated coverage: 95%+

• KEV within SLA: As close to 100% as possible for in-scope assets

How to choose a vulnerability management platform for your business

Not every vulnerability management tool will be right for your environment, so it’s worth evaluating your needs carefully before committing.

Start with these questions:

• Can the tool handle the size and complexity of your environment?

• Does it support strong asset discovery and inventory?

• Does it prioritize vulnerabilities using CVSS, exploitability, and business context?

• Does it support automation for ticketing, patching, or validation?

• Is the reporting useful for operations and compliance?

• Does it integrate with your patching tools, endpoint management tools, and ticketing tools?

• Is the vendor trustworthy and the product actually usable?

If vulnerability remediation is a priority, look closely at whether the platform only reports issues or also helps you fix them. Those are very different experiences.

Vulnerability management FAQs

What is vulnerability management?

Vulnerability management is the ongoing process of identifying, prioritizing, fixing, and monitoring security weaknesses across your environment.

• It includes scanning, triage, remediation, validation, and reporting.

• It is continuous, not a one-time project.

• Patch management is one part of it, not the whole thing.

How does vulnerability management differ from patch management?

Vulnerability management is the broader program; patch management is one remediation method within that program.

• Vulnerability management includes discovery, prioritization, exceptions, compensating controls, and verification.

• Patch management focuses on testing, approving, and deploying software updates.

• Some vulnerabilities are fixed with patches; others need configuration changes, isolation, or temporary mitigations.

How are security vulnerabilities scored?

Most publicly disclosed vulnerabilities are scored using CVSS, which rates severity on a 0.0–10.0 scale.

• NIST publishes CVSS scores through the National Vulnerability Database.

• CVSS is useful for baseline severity, but not for business priority by itself.

• EPSS, KEV status, and asset criticality add the missing context.

How often should we scan?

You should scan at least weekly for most internal assets and more frequently for internet-facing systems.

• Scan public-facing systems daily or continuously when possible.

• Run additional scans after major changes, patch windows, or new software deployments.

• The more dynamic your environment, the shorter your scan cadence should be.

Who owns remediation vs. approval?

IT or system owners usually remediate; security typically prioritizes and validates; approvals depend on change risk.

• SecOps: triage, risk ranking, validation

• Sysadmin / endpoint team: patching and configuration changes

• App owner: business approval for app-impacting changes

• Change advisory: approval for higher-risk production changes

What SLAs align to each CVSS band?

A common baseline is 90 days for low, 30 days for medium, 7–14 days for high, and 24–72 hours for critical.

• KEV-listed vulnerabilities should usually be handled faster than their CVSS score alone would suggest.

• Internet-facing and business-critical assets may need tighter SLAs.

• Document exceptions when operational constraints prevent normal remediation timing.

How do we handle KEV and zero-days?

Treat KEV-listed vulnerabilities and serious zero-days as emergency-priority items.

• Check whether the asset is exposed, critical, or reachable from untrusted networks.

• Patch immediately if a fix exists.

• If no patch exists, apply compensating controls such as blocking access, disabling the service, increasing monitoring, or isolating the asset.

What’s the difference between a vulnerability assessment and penetration testing?

A vulnerability assessment identifies potential weaknesses; penetration testing manually validates exploitability and control effectiveness.

• Assessments are broader and more repeatable.

• Pen tests go deeper on attack paths and real-world exploitation.

• Pen testing is not a replacement for routine vulnerability management.

What are the most common vulnerabilities?

Some of the most common vulnerabilities include unpatched software, zero-days, weak passwords, and misconfigurations.

• Outdated third-party apps are frequent offenders.

• Misconfigurations often create risk even when systems are fully patched.

• Weak identity and access controls can turn a minor flaw into a major incident.

Ready to take the guesswork out of vulnerability management? PDQ helps you identify risks, prioritize vulnerabilities, and patch systems from one secure platform. Start your free 14-day trial and see how much easier the whole process can be when your tools pull in the same direction.