What it does. Build an automated SLA breach alerting system for vulnerability remediation, Part of mukul975/Anthropic-Cybersecurity-Skills (817 security skills) (mukul975/Anthropic-Cybersecurity-Skills).

Upstream	mukul975/Anthropic-Cybersecurity-Skills
Skill file	skills/implementing-vulnerability-sla-breach-alerting/SKILL.md
License	Apache-2.0 (skill folder LICENSE)
Author	mukul975
Fetched	2026-09-10

Install

• npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill implementing-vulnerability-sla-breach-alerting, or copy the skill folder into ~/.claude/skills/implementing-vulnerability-sla-breach-alerting/.
• Raw file: curl -sL https://raw.githubusercontent.com/mukul975/Anthropic-Cybersecurity-Skills/HEAD/skills/implementing-vulnerability-sla-breach-alerting/SKILL.md

SKILL.md (verbatim)

1 placeholder credential was shortened (for example to api_key=YOUR_KEY) to pass the site's secret filter.

name: implementing-vulnerability-sla-breach-alerting
description: Build an automated SLA breach alerting system for vulnerability remediation,
  including a database schema for SLA tracking, breach detection logic, notification
  dispatch, a scheduled check runner, and a KPI/compliance metrics dashboard. Use
  when implementing severity-based SLA timelines (critical/high/medium/low), detecting
  and escalating SLA breaches, or building vulnerability remediation compliance reporting.
domain: cybersecurity
subdomain: vulnerability-management
tags:
- vulnerability-sla
- remediation-tracking
- alerting
- compliance
- sla-breach
- vulnerability-management
- escalation
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

Implementing Vulnerability SLA Breach Alerting

Overview

Vulnerability remediation SLAs define maximum timeframes for addressing security findings based on severity. This skill covers building an automated alerting system that tracks remediation timelines, detects SLA breaches, sends escalation notifications, and generates compliance reports. Industry-standard SLA targets are: Critical (24-48 hours), High (15-30 days), Medium (60 days), Low (90 days).

When to Use

• When deploying or configuring implementing vulnerability sla breach alerting 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

• Python 3.9+ with requests, pandas, jinja2, smtplib libraries
• Vulnerability management platform with API access (DefectDojo, Qualys, Tenable)
• SMTP server or webhook endpoint (Slack, Microsoft Teams, PagerDuty)
• Database for SLA tracking (PostgreSQL or SQLite)

SLA Policy Definition

Standard SLA Tiers

Severity	Remediation SLA	Grace Period	Escalation Level
Critical (CVSS 9.0-10.0)	48 hours	12 hours	VP Engineering + CISO
High (CVSS 7.0-8.9)	15 days	5 days	Director of Engineering
Medium (CVSS 4.0-6.9)	60 days	14 days	Team Lead
Low (CVSS 0.1-3.9)	90 days	30 days	Asset Owner

SLA Configuration File

# sla_policy.yaml
sla_tiers:
  critical:
    cvss_min: 9.0
    cvss_max: 10.0
    remediation_days: 2
    grace_period_days: 0.5
    escalation_contacts:
      - ciso@company.com
      - vp-engineering@company.com
    pagerduty_severity: critical
  high:
    cvss_min: 7.0
    cvss_max: 8.9
    remediation_days: 15
    grace_period_days: 5
    escalation_contacts:
      - security-director@company.com
    pagerduty_severity: high
  medium:
    cvss_min: 4.0
    cvss_max: 6.9
    remediation_days: 60
    grace_period_days: 14
    escalation_contacts:
      - team-lead@company.com
    pagerduty_severity: warning
  low:
    cvss_min: 0.1
    cvss_max: 3.9
    remediation_days: 90
    grace_period_days: 30
    escalation_contacts:
      - asset-owner@company.com
    pagerduty_severity: info

notification_channels:
  slack:
    webhook_url: "${SLACK_WEBHOOK_URL}"
    channel: "#vulnerability-alerts"
  email:
    smtp_host: smtp.company.com
    smtp_port: 587
    from_address: vuln-alerts@company.com
  pagerduty:
    api_key: YOUR_KEY
    service_id: "${PAGERDUTY_SERVICE_ID}"

alert_schedules:
  approaching_breach:
    percentage_elapsed: 80
    frequency_hours: 24
  at_breach:
    notification: immediate
    escalation: true
  post_breach:
    frequency_hours: 12
    escalation_increase: true

Workflow

Step 1: Database Schema for SLA Tracking

CREATE TABLE vulnerability_sla (
    id SERIAL PRIMARY KEY,
    cve_id VARCHAR(20) NOT NULL,
    finding_id VARCHAR(100) NOT NULL,
    asset_hostname VARCHAR(255),
    severity VARCHAR(20) NOT NULL,
    cvss_score DECIMAL(3,1),
    discovered_at TIMESTAMP NOT NULL,
    sla_deadline TIMESTAMP NOT NULL,
    remediated_at TIMESTAMP,
    status VARCHAR(20) DEFAULT 'open',
    owner_email VARCHAR(255),
    escalation_level INTEGER DEFAULT 0,
    last_alert_sent TIMESTAMP,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_sla_status ON vulnerability_sla(status);
CREATE INDEX idx_sla_deadline ON vulnerability_sla(sla_deadline);
CREATE INDEX idx_sla_severity ON vulnerability_sla(severity);

Step 2: SLA Breach Detection Logic

from datetime import datetime, timedelta, timezone
import yaml

def load_sla_policy(policy_path="sla_policy.yaml"):
    with open(policy_path, "r") as f:
        return yaml.safe_load(f)

def get_sla_tier(cvss_score, policy):
    for tier_name, tier in policy["sla_tiers"].items():
        if tier["cvss_min"] <= cvss_score <= tier["cvss_max"]:
            return tier_name, tier
    return "low", policy["sla_tiers"]["low"]

def calculate_sla_deadline(discovered_at, cvss_score, policy):
    tier_name, tier = get_sla_tier(cvss_score, policy)
    deadline = discovered_at + timedelta(days=tier["remediation_days"])
    return deadline, tier_name

def check_sla_status(discovered_at, sla_deadline, remediated_at=None):
    now = datetime.now(timezone.utc)
    if remediated_at:
        if remediated_at <= sla_deadline:
            return "remediated_within_sla"
        return "remediated_breach"
    if now > sla_deadline:
        overdue_days = (now - sla_deadline).days
        return f"breached_{overdue_days}d_overdue"
    remaining = sla_deadline - now
    total_sla = sla_deadline - discovered_at
    pct_elapsed = ((total_sla - remaining) / total_sla) * 100
    if pct_elapsed >= 80:
        return "approaching_breach"
    return "within_sla"

Step 3: Notification Dispatch

import requests
import json
import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

def send_slack_alert(webhook_url, vuln_data, sla_status):
    color = {"breached": "#FF0000", "approaching_breach": "#FFA500", "within_sla": "#36A64F"}
    status_color = color.get("breached" if "breached" in sla_status else sla_status, "#808080")
    payload = {
        "attachments": [{
            "color": status_color,
            "title": f"Vulnerability SLA Alert: {vuln_data['cve_id']}",
            "fields": [
                {"title": "Severity", "value": vuln_data["severity"], "short": True},
                {"title": "CVSS", "value": str(vuln_data["cvss_score"]), "short": True},
                {"title": "Asset", "value": vuln_data["asset_hostname"], "short": True},
                {"title": "SLA Status", "value": sla_status, "short": True},
                {"title": "Deadline", "value": vuln_data["sla_deadline"].strftime("%Y-%m-%d %H:%M UTC"), "short": True},
                {"title": "Owner", "value": vuln_data.get("owner_email", "Unassigned"), "short": True},
            ],
        }]
    }
    requests.post(webhook_url, json=payload, timeout=10)

def send_pagerduty_alert(api_key, service_id, vuln_data, severity):
    payload = {
        "routing_key": api_key,
        "event_action": "trigger",
        "payload": {
            "summary": f"SLA Breach: {vuln_data['cve_id']} on {vuln_data['asset_hostname']}",
            "severity": severity,
            "source": vuln_data["asset_hostname"],
            "custom_details": {
                "cve_id": vuln_data["cve_id"],
                "cvss_score": vuln_data["cvss_score"],
                "sla_deadline": vuln_data["sla_deadline"].isoformat(),
            }
        }
    }
    requests.post(
        "https://events.pagerduty.com/v2/enqueue",
        json=payload, timeout=10
    )

def send_email_alert(smtp_config, to_addresses, vuln_data, sla_status):
    msg = MIMEMultipart("alternative")
    msg["Subject"] = f"[SLA {sla_status.upper()}] {vuln_data['cve_id']} - {vuln_data['severity']}"
    msg["From"] = smtp_config["from_address"]
    msg["To"] = ", ".join(to_addresses)
    body = f"""
    Vulnerability SLA Alert

    CVE: {vuln_data['cve_id']}
    Severity: {vuln_data['severity']} (CVSS {vuln_data['cvss_score']})
    Asset: {vuln_data['asset_hostname']}
    SLA Deadline: {vuln_data['sla_deadline'].strftime('%Y-%m-%d %H:%M UTC')}
    Status: {sla_status}
    Owner: {vuln_data.get('owner_email', 'Unassigned')}

    Please take immediate action to remediate this vulnerability.
    """
    msg.attach(MIMEText(body, "plain"))
    with smtplib.SMTP(smtp_config["smtp_host"], smtp_config["smtp_port"]) as server:
        server.starttls()
        server.send_message(msg)

Step 4: Scheduled SLA Check Runner

# Run SLA breach check every hour via cron
echo "0 * * * * cd /opt/vuln-sla && python3 scripts/process.py --check-sla" | crontab -

# Manual check
python3 scripts/process.py --check-sla --policy sla_policy.yaml

# Generate SLA compliance report
python3 scripts/process.py --report --period monthly --output sla_report.html

SLA Metrics Dashboard

Key Performance Indicators

def calculate_sla_metrics(db_connection, period_start, period_end):
    metrics = {
        "total_findings": 0,
        "remediated_within_sla": 0,
        "sla_breach_count": 0,
        "mean_time_to_remediate": {},
        "sla_compliance_rate": 0.0,
        "current_overdue": 0,
    }
    # Query findings in period grouped by severity
    query = """
        SELECT severity, COUNT(*) as total,
               SUM(CASE WHEN remediated_at <= sla_deadline THEN 1 ELSE 0 END) as within_sla,
               AVG(EXTRACT(EPOCH FROM (COALESCE(remediated_at, NOW()) - discovered_at))/86400) as avg_days
        FROM vulnerability_sla
        WHERE discovered_at BETWEEN %s AND %s
        GROUP BY severity
    """
    return metrics

References

• Vulnerability Management SLAs Guide
• NIST SP 800-40 Rev 4 - Patch Management
• PagerDuty Events API v2
• Slack Incoming Webhooks

Other files in this skill

• LICENSE
• assets/template.md
• references/api-reference.md
• references/standards.md
• references/workflows.md
• scripts/agent.py
• scripts/process.py

assets/template.md (verbatim)

Vulnerability SLA Policy Template

1. Purpose

This policy establishes remediation timelines for security vulnerabilities based on severity classification, defines escalation procedures for SLA breaches, and specifies reporting requirements for compliance tracking.

2. Scope

This policy applies to all information systems, applications, and infrastructure components managed by [Organization Name].

3. SLA Definitions

Severity	CVSS Range	Remediation Timeline	Grace Period	Escalation Path
Critical	9.0 - 10.0	48 hours	12 hours	Asset Owner -> Security Director -> CISO
High	7.0 - 8.9	15 calendar days	5 days	Asset Owner -> Team Lead -> Security Director
Medium	4.0 - 6.9	60 calendar days	14 days	Asset Owner -> Team Lead
Low	0.1 - 3.9	90 calendar days	30 days	Asset Owner

4. Exception Process

4.1 Exception Request Requirements

• CVE identifier and affected system details
• Business justification for extension
• Compensating controls implemented
• Proposed new remediation date
• Risk acceptance signature from system owner and CISO

4.2 Maximum Exception Duration

• Critical: 14 days maximum extension
• High: 30 days maximum extension
• Medium: 60 days maximum extension
• Low: 90 days maximum extension

5. Alerting Configuration

5.1 Notification Schedule

80% SLA elapsed -> Warning to asset owner (email + Slack)
100% SLA elapsed -> Breach alert (email + Slack + PagerDuty for Critical/High)
SLA + 24 hours -> Escalation Level 1 (team lead)
SLA + 72 hours -> Escalation Level 2 (director)
SLA + 7 days -> Escalation Level 3 (CISO)

5.2 Notification Channels

• Email: All severity levels
• Slack: High and Critical severity
• PagerDuty: Critical severity SLA breaches only
• Jira: Automatic ticket creation for all findings

6. Reporting Requirements

6.1 Weekly Report

• Count of open findings by severity
• Count of SLA breaches by severity
• Top 5 assets with most open findings
• Remediation velocity trend

6.2 Monthly Report

• Overall SLA compliance rate by severity
• Mean time to remediate by severity
• Exception count and approval rate
• Quarter-over-quarter improvement trends

6.3 Executive Dashboard

• Overall compliance percentage
• Risk exposure trend (critical/high open count over time)
• Team/business unit comparison
• Regulatory compliance status (PCI, SOC2, HIPAA)

7. Compliance Mapping

Regulation	Requirement	SLA Alignment
PCI DSS 4.0	Req 6.3.3	Critical/High within 30 days
SOC 2	CC7.1	Evidence of SLA tracking and remediation
HIPAA	164.312(a)(1)	Risk-based remediation timeline
CISA BOD 22-01	KEV remediation	14 days for KEV-listed CVEs
NIST CSF 2.0	ID.RA-01	Risk-ranked vulnerability management

8. Roles and Responsibilities

• Asset Owner: Remediate within SLA, request exceptions when needed
• Security Team: Monitor SLA compliance, manage alerting system
• Team Lead: Review team SLA metrics, escalate blockers
• CISO: Approve critical exceptions, review monthly metrics

references/api-reference.md (verbatim)

API Reference: Vulnerability SLA Breach Alerting

Libraries Used

Library	Purpose
requests	Slack webhook and Jira API integration
smtplib	Send email alerts for SLA breaches
json	Parse vulnerability and SLA data
datetime	Calculate SLA deadlines and breach timing
email.mime.text	Compose HTML email notifications

Installation

pip install requests

Alert Channels

Slack Webhook Alert

import requests
import os

SLACK_WEBHOOK = os.environ["SLACK_WEBHOOK_URL"]

def send_slack_alert(breaches):
    blocks = [
        {
            "type": "header",
            "text": {"type": "plain_text", "text": "SLA Breach Alert"}
        },
        {
            "type": "section",
            "text": {
                "type": "mrkdwn",
                "text": f"*{len(breaches)} vulnerabilities have breached SLA*",
            }
        },
    ]
    for breach in breaches[:10]:
        blocks.append({
            "type": "section",
            "text": {
                "type": "mrkdwn",
                "text": (
                    f"*{breach['cve']}* — {breach['severity'].upper()}\n"
                    f"Host: `{breach['host']}` | Overdue: {breach['hours_overdue']}h\n"
                    f"Owner: {breach.get('owner', 'Unassigned')}"
                ),
            }
        })

    resp = requests.post(
        SLACK_WEBHOOK,
        json={"blocks": blocks},
        timeout=10,
    )
    return resp.status_code == 200

Email Alert (SMTP)

import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

def send_email_alert(breaches, recipients):
    smtp_host = os.environ["SMTP_HOST"]
    smtp_port = int(os.environ.get("SMTP_PORT", "587"))
    smtp_user = os.environ["SMTP_USER"]
    smtp_pass = os.environ["SMTP_PASS"]

    msg = MIMEMultipart("alternative")
    msg["Subject"] = f"SLA Breach: {len(breaches)} vulnerabilities overdue"
    msg["From"] = smtp_user
    msg["To"] = ", ".join(recipients)

    html = "<h2>SLA Breach Report</h2><table border='1'>"
    html += "<tr><th>CVE</th><th>Severity</th><th>Host</th><th>Hours Overdue</th></tr>"
    for b in breaches:
        html += f"<tr><td>{b['cve']}</td><td>{b['severity']}</td>"
        html += f"<td>{b['host']}</td><td>{b['hours_overdue']}</td></tr>"
    html += "</table>"

    msg.attach(MIMEText(html, "html"))

    with smtplib.SMTP(smtp_host, smtp_port) as server:
        server.starttls()
        server.login(smtp_user, smtp_pass)
        server.sendmail(smtp_user, recipients, msg.as_string())

Jira Ticket Creation

JIRA_URL = os.environ["JIRA_URL"]
JIRA_AUTH = (os.environ["JIRA_USER"], os.environ["JIRA_TOKEN"])

def create_jira_ticket(breach):
    ticket = {
        "fields": {
            "project": {"key": os.environ.get("JIRA_PROJECT", "VULN")},
            "summary": f"SLA Breach: {breach['cve']} on {breach['host']}",
            "description": (
                f"Vulnerability {breach['cve']} ({breach['severity']}) "
                f"has breached its remediation SLA.\n\n"
                f"Host: {breach['host']}\n"
                f"Hours overdue: {breach['hours_overdue']}\n"
                f"Discovery date: {breach['discovery_date']}\n"
                f"SLA deadline: {breach['deadline']}\n\n"
                f"Required action: Remediate immediately."
            ),
            "issuetype": {"name": "Bug"},
            "priority": {"name": "Highest" if breach["severity"] == "critical" else "High"},
            "labels": ["sla-breach", "security", breach["severity"]],
        }
    }
    resp = requests.post(
        f"{JIRA_URL}/rest/api/2/issue",
        auth=JIRA_AUTH,
        json=ticket,
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()["key"]

SLA Breach Detection

from datetime import datetime, timedelta

SLA_TIERS = {
    "critical": timedelta(hours=24),
    "high": timedelta(hours=72),
    "medium": timedelta(days=30),
    "low": timedelta(days=90),
}

def detect_breaches(vulnerabilities):
    breaches = []
    now = datetime.now()
    for vuln in vulnerabilities:
        if vuln.get("remediated"):
            continue
        discovery = datetime.fromisoformat(vuln["discovery_date"])
        sla = SLA_TIERS.get(vuln["severity"].lower(), timedelta(days=90))
        deadline = discovery + sla
        if now > deadline:
            breaches.append({
                **vuln,
                "deadline": deadline.isoformat(),
                "hours_overdue": round((now - deadline).total_seconds() / 3600, 1),
            })
    return sorted(breaches, key=lambda b: b["hours_overdue"], reverse=True)

Orchestration

def run_sla_breach_alerting(vulnerabilities):
    breaches = detect_breaches(vulnerabilities)
    if not breaches:
        return {"breaches": 0, "alerts_sent": False}

    # Send alerts through all channels
    send_slack_alert(breaches)
    send_email_alert(breaches, os.environ.get("ALERT_RECIPIENTS", "").split(","))

    # Create Jira tickets for critical/high breaches only
    for breach in breaches:
        if breach["severity"] in ("critical", "high"):
            create_jira_ticket(breach)

    return {"breaches": len(breaches), "alerts_sent": True}

Output Format

{
  "run_time": "2025-01-15T10:00:00Z",
  "breaches_detected": 5,
  "alerts": {
    "slack": true,
    "email": true,
    "jira_tickets_created": 3
  },
  "breaches": [
    {
      "cve": "CVE-2024-21887",
      "severity": "critical",
      "host": "web-prod-01",
      "hours_overdue": 48.5,
      "deadline": "2025-01-13T10:00:00",
      "owner": "platform-team"
    }
  ]
}

references/standards.md (verbatim)

Standards and References - Vulnerability SLA Breach Alerting

Primary Standards

NIST SP 800-40 Rev 4

• Title: Guide to Enterprise Patch Management Planning
• URL: https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final
• Relevance: Defines organizational patch management lifecycle and remediation timelines

CISA Binding Operational Directive 22-01

• Title: Reducing the Significant Risk of Known Exploited Vulnerabilities
• URL: https://www.cisa.gov/binding-operational-directive-22-01
• SLA Mandate: Federal agencies must remediate KEV-listed vulnerabilities within specified timeframes (typically 14 days for new additions)

PCI DSS v4.0 Requirement 6.3

• Title: Security Vulnerabilities Are Identified and Addressed
• URL: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf
• SLA Requirement: Critical and high-severity vulnerabilities must be patched within 30 days of release; risk-ranked approach for all others

SOC 2 Type II - CC7.1

• Title: Detection and Monitoring of Security Events
• Relevance: Requires evidence of vulnerability management program with defined remediation timelines and tracking

ISO 27001:2022 - Control A.8.8

• Title: Management of Technical Vulnerabilities
• Relevance: Requires timely identification and remediation of technical vulnerabilities with defined response timelines

Industry SLA Benchmarks

SANS Vulnerability Management Maturity

• Critical: 24-48 hours
• High: 7-30 days
• Medium: 30-90 days
• Low: 90-180 days

CIS Controls v8 - Control 7

• Title: Continuous Vulnerability Management
• URL: https://www.cisecurity.org/controls/continuous-vulnerability-management
• Implementation Group 1: Remediate detected vulnerabilities monthly
• Implementation Group 2: Automated remediation tracking with SLA enforcement
• Implementation Group 3: Real-time SLA monitoring with automated escalation

Integration APIs

PagerDuty Events API v2

• URL: https://developer.pagerduty.com/api-reference/a7d81b0e9200f-send-an-event-to-pager-duty
• Endpoint: https://events.pagerduty.com/v2/enqueue

Slack Incoming Webhooks

• URL: https://api.slack.com/messaging/webhooks
• Rate Limit: 1 message per second per webhook

Microsoft Teams Incoming Webhook

• URL: https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook

Jira REST API

• URL: https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Relevance: Create and track remediation tickets with SLA metadata

references/workflows.md (verbatim)

Workflows - Vulnerability SLA Breach Alerting

Workflow 1: SLA Assignment on New Findings

Trigger

New vulnerability findings imported from scanner.

Steps

1. Parse incoming vulnerability data (CVE ID, CVSS score, affected asset)
2. Look up asset criticality from CMDB to determine if SLA should be tightened
3. Calculate SLA tier based on CVSS score and asset criticality
4. Compute SLA deadline: discovered_at + remediation_days
5. Insert SLA record into tracking database
6. Assign finding owner based on asset ownership mapping
7. Send initial notification to asset owner with SLA deadline

Workflow 2: Hourly SLA Breach Check

Trigger

Cron job running every hour.

Steps

1. Query all open vulnerability SLA records
2. For each record, calculate current SLA status:
   • within_sla: Less than 80% of SLA window elapsed
   • approaching_breach: 80-100% of SLA window elapsed
   • breached: Past SLA deadline
3. For approaching_breach findings (first notification):
   • Send Slack/Teams warning to asset owner
   • Send email notification to asset owner and team lead
4. For breached findings:
   • Send immediate Slack alert to security team channel
   • Trigger PagerDuty incident for critical/high severity
   • Send escalation email to management chain
   • Update escalation_level in database
5. For post-breach findings (already breached, escalation increase):
   • Every 12 hours, increase escalation level
   • Level 1: Team lead notification
   • Level 2: Director notification
   • Level 3: VP/CISO notification

Workflow 3: Remediation Confirmation

Trigger

Vulnerability scanner re-scan confirms finding resolved.

Steps

1. Match resolved finding to SLA record
2. Record remediation timestamp
3. Calculate if remediation was within SLA
4. Update SLA record status to remediated_within_sla or remediated_breach
5. Close any associated PagerDuty incidents
6. Send confirmation notification to asset owner
7. Update metrics dashboard

Workflow 4: Monthly SLA Compliance Report

Trigger

First business day of each month.

Steps

1. Query all SLA records for the previous month
2. Calculate metrics by severity tier:
   • Total findings per tier
   • SLA compliance rate per tier
   • Mean time to remediate per tier
   • Count of currently overdue findings
3. Identify top 10 assets with most SLA breaches
4. Identify teams with lowest compliance rates
5. Generate HTML report with charts
6. Email report to security leadership
7. Update executive dashboard

Back to mukul975/Anthropic-Cybersecurity-Skills (817 security skills) or Agent skills.