← Back to Articles

Remediation Tracking and SLA Management: Building a System That Actually Closes Vulnerabilities

November 21, 2024•Vulnerability Management•4 min read

You ran the scan. You filed the tickets. Three months later, the same critical CVE is still sitting unpatched on a production server, and nobody can tell you why. The gap between finding vulnerabilities and fixing them is where real breaches happen—and it's exactly the gap that a disciplined remediation tracking and SLA management program is designed to close.

Why Remediation Tracking Fails Without Structure

Vulnerability management tools generate thousands of findings. Without a formal remediation workflow, those findings land in spreadsheets, get assigned to the wrong teams, or simply age out of memory. The root cause isn't laziness—it's the absence of clear ownership, enforceable timelines, and automated accountability.

A mature remediation tracking program answers three questions at any given moment:

  1. What's open? — Every finding has a current status.
  2. Who owns it? — Every finding has an assigned remediation owner.
  3. When is it due? — Every finding has an SLA based on severity.

Defining SLA Tiers That Reflect Real Risk

SLAs should map directly to severity and asset context. A critical vulnerability on an internet-facing payment server is not the same as a medium finding on an isolated development box. Here's a practical SLA matrix used in enterprise environments:

Severity Internet-Facing Assets Internal Production Dev/Test
Critical 48 hours 7 days 14 days
High 7 days 14 days 30 days
Medium 30 days 45 days 60 days
Low 90 days 90 days 90 days

Document these in your organization's vulnerability management policy and get sign-off from asset owners and leadership. SLAs without executive endorsement become suggestions.

Automating the Pipeline: From Scan to Ticket to Verification

Manual tracking doesn't scale. The goal is a pipeline: scan → parse → ticket → track → rescan → close. Here's a simplified example using a Nessus export piped into Jira via a Python script:

import csv
import requests

JIRA_URL = "https://jira.corp.local/rest/api/2/issue"
HEADERS = {"Content-Type": "application/json"}
SLA_MAP = {"Critical": 7, "High": 14, "Medium": 45, "Low": 90}

with open("nessus_export.csv", "r") as f:
    reader = csv.DictReader(f)
    for row in reader:
        severity = row["Risk"]
        due_days = SLA_MAP.get(severity, 90)
        payload = {
            "fields": {
                "project": {"key": "VULN"},
                "summary": f"[{severity}] {row['Name']} on {row['Host']}",
                "description": row["Synopsis"],
                "issuetype": {"name": "Bug"},
                "duedate": (datetime.now() + timedelta(days=due_days)).strftime("%Y-%m-%d"),
                "assignee": {"name": get_owner(row["Host"])}
            }
        }
        requests.post(JIRA_URL, json=payload, headers=HEADERS, auth=("svc_vuln", "token"))

This creates tickets with automatic due dates and assigns them to the correct asset owner. Deduplication logic (not shown) prevents duplicate tickets for recurring findings.

Tracking SLA Compliance and Escalation

Once tickets exist, you need dashboards and escalation paths. A weekly cron job can flag overdue items and notify management:

# Query Jira for overdue VULN tickets and send summary to Slack
curl -s -u svc_vuln:token "https://jira.corp.local/rest/api/2/search?jql=project=VULN+AND+duedate+<+now()+AND+status!=Done" \
  | jq '.issues[] | {key, summary: .fields.summary, due: .fields.duedate, owner: .fields.assignee.name}' \
  | curl -X POST -H 'Content-type: application/json' --data @- https://hooks.slack.com/services/T00/B00/xxx

Establish a three-tier escalation model: asset owner → their manager → CISO. Each escalation triggers after a defined percentage past SLA (e.g., 25% overdue, 50% overdue, 100% overdue).

Metrics That Matter to Leadership

Report on these monthly:

  • SLA compliance rate by severity tier (target: ≥ 90%)
  • Mean time to remediate (MTTR) segmented by business unit
  • Overdue aging — how far past SLA overdue items have drifted
  • Recurrence rate — findings that reappear after closure

These metrics transform vulnerability management from a technical exercise into a business governance function.

Final Thought

Finding vulnerabilities is table stakes. Tracking their remediation to closure—within enforceable timelines, with clear ownership, and with executive visibility—is what separates a security program that reports risk from one that reduces it.

Have questions about remediation tracking and sla management? I'm always happy to talk shop — reach out or connect with me on LinkedIn.

← Back to Articles