APP-006 Vulnerability Management
Description
A vulnerability management process exists that identifies, classifies, prioritises, and remediates vulnerabilities in systems and applications on a risk-based schedule. Vulnerability scanning of internet-exposed systems is performed at least monthly. Critical and high-severity findings have defined remediation SLAs. Vulnerability metrics are tracked and reported.
Rationale
Unmanaged vulnerabilities accumulate and become exploitable attack surface. A formal programme with defined SLAs ensures that critical findings are addressed before they are weaponised.
Framework Mappings (6)
| TVM-01 | Threat and Vulnerability Management Policy and Procedures | full |
| TVM-03 | Vulnerability Identification | full |
| TVM-08 | Vulnerability Remediation Schedule | full |
| TVM-09 | Vulnerability Prioritization | full |
| RA-5 | Vulnerability Monitoring and Scanning | full |
| SI-2 | Flaw Remediation | partial |
Evidence (2)
Vulnerability scan reports for internet-exposed systems from the past 30 days, showing scan coverage, findings, and remediation status against defined SLAs.
Example: Tenable.io, Qualys, or AWS Inspector scan report for internet-facing assets, run within the last 30 days, listing all findings with CVE identifiers, CVSS scores, affected assets, and remediation status. Report should include an asset coverage summary.
Test: Request the last two vulnerability scan reports (to confirm regularity). Verify: (1) scans cover all internet-exposed assets — cross-reference asset inventory to confirm coverage, (2) critical findings (CVSS ≥ 9.0) have been remediated or have an open ticket with a target date within the critical SLA (typically 14–30 days), (3) high findings (CVSS 7.0–8.9) are within their defined SLA, (4) scan frequency is at least monthly.
Vulnerability management metrics report showing SLA adherence, mean time to remediate by severity, and trend of open findings over time.
Example: Monthly or quarterly vulnerability management report (dashboard export or PDF) from Tenable, Qualys, Drata, or an internal tracking tool, showing MTTR by severity, open finding counts by age, and SLA breach rate for the last reporting period.
Test: Request the most recent vulnerability management metrics report. Verify: (1) the report covers the last full reporting period, (2) MTTR for critical findings is within the policy-defined SLA, (3) the trend in open critical/high findings is flat or declining, (4) any SLA breaches are documented with a remediation plan or risk acceptance.
Questions (2)
Does your organisation have a vulnerability management process that identifies, classifies, prioritises, and remediates vulnerabilities on a risk-based schedule with defined SLAs?
The process must include regular scanning (at minimum monthly for internet-exposed systems), defined SLAs by severity, and documented metrics. Ad hoc patching without tracking does not satisfy this control.
What are your defined remediation SLAs for critical-severity vulnerabilities (CVSS ≥ 9.0) in internet-exposed systems?
14–30 days is a widely accepted industry standard for critical findings. SLAs beyond 30 days for critical vulnerabilities in internet-exposed systems represent a significant risk exposure.