/building-vulnerability-aging-and-sla-tracking

name: building-vulnerability-aging-and-sla-tracking
description: Implement a vulnerability aging dashboard and SLA tracking system that measures time-to-remediation against severity-based deadlines (e.g. 14 days critical, 30 days high, 60 days medium, 90 days low), with automated escalations and compliance metrics reporting. Use when designing SLA policies, building aging/remediation dashboards, or proving compliance with remediation timelines.
domain: cybersecurity
subdomain: vulnerability-management
tags:
- vulnerability-management
- sla-tracking
- remediation-metrics
- aging-report
- kpi
- compliance
- risk-management
version: '1.0'
author: mahipal
license: Apache-2.0
nist_csf:
- ID.RA-01
- ID.RA-02
- ID.IM-02
- ID.RA-06
mitre_attack:
- T1190
- T1203
- T1068

Building Vulnerability Aging and SLA Tracking

Overview

With over 30,000 new vulnerabilities identified in 2024 (a 17% increase from the prior year), organizations must track how long vulnerabilities remain unpatched and whether remediation occurs within defined Service Level Agreements (SLAs). Vulnerability aging measures the time between discovery and remediation, while SLA tracking enforces severity-based deadlines. Industry benchmarks indicate standard SLAs of 14 days for critical, 30 days for high, 60 days for medium, and 90 days for low vulnerabilities, though more aggressive timelines (24-48 hours for actively exploited critical CVEs) are increasingly common. This skill covers designing SLA policies, building aging dashboards, implementing automated escalations, and generating compliance metrics.

When to Use

• When deploying or configuring building vulnerability aging and sla tracking capabilities in your environment
• When establishing security controls aligned to compliance requirements
• When building or improving security architecture for this domain
• When conducting security assessments that require this implementation

Prerequisites

• Vulnerability management platform with historical scan data
• Asset inventory with criticality ratings
• ITSM/ticketing system for remediation tracking
• Reporting platform (Splunk, Elastic, Power BI, Grafana)
• Stakeholder agreement on SLA timelines and escalation procedures

Core Concepts

Standard Vulnerability SLA Framework

| Severity | CVSS Range | Standard SLA | Aggressive SLA | CISA KEV SLA | |----------|-----------|-------------|----------------|-------------| | Critical | 9.0-10.0 | 14 days | 48 hours | BOD 22-01 due date | | High | 7.0-8.9 | 30 days | 7 days | 14 days | | Medium | 4.0-6.9 | 60 days | 30 days | N/A | | Low | 0.1-3.9 | 90 days | 60 days | N/A | | Informational | 0.0 | Best effort | Best effort | N/A |

Adaptive SLA Modifiers

| Factor | Modifier | Rationale | |--------|----------|-----------| | Internet-facing asset | -50% SLA | Higher exposure risk | | CISA KEV listed | Override to 48h | Active exploitation confirmed | | EPSS > 0.7 | -50% SLA | High exploitation probability | | Tier 1 (crown jewel) asset | -25% SLA | Maximum business impact | | Compensating control in place | +25% SLA | Risk partially mitigated | | Vendor patch unavailable | Exception with review date | Cannot remediate yet |

Key Performance Indicators (KPIs)

| KPI | Formula | Target | |-----|---------|--------| | Mean Time to Remediate (MTTR) | Avg(remediation_date - discovery_date) | < 30 days overall | | SLA Compliance Rate | (Vulns remediated within SLA / Total vulns) * 100 | >= 90% | | Overdue Vulnerability Count | Count where age > SLA | Trending downward | | Vulnerability Aging Distribution | Count by age bucket (0-14d, 15-30d, 31-60d, 60+d) | Majority in 0-30d | | Remediation Velocity | Vulns closed per week | Trending upward | | Exception Rate | (Exceptions / Total vulns) * 100 | < 5% |

Workflow

Step 1: Define SLA Policy Document

Vulnerability Remediation SLA Policy v1.0

1. Scope: All information systems and applications
2. Severity Classification: Based on CVSS v4.0/v3.1 base score
3. SLA Timelines: See Standard SLA Framework table
4. Adaptive Modifiers: Applied based on asset context
5. Exception Process:
   - Must be documented with business justification
   - Requires compensating control description
   - Maximum extension: 90 days (one renewal)
   - CISO approval required for Critical/High exceptions
6. Escalation Path:
   - 50% SLA elapsed: Automated reminder to asset owner
   - 75% SLA elapsed: Escalation to manager
   - 100% SLA elapsed (overdue): CISO notification
   - 120% SLA elapsed: VP/CTO escalation
7. Metrics Reporting: Monthly to security committee

Step 2: Build the Aging Calculation Engine

import pandas as pd
from datetime import datetime, timedelta

class VulnerabilityAgingTracker:
    """Track vulnerability aging and SLA compliance."""

    SLA_DAYS = {
        "Critical": 14,
        "High": 30,
        "Medium": 60,
        "Low": 90,
    }

    def __init__(self, sla_overrides=None):
        if sla_overrides:
            self.SLA_DAYS.update(sla_overrides)

    def calculate_aging(self, vulns_df):
        """Calculate aging metrics for each vulnerability."""
        today = datetime.now()

        vulns_df["discovery_date"] = pd.to_datetime(vulns_df["discovery_date"])
        vulns_df["remediation_date"] = pd.to_datetime(
            vulns_df["remediation_date"], errors="coerce"
        )

        vulns_df["age_days"] = vulns_df.apply(
            lambda row: (row["remediation_date"] - row["discovery_date"]).days
            if pd.notna(row["remediation_date"])
            else (today - row["discovery_date"]).days,
            axis=1
        )

        vulns_df["sla_days"] = vulns_df["severity"].map(self.SLA_DAYS)
        vulns_df["sla_deadline"] = vulns_df["discovery_date"] + \
            pd.to_timedelta(vulns_df["sla_days"], unit="D")

        vulns_df["is_overdue"] = vulns_df.apply(
            lambda row: row["age_days"] > row["sla_days"]
            if pd.isna(row["remediation_date"])