Security Vulnerability Remediation SLA Planner
Plan vulnerability remediation SLAs by severity and calculate team capacity needs for security management.
Worked Examples
Example 1: Enterprise Vulnerability Backlog
Problem: 100-person company discovers: 5 critical, 20 high, 50 medium, 100 low vulnerabilities. Security team: 3 people. Avg fix time: 6 hours. Can they meet standard SLAs?
Solution: SLA Requirements:\n- Critical (24h): 5 vulns Γ 6h = 30h needed, 3 Γ 24h = 72h available β\n- High (7d): 20 vulns Γ 6h = 120h needed, 3 Γ 168h = 504h available β\n- Medium (30d): 50 vulns Γ 6h = 300h needed, 3 Γ 720h = 2,160h available β\n- Low (90d): 100 vulns Γ 6h = 600h needed, 3 Γ 2,160h = 6,480h available β\n\nAnalysis:\nWith exclusive focus, can meet all SLAs. But:\n- Security team has other duties (monitoring, incidents)\n- New vulns arrive continuously\n- Realistically, 50% capacity for remediation\n\nActual capacity:\n- Critical: 36h β 6 vulns (breach 0)\n- High: 252h β 42 vulns (breach 0)\n- Medium: 1,080h β 180 vulns (no breach)\n\nRecommendation: Doable if vulnerabilities are addressed immediately and team focused.
Result: Theoretical: SLAs achievable | Realistic: Need prioritization and focus
Example 2: Understaffed Security Team
Problem: 2-person team, 8 critical, 40 high, 80 medium, 150 low vulns discovered. Standard SLAs. Impossible to meet allβwhat's the strategy?
Solution: Capacity Analysis:\n- Team capacity: 2 Γ 40h/week = 80h/week\n- Actual for remediation: ~40h/week (50% after meetings, monitoring)\n\nCritical Vulns (24h SLA):\n- 8 vulns Γ 6h = 48h\n- Available: 2 Γ 24h = 48h\n- Can barely meet if dropping everything\n\nHigh Vulns (7d SLA):\n- 40 Γ 6h = 240h\n- Available: 2 Γ 168h Γ 50% = 168h\n- Will breach ~12 vulns\n\nStrategy:\n1. Immediately patch all 8 criticals (full team, 2 days)\n2. Triage high vulns:\n - 15 internet-facing: patch in 7 days\n - 25 internal: extend to 14 days\n3. Implement compensating controls (WAF) for delay\n4. Request budget for 1 additional security engineer\n\nAlternative:\n- Hire contractors for medium/low backlog ($50K)\n- Team focuses on critical/high only
Result: Breach inevitable | Focus on critical/high | Hire temp help or extend SLAs
Example 3: Cloud Infrastructure Continuous Scanning
Problem: SaaS company: continuous scanning finds 2-5 new vulns daily. 5-person security team. How to maintain SLA compliance continuously?
Solution: Incoming Vulns:\n- Average: 3.5 vulns/day Γ 30 = 105/month\n- Mix: 0.3 critical, 3 high, 10 medium, 92 low\n\nMonthly Capacity:\n- 5 people Γ 40h Γ 50% for remediation = 400h/month\n- At 4h per vuln: 100 vulns/month capacity\n\nCapacity-Demand Balance:\n- Demand: 105 vulns\n- Capacity: 100 vulns\n- Deficit: 5 vulns/month (backlog grows)\n\nSustainable Model:\n1. Automate low-severity (dependency updates)\n - Reduces: 92 low β 20 low (automation handles 72)\n - New demand: 33 vulns/month\n2. Implement patch management pipeline\n - Reduces avg time: 4h β 3h\n - New capacity: 133 vulns/month\n\nResult: 133 capacity > 33 demand = sustainable\n\nKey: Automation is mandatory for continuous compliance
Result: Manual: unsustainable | With automation: sustainable | 133 > 33 capacity
Frequently Asked Questions
What is a vulnerability remediation SLA?
Remediation SLA specifies maximum time allowed to fix security vulnerabilities based on severity. Example: Critical 24 hours, High 7 days, Medium 30 days, Low 90 days. SLAs balance risk (patch quickly) with operational reality (testing takes time). Missing SLAs increases breach risk.
How are vulnerability severities determined?
Most organizations use CVSS (Common Vulnerability Scoring System): 9.0-10.0 = Critical, 7.0-8.9 = High, 4.0-6.9 = Medium, 0.1-3.9 = Low. CVSS considers exploitability, impact, and scope. Some add business context: internet-facing critical systems may escalate severity.
What is a realistic remediation SLA for critical vulnerabilities?
Industry standards: Critical 24-48 hours, High 7-14 days, Medium 30-60 days, Low 90+ days. But context mattersβa critical vuln in a non-internet-facing internal system might accept 7-day SLA. Conversely, a high vuln in production payment processing might get 24-hour treatment.
How long does vulnerability remediation actually take?
Varies widely: simple config changes (30 min to 2 hours), dependency updates (2-8 hours including testing), code changes (1-3 days), architectural changes (weeks). Average across all types: 4-8 hours. Critical vulns often get emergency patches (hours), followed by proper fixes (days).
What if I can't meet remediation SLAs?
Options: (1) Increase security team capacity, (2) Implement compensating controls (WAF, network segmentation) to reduce risk temporarily, (3) Take systems offline until patched, (4) Adjust SLAs to realistic levels. Chronic SLA misses indicate understaffing or unrealistic targets.
What is the difference between vulnerability scanning and penetration testing?
Scanning is automated discovery of known vulnerabilities using tools (Nessus, Qualys). Pen testing is manual simulation of attacks to find exploitable weaknesses. Scanning finds many issues quickly; pen testing finds what's actually exploitable. Do scanning continuously, pen testing periodically.