About

Imported from mukul975/anthropic-cybersecurity-skills (skills/implementing-vulnerability-remediation-sla/SKILL.md). Install upstream with npx skills add mukul975/anthropic-cybersecurity-skills --skill implementing-vulnerability-remediation-sla. Copyright stays with the author (Apache-2.0).

Implementing Vulnerability Remediation SLA

Name: implementing-vulnerability-remediation-sla
Author: mukul975

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.

When to Use

When deploying or configuring implementing vulnerability remediation sla 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 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

Severity Classification: CVSS base score + threat context (EPSS, KEV)
Asset Tiering: Business criticality and exposure level
Remediation Timeframes: Maximum days to remediate by category
Exception Process: Documented approval for SLA extensions
Escalation Procedures: Actions when SLAs are breached
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

Workflow

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

Start with achievable SLAs and tighten over time as maturity improves
Use automated ticketing to eliminate manual SLA tracking
Provide remediation teams with clear fix instructions, not just CVE numbers
Track SLA compliance at the team/department level for accountability
Report SLA metrics to executive leadership monthly
Include compensating controls as valid interim remediation
Align SLAs with regulatory requirements (PCI DSS, HIPAA, SOX)
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

Use it

Copy one of these into your project. Installing also returns the manifest and these snippets.

yaml

targets:
  - https://api.opensmartroute.ai/api/v1/registry/mukul975-anthropic-cybersecurity-skills-implementing-vul-9f0133/manifest   # or paste the manifest below

Manifest

An Open Capability Manifest: the router reads it to know what this does, what it costs and when to pick it.

mukul975-anthropic-cybersecurity-skills-implementing-vul-9f0133.ocm.jsonjson

{
  "ocm": "1",
  "id": "mukul975-anthropic-cybersecurity-skills-implementing-vul-9f0133",
  "kind": "skill",
  "name": "implementing-vulnerability-remediation-sla",
  "description": "Design a vulnerability remediation SLA program covering asset tiering, a severity-based SLA matrix, exception processes, escalation chains, ticketing-system integration, and remediation KPIs/trending metrics. Use when defining mandatory patching timeframes by severity and asset criticality, building an SLA policy document, or setting up escalation and KPI tracking for vulnerability remediation.",
  "publisher": "mukul975",
  "version": "1.0.0",
  "capabilities": {
    "domains": [
      "coding",
      "math"
    ],
    "tags": [
      "skill-md",
      "vulnerability-management",
      "cve",
      "sla",
      "remediation",
      "patch-management",
      "risk",
      "skills-sh"
    ],
    "languages": [
      "en"
    ]
  },
  "quality_prior": 0.6,
  "examples": [
    "Design a vulnerability remediation SLA program covering asset tiering, a severity-based SLA matrix, exception processes, escalation chains, ticketing-system integration, and remediation KPIs/trending metrics. Use when defining mandatory patching timeframes by severity and asset criticality, building an SLA policy document, or setting up escalation and KPI tracking for vulnerability remediation."
  ],
  "primary": false,
  "metadata": {
    "source": {
      "provider": "skills.sh",
      "repository": "https://github.com/mukul975/anthropic-cybersecurity-skills",
      "path": "skills/implementing-vulnerability-remediation-sla/SKILL.md",
      "ref": "HEAD",
      "url": "https://github.com/mukul975/anthropic-cybersecurity-skills/blob/HEAD/skills/implementing-vulnerability-remediation-sla/SKILL.md",
      "key": "mukul975/anthropic-cybersecurity-skills/skills/implementing-vulnerability-remediation-sla/SKILL.md"
    },
    "license": "Apache-2.0"
  },
  "instructions": "# Implementing Vulnerability Remediation SLA\n\n## Overview\nVulnerability 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.\n\n\n## When to Use\n\n- When deploying or configuring implementing vulnerability remediation sla capabilities in your environment\n- When establishing security controls aligned to compliance requirements\n- When buildi",
  "cost": {
    "context_tokens": 1679
  }
}

Fetch it by URL: GET /api/v1/registry/mukul975-anthropic-cybersecurity-skills-implementing-vul-9f0133/manifest?version=1.0.0

Reviews

Star ratings from people who tried it. One review per account; edit yours any time.

No reviews yet. Install it, try it, and be the first to rate it.