/remediation-tracking

name: remediation-tracking
description: >-
  Manage the vulnerability remediation lifecycle: assign owners and SLAs, track
  fix/verify/close states, handle risk acceptances and exceptions, and report
  program metrics (SLA compliance, MTTR, aging, recurrence). Use when turning a
  prioritized list into tracked, accountable work.

Goal

Every prioritized vulnerability has an owner, an SLA, and a current lifecycle state — and the program can report how it's doing, not just dump a scan.

Lifecycle states

`Open → Assigned → In Progress → Remediated → Verified → Closed`, plus `Risk Accepted` / `Exception` (time-boxed, with an owner and review date) and `Reopened` (regressed or re-detected).

Steps

1. **Assign** — owner (team that controls the asset), tier-based SLA, and target date. SLA clock starts at first detection, not at assignment. 2. **Define "done"** — patch, config change, compensating control, or decommission. A compensating control is a mitigation, not a closure — track it as such with a re-review date. 3. **Verify** — confirm the fix via rescan or manual check before closing; never close on the owner's say-so alone. 4. **Govern exceptions** — risk acceptances are time-boxed, justified, owned, and expire into a re-review. No permanent exceptions. 5. **Report metrics** — SLA compliance %, MTTR by severity, open aging buckets, backlog trend, recurrence rate, and KEV exposure. Surface what's breaching.

Output

A tracker view (per-item: owner · tier · SLA · state · due/aging · verification) plus a program-metrics summary. For exec/board framing use `security-reporting`; for trend visuals use `security-diagramming`.

Notes

Recurrence rate is the health signal everyone ignores — vulns that keep coming back mean the root cause (golden image, base layer, IaC module) isn't fixed. Verify before close, or your metrics lie. Aging exceptions are debt; make them expire.