building-vulnerability-aging-and-sla-tracking

Track SLA compliance by calculating each vulnerability's age from discovery date, comparing it against severity-based deadlines (14 days critical, 30 high, 60 medium, 90 low), and computing the percentage remediated within SLA. The provided pandas-based tracker automates this calculation.

Standard SLAs are 14 days for critical (CVSS 9.0-10.0), 30 days for high, 60 days for medium, and 90 days for low severity. Aggressive programs use 48 hours for critical, and CISA KEV-listed vulnerabilities should follow BOD 22-01 due dates.

Calculate MTTR as the average of remediation_date minus discovery_date across closed vulnerabilities. Include open overdue items in dashboards separately, since computing MTTR only on closed findings hides the aging backlog.

Yes, static SLAs miss risk context. Apply modifiers such as -50% for internet-facing assets, 48-hour override for CISA KEV-listed CVEs, -50% for EPSS above 0.7, and -25% for tier-1 crown jewel assets.

Compliance is often inflated because the SLA clock starts at report date instead of discovery date, or because overdue open items are excluded from metrics. Verify the timer uses discovery_date and that open overdue vulnerabilities appear in dashboards.

Use a documented exception workflow requiring business justification, a compensating control description, and an expiry date, with CISO approval for critical and high exceptions. Avoid blanket waivers and cap extensions at 90 days with one renewal.