Vulnerability Management Process: Framework, Templates & Best Practices

The Vulnerability Management Lifecycle

Vulnerability management is a continuous cycle, not a one-time project. The lifecycle consists of six stages that repeat on a regular cadence.

Stage 1: Asset Discovery and Inventory

You cannot protect what you do not know exists. Before scanning for vulnerabilities, you need a comprehensive and current inventory of every asset in your environment.

What to inventory:

• Servers and workstations: Physical and virtual machines, including operating system versions and patch levels
• Network devices: Routers, switches, firewalls, load balancers, wireless access points
• Cloud resources: VMs, containers, serverless functions, storage buckets, databases, managed services across AWS, Azure, GCP
• Applications: Commercial off-the-shelf software, custom-developed applications, SaaS platforms
• APIs: Internal and external-facing APIs with their underlying infrastructure
• IoT and OT devices: Connected devices that may not support traditional agents
• Shadow IT: Unapproved cloud services, personal devices, and rogue applications

Asset classification attributes to capture:

Automate asset discovery using network scanning tools (Nmap, Rumble), cloud provider APIs, and endpoint management platforms. Reconcile discoveries against your CMDB monthly to catch drift.

Stage 2: Vulnerability Scanning

With a complete asset inventory, configure scanning to achieve maximum coverage with minimal operational disruption.

Scanning approaches:

• Authenticated (credentialed) scans log into systems to check installed software versions, configurations, and local vulnerabilities. These produce far more accurate results than unauthenticated scans
• Unauthenticated (network) scans probe systems from the network perspective, identifying open ports, services, and externally visible vulnerabilities
• Agent-based scanning deploys lightweight agents on endpoints for continuous assessment without network scan traffic
• Cloud-native scanning uses provider APIs and services (AWS Inspector, Azure Defender, GCP Security Command Center) to assess cloud workloads
• Container image scanning checks container images in registries for known vulnerabilities before deployment
• Web application scanning (DAST) crawls and tests web applications for OWASP Top 10 vulnerabilities

Recommended scanning cadence:

• External-facing assets: Weekly
• Internal servers and infrastructure: Bi-weekly to monthly
• Workstations and endpoints: Monthly via agents
• Container images: On every build in CI/CD pipeline
• Web applications: Monthly automated, quarterly manual penetration testing
• Cloud configurations: Continuous via CSPM tools

Stage 3: Vulnerability Assessment and Prioritization

Raw scan results are overwhelming. A mid-sized organization can easily have 50,000 to 200,000 vulnerability findings across its environment. Without effective prioritization, teams drown in noise and either try to fix everything (impossible) or fix nothing meaningful.

Do not rely solely on CVSS scores. The Common Vulnerability Scoring System measures the technical severity of a vulnerability in isolation. It does not account for your specific environment, compensating controls, or threat intelligence. A CVSS 9.8 vulnerability on an air-gapped development server with no sensitive data is far less urgent than a CVSS 7.0 vulnerability on your internet-facing payment processing system.

Use a risk-based prioritization framework:

Combine multiple factors to calculate a contextual risk score:

1. CVSS base score (technical severity)
2. Exploit availability (Is there a public exploit? Is it being used in the wild?)
3. Asset criticality (How important is this system to the business?)
4. Data sensitivity (What data could be compromised?)
5. Internet exposure (Is this reachable from the internet?)
6. Compensating controls (Is there a WAF, network segmentation, or other mitigation in place?)
7. Threat intelligence (Is this vulnerability being actively exploited by threat actors targeting your industry?)

Prioritization tiers:

Use CISA's Known Exploited Vulnerabilities (KEV) catalog as a mandatory input. If a vulnerability is on the KEV list, it has confirmed exploitation in the wild and should be treated as Critical regardless of other factors.

Use our Risk Assessment Calculator to model the business impact of different vulnerability scenarios.

Stage 4: Remediation Workflow

Prioritization without a structured remediation workflow leads to findings sitting in dashboards indefinitely. Build a process that assigns ownership, tracks progress, and enforces accountability.

Remediation Options

Not every vulnerability can or should be fixed with a patch. Your workflow should support multiple remediation approaches:

• Patch: Apply the vendor-supplied update that fixes the vulnerability. This is the preferred approach when patches are available and tested
• Upgrade: Move to a newer version of the software that is no longer affected
• Configuration change: Modify settings to eliminate the vulnerable condition (disable unused services, restrict access, harden configurations)
• Compensating control: When patching is not possible (legacy systems, vendor dependencies), implement controls that reduce the risk: network segmentation, WAF rules, enhanced monitoring, access restrictions
• Accept risk: For low-priority findings where remediation cost exceeds the risk, formally document the risk acceptance with business owner sign-off and an expiration date for re-evaluation
• Decommission: Retire the vulnerable system if it is no longer needed

Remediation Workflow Steps

1. Triage and assign: Route prioritized findings to the responsible asset owner or team. Include vulnerability details, affected assets, priority level, and SLA deadline
2. Validate finding: The responsible team confirms the vulnerability is real (not a false positive) and applicable to their environment
3. Plan remediation: Determine the remediation approach, test the fix in a non-production environment, and schedule the change window
4. Implement fix: Apply the patch, configuration change, or compensating control following your change management process
5. Verify remediation: Re-scan the affected asset to confirm the vulnerability is resolved. Do not close findings based on the assertion that a patch was applied; verify with a scan
6. Document and close: Record the remediation action, date, and verification results. Close the finding in your tracking system

Handling Exceptions and Risk Acceptances

Every program needs a formal exception process for vulnerabilities that cannot be remediated within SLA:

• Exception request must include: business justification, compensating controls in place, risk assessment, proposed re-evaluation date, and business owner approval
• Maximum exception duration: 90 days for Critical and High findings, 180 days for Medium and Low
• Mandatory review: All exceptions must be reviewed at expiration with fresh risk assessment
• Exception tracking: Maintain a register of all active exceptions visible to security leadership

Stage 5: Verification and Validation

Closing the loop is what separates mature programs from checkbox exercises.

• Automated re-scanning: Configure your scanner to automatically re-scan assets after the remediation SLA passes
• Spot checks: Manually verify a sample of remediated findings to ensure quality
• Penetration testing: Quarterly penetration tests validate that critical vulnerabilities are truly resolved and not just masked
• Red team exercises: Annual red team engagements test whether your vulnerability management program actually reduces attacker success

Stage 6: Reporting and Program Improvement

Report vulnerability management metrics at three levels:

Operational (weekly):

• New vulnerabilities discovered this week
• Vulnerabilities remediated this week
• Overdue findings by priority
• Top 10 most critical open findings

Tactical (monthly):

• Mean time to remediate (MTTR) by priority level
• SLA compliance rate by team
• Vulnerability aging analysis
• Scan coverage percentage
• Exception register summary

Strategic (quarterly):

• Overall risk posture trend
• Comparison against industry benchmarks
• Program maturity assessment
• Resource and tooling needs
• Compliance status

Key Metrics and Benchmarks

Track these metrics to evaluate your program's maturity:

Coverage metrics:

• Scan coverage: Percentage of assets scanned within the defined cadence. Target: 95%+
• Authenticated scan ratio: Percentage of scans performed with credentials. Target: 80%+

Efficiency metrics:

• Mean time to remediate (MTTR): Average days from discovery to verified remediation
  • Critical: Target under 7 days (industry median: 30 days)
  • High: Target under 30 days (industry median: 60 days)
  • Medium: Target under 60 days
• SLA compliance rate: Percentage of findings remediated within the defined SLA. Target: 85%+

Risk metrics:

• Open critical/high findings: Total count with trend over time. Should be decreasing
• Vulnerability density: Findings per asset, normalized for comparison across teams
• Recurrence rate: Percentage of vulnerabilities that reappear after remediation, indicating systemic issues
• KEV exposure: Number of CISA KEV vulnerabilities present in your environment. Target: zero within 14 days of KEV listing

Vulnerability Management Templates

Vulnerability Register Template

Maintain a centralized register with the following fields for each finding:

• Finding ID (unique identifier)
• Vulnerability name and CVE (e.g., CVE-2025-12345)
• Source (scanner name, penetration test, bug bounty)
• Affected asset(s) with asset ID from your inventory
• CVSS score (base and environmental if available)
• Risk priority (Critical / High / Medium / Low)
• Status (Open / In Progress / Remediated / Verified / Accepted / False Positive)
• Assigned owner (individual or team)
• Discovery date
• SLA deadline
• Remediation action taken
• Verification date and method
• Exception details (if applicable)

Scan Schedule Template

Document your scanning program:

• Scan name (e.g., "Weekly External Perimeter Scan")
• Scope (IP ranges, asset groups, cloud accounts)
• Scan type (authenticated, unauthenticated, agent-based)
• Frequency (weekly, bi-weekly, monthly, continuous)
• Scan window (day of week, time, duration)
• Scanner (tool name and version)
• Owner responsible for reviewing results
• Exclusions with documented justification

Remediation SLA Matrix

Define and document your SLAs clearly:

Monthly VM Program Report Template

Structure your monthly report with these sections:

1. Executive summary (3-5 sentences on overall posture and key developments)
2. New findings by priority with month-over-month comparison
3. Remediation progress showing closures, SLA compliance, and MTTR
4. Overdue findings with escalation status and responsible owners
5. Scan coverage showing percentage of assets covered
6. Exception register listing active risk acceptances
7. Top risks highlighting the most significant open findings
8. Recommendations for program improvements

Selecting Vulnerability Scanning Tools

Your tool selection should match your environment complexity and budget:

Enterprise vulnerability scanners:

• Tenable Nessus / Tenable.io: Market leader with extensive plugin library and cloud-native options
• Qualys VMDR: Cloud-native platform with integrated patch management
• Rapid7 InsightVM: Strong risk scoring and integration with SIEM and SOAR platforms

Open-source options:

• OpenVAS / Greenbone: Full-featured community scanner suitable for smaller environments
• Nuclei: Template-based scanner excellent for web application and API testing
• Trivy: Container and infrastructure-as-code scanning

Cloud-native tools:

• AWS Inspector: Automated scanning for EC2 instances, Lambda functions, and ECR container images
• Microsoft Defender for Cloud: Azure-native vulnerability assessment and CSPM
• GCP Security Command Center: Vulnerability and threat detection for Google Cloud

Evaluation criteria:

• Asset coverage (servers, cloud, containers, applications)
• Accuracy (false positive rate, detection coverage)
• Integration with your ticketing system, SIEM, and CI/CD pipeline
• Authenticated scanning capabilities
• Reporting and dashboard quality
• Pricing model (per asset, per scan, per IP)

Common Pitfalls in Vulnerability Management

Pitfall 1: Scanning Without Remediation

Problem: Organizations run scans, generate reports, and file them away. Vulnerabilities are discovered but never fixed.

Solution: Connect scan results directly to your ticketing system with automated ticket creation. Assign ownership and enforce SLAs. Report overdue findings to leadership weekly.

Pitfall 2: Prioritizing by CVSS Alone

Problem: Teams spend weeks patching a CVSS 10.0 on a test server while ignoring a CVSS 7.5 on their internet-facing payment system.

Solution: Implement risk-based prioritization that factors in asset criticality, exposure, exploit availability, and threat intelligence. CVSS is one input, not the only input.

Pitfall 3: Incomplete Asset Inventory

Problem: You cannot scan what you do not know exists. Shadow IT, cloud sprawl, and M&A activity create blind spots.

Solution: Run discovery scans across your entire IP space regularly. Integrate cloud provider APIs for automatic inventory. Reconcile against your CMDB and investigate discrepancies.

Pitfall 4: No Verification After Remediation

Problem: Findings are closed after a patch is deployed without confirming the vulnerability is actually resolved.

Solution: Require a verification scan before closing any finding. Automate re-scanning of remediated assets. Audit a sample of closures monthly.

Pitfall 5: Treating VM as a Security-Only Problem

Problem: Security identifies vulnerabilities but system administrators and developers own remediation. Without their buy-in, nothing gets fixed.

Solution: Make vulnerability remediation a shared KPI. Include MTTR and SLA compliance in team performance metrics. Provide dashboards that give asset owners visibility into their findings. Celebrate teams that consistently meet SLAs.

Program Maturity Assessment

Evaluate your vulnerability management program against these maturity levels:

Level 1 - Initial: Scans are run ad hoc with no consistent cadence. Results are reviewed manually. No formal remediation process or SLAs. Limited asset inventory.

Level 2 - Developing: Regular scan schedule established. Basic prioritization by CVSS. Findings assigned to owners. SLAs defined but not consistently enforced. Asset inventory exists but is incomplete.

Level 3 - Defined: Risk-based prioritization implemented. Automated ticket creation and workflow. SLAs enforced with exception process. Comprehensive asset inventory maintained. Monthly reporting to leadership.

Level 4 - Managed: Metrics-driven program with benchmarking. Vulnerability data integrated with threat intelligence. Automated verification scanning. Quarterly penetration testing validates program effectiveness. Program covers cloud, containers, and applications in addition to infrastructure.

Level 5 - Optimizing: Continuous improvement driven by data. VM integrated into CI/CD pipeline (shift-left). Automated remediation for known vulnerability classes. Red team exercises validate program. Risk-based metrics inform strategic security investment decisions.

Most organizations should target Level 3 within 12 months and Level 4 within 24 months. For help assessing your overall security and compliance readiness, explore our Security & Compliance resources and use the Risk Assessment Calculator to quantify your exposure.