Implementing Vulnerability Remediation SLA

Overview

Vulnerability remediation SLAs define mandatory timeframes for patching or mitigating identified vulnerabilities based on severity, asset criticality, and exploit availability. Effective SLA programs drive accountability, ensure consistent remediation timelines, and provide measurable KPIs for vulnerability management maturity.

Prerequisites

• Vulnerability scanning program producing regular findings
• Asset inventory with criticality classifications
• Ticketing system (Jira, ServiceNow, etc.) for remediation tracking
• Executive sponsorship for SLA enforcement
• Cross-functional agreement from IT operations, development, and security

Core Concepts

SLA Framework Components

1. Severity Classification: CVSS base score + threat context (EPSS, KEV)
2. Asset Tiering: Business criticality and exposure level
3. Remediation Timeframes: Maximum days to remediate by category
4. Exception Process: Documented approval for SLA extensions
5. Escalation Procedures: Actions when SLAs are breached
6. Metrics and Reporting: KPIs for compliance tracking

Recommended SLA Matrix

Severity	Tier 1 (Critical)	Tier 2 (Important)	Tier 3 (Standard)
Critical (CVSS 9.0-10.0)	24-48 hours	72 hours	7 days
High (CVSS 7.0-8.9)	7 days	14 days	30 days
Medium (CVSS 4.0-6.9)	30 days	45 days	60 days
Low (CVSS 0.1-3.9)	90 days	90 days	90 days
CISA KEV Listed	24 hours	48 hours	7 days

SLA Accelerators (Reduce SLA by 50%)

• Exploit code publicly available
• Active exploitation observed in the wild (CISA KEV)
• Internet-facing asset affected
• EPSS score > 0.5 (50% exploitation probability)
• Previous breach via similar vulnerability type

Implementation Steps

Step 1: Define Asset Tiers

Tier 1 (Critical Assets):
- Customer-facing production systems
- Payment processing infrastructure
- Domain controllers and identity systems
- Core network infrastructure (firewalls, routers)
- Databases containing PII/PHI/PCI data

Tier 2 (Important Assets):
- Internal production applications
- Email and collaboration systems
- Development/staging environments with production data
- Backup and recovery infrastructure
- VPN and remote access gateways

Tier 3 (Standard Assets):
- End-user workstations
- Development/test environments
- Print servers and peripheral management
- Non-critical internal tools

Step 2: Establish SLA Policy Document

Key sections to include:

• Purpose and scope
• Roles and responsibilities (RACI matrix)
• Severity definitions and calculation method
• Remediation timeframes by severity and asset tier
• Exception request process and approval authority
• Escalation procedures for SLA breaches
• Metrics, reporting cadence, and governance
• Policy review and update schedule

Step 3: Integrate with Ticketing System

# ServiceNow / Jira integration for automatic ticket creation
# See process.py for full implementation

# Key fields for remediation tickets:
# - Vulnerability ID (CVE/Plugin ID)
# - Affected host(s)
# - Severity (CVSS + contextual factors)
# - Asset tier
# - SLA deadline (calculated from discovery date)
# - Assignment group
# - Remediation instructions
# - Verification criteria

Step 4: Configure Escalation Chain

SLA Status          Action                          Notify
───────────────────────────────────────────────────────────
75% elapsed         Warning email                   Asset owner
100% elapsed        SLA breach notification          Manager + CISO
100% + 7 days       Executive escalation             VP/CTO
100% + 30 days      Risk acceptance required          CISO approval
100% + 90 days      Compensating controls mandatory   Board report

Step 5: Establish Exception Process

Valid exception reasons:

• System cannot be patched without major downtime (scheduled maintenance window)
• No vendor patch available (apply compensating controls)
• Patch breaks critical functionality (require test results as evidence)
• End-of-life system pending decommission (document risk acceptance)

Exception requirements:

• Written justification with business impact
• Compensating controls documented and implemented
• Approved by asset owner AND security leadership
• Maximum exception duration: 90 days (renewable with re-approval)
• Tracked in vulnerability management platform

Key Performance Indicators (KPIs)

Primary Metrics

KPI	Definition	Target
SLA Compliance Rate	% of vulns remediated within SLA	>90%
Mean Time to Remediate (MTTR)	Average days from discovery to fix	Critical: <3d, High: <10d
Vulnerability Backlog	Open vulnerabilities past SLA	<5% of total
Exception Rate	% of findings with active exceptions	<10%
Recurrence Rate	% of vulns that reappear after remediation	<5%

Trending Metrics

• Month-over-month SLA compliance trend
• MTTR trend by severity
• Vulnerability density per asset (vulns/host)
• Patch coverage rate (% of assets scanned and compliant)
• Time to first response (acknowledgment of finding)

Best Practices

1. Start with achievable SLAs and tighten over time as maturity improves
2. Use automated ticketing to eliminate manual SLA tracking
3. Provide remediation teams with clear fix instructions, not just CVE numbers
4. Track SLA compliance at the team/department level for accountability
5. Report SLA metrics to executive leadership monthly
6. Include compensating controls as valid interim remediation
7. Align SLAs with regulatory requirements (PCI DSS, HIPAA, SOX)
8. Review and adjust SLAs annually based on threat landscape changes

Common Pitfalls

• Setting unrealistic SLAs that teams cannot meet (creates SLA fatigue)
• No executive enforcement of SLA breaches
• Treating all assets equally without tiering
• Not accounting for vulnerability context (EPSS, KEV) in SLA calculation
• Missing exception management process (leads to untracked risk)
• Measuring only compliance rate without analyzing root causes of breaches

Related Skills

• prioritizing-vulnerabilities-with-cvss-scoring
• implementing-patch-management-workflow
• implementing-vulnerability-metrics-and-reporting
• implementing-exception-management-process

Verification Criteria

Confirm successful execution by validating:

• [ ] All prerequisite tools and access requirements are satisfied
• [ ] Each workflow step completed without errors
• [ ] Output matches expected format and contains expected data
• [ ] No security warnings or misconfigurations detected
• [ ] Results are documented and evidence is preserved for audit

Compliance Framework Mapping

This skill supports compliance evidence collection across multiple frameworks:

• SOC 2: CC7.1 (Monitoring), CC8.1 (Change Management)
• ISO 27001: A.12.6 (Technical Vulnerability Management)
• NIST 800-53: RA-5 (Vulnerability Scanning), SI-2 (Flaw Remediation), CM-6 (Configuration Settings)
• NIST CSF: ID.RA (Risk Assessment), PR.IP (Information Protection)

Claw GRC Tip: When this skill is executed by a registered agent, compliance evidence is automatically captured and mapped to the relevant controls in your active frameworks.

Deploying This Skill with Claw GRC

Agent Execution

Register this skill with your Claw GRC agent for automated execution:

# Install via CLI
npx claw-grc skills add implementing-vulnerability-remediation-sla

# Or load dynamically via MCP
grc.load_skill("implementing-vulnerability-remediation-sla")

Audit Trail Integration

When executed through Claw GRC, every step of this skill generates tamper-evident audit records:

• SHA-256 chain hashing ensures no step can be modified after execution
• Evidence artifacts (configs, scan results, logs) are automatically attached to relevant controls
• Trust score impact — successful execution increases your agent's trust score

Continuous Compliance

Schedule this skill for recurring execution to maintain continuous compliance posture. Claw GRC monitors for drift and alerts when re-execution is needed.