Vulnerability Management Checklist

Overview

This checklist covers the end-to-end lifecycle of a vulnerability management program — from asset discovery and scan configuration through patching SLAs, risk acceptance, and compliance evidence collection. Use it during program setup, quarterly reviews, or as an operational run-book when onboarding new asset classes into your scanning pipeline.

Note: Vulnerability management is a continuous process, not a project. Schedule a recurring review of this checklist at least quarterly to ensure scan coverage, SLA adherence, and risk register accuracy stay current.

1. Asset Inventory

Accurate asset inventory is the foundation of vulnerability management — you cannot scan or patch what you do not know exists.

• Run a full network discovery scan — Use a tool such as Nmap or your scanner's built-in discovery mode to enumerate all live hosts on RFC 1918 ranges and any routable segments

  # Nmap discovery across internal /16 — adapt to your CIDR
  nmap -sn 10.10.0.0/16 -oG - | awk '/Up$/{print $2}' > discovered_hosts.txt

• Cross-reference discovered hosts against CMDB — Flag any host present in the scan output but absent from the CMDB as a shadow IT candidate requiring ownership assignment

• Tag assets by criticality — Assign a tier (Critical / High / Standard / Low) that will drive scan frequency and patching SLA selection

• Assign an owner to every asset — Every host, container, and cloud resource must have a named owner and backup contact in the CMDB

• Include cloud-hosted assets — Pull IaaS/PaaS inventories from AWS, Azure, or GCP APIs; do not rely solely on internal network scans

• Enumerate container and serverless workloads — Container images and Lambda/Cloud Run functions have their own CVE surface; ensure they are registered as scannable assets

2. Scanning Configuration

A misconfigured scanner produces false negatives as dangerous as not scanning at all.

• Use authenticated scans wherever possible — Provide scanner credentials (SSH key, Windows domain account, API token) to enable local enumeration of installed packages and registry values

  # Example Nessus authenticated scan credential check
  # Confirm SSH key auth works before adding to scan policy
  ssh -i /etc/nessus/scanner_key scanuser@target-host "id"

• Maintain a separate unauthenticated scan profile — Run unauthenticated scans against DMZ and externally reachable assets to simulate an attacker with no credentials

• Configure scan policies per asset tier — Critical assets warrant a full plugin set; Standard assets may use a tuned policy to reduce runtime and noise

• Define and document exclusions — Any host or port range excluded from scanning must be recorded with a business justification and an expiry date

• Enable CVSS-based severity mapping — Ensure your scanner maps findings to CVSS v3.1 base scores; disable legacy CVSS v2-only scoring where possible

• Validate scanner plugin feeds are current — Confirm plugin/feed updates run at least daily before any scheduled scan window

  # Qualys: check last scan engine update via API
  curl -u "user:pass" -H "X-Requested-With: Curl" \
    "https://qualysapi.qualys.com/api/2.0/fo/appliance/?action=list" \
    | grep -i "last_updated"

• Test scanner credentials quarterly — Verify that service accounts used for authenticated scans have not been locked, expired, or had permissions reduced

3. Scan Cadence

Consistent scan scheduling ensures new vulnerabilities are detected promptly and remediation progress can be measured over time.

• Schedule weekly scans for all Critical and High-tier assets — Run during a low-traffic maintenance window and alert on scan failures within 2 hours
• Schedule monthly scans for Standard-tier assets — Monthly cadence balances coverage with scanner resource consumption
• Schedule quarterly scans for Low-tier or isolated assets — Review the Low-tier classification annually; assets may be re-tiered as business impact changes
• Define ad-hoc scan triggers — Document the conditions that require an out-of-band scan: a zero-day announcement, a new CVE affecting a known technology, or a significant infrastructure change
• Run post-change validation scans — After any major deployment, patch window, or firewall rule change, run a targeted scan of affected assets within 24 hours to confirm no new exposures were introduced
• Track scan completion rates — Generate a weekly report showing percentage of scheduled scans that completed successfully; target 98%+ coverage

4. Patching SLAs

Documented SLAs create accountability and provide a measurable baseline for audit and compliance purposes.

• Critical (CVSS 9.0–10.0): patch within 24–48 hours — For zero-days with active exploitation, escalate immediately; do not wait for the next patch cycle

  SLA Timer Start: Date/time CVE first appears in scan results
  SLA Timer End:   Date/time patch applied AND validated scan shows no finding
  Breach Action:   Automatic ticket escalation to CISO + system owner
  

• High (CVSS 7.0–8.9): patch within 7 days — If a patch is unavailable, a compensating control (WAF rule, network ACL, service disable) must be in place within 7 days with a full patch target of 30 days

• Medium (CVSS 4.0–6.9): patch within 30 days — Include in the next scheduled maintenance window; track as a standard change

• Low (CVSS 0.1–3.9): patch within 90 days — Bundle with quarterly update cycles; acceptable to defer if compensating controls exist

• Establish an emergency patching procedure — Document the break-glass process for deploying a patch outside normal change windows, including required approvals and rollback criteria

• Track patch exceptions separately from risk acceptances — A patch exception is a temporary delay with a hard deadline; a risk acceptance is a formal decision not to patch

5. Risk Acceptance

Not every vulnerability can or should be patched immediately. A formal risk acceptance process prevents informal deferrals from accumulating into an unmanaged backlog.

• Document a risk acceptance policy — Define who can accept risk at each severity level (e.g., team lead for Medium, CISO sign-off for High/Critical)

• Use a standard risk acceptance form — The form must capture: CVE ID, affected asset, CVSS score, business justification, compensating controls in place, and expiry date

  Risk Acceptance Form Fields:
  - CVE / Finding ID:
  - Asset(s) affected:
  - CVSS Base Score:
  - Business justification (why patching is not feasible now):
  - Compensating controls implemented:
  - Acceptance expiry date (max 90 days for High; 180 days for Medium/Low):
  - Approver name and date:
  

• Set maximum expiry windows by severity — High: 90 days; Medium: 180 days; Low: 365 days; Critical: no acceptance permitted without executive sign-off and board notification

• Send expiry reminders at 30/14/7 days before expiry — Automate via ticketing system or calendar event; expired acceptances must be re-approved or remediated

• Re-evaluate acceptances when threat intelligence changes — If a CVE transitions from theoretical to actively exploited, existing acceptances must be reviewed within 48 hours

• Maintain a risk register — All active acceptances are logged in a central risk register with links to the originating scan finding

6. Remediation Tracking

Visibility into remediation progress prevents vulnerabilities from aging past SLA thresholds unnoticed.

• Create a ticket for every High and Critical finding — Ticket must reference the CVE ID, affected host(s), SLA deadline, and assigned owner; link back to the scanner finding ID

• Integrate your scanner with your ticketing system — Automate ticket creation on new High/Critical findings; auto-close tickets when the next scan confirms the finding is resolved

• Generate weekly aging reports — Show all open findings grouped by severity with days-open and SLA status (On Track / At Risk / Breached)

  Aging Report Columns:
  CVE ID | Asset | Severity | Days Open | SLA Deadline | Status | Owner
  -------|-------|----------|-----------|--------------|--------|------
  

• Set automated SLA breach alerts — At 75% of SLA elapsed, send a warning to the asset owner; at 100%, escalate to their manager and the security team lead

• Track repeat findings — If the same CVE reappears on the same asset within 30 days of remediation closure, flag as a re-open and investigate why the fix did not hold

• Review findings closed as "Not Applicable" — Audit a sample each month to confirm the justification is valid and the scanner is not producing systematic false negatives

• Measure remediation velocity — Track the number of findings opened vs. closed per week; a persistent backlog growth trend is an early warning sign

7. Reporting & Metrics

Metrics turn raw vulnerability data into decision-making signals for security leadership and business stakeholders.

• Publish an executive dashboard — Weekly one-page summary showing: total open findings by severity, SLA compliance rate, critical findings resolved this week, and top 5 most-vulnerable asset groups

• Track Mean Time to Remediate (MTTR) by severity — Calculate MTTR monthly; use as a KPI in security team performance reviews

  MTTR (Critical) = Sum of (Close Date − Open Date) for all Critical findings / Count of closed Critical findings
  Target:
    Critical: ≤ 2 days
    High:     ≤ 7 days
    Medium:   ≤ 30 days
  

• Produce a monthly trend report — Show month-over-month change in total open findings, new findings introduced, and findings closed; a downward trend in open findings is the target state

• Report on scan coverage — Express as a percentage of inventoried assets scanned within their required cadence window; flag any assets overdue

• Identify recurring vulnerable asset groups — Assets that consistently appear in High/Critical findings may indicate a systemic patching problem (e.g., end-of-life OS, unsupported software) requiring a remediation project rather than individual patches

• Benchmark against industry data — Compare your MTTR and open-finding density against sector-specific benchmarks (e.g., CIS Controls benchmarks, Verizon DBIR) annually

8. Compliance & Audit

Regulatory frameworks and audit requirements demand documented evidence that your vulnerability management program is operating as described.

• Map findings to regulatory controls — For each active framework (PCI DSS, ISO 27001, SOC 2, NIST CSF), document which vulnerability management controls satisfy which requirements

  Example Mapping:
  PCI DSS Req 6.3.3  → Monthly authenticated scans + patch SLA evidence
  ISO 27001 A.12.6.1 → Scan results, MTTR metrics, risk register
  SOC 2 CC7.1        → Scan schedule, remediation tickets, trend reports
  

• Retain scan reports for the required period — PCI DSS requires 12 months of scan history; align retention to your most demanding applicable framework

• Preserve evidence of remediation — For each closed finding, retain the pre-patch and post-patch scan results that demonstrate the vulnerability was present and then resolved

• Conduct a quarterly internal review — Walk through open findings, SLA compliance, and risk register with the security team; document the review with attendees and action items

• Schedule an annual third-party penetration test — External pen tests validate that your scanner is not missing vulnerabilities and that compensating controls are effective

• Validate your scanner against a known-vulnerable test host — Quarterly, confirm your scanner correctly identifies a set of known CVEs on a controlled test system to detect plugin drift or credential failures

  # Example: spin up a Metasploitable container as a scanner validation target
  docker run -d --name vuln-target --network isolated -p 127.0.0.1:2222:22 \
    tleemcjr/metasploitable2
  # Run scanner against 127.0.0.1:2222 — expect known findings

• Document your vulnerability management policy — Maintain a written policy (reviewed annually) that defines scope, roles, SLAs, risk acceptance thresholds, and escalation paths

• Test your escalation chain — Annually simulate a Critical finding with no available patch to verify the emergency patching procedure and executive escalation path work as documented

SLA Quick Reference

Roles & Responsibilities