Patching SLAs documented + met
Demonstrate that the organization has formally documented patching SLAs for all asset classes and consistently meets those timelines in practice, with evidence of measurement and accountability.
Description
What this control does
This control requires that the organization define and document Service Level Agreements (SLAs) for applying security patches across all system types (e.g., critical systems within 48 hours, high-risk within 7 days, standard within 30 days). These SLAs establish maximum time windows from patch availability or vulnerability disclosure to deployment in production environments. The control also mandates tracking actual patching performance against these commitments, with evidence demonstrating consistent adherence to the documented timelines. This matters because attackers actively exploit known vulnerabilities within hours or days of public disclosure, and delayed patching creates predictable windows of exposure.
Control objective
What auditing this proves
Demonstrate that the organization has formally documented patching SLAs for all asset classes and consistently meets those timelines in practice, with evidence of measurement and accountability.
Associated risks
Risks this control addresses
- Exploitation of publicly disclosed vulnerabilities during extended patching delays, particularly for critical flaws with available proof-of-concept code
- Inconsistent patching prioritization leading to high-risk systems remaining unpatched while lower-priority systems receive updates
- Lack of accountability for missed patching deadlines allowing systemic delays without corrective action or escalation
- Regulatory non-compliance for industries requiring specific patch deployment timelines (PCI-DSS, HIPAA, FISMA)
- Lateral movement and privilege escalation by attackers exploiting unpatched internal systems after initial compromise
- Operational disruption from emergency patching rushed responses when proactive SLAs are not met, increasing change-related outages
- Inability to demonstrate due diligence in breach investigations when patching timelines are undefined or unmeasured
Testing procedure
How an auditor verifies this control
- Obtain the formal patch management policy or standard documenting SLA timelines for each system classification or criticality tier (e.g., critical/high/medium/low or production/non-production).
- Review the documented SLAs to verify they include specific timeframes tied to vulnerability severity ratings (CVSS scores or vendor severity levels) and asset criticality.
- Request patch management tracking reports or dashboard exports covering the most recent three-month period showing patch deployment dates, vulnerability publication dates, and SLA compliance metrics.
- Select a sample of 20-30 patches applied during the review period, stratified across severity levels and system types, and calculate the elapsed time from vendor release or vulnerability disclosure to production deployment.
- Compare the calculated deployment timeframes for the sample against the documented SLAs to identify any instances where deadlines were missed.
- For any missed SLAs identified, request exception documentation, risk acceptance records, or compensating controls justifying the delay.
- Interview the patch management team or system administrators to confirm the process for monitoring SLA compliance, escalating delays, and reporting metrics to management.
- Review management reports or security committee meeting minutes from the past quarter to verify that patching SLA performance is regularly communicated to leadership with visibility into trends and exceptions.
Where this control is tested