<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: implementing-vulnerability-sla-tracking
description: >-
  Track and enforce vulnerability remediation SLAs by severity, asset tier, and
  regulatory requirement. Automate escalation workflows, generate compliance
  reports, and measure mean-time-to-remediate (MTTR) across the organization.
domain: cybersecurity
subdomain: vulnerability-management
tags:
  - sla-tracking
  - remediation-sla
  - mttr
  - compliance
  - vulnerability-metrics
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: []
---

# Implementing Vulnerability SLA Tracking

## Overview

SLA tracking transforms vulnerability management from a scan-and-forget exercise
into an accountable remediation program. Define severity-based timelines, track
adherence, escalate breaches, and report MTTR to leadership. Without SLA tracking,
critical vulnerabilities linger indefinitely.

## Prerequisites

| Requirement | Install |
|---|---|
| Python 3.10+ | Agent tooling |
| jq | `apt install jq` or `brew install jq` |
| Nessus Professional | Scan data source |
| Jira/ServiceNow | Ticket tracking (optional) |

## Key Concepts

### SLA Definitions

| Severity | Tier 1 (Crown Jewels) | Tier 2 (Business Critical) | Tier 3 (Standard) | Tier 4 (Low Impact) |
|---|---|---|---|---|
| Critical (CVSS 9.0–10.0) | 24 hours | 72 hours | 7 days | 14 days |
| High (CVSS 7.0–8.9) | 72 hours | 7 days | 14 days | 30 days |
| Medium (CVSS 4.0–6.9) | 14 days | 30 days | 60 days | 90 days |
| Low (CVSS 0.1–3.9) | 30 days | 60 days | 90 days | 180 days |

### SLA Calculation

```python
from datetime import datetime, timedelta

SLA_MATRIX = {
    ("critical", 1): timedelta(hours=24),
    ("critical", 2): timedelta(hours=72),
    ("critical", 3): timedelta(days=7),
    ("critical", 4): timedelta(days=14),
    ("high", 1): timedelta(hours=72),
    ("high", 2): timedelta(days=7),
    ("high", 3): timedelta(days=14),
    ("high", 4): timedelta(days=30),
    ("medium", 1): timedelta(days=14),
    ("medium", 2): timedelta(days=30),
    ("medium", 3): timedelta(days=60),
    ("medium", 4): timedelta(days=90),
    ("low", 1): timedelta(days=30),
    ("low", 2): timedelta(days=60),
    ("low", 3): timedelta(days=90),
    ("low", 4): timedelta(days=180),
}

def get_sla_deadline(severity: str, asset_tier: int, discovered: datetime) -> datetime:
    sla_duration = SLA_MATRIX.get((severity.lower(), asset_tier), timedelta(days=90))
    return discovered + sla_duration
```

### Escalation Rules

| Days Past SLA | Action |
|---|---|
| 0 (SLA day) | Auto-notify asset owner |
| +3 days | Escalate to team lead |
| +7 days | Escalate to director |
| +14 days | Escalate to CISO with risk acceptance request |
| +30 days | Flag as accepted risk — requires formal sign-off |

### Nessus Data Extraction for SLA Tracking

```bash
# Export scan with timestamps for SLA calculation
curl -sk -H "X-ApiKeys: accessKey=$NESSUS_ACCESS;secretKey=$NESSUS_SECRET" \
  "https://localhost:8834/scans/$SCAN_ID/export" \
  -d 'format=csv' | \
  awk -F',' 'NR>1 {print $1","$2","$3","$4","$5}' > vuln_sla_input.csv

# Calculate overdue findings
python3 -c "
import csv, json
from datetime import datetime, timedelta
overdue = []
with open('vuln_sla_input.csv') as f:
    for row in csv.reader(f):
        if len(row) >= 4 and row[3]:
            severity = row[2].lower()
            days_open = (datetime.now() - datetime.strptime(row[3], '%Y-%m-%d')).days
            sla_days = {'critical': 3, 'high': 7, 'medium': 30, 'low': 90}.get(severity, 90)
            if days_open > sla_days:
                overdue.append({'cve': row[1], 'severity': severity, 'days_open': days_open, 'sla': sla_days})
print(json.dumps(overdue, indent=2))
"
```

## Workflow

1. **Define** — Establish SLA matrix aligned to severity and asset tier
2. **Ingest** — Import scan findings with discovery timestamps
3. **Calculate** — Compute SLA deadlines and days remaining for each finding
4. **Monitor** — Dashboard showing open/overdue/approaching-SLA counts
5. **Escalate** — Automated notifications at SLA milestones
6. **Report** — Weekly MTTR report to security leadership

## Verification

| Check | Method |
|---|---|
| SLA matrix defined | All severity × tier combinations have deadlines |
| Timestamps accurate | Discovery dates match scan completion times |
| Escalations firing | Test notification triggers at each threshold |
| MTTR calculating | Metric uses median of closed findings |
| Overdue count correct | Manual spot-check against scan data |

## References

- [NIST SP 800-40r4 — Patch Management](https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final)
- [CIS Control 7 — Continuous Vulnerability Management](https://www.cisecurity.org/controls/continuous-vulnerability-management)
- [PCI DSS Requirement 6.3.3 — Patch Installation](https://www.pcisecuritystandards.org/)
