Summary
Vulnerability Remediation SLAs establish severity-based timelines for addressing security findings, ensuring that vulnerabilities are tracked to resolution within agreed timeframes.
Description
Identifying vulnerabilities is only effective if findings are remediated in a timely manner. Without defined remediation timelines, vulnerability backlogs grow indefinitely, and critical issues may persist in production for months. Vulnerability Remediation SLAs establish mandatory timelines for addressing findings based on their severity, create accountability for remediation, and provide a framework for exceptions when immediate remediation is not feasible. This control applies to findings regardless of how they were identified, providing a consistent remediation framework across the organisation.
Requirements
- Remediation SLAs MUST be defined for security vulnerability findings, with timelines differentiated by severity level
- Remediation SLA timelines MUST be documented and approved, reflecting the organisation’s risk appetite and regulatory obligations
- SLA compliance MUST be tracked and reported to relevant stakeholders on a regular cadence
- A documented exception and risk-acceptance process MUST exist for vulnerabilities that cannot be remediated within the defined SLA
- Remediation SLA definitions, compliance metrics, and exception records MUST be retained in accordance with the organisation’s record retention policy
Examples & Commentary
- Severity Classification: Use an industry-recognised standard such as CVSS for severity scoring, supplemented by environmental context. A critical CVSS score in an internet-facing application may warrant faster remediation than the same score in an isolated internal tool
- SLA Clock Start: Define clearly when the SLA clock begins — typically when the finding is first reported by a scanning tool, not when a developer triages it. This prevents delays from slow triage processes
- Exception Governance: Establish a lightweight but auditable exception process. For example, a developer can request a 30-day waiver for a high-severity finding with justification and compensating controls, approved by the security team. The waiver is time-bound and automatically escalates if not resolved
- Dashboard & Visibility: Maintain a vulnerability dashboard showing open findings by severity, SLA status (on-track, at-risk, overdue), and trends over time. Make this visible to engineering teams and leadership to drive accountability
- Relationship to Deployment Gating: Remediation SLAs define when a finding must be fixed. Deployment Gating (mi-12) defines whether an application with outstanding findings can be deployed. Together they provide both a timeline for remediation and a hard stop when that timeline is not met