The Latest

Vulnerability Management: Process, Tools and Best Practices for Enterprise (2026)

byPriyanshu Sahay
August 24, 2026
Vulnerability Management
Vulnerability Management
By HOC Team  |  Last updated: August 2026  |  Read time: ~24 min

In December 2021, the Apache Log4Shell vulnerability (CVE-2021-44228) was published. Within 12 hours, scanning for vulnerable systems had begun at scale. Within 72 hours, exploitation attempts numbered in the millions.

Organisations with a mature vulnerability management programme knew within hours which of their systems ran a vulnerable version of Log4j — they had an asset inventory, they had a software bill of materials, and they had a process for emergency patch deployment. They patched in days.

Organisations without a vulnerability management programme spent weeks manually searching codebases and inventories they did not know were incomplete, patching systems they did not know they had, and hoping that attackers had not found them first.

Log4Shell was not unusual in its speed of exploitation — it was representative of the modern threat landscape. The Rapid7 Vulnerability Intelligence Report found that the median time from vulnerability disclosure to active exploitation in the wild is now 12 days.

Many critical vulnerabilities are exploited within hours of publication. An organisation that patches CRITICAL vulnerabilities in 30 days is — in practice — patching after the majority of exploitation attempts have already occurred against that vulnerability.

Vulnerability management is the continuous process of identifying, classifying, prioritising, remediating, and verifying security vulnerabilities in an organisation's technology environment.

This guide covers the complete enterprise vulnerability management lifecycle: the six-phase process, CVSS scoring and risk-based prioritisation, the vulnerability scanning toolchain (Nessus, Qualys, Rapid7, OpenVAS, Trivy), patch management SLAs, metrics and KPIs that prove programme effectiveness, and the common programme failures that turn vulnerability management into a compliance exercise rather than a security outcome.

📊 Vulnerability management in 2026 Median time from CVE disclosure to exploitation in the wild: 12 days (Rapid7) · Average enterprise vulnerability backlog: 57,000 open findings · Only 5% of CVEs are ever exploited in the wild — risk-based prioritisation is essential · CISA KEV catalogue contains 1,100+ known-exploited vulnerabilities — these must be patched first · 60% of breaches exploit a vulnerability for which a patch had been available for more than 6 months (Ponemon) · Mean time to remediate CRITICAL CVEs in mature programmes: 9 days; immature: 74 days
📋 Table of Contents
  1. The vulnerability management lifecycle — six phases
  2. Phase 1 — Asset discovery and inventory
  3. Phase 2 — Vulnerability scanning
  4. Phase 3 — CVSS scoring and risk-based prioritisation
  5. Phase 4 — Remediation and patch management
  6. Phase 5 — Verification and validation
  7. Phase 6 — Reporting and continuous improvement
  8. Vulnerability scanning tools — enterprise comparison
  9. Patch SLAs and policy framework
  10. KPIs and metrics that prove programme effectiveness
  11. Best practices and common programme failures
  12. Frequently asked questions
1. The vulnerability management lifecycle — six phases

Vulnerability management is not a one-time audit — it is a continuous cycle. The moment a scan is complete, new vulnerabilities are disclosed, new assets are deployed, and new configurations are changed. A mature programme runs continuously, with scanning on defined schedules, prioritisation in near-real-time as new CVEs are published, and remediation tracked through to verified closure.

Vulnerability management lifecycle — six phases from asset discovery through continuous improvement, with the CISA KEV catalogue and threat intelligence feeding prioritisation at Phase 3
Vulnerability Management Lifecycle — Six Continuous Phases ① DISCOVER Asset inventory CMDB · cloud APIs ② SCAN Nessus / Qualys Trivy · OpenVAS ③ PRIORITISE CVSS + EPSS CISA KEV · Asset crit. ★ Most important phase ④ REMEDIATE Patch · mitigate accept · transfer ⑤ VERIFY Re-scan · pen test Confirm closure ⑥ REPORT MTTR · KPIs · trends Board reporting Continuous cycle — repeat on defined schedule (weekly scans, continuous cloud) CISA KEV + Threat Intel Known-Exploited Vulns · EPSS scores · OSINT
2. Phase 1 — Asset discovery and inventory
1
Asset Discovery — you cannot scan what you cannot find
The most common vulnerability management failure is an incomplete asset inventory — unscanned assets become attacker entry points

Every vulnerability management programme fails or succeeds based on the completeness of the asset inventory. An asset that is not in the inventory is not scanned. An asset that is not scanned is not patched. An unpatched asset with a known critical vulnerability that the organisation does not know exists is more dangerous than a patched system the organisation knows about, because it provides attackers with a blind-spot entry point.

Asset discovery methods
  • Network scanning discovery: Nmap, Masscan, or the scanner's own discovery module scans IP ranges and identifies active hosts. Fast and comprehensive for on-premises networks; requires appropriate network access. Run discovery scans weekly — new devices appear regularly.
  • Active Directory / LDAP query: Pull all computer objects from AD. Covers all domain-joined Windows systems. Does not cover non-Windows, cloud, or unmanaged devices.
  • Cloud provider APIs: AWS (describe-instances, describe-buckets), Azure (az vm list), GCP (gcloud compute instances list). Pull all cloud assets programmatically. Essential for cloud-heavy environments — cloud assets spin up and down constantly. Integrate with CSPM tools (Prisma Cloud, Wiz, Orca) for continuous cloud asset visibility.
  • MDM / endpoint management: Microsoft Intune, Jamf, or SCCM asset lists cover managed endpoints. Combine with network discovery to identify unmanaged devices (shadow IT).
  • CMDB integration: If a CMDB (ServiceNow, BMC Remedy) exists, sync with it — the CMDB may have business context (asset owner, criticality, business function) that enriches the vulnerability management data. Note: CMDBs are frequently stale — never rely solely on CMDB without validation against discovery scans.
  • Container and Kubernetes inventory: kubectl get nodes, kubectl get pods -A, and container registry APIs. Container environments are particularly dynamic — asset discovery must be continuous rather than scheduled.
# Network discovery — find all active hosts in a subnet range nmap -sn 10.0.0.0/16 -oA discovery-scan --min-rate 1000 # -sn = ping scan only (no port scan) — fast discovery # -oA = output in all formats (for import into VM platform) # Results: list of all active IP addresses in the range # Pull all computer objects from Active Directory Get-ADComputer -Filter * -Properties Name,OperatingSystem,LastLogonDate | Select-Object Name,OperatingSystem,LastLogonDate | Export-Csv -Path "ad-computers.csv" -NoTypeInformation # Filter out computers with LastLogonDate > 90 days — likely decommissioned # AWS — list all EC2 instances across all regions aws ec2 describe-instances --query 'Reservations[*].Instances[*].{ ID:InstanceId,Type:InstanceType,State:State.Name, IP:PrivateIpAddress,Tags:Tags}' --output json > aws-inventory.json # Find unmanaged devices — in network scan but NOT in AD or MDM # Compare nmap discovery output against AD computer list comm -23 <(sort nmap-hosts.txt) <(sort ad-computers.txt) # Every IP in nmap results but not in AD is an unmanaged device requiring investigation
Asset classification — criticality tiers

Not every asset carries the same risk. Assign criticality tiers to assets based on business impact — this drives scan frequency, patch SLAs, and remediation prioritisation for vulnerabilities on those assets.

TierDefinitionExamplesScan frequencyCRITICAL patch SLA
Tier 1 — CriticalCompromise causes immediate, severe business impact or regulatory breachDomain controllers, payment systems, PII databases, internet-facing web apps, CA serversDaily (agent) or weekly (network)24 hours
Tier 2 — HighCompromise causes significant disruption or significant data exposureApplication servers, file servers, cloud production workloads, ERP systemsWeekly7 days
Tier 3 — MediumCompromise causes limited disruption; data exposure limited in scopeDeveloper workstations, internal business applications, test environmentsMonthly30 days
Tier 4 — LowCompromise has minimal business impactDecommission-pending systems, isolated lab environments, printersQuarterly90 days
3. Phase 2 — Vulnerability scanning
2
Vulnerability Scanning — authenticated scans find 5–10× more vulnerabilities than unauthenticated
Always use authenticated scanning for internal assets — unauthenticated scans produce false assurance

A vulnerability scan identifies software versions, configurations, and missing patches on each asset and compares them against a database of known vulnerabilities (NVD, vendor advisories). The quality of scan results depends critically on authentication: unauthenticated scans can only detect what is visible from the network (open ports, service banners) and miss the majority of vulnerabilities that require OS-level access to detect (missing patches, insecure configurations, installed software CVEs). An unauthenticated scan produces a false sense of security — it shows a small number of findings when hundreds may exist.

Scan types and when to use each
  • Authenticated network scan: Scanner connects to the target over the network using privileged credentials (SSH for Linux, WMI/SMB for Windows). Detects: missing patches, installed software CVEs, OS configuration issues, user account settings. The standard scan type for infrastructure vulnerability management. Requires credential management — use a dedicated scan account with local admin rights, never domain admin.
  • Agent-based scan: A lightweight agent installed on the endpoint runs scans locally and reports to the central VM platform. Advantages: works on endpoints not reachable by the network scanner (remote workers, off-VPN laptops), no credential management required, runs continuously rather than on schedule, lower network impact. Disadvantages: requires agent deployment and management. Best for: endpoints, laptops, cloud VMs.
  • Unauthenticated / external scan: Simulates an external attacker's view — scans internet-facing assets without credentials. Finds: exposed services, missing TLS configurations, publicly accessible sensitive files, web application vulnerabilities visible externally. Run monthly against all internet-facing assets. Also run from a dedicated external IP to avoid firewall whitelist effects.
  • Web application scan: DAST (Dynamic Application Security Testing) scans the running web application for OWASP Top 10 vulnerabilities — SQL injection, XSS, CSRF, authentication issues, misconfigured headers. Tools: OWASP ZAP, Burp Suite Enterprise, Nuclei. Separate from infrastructure vulnerability scanning.
  • Container image scan: Scans container images for OS package CVEs and application dependency vulnerabilities. Tools: Trivy, Grype, Anchore. Runs in CI/CD pipeline at build time and against the container registry continuously.
# Nessus authenticated scan via CLI (nessuscli) # Requires: Nessus Professional or Essentials installed nessuscli scan new \ --name "Weekly-Internal-Scan-$(date +%Y%m%d)" \ --policy "Advanced Scan" \ --targets "10.0.0.0/8,172.16.0.0/12" \ --credentials "windows-scan-account,linux-ssh-key" # OpenVAS / Greenbone — open-source scanner via CLI gvm-cli --gmp-username admin --gmp-password admin socket \ --xml "<create_task><name>Weekly Scan</name>\ <config id='daba56c8-73ec-11df-a475-002264764cea'/>\ <target id='TARGET_UUID'/></create_task>" # Trivy — container and filesystem vulnerability scan trivy image --severity HIGH,CRITICAL --format json \ --output scan-results.json myapp:latest # Trivy Kubernetes cluster scan trivy k8s --report summary --severity HIGH,CRITICAL cluster # Nuclei — fast web application and infrastructure scanning nuclei -u https://target.com \ -t cves/ -t exposures/ -t misconfiguration/ \ -severity high,critical \ -o nuclei-results.json -json # Nmap — service version detection for inventory enrichment nmap -sV -O -p 22,80,443,3389,445,3306,5432,1433 \ --script=banner,http-title,ssl-cert \ 10.0.1.0/24 -oA service-scan # Best practice: dedicated scan account with minimum required privileges # Windows: Local Administrators group on targets (NOT domain admin) # Linux: SSH key authentication, sudo rights for specific commands only
Scan credential management — security of the scanner itself

The vulnerability scanner stores credentials to authenticate to every scanned system. If the scanner is compromised, all those credentials are compromised. Scanner infrastructure must be hardened: dedicated VLAN with strict firewall rules, no internet access, credential storage encrypted, MFA for scanner console access, and scan credentials rotated quarterly. The scan account should have no interactive login rights and no ability to make configuration changes — read-only access for vulnerability detection is sufficient for most scan types.

4. Phase 3 — CVSS scoring and risk-based prioritisation
🎯
Risk-based prioritisation — the most important and most misunderstood phase
Only 5% of CVEs are ever exploited — patch by exploit probability, not just CVSS score
Understanding CVSS v3.1 scores

The Common Vulnerability Scoring System (CVSS) provides a standardised severity score from 0.0 to 10.0 based on six base metrics: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, and the CIA impact (Confidentiality, Integrity, Availability). CVSS is useful for standardised severity comparison but is not a complete prioritisation system — it describes the worst-case theoretical severity of a vulnerability, not the likelihood that it will be exploited against your organisation in the near term.

9.0–10.0
Critical
Patch: 24–48h
Remote code execution, no authentication, no user interaction. Patch immediately — no exceptions for Tier 1 assets.
7.0–8.9
High
Patch: 7 days
Significant impact with some prerequisites. Exploit code often available. Treat as Critical if in CISA KEV.
4.0–6.9
Medium
Patch: 30 days
Moderate impact, typically requires authentication or local access. Large backlog item — triage carefully.
0.1–3.9
Low
Patch: 90 days
Minimal impact, significant prerequisites. Address in normal patching cycles. Accept risk for isolated systems.
Beyond CVSS — the risk-based prioritisation framework

CVSS alone produces massive backlogs of medium-severity findings that cannot all be patched quickly. The average enterprise has 57,000 open vulnerability findings — treating everything equally is impossible. Risk-based prioritisation combines four factors to determine true remediation priority:

RISK-BASED PRIORITY SCORE (calculate for each finding): ═══════════════════════════════════════════════════════════ Factor 1: CVSS Base Score (0–10) Weight: 30% of priority score Factor 2: EPSS Score — Exploit Prediction Scoring System (0–1.0) EPSS predicts the probability that a CVE will be exploited in the next 30 days, based on threat intelligence, exploit code availability, and historical exploitation patterns. Source: first.org/epss (updated daily) Weight: 40% of priority score — the most predictive single factor Example: CVE-2021-44228 (Log4Shell): EPSS 0.975 (97.5% exploitation probability) CVE-2023-XXXXX (minor info disclosure): EPSS 0.003 (0.3%) Factor 3: CISA KEV — Known Exploited Vulnerability catalogue Binary flag: is this CVE in the CISA KEV catalogue? KEV = actively exploited by real attackers in the wild Mandate: US federal agencies must patch KEV within 2 weeks Source: cisa.gov/known-exploited-vulnerabilities-catalog Effect: if KEV = YES → move to top of queue regardless of CVSS score Factor 4: Asset criticality tier (1–4, where 1=most critical) Weight: 30% of priority score — same CVE on a DC vs a printer = very different risk PRIORITY SCORE = (CVSS × 0.3) + (EPSS × 10 × 0.4) + (Criticality bonus) + (KEV bonus) EXAMPLE: CVE-2021-44228 (Log4Shell) on a Tier 1 web server: CVSS: 10.0 → 10×0.3 = 3.0 EPSS: 0.975 → 9.75×0.4 = 3.9 KEV: Yes → +3 bonus Asset: Tier 1 → +2 bonus Total priority score: 11.9 → PATCH IMMEDIATELY CVE-2023-XXXX (Medium web vuln) on a Tier 3 dev workstation: CVSS: 5.5 → 5.5×0.3 = 1.65 EPSS: 0.003 → 0.03×0.4 = 0.012 KEV: No → 0 Asset: Tier 3 → 0 Total priority score: 1.66 → next quarterly patch cycle
CISA KEV — the mandatory starting point

The CISA Known Exploited Vulnerabilities catalogue is the most actionable threat intelligence feed for vulnerability prioritisation. It lists CVEs that CISA has confirmed are being actively exploited by real threat actors — not theoretically exploitable, but actually used in attacks. The catalogue currently contains over 1,100 CVEs with mandatory remediation timelines for US federal agencies (typically 2 weeks). Any organisation should treat KEV entries as automatically promoted to the top of the remediation queue, regardless of CVSS score. Several KEV entries have CVSS scores below 7.0 — they would be deprioritised by CVSS-only programmes but are being exploited in the wild.

# Download the CISA KEV catalogue (JSON format, updated regularly) curl -o kev.json https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json # Extract CVE IDs from KEV for comparison against scan results cat kev.json | jq -r '.vulnerabilities[].cveID' | sort > kev-cve-ids.txt wc -l kev-cve-ids.txt # Count of known exploited vulnerabilities in the catalogue # Check if your scan results contain any KEV entries comm -12 <(sort your-scan-cves.txt) <(sort kev-cve-ids.txt) # Any output = CVE in your environment that is known-exploited = PATCH IMMEDIATELY # EPSS scores API — check exploitation probability for a specific CVE curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" | jq '.data[].epss' # Returns: "0.97567" — 97.5% probability of exploitation in next 30 days # CVEs with EPSS > 0.1 (10%) should be treated as high priority regardless of CVSS
Build a live CVSS × EPSS × KEV dashboard before your next board meeting. The combination of EPSS and KEV data, overlaid on your scan results, produces a prioritisation view that is both defensible to auditors and understandable to non-technical executives. "We have 3 vulnerabilities in the CISA KEV catalogue on production systems, all being patched this week" is a board-level statement. "We have 57,000 open findings" is not. Tenable, Qualys, and Rapid7 all now incorporate EPSS scoring natively — if your scanner does not, export CVE IDs and enrich with the FIRST EPSS API.
5. Phase 4 — Remediation and patch management
4
Remediation — patch, mitigate, accept, or transfer
Every vulnerability has exactly one of four treatment options — the choice must be documented and risk-owned
Remediation options
  • Patch: Apply the vendor-supplied patch or update. The preferred treatment for the vast majority of vulnerabilities. Patching should be automated wherever possible — WSUS/SCCM/Intune for Windows, yum-cron/unattended-upgrades for Linux, cloud-native patch managers (AWS Systems Manager, Azure Update Manager) for cloud VMs.
  • Mitigate / compensating control: When a patch is not available (zero-day) or cannot be applied immediately (business change freeze, compatibility issues), implement a compensating control that reduces the exploitability or impact: disable the vulnerable feature, add network-layer access controls, block the exploit path at the WAF, or isolate the affected system. Document the compensating control and set a deadline for the patch.
  • Accept risk: Acknowledge that a vulnerability exists and consciously decide not to remediate it — because the exploitation risk is low (low EPSS, unexploitable in context), the remediation cost exceeds the risk value, or a mitigating control already reduces risk to an acceptable level. Risk acceptance must be documented, risk-owned by a named individual, time-limited (typically 90-day renewable), and reviewed at each re-scan.
  • Transfer: Move the financial risk to a third party — cyber insurance. Note: insurance does not reduce the likelihood of exploitation; it only changes who bears the financial cost. Transfer is appropriate in combination with other treatments, not as a standalone approach.
Patch management automation
# Windows — automated patching with WSUS / Microsoft Update # Configure Windows Update policy via GPO or Intune Computer Configuration → Administrative Templates → Windows Components → Windows Update Configure Automatic Updates: 4 - Auto download and schedule install Scheduled install day: Every day (for critical patches) Scheduled install time: 03:00 AM # Linux — automated security updates (Ubuntu/Debian) apt install unattended-upgrades cat /etc/apt/apt.conf.d/50unattended-upgrades # Ensure this line is uncommented: # "${distro_id}:${distro_codename}-security"; systemctl enable --now unattended-upgrades # AWS Systems Manager — Patch Manager for EC2 fleet aws ssm create-patch-baseline \ --name "Security-Critical-Patches" \ --operating-system "AMAZON_LINUX_2" \ --approval-rules '{"PatchRules":[ {"PatchFilterGroup":{"PatchFilters":[ {"Key":"SEVERITY","Values":["Critical","Important"]}]}, "ApproveAfterDays":0,"ComplianceLevel":"CRITICAL"}]}' # AWS — run patch baseline against all tagged EC2 instances aws ssm start-associations-once \ --association-ids "ASSOCIATION_ID" # Ansible — patch all Linux hosts in inventory cat > patch-playbook.yml << 'EOF' --- - name: Apply security patches hosts: all become: yes tasks: - name: Update all packages (RedHat/CentOS) yum: name: '*' security: yes state: latest when: ansible_os_family == "RedHat" - name: Update all packages (Debian/Ubuntu) apt: upgrade: dist update_cache: yes when: ansible_os_family == "Debian" - name: Reboot if required reboot: reboot_timeout: 300 when: reboot_required_file.stat.exists EOF ansible-playbook -i inventory.ini patch-playbook.yml # Third-party patch management tools with vulnerability scanner integration: # Ivanti Security Controls — integrates with Ivanti Neurons for RBVM # ManageEngine Patch Manager Plus — 850+ third-party apps # Automox — cloud-native, OS + third-party patching # Tanium Patch — enterprise, integrates with Tanium VM
Patch testing before production

Critical security patches for internet-facing systems should be applied as quickly as possible — test in a staging environment in parallel rather than sequentially. For non-critical patches: test in a representative environment (same OS version, same application stack), observe for 48–72 hours, then roll out in waves (10% of fleet → 25% → 100%). Canary deployments for patches reduce the blast radius of a patch causing application failures in production. Always have a tested rollback procedure before deploying patches to production.

6. Phase 5 — Verification and validation
5
Verification — patches must be proven effective, not assumed
25–30% of "patched" vulnerabilities reappear in the next scan due to patch failures, image rebuilds, or rollbacks

Verification confirms that the remediation action actually resolved the vulnerability. Vulnerabilities are only marked as closed when a subsequent scan confirms they are no longer present. Common reasons vulnerabilities reappear after "patching": patch was applied but the service was not restarted (so the old version is still running in memory), patch was applied to one node but not others in a cluster, a new VM was deployed from an unpatched image template, or the patch was rolled back due to a compatibility issue without a compensating control being applied.

  • Rescan after remediation: Schedule a targeted rescan of the specific asset within 24–48 hours of the patch being applied. Confirm the CVE is no longer present before closing the ticket.
  • Automated verification in CI/CD: For containerised workloads, Trivy or Grype scans as part of the deployment pipeline confirm the deployed image is patch-compliant before it reaches production. The pipeline fails and the deployment is blocked if a CRITICAL CVE is present.
  • Penetration testing validation: Annual (or more frequent) penetration tests validate that prioritised remediation is effective — a pen tester attempting to exploit previously identified vulnerabilities and confirming they cannot is the highest-confidence validation method.
  • Compliance scan for audit evidence: For vulnerabilities tied to regulatory requirements (PCI DSS quarterly ASV scans, ISO 27001 A.8.8), the verification scan produces the audit evidence required to demonstrate compliance.
# Verify a specific CVE is no longer present on a host # Nessus: rescan with a plugin ID filter for the specific CVE nessuscli scan new \ --name "Verification-CVE-2021-44228-$(date +%Y%m%d)" \ --policy "Advanced Scan" \ --targets "10.0.1.25" \ --plugin-set "CVE-2021-44228" # Trivy — verify container is clean after patching base image docker pull myapp:patched-1.0.1 trivy image --exit-code 1 --severity CRITICAL myapp:patched-1.0.1 # exit code 0 = no CRITICAL CVEs = verification passed # exit code 1 = CRITICAL CVEs remain = verification failed, do not deploy # Nuclei — verify specific CVE is no longer exploitable nuclei -u https://target.com/api -t cves/2021/CVE-2021-44228.yaml # Returns: [INF] No results found — CVE is no longer exploitable
7. Phase 6 — Reporting and continuous improvement
📊
Reporting — different stakeholders need different vulnerability data
Boards need risk narrative; IT teams need ticket queues; auditors need evidence

Vulnerability data must be translated into the right format for each audience. A raw scan report with 57,000 findings is not useful to anyone. A structured report that shows: trend of CRITICAL and HIGH findings over time, MTTR against SLA, KEV exposure count, and percentage of assets scanned — is actionable for IT teams and interpretable by leadership.

Report types
  • Operational report (weekly, for IT/security teams): Open CRITICAL/HIGH findings by asset owner, overdue findings (SLA breached), new findings from most recent scan, findings closed this week. Drives the patch queue.
  • Management report (monthly, for CISO and IT leadership): MTTR trend by severity, total open findings by severity and age, SLA compliance rate, scan coverage percentage, top vulnerable assets and systems, KEV exposure. Shows programme performance.
  • Executive/board report (quarterly): Vulnerability risk trend (is the programme improving?), comparison against industry benchmarks, CRITICAL and KEV exposure summary, key remediation achievements, and investment required for programme improvement. Business language — risk dollars not CVE IDs.
Continuous improvement — closing the loop

Each scan cycle should answer: which assets have the highest concentration of vulnerabilities (systemic patching or asset management failure?), which vulnerabilities keep reappearing (patch process failure? image template not updated?), which asset owners are consistently missing SLAs (resourcing issue? awareness issue?), and where is the scanning coverage gap (assets not being scanned at all). Quarterly programme reviews should update asset criticality tiers, scan schedules, SLA targets, and prioritisation weights based on observed patterns and evolving threat intelligence.

8. Vulnerability scanning tools — enterprise comparison
ToolTypeCoverageEPSS / KEVBest forLicence
Tenable Nessus ProfessionalNetwork + agentOS, apps, network devices, cloud, containersYes (EPSS + Tenable VPR score)Mid-size to enterprise on-premises and hybrid environments. Most comprehensive plugin library (200,000+ checks).Commercial
Tenable.io / Vulnerability ManagementCloud SaaS + agentSame as Nessus + cloud assets + web apps + identityYes (VPR = CVSS + EPSS + threat intel)Enterprise cloud-heavy environments needing unified visibility across cloud + on-prem + containers.Commercial
Qualys VMDRCloud SaaS + agentOS, apps, containers, cloud assets, web apps, OTYes (QDS score)Large enterprises needing compliance + VM in one platform. Strong PCI DSS ASV scanning capability.Commercial
Rapid7 InsightVMCloud SaaS + agent + networkOS, apps, containers, cloud, webYes (EPSS integrated)Enterprises wanting strong integration with Rapid7 SIEM (InsightIDR) and incident response toolchain.Commercial
OpenVAS / GreenboneNetwork scannerOS, apps, network devices — 75,000+ testsPartial (community plugins)Budget-conscious organisations. Free community edition (Greenbone Community) covers most infrastructure needs. Requires more tuning than commercial tools.Open-source (GPL)
Trivy (Aqua Security)Container/IaC/filesystemContainer images, Kubernetes, IaC, filesystems, SBOMsYes (EPSS scores in v0.47+)DevSecOps pipelines and cloud-native environments. Best-in-class container vulnerability scanning. Free.Open-source (Apache)
Grype (Anchore)Container/SBOMContainer images, SBOMs, filesystemsYes (EPSS integrated)CI/CD pipeline scanning; SBOM-based vulnerability detection. Works well alongside Syft for SBOM generation.Open-source (Apache)
Nuclei (ProjectDiscovery)Web/API/networkCVEs, misconfigs, web, API, network services — 9,000+ templatesPartialFast, template-based scanning for specific CVEs and misconfigurations. Excellent for DevSecOps and targeted verification scanning.Open-source (MIT)
Microsoft Defender Vulnerability ManagementAgent-based (Windows/Linux/macOS)OS, apps, browser plugins, certificates, network sharesYes (CVSS + exposure score)Microsoft-heavy enterprises already using Defender for Endpoint. Zero additional deployment cost for Defender E5 customers.Commercial (included in E5)
Wiz / Orca Security / Prisma CloudCloud CSPM + agentless scanningCloud resources, containers, Kubernetes, IaC, secrets, identitiesYesCloud-native enterprises. Agentless scanning of cloud VMs without deploying agents. Combines VM with CSPM and CIEM.Commercial
💡 The right tool combination for most enterprise environments (2026) For on-premises and hybrid: Tenable.io or Qualys VMDR as the primary scanner with agents on all endpoints and credential-based network scanning for infrastructure. For cloud workloads: Wiz or Orca for agentless cloud scanning (no agent deployment, scans cloud APIs directly) alongside Trivy in CI/CD pipelines. For containers: Trivy in the CI/CD pipeline (build-time) and Trivy operator or Trivy server for runtime scanning in Kubernetes. Microsoft Defender Vulnerability Management is worth enabling for any organisation already paying for Defender E5 — it adds zero additional cost and covers Windows, Linux, and macOS endpoints with no additional agent required.
9. Patch SLAs and policy framework
📋
Patch SLA policy — define, communicate, measure, and enforce
SLAs without measurement and enforcement are aspirations, not controls
VULNERABILITY MANAGEMENT — PATCH SLA POLICY ═══════════════════════════════════════════════════════════════════ Scope: All technology assets within the organisation's ISMS scope Owner: Information Security Manager Review: Annual (or following a major vulnerability disclosure event) 1. SEVERITY DEFINITIONS AND REMEDIATION SLAs ───────────────────────────────────────────── CRITICAL (CVSS 9.0–10.0 OR in CISA KEV): Tier 1 assets: Patch within 24 hours of scanner detection Tier 2 assets: Patch within 48 hours Tier 3 assets: Patch within 7 days Exception process: CISO sign-off required; compensating control mandatory within 24h of exception HIGH (CVSS 7.0–8.9 NOT in CISA KEV): Tier 1 assets: Patch within 7 days Tier 2 assets: Patch within 14 days Tier 3 assets: Patch within 30 days Exception process: Security Manager sign-off required MEDIUM (CVSS 4.0–6.9): All tiers: Patch within 30 days (Tier 1) or 60 days (Tier 2/3) Exception: Document in vulnerability register with risk owner sign-off LOW (CVSS 0.1–3.9): All tiers: Patch within 90 days or next quarterly patch cycle Exception: Risk acceptance by asset owner with annual review 2. EXCEPTION PROCESS ────────────────────── An exception may be requested when a patch: a) Is not yet available (zero-day — implement compensating control) b) Would break a critical business function (compatibility) c) Cannot be applied during a business change freeze Exception requirements: - Written request with business justification - Compensating control described and implemented - Deadline for patch application - Risk owner sign-off (CISO for CRITICAL, SM for HIGH) - Exception logged in vulnerability register - Exception reviewed at next scan cycle 3. SCAN SCHEDULE ──────────────── Tier 1 assets: Daily agent scan + weekly authenticated network scan Tier 2 assets: Weekly agent scan or authenticated network scan Tier 3 assets: Monthly scan Internet-facing assets: Weekly unauthenticated external scan Cloud assets: Continuous CSPM + weekly agent scan Container images: Every build (CI/CD pipeline) + daily registry scan 4. VERIFICATION REQUIREMENT ──────────────────────────── All CRITICAL and HIGH vulnerabilities must be verified as resolved by a subsequent scan before the finding is closed in the VM platform. Findings are not closed based on a change ticket alone.
10. KPIs and metrics that prove programme effectiveness
Mean Time to Remediate (MTTR)
CRITICAL < 9 days
Average days from scanner detection to verified closure, by severity. Industry benchmark: CRITICAL <9 days (mature); <30 days (average). Track trend month-over-month.
SLA Compliance Rate
> 90%
% of findings remediated within defined SLA. Target: 95%+ for CRITICAL, 90%+ for HIGH. Below 80% indicates resourcing or process failure requiring escalation.
Scan Coverage
> 95%
% of known assets scanned within the defined schedule period. Assets below 95% coverage represent blind spots. Target 100% for Tier 1 assets.
Vulnerability Backlog Trend
Decreasing
Total open findings by severity over time. Growing backlog = programme not keeping pace with new disclosures. Flat or declining = programme is working.
KEV Exposure Count
= 0
Number of CISA KEV entries present in your environment. Target: zero. Any KEV finding older than 14 days is a programme failure requiring immediate escalation.
Vulnerability Age
< 30 days avg
Average age of open CRITICAL and HIGH findings. High average age indicates a remediation bottleneck. Break down by asset owner to identify which teams are behind.
Recurrence Rate
< 5%
% of closed vulnerabilities that reappear in the next scan. High recurrence (>15%) indicates patch process failure — patches not sticking, image templates not updated, rollbacks without re-patching.
Authenticated Scan Rate
> 90%
% of scanned assets scanned with authenticated credentials. Unauthenticated scans miss 80–90% of vulnerabilities. Low rate = false assurance from the programme.
11. Best practices and common programme failures
✅
Enterprise vulnerability management — best practices checklist
Prioritise controls that directly reduce exploitation risk
🔴 Critical — programme foundations
  • ✓
    Complete asset inventory before any scanning begins — a scan against an incomplete inventory produces a false sense of security. The assets not in inventory are the ones most likely to be unpatched (unknown to IT operations and therefore never patched).
  • ✓
    Always use authenticated scanning — unauthenticated scans find 10–20% of vulnerabilities that authenticated scans find. Never report programme health based on unauthenticated scan data. If scan credentials are failing on a portion of assets, that is the metric to report and fix.
  • ✓
    Subscribe to CISA KEV and treat KEV entries as emergency patches — free, highly actionable threat intelligence. Any KEV CVE in your environment is known to be exploited in the wild and must be patched within 14 days maximum regardless of asset tier. Set up automated KEV alerting against your scan results.
  • ✓
    Integrate EPSS scores into prioritisation — CVSS-only prioritisation treats a 9.8 CVE that has never been exploited the same as a 7.5 CVE being actively exploited in ransomware campaigns. EPSS provides exploitation probability. Free API from first.org or native in Tenable, Qualys, and Rapid7.
  • ✓
    Assign asset owners and make SLA compliance their accountability — vulnerability management fails when remediation is the security team's problem rather than the asset owner's. The security team identifies and prioritises. The asset owner and their team patch. SLA compliance is an operational metric for system owners, not a security team metric.
🟡 High — programme maturity
  • ✓
    Integrate the VM platform with your ITSM (ServiceNow, Jira) — automatically create remediation tickets from scan findings, assign to the correct team, set due dates based on SLA policy, and track closure status back to the scanner. Manual ticket creation is slow, error-prone, and produces stale data.
  • ✓
    Deploy agents on all managed endpoints — agents eliminate the coverage gap for laptops that are off-network, VMs that are network-unreachable from the scanner, and assets behind NAT. Agent-based scanning is the only way to maintain continuous visibility for endpoints.
  • ✓
    Include container and cloud assets in the programme scope — traditional VM programmes cover on-premises infrastructure but miss container images, serverless functions, cloud-native services, and cloud VMs deployed without the scanner agent. Cloud and container vulnerabilities are growing faster than traditional OS vulnerabilities.
  • ✓
    Establish a formal exception and risk acceptance process — without it, the programme either has 100% compliance on paper (because exceptions are undocumented) or teams self-approve delays. A documented exception process with risk owner sign-off makes risk acceptance visible, time-limited, and auditable.
Common vulnerability management programme failures
Failure modeSymptomRoot causeFix
Compliance-theatre scanningScans run monthly on schedule but findings are never actionedNo accountability for remediation; no SLA enforcement; VM seen as audit exerciseAssign asset owners; make SLA compliance a management KPI; escalation process for breaches
Unauthenticated scanningLow finding count; findings seem manageable; major breach occursScan credentials not configured; credential management difficult; false assurance from low finding countInvest in credential management; use agent-based scanning as fallback; report authenticated scan rate as a KPI
Incomplete asset inventoryRansomware spreads through an "unknown" server; attacker pivots through unscanned deviceAsset inventory not maintained; shadow IT; cloud sprawlContinuous discovery scanning; cloud API integration; MDM for endpoint visibility; compare scan results to DHCP logs
CVSS-only prioritisationTeam patches low-risk theoretical vulnerabilities while actively-exploited CVEs waitNo EPSS or KEV integration; CVSS scores drive the queueIntegrate EPSS; check CISA KEV daily; weight by asset criticality; re-sort the queue
No verification scanning"Patched" vulnerabilities reappear; closure rate looks good but assets remain exploitableFindings closed based on change tickets without confirmation scanningMandate re-scan before closure; automated verification scan triggered by ticket closure
Scanner island — no ITSM integrationIT teams not aware of vulnerabilities; security team manually creating tickets; stale dataVM platform and ITSM not integrated; manual handoffAPI integration between VM platform and ServiceNow/Jira; auto-ticket creation with SLA due dates
12 days
median time from CVE disclosure to active exploitation in the wild (Rapid7 2025)
5%
of published CVEs are ever exploited in the wild — EPSS and KEV identify which 5%
57,000
average open vulnerability findings in an enterprise environment — risk-based prioritisation is essential
60%
of breaches exploit vulnerabilities where a patch had been available for more than 6 months (Ponemon)

⚡ Start your vulnerability management programme — first four actions

  1. Download the CISA KEV catalogue and check it against your environment today — it takes 30 minutes. Download the JSON feed from cisa.gov/known-exploited-vulnerabilities-catalog. Extract the CVE IDs. Cross-reference against your existing scan results or asset inventory. Any match is a vulnerability that is known to be actively exploited in the wild and must be your first remediation priority. Set up a daily automated check: curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | jq -r '.vulnerabilities[].cveID'
  2. Run your first authenticated vulnerability scan within 7 days. If you have Nessus Essentials (free for up to 16 IPs), Tenable.io trial, or OpenVAS — set up one authenticated scan against your most critical 10 servers. Use the scan results to: measure how complete your patch management has been, identify what CRITICAL and HIGH findings exist right now, and build the business case for expanding the programme. A CISO who walks into a board meeting with "we have 3 unpatched Log4Shell-severity vulnerabilities on production systems" has a budget conversation. A CISO without scan data does not.
  3. Define your patch SLAs in a one-page policy this week. Use the template in Section 9 as a starting point. Get it signed by the CISO or CTO. Distribute it to all IT system owners. The SLA without enforcement is an aspiration; the SLA with a monthly SLA compliance KPI reported to management is a control. Start measuring SLA compliance from the date the policy is signed.
  4. Connect vulnerability management to your broader security programme. Vulnerability management feeds and is fed by: asset inventory (CMDB or cloud APIs), change management (patch deployments are changes), incident response (vulnerabilities exploited in incidents → priority remediation), DevSecOps (scan in CI/CD pipeline), and risk management (unpatched vulnerabilities are risks in the risk register). DevSecOps and CI/CD scanning → | Incident response → | Container vulnerability scanning → | Cloud vulnerability management →
Frequently asked questions
What is vulnerability management?

Vulnerability management is the continuous process of identifying, classifying, prioritising, remediating, and verifying security vulnerabilities in an organisation's technology environment. It is not a one-time scan or annual audit — it is an ongoing cycle that operates continuously as new vulnerabilities are disclosed daily, new assets are deployed, and configurations change. A mature vulnerability management programme maintains a complete asset inventory, scans all assets on defined schedules using authenticated credentials, prioritises findings by exploitation probability (EPSS) and known exploitation (CISA KEV) rather than CVSS score alone, tracks remediation to verified closure, and measures programme effectiveness through KPIs including MTTR, SLA compliance rate, and scan coverage percentage.

What is the CVSS score and how should it be used in vulnerability management?

CVSS (Common Vulnerability Scoring System) is a standardised framework for rating the severity of security vulnerabilities on a scale from 0.0 to 10.0. Scores are categorised as Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), and Low (0.1–3.9). CVSS is useful for standardised severity comparison but is not a complete prioritisation framework — it describes the theoretical worst-case severity of a vulnerability, not the likelihood that it will be exploited against your organisation. CVSS-only prioritisation treats a 9.8 CVE that has never been exploited the same as a 7.5 CVE being actively used in ransomware campaigns. Effective prioritisation combines CVSS with EPSS (Exploit Prediction Scoring System — exploitation probability in the next 30 days), the CISA KEV catalogue (known active exploitation), and asset criticality tier.

What is the CISA KEV catalogue and why does it matter?

The CISA Known Exploited Vulnerabilities (KEV) catalogue is a free, continuously updated list of CVEs that CISA has confirmed are being actively exploited by real threat actors in the wild. It currently contains over 1,100 vulnerabilities. US federal agencies are required to patch KEV entries within defined timelines (typically 2 weeks). For any organisation, KEV entries should be treated as the highest remediation priority regardless of CVSS score — several KEV entries have CVSS scores below 7.0 that would be deprioritised by CVSS-only programmes, yet are being actively used in attacks. The KEV feed is available at cisa.gov/known-exploited-vulnerabilities-catalog in JSON format and can be integrated into vulnerability management platforms or checked daily via a simple API query against your scan results.

What is the difference between authenticated and unauthenticated vulnerability scanning?

An authenticated scan uses credentials (Windows admin account, SSH key) to log into each scanned system and inspect it from the inside — checking installed software versions, missing patches, OS configurations, and security settings. An unauthenticated scan only sees what is visible from the network — open ports, service banners, and network-level vulnerabilities. Authenticated scans typically find 5–10 times more vulnerabilities than unauthenticated scans of the same system. Running only unauthenticated scans produces a false sense of security — the finding count looks manageable because the majority of vulnerabilities are simply not visible. Always use authenticated scanning for internal assets. Reserve unauthenticated scanning for external attack surface scanning (simulating an external attacker's view of internet-facing services).

What are realistic patch SLAs for enterprise vulnerability management?

Industry benchmark SLAs for enterprise vulnerability management: CRITICAL vulnerabilities (CVSS 9.0+ or in CISA KEV) should be patched within 24–48 hours on Tier 1 (critical) assets and within 7 days on lower-tier assets. HIGH vulnerabilities (CVSS 7.0–8.9) should be patched within 7 days on Tier 1 assets and 14–30 days on others. MEDIUM vulnerabilities within 30–60 days. LOW within 90 days or the next quarterly patch cycle. These SLAs apply from the date the vulnerability appears in a scan result, not from the date the CVE was publicly disclosed. Mature programmes (MTTR under 9 days for CRITICAL) consistently outperform these targets; average programmes take 30–60 days for CRITICAL vulnerabilities. SLAs without measurement and enforcement are aspirations — the programme must track SLA compliance rate as a reported KPI.

What tools are used for vulnerability scanning in enterprise environments?

The most widely used enterprise vulnerability scanning tools are: Tenable Nessus / Tenable.io (most comprehensive plugin library, strong cloud integration, native EPSS and KEV integration), Qualys VMDR (cloud SaaS, strong compliance scanning, PCI DSS ASV capability), and Rapid7 InsightVM (strong SIEM integration, good for organisations also using InsightIDR). For cloud-native environments: Wiz and Orca Security provide agentless scanning of cloud assets without deploying agents. For container and DevSecOps pipelines: Trivy (open-source, excellent CI/CD integration) and Grype (Anchore, SBOM-based scanning). For open-source infrastructure scanning: OpenVAS/Greenbone Community Edition. Microsoft Defender Vulnerability Management is worth enabling for Microsoft E5 customers at zero additional cost. Most enterprises use a combination — a primary scanner for infrastructure plus a specialised tool for containers and cloud.

About the author Written by the HOC Team at Hackers Online Club — a cybersecurity community trusted by security engineers, vulnerability management teams, CISOs, and IT operations professionals since 2010. 15+ years of practical cybersecurity guides, vulnerability management tutorials, and enterprise security resources. Learn more about HOC →