Vulnerability Management
Continuous Vulnerability Management, Risk-Based Prioritization & Remediation Programs for Organizations Across All Compliance Frameworks
Vulnerability management is the continuous, systematic process of identifying, classifying, prioritizing, remediating, and verifying security weaknesses across an organization’s technology environment — the ongoing program that ensures known vulnerabilities don’t accumulate into the exploitable attack surface that threat actors rely on. It is not a one-time exercise. It is not synonymous with penetration testing. And it is not satisfied by running a scan, generating a report, and filing the output until the next compliance cycle. Vulnerability management is the difference between an organization that knows what weaknesses exist in its environment and is actively reducing them, and an organization that finds out what weaknesses exist when an attacker exploits them.
The compliance and regulatory environment for vulnerability management has become substantially more specific in the past two years. PCI DSS 4.0 — the only active version since March 2025 — mandates quarterly external scans by an Approved Scanning Vendor (ASV) and authenticated internal scans with credentialed access, alongside specific patch timing requirements and explicit remediation thresholds linked to CVSS scoring. CISA’s Known Exploited Vulnerabilities (KEV) catalog — maintained by the Cybersecurity and Infrastructure Security Agency and updated continuously as new exploits are confirmed in the wild — has become the highest-signal prioritization source in enterprise vulnerability management, with CISA Binding Operational Directive 22-01 requiring federal agencies to remediate KEV entries within defined timelines. The Exploit Prediction Scoring System (EPSS), maintained by FIRST alongside CVSS, provides probability-based scoring of how likely a given vulnerability is to be exploited in the next 30 days — the most operationally useful prioritization signal available for the hundreds of new CVEs published each month that CVSS severity alone cannot adequately triage. And the proposed HIPAA Security Rule update targeting May 2026 finalization would add explicit patch management and vulnerability remediation requirements to the healthcare compliance framework for the first time.
Lionhive provides continuous vulnerability management programs — asset discovery, authenticated scanning, risk-based prioritization using CVSS, EPSS, and CISA KEV intelligence, remediation tracking, patch management, verification rescans, and compliance-ready reporting — for organizations across financial services, healthcare, technology, manufacturing, legal, and professional services sectors.
The average enterprise environment generates thousands of vulnerability findings per scan cycle. Organizations that try to remediate every finding with equal urgency don’t remediate — they freeze. Organizations that prioritize only on CVSS severity miss the vulnerabilities that attackers are actually exploiting today. The purpose of vulnerability management is not to have a zero-finding scan report. It is to ensure that the vulnerabilities most likely to be exploited against your specific environment are addressed before they are. That requires prioritization intelligence, not just a scanner and a spreadsheet.
Vulnerability Scanning vs. Vulnerability Management — The Program vs. The Tool
Vulnerability scanning is a tool. Vulnerability management is a program. The distinction matters commercially — many organizations that believe they have a vulnerability management program actually have a recurring scan scheduled in a tool, producing reports that accumulate in a shared drive. A vulnerability scanner without the prioritization process, remediation ownership assignment, SLA tracking, verification rescanning, and compliance reporting infrastructure that constitute a program is not vulnerability management. It is the discovery phase of vulnerability management, applied in isolation and producing findings without a systematic path to their resolution.
Effective vulnerability management programs have six components operating in continuous cycle:
Asset Discovery — You cannot manage vulnerabilities in assets you don’t know exist. Shadow IT, cloud resources provisioned outside formal IT processes, legacy systems retained past their planned decommission date, and the devices that appear on networks without going through standard procurement create an unknown attack surface that vulnerability scanners miss because they aren’t scanning for what they don’t know is there. Asset discovery — combining network scanning, cloud API integration, endpoint agent deployment, and external attack surface discovery — establishes the asset inventory that is both a vulnerability management foundation and an explicit requirement of the proposed HIPAA Security Rule update’s technology asset inventory provision. The NIST CSF 2.0 Identify function’s ID.AM (Asset Management) subcategories define the asset inventory and classification practices that vulnerability management programs build on.
Vulnerability Scanning — Authenticated, credentialed scanning that logs into target systems using appropriate credentials to assess vulnerabilities from inside the system — rather than only from the network layer — produces substantially more complete and accurate results than uncredentialed scanning. Uncredentialed scans observe systems from the network and identify externally visible weaknesses; credentialed scans assess actual patch levels, software versions, registry configurations, and running services with the depth of access that produces the findings that matter for remediation prioritization. PCI DSS 4.0 Requirement 11.3.1.2 explicitly mandates authenticated scanning for internal vulnerability scans, with documentation required for any system that cannot accept credentials for scanning. For external scanning, PCI DSS requires quarterly assessments by an ASV using tools validated by the PCI Security Standards Council, with all external vulnerabilities scoring CVSS 4.0 or higher addressed within the three-month scan window before a passing scan can be achieved.
Risk-Based Prioritization — Covered separately in the next section, as it is the component most organizations implement inadequately and the one that most determines whether a vulnerability management program actually reduces risk.
Remediation Tracking — Findings without assigned ownership, defined SLAs, and tracked remediation status are findings that will exist unchanged in the next scan cycle. Vulnerability management programs integrate with ticketing systems — Jira, ServiceNow, Azure DevOps — to automatically create remediation tickets from findings, assign ownership to the system owners responsible for affected assets, track SLA compliance, and escalate overdue items through the governance chain. SLAs that define expected remediation timelines by severity — Critical findings within 24-48 hours, High within 7-14 days, Medium within 30-90 days — provide the governance structure that transforms findings into action and the documentation that compliance auditors examine to verify that identified vulnerabilities are being addressed.
Patch Management — Remediation of most vulnerabilities requires patching — applying vendor-released updates that address the specific weaknesses identified. Patch management and vulnerability management are operationally inseparable: the vulnerability scanning program identifies what needs patching; the patch management program delivers, tests, and validates the patches that address identified findings. PCI DSS 4.0 Requirement 6.3.3 requires patches to be applied within one month of release for Critical and High severity vulnerabilities in the cardholder data environment. The proposed HIPAA Security Rule update would impose specific patch management timing requirements for systems handling ePHI. For production systems where immediate patching creates operational risk, compensating controls — network segmentation, enhanced monitoring, access restriction — must be documented and their effectiveness evaluated against the residual risk of the unpatched vulnerability.
Verification & Reporting — Remediation that isn’t verified hasn’t been completed from a compliance perspective. Rescanning after remediation confirms that patches were applied successfully, configurations were corrected, and the vulnerability finding no longer appears. PCI DSS explicitly requires passing rescans after remediation for external ASV scans. Compliance reporting — documenting scan dates, scan scope, finding counts by severity, remediation SLA performance, Mean Time to Remediate (MTTR), and trend lines showing risk reduction over time — provides auditors, QSAs, and executive leadership with the evidence that the vulnerability management program is functioning as designed rather than running in name only.
Risk-Based Prioritization — CVSS, EPSS & CISA KEV
Modern vulnerability management environments produce hundreds to thousands of findings per scan cycle across enterprise environments. A large organization’s vulnerability backlog at any point in time may contain tens of thousands of open findings across all severity levels. Prioritizing remediation by CVSS severity alone — addressing all Critical and High findings before Medium and Low — is an improvement over no prioritization, but it still produces inefficient remediation sequences because CVSS Base Score reflects the intrinsic technical severity of a vulnerability in isolation, not the probability that it will be exploited against a specific organization in a given timeframe. Two Critical-severity vulnerabilities may have radically different actual risk profiles depending on whether threat actors are actively exploiting them, whether they affect internet-facing systems or internal-only assets, and whether compensating controls in the organization’s specific environment reduce their practical exploitability.
The current best practice for vulnerability prioritization uses three signals in combination:
CVSS v4.0 — The Common Vulnerability Scoring System version 4.0, maintained by FIRST and referenced by PCI DSS, HIPAA, NIST, and virtually every compliance framework that addresses vulnerability management, provides the foundational severity score — a 0.0 to 10.0 numerical rating reflecting the Base metrics of attack vector, attack complexity, privileges required, user interaction, scope, and impact. CVSS v4.0, released in November 2023 and the current standard, introduced refined scoring for supplemental metrics and clearer guidance for environmental adjustments that allow organizations to modify base scores based on the mitigating controls and asset criticality of their specific environment. Organizations that apply Environmental metrics to CVSS scores — reducing effective severity for vulnerabilities on systems with compensating controls or lower criticality — produce more accurate prioritization than those applying only Base scores uniformly.
EPSS (Exploit Prediction Scoring System) — The Exploit Prediction Scoring System, developed by a team of researchers and maintained by FIRST, generates a daily probability score (0.0 to 1.0) estimating the likelihood that a specific CVE will be exploited in the wild within the next 30 days. EPSS scores are derived from a machine learning model trained on vulnerability characteristics and observed exploitation activity across a broad sensor network. A CVE with a CVSS score of 7.5 (High) and an EPSS score of 0.02 (2% probability of exploitation in 30 days) represents a different prioritization decision than a CVE with a CVSS score of 7.5 and an EPSS score of 0.45 (45% probability). Combining CVSS severity with EPSS probability produces a two-dimensional prioritization model that more accurately reflects actual remediation urgency than either metric alone — allowing security teams to deprioritize high-severity theoretical vulnerabilities that show no exploitation activity and concentrate resources on vulnerabilities that are both severe and actively being weaponized.
CISA KEV (Known Exploited Vulnerabilities Catalog) — The CISA KEV catalog is the highest-priority remediation signal available — a continuously updated list of vulnerabilities that CISA has confirmed are being actively exploited in the wild. KEV entries represent confirmed exploitation, not predicted risk. A vulnerability on the KEV catalog is being used by threat actors right now against real organizations. CISA Binding Operational Directive 22-01 requires all federal civilian agencies to remediate KEV entries within defined timelines — typically 14 days for KEV entries with federal agency impact. For private sector organizations, KEV entries represent the subset of the vulnerability backlog that merits emergency-level prioritization regardless of CVSS score, EPSS probability, or current SLA schedule. Lionhive integrates CISA KEV monitoring into every vulnerability management program — triggering immediate escalation when a KEV entry appears in the organization’s environment, regardless of where it falls in the standard remediation queue.
The practical prioritization model combines all three: address KEV entries immediately regardless of other scheduling; among non-KEV findings, prioritize by combined CVSS + EPSS score with Environmental CVSS adjustments for asset criticality and compensating control context; and apply standard SLA timelines to the remaining backlog by severity tier. This model routes resources toward the vulnerabilities that are both technically severe and actively being exploited, rather than toward the theoretical worst-case vulnerabilities that have never been seen in the wild.
Compliance Framework Requirements
PCI DSS 4.0 (Requirements 6 and 11) — The most prescriptive major framework for vulnerability management. Requirement 11.3.1 mandates quarterly internal authenticated vulnerability scans; Requirement 11.3.2 mandates quarterly external scans by an ASV. External vulnerabilities with CVSS 4.0 or higher must be addressed within the three-month scan window. Requirement 6.3.3 mandates patches applied within one month for Critical and High vulnerabilities. Requirement 6.3.1 requires a documented vulnerability identification and risk-ranking process. After significant infrastructure changes, additional scans are required — the quarterly minimum does not replace change-triggered scanning. Segmentation testing for service providers must occur at least biannually. The entire vulnerability management lifecycle — scan, rank, remediate, verify — must be documentable for QSA review.
Proposed HIPAA Security Rule (Target finalization May 2026) — The proposed Security Rule update introduces specific patch management requirements with defined timing obligations for systems handling ePHI — the first explicit patch timing requirements in HIPAA’s history. The technology asset inventory requirement creates the foundation for systematic ePHI system vulnerability management. Organizations preparing for the proposed rule’s compliance deadline should establish authenticated scanning programs covering all ePHI systems now, generating the scan history and remediation documentation that the updated rule will require.
NIST CSF 2.0 — The NIST Cybersecurity Framework 2.0 Identify function’s ID.RA (Risk Assessment) subcategories define vulnerability identification and analysis as core organizational capabilities. The Respond function’s RS.MI (Mitigation) subcategories address vulnerability containment and remediation. NIST SP 800-40 provides specific patch management guidance referenced by multiple compliance frameworks. Organizations aligning with NIST CSF 2.0 implement vulnerability management as the operational mechanism for continuous risk reduction across the framework’s Identify-Protect-Detect cycle.
ASD Essential Eight (Updated September 2025) — Two of the eight mitigation strategies — Patch Applications and Patch Operating Systems — are directly vulnerability management components. The Essential Eight Maturity Level 2 requirements, mandated for Australian Commonwealth entities under PSPF Policy 14, specify patch timing requirements: internet-facing services patched within two weeks of release, other applications and operating systems within one month, with patches for vulnerabilities with exploits available addressed within 48 hours. For organizations in Canberra and broader Australian government supply chains, Essential Eight ML2 patch management compliance is a contractual and procurement requirement.
ISO 27001 — Annex A Control 8.8 (Management of technical vulnerabilities) requires organizations to obtain information about technical vulnerabilities in a timely fashion, evaluate exposure, and take appropriate measures. ISO 27001 certification auditors examine whether the vulnerability management process produces evidence of systematic identification, assessment, and remediation — not whether the organization has a scanner installed.
SOC 2 — The Common Criteria’s CC7 (Systems Operations) and its monitoring requirements, and CC9 (Risk Mitigation), create the framework expectation that organizations systematically identify and address security risks — which SOC 2 auditors increasingly interpret to require vulnerability scanning evidence. Organizations whose SOC 2 evidence packages include vulnerability scan records, remediation tracking, and MTTR metrics satisfy auditor inquiries about CC7 monitoring controls more completely than those relying solely on policy documentation.
CMMC 2.0 — RA.L2-3.11.2 (Vulnerability Scanning) requires periodic scanning of organizational systems and applications when new vulnerabilities affecting those systems are identified. CA.L2-3.12.4 (System Security Plans) requires documentation of vulnerability management controls. With CMMC full implementation required by October 2026, defense contractors must demonstrate functioning vulnerability management programs as part of their CMMC Level 2 assessment.
Cloud Vulnerability Management — The Infrastructure That Standard Scanning Misses
Cloud infrastructure introduces vulnerability management challenges that traditional network scanning cannot adequately address. Cloud-native vulnerabilities — misconfigurations in IAM policies, storage bucket permissions, network security group rules, serverless function configurations, and container image vulnerabilities — don’t appear in standard network vulnerability scans because they exist in the cloud control plane and configuration layer rather than in the software installed on traditional server operating systems.
Effective cloud vulnerability management requires three parallel programs: cloud security posture management (CSPM) tools that continuously scan cloud resource configurations against security benchmarks and flag misconfigurations; container image scanning that examines base images, application dependencies, and installed packages for known CVEs before images are deployed to production; and infrastructure-as-code (IaC) scanning that evaluates Terraform, CloudFormation, and Kubernetes manifests for security misconfigurations before they are applied to the environment. Lionhive integrates cloud vulnerability management across AWS, Azure, and Google Cloud — ensuring that the vulnerability program covers the full environment rather than only the traditional infrastructure components that conventional scanners address.
The Vulnerability Management — Penetration Testing Relationship
Vulnerability management and penetration testing address complementary security questions through different mechanisms — and an effective security program requires both, not a choice between them.
Vulnerability management is continuous and automated — running on schedules (weekly, monthly, quarterly) and producing findings from tool-based scanning that identifies known weaknesses across the full asset inventory. Its strength is breadth and continuity: it covers the entire environment on a regular cadence and tracks the remediation of known vulnerabilities over time. Its limitation is that it identifies weaknesses by pattern-matching against known vulnerability databases — it cannot discover novel attack paths, logic flaws in application design, or the chained exploitation sequences that only human testers can identify.
Penetration testing is periodic and human-led — conducted annually or after significant changes by qualified testers who actively attempt to exploit vulnerabilities to demonstrate real-world attack paths. Its strength is depth and adversarial creativity: it finds what automated scanning misses, demonstrates the actual impact of vulnerabilities through exploitation, and produces evidence that compliance frameworks specifically require as demonstration of security control effectiveness. Its limitation is that it is a point-in-time engagement — the vulnerabilities introduced between annual penetration tests are the ones that vulnerability management must track and remediate continuously.
The relationship is sequential: vulnerability management reduces the remediated attack surface that penetration testers evaluate; penetration testing validates whether the vulnerability management program’s remediation efforts have actually addressed the most significant attack paths; and the penetration test findings inform the next vulnerability management cycle’s prioritization. Organizations that conduct annual penetration testing without a continuous vulnerability management program find that penetration testers are documenting vulnerabilities that should have been identified and addressed months earlier. Organizations that run vulnerability management programs without periodic penetration testing validate that known vulnerabilities are being tracked and patched, but have no assurance that the compensating controls and architecture are holding up against adversarial exploitation attempts.
Vulnerability Management Metrics — What Mature Programs Measure
The metrics that distinguish a functioning vulnerability management program from a scanning exercise are the metrics that demonstrate not just what vulnerabilities exist, but how quickly and completely the organization is reducing its exposure to them.
Mean Time to Remediate (MTTR) — The average elapsed time between vulnerability discovery and verified remediation, measured by severity tier. MTTR trending downward over consecutive quarters indicates a maturing program. MTTR consistently exceeding SLA targets by severity indicates a remediation capacity or prioritization problem that requires process intervention rather than scanner tuning.
Vulnerability Backlog Trend — The total count of open findings by severity tier, tracked over time. A backlog that grows faster than it shrinks indicates that the remediation program is not keeping pace with new vulnerability discovery — a signal that either scanning frequency is outpacing remediation capacity, SLA timelines are unrealistic for the organization’s operational context, or ownership and accountability for remediation is insufficiently defined.
SLA Compliance Rate — The percentage of findings remediated within the defined SLA for each severity tier. SLA compliance rates below 80% for Critical and High findings indicate material program dysfunction. Compliance auditors examine SLA compliance documentation as evidence that the vulnerability management program produces actual risk reduction rather than finding accumulation.
KEV Exposure Time — The elapsed time between a CVE’s addition to the CISA KEV catalog and its verified remediation in the organization’s environment. Organizations with functioning vulnerability management programs that integrate KEV monitoring remediate KEV entries within hours to days of catalog addition. Organizations without KEV integration may not identify KEV exposure until the next scheduled scan cycle — leaving confirmed exploited vulnerabilities unaddressed for weeks.
Patch Coverage Rate — The percentage of assets in the asset inventory with current patches applied across defined severity categories. Patch coverage rates below defined thresholds for Critical patches are finding categories in PCI DSS QSA assessments and SOC 2 audits.
The Lionhive Vulnerability Management Program
Lionhive delivers managed vulnerability management as an integrated component of the security program — not a standalone scanning service that produces reports the client is left to act on independently.
The program begins with asset discovery and inventory establishment — identifying all systems, applications, and cloud resources within scope through network scanning, cloud API integration, and endpoint agent deployment. Authenticated credentialed scanning covers all in-scope assets on a schedule aligned with compliance framework requirements — at minimum quarterly for PCI DSS environments, with continuous scanning for critical and internet-facing systems. External ASV scanning for PCI DSS environments is coordinated through PCI Security Standards Council-listed Approved Scanning Vendor partnerships.
Findings from each scan cycle are processed through the three-signal prioritization model — CVSS v4.0 with Environmental adjustments, EPSS probability, and CISA KEV status — producing a prioritized remediation queue with assigned ownership, SLA timelines, and ticketing system integration. KEV entries trigger immediate escalation regardless of scheduling. Patch management execution — deploying patches to endpoints through Microsoft Intune, server patching through automated patch management tooling, and cloud configuration remediation through infrastructure-as-code corrections — is coordinated with client IT teams at the level of co-management or full management appropriate to the organization’s internal IT capacity.
Verification rescans confirm remediation for Critical and High findings, producing the documented pass confirmation that PCI DSS and SOC 2 auditors require. Compliance-ready reporting — scan records, remediation tracking, MTTR metrics, SLA compliance rates, trend analysis — is maintained in a format that satisfies the documentation requirements of every framework the organization is subject to and produced on the reporting cycle that audit and QSA schedules require.
📞 Build Your Vulnerability Management Program
Whether you are establishing a vulnerability management program for the first time to satisfy a PCI DSS requirement, a SOC 2 auditor’s expectation, or the proposed HIPAA Security Rule’s patch management provisions — or rebuilding a program whose MTTR metrics and backlog trends indicate it is not producing actual risk reduction — Lionhive provides the asset discovery, authenticated scanning, risk-based prioritization, remediation integration, and compliance reporting infrastructure that transforms vulnerability management from a recurring compliance task into a functioning risk reduction program. To discuss your vulnerability management requirements, scope, and compliance framework obligations, contact us directly or book a strategy session.
👉 Book a Vulnerability Management Consultation
📞 +1 469 364 9010
Part of Lionhive’s Cybersecurity & Compliance practice — see also Penetration Testing, Dark Web Monitoring, Managed SOC, NIST CSF 2.0, and SOC 2 Type II.