Discovery is cheap; remediation is the product

Any scanner can hand you a list of problems. What separates a security program from a noisy dashboard is what happens after discovery: does each finding get an owner, a deadline, and a verified close — or does it sit in a queue accumulating age until a security posture score quietly slides? Remediation tracking is the discipline of treating every finding as a ticket with a lifecycle, not a row in an export nobody re-reads.

The reason this matters is uncomfortable: the dangerous gap is never between "secure" and "insecure," it's between "we know about it" and "we fixed it." Remediation tracking lives entirely inside that gap.

A finding needs three things to move

A finding that lacks any one of these stalls:

  1. An owner. Not a team — a person. "Engineering should look at this" is how a critical sits open for six weeks. One name, accountable.
  2. A due date driven by severity. Without a deadline, everything is "later." The deadline comes from an SLA, not from how busy someone feels this week.
  3. A definition of done. "I think I patched it" is not closure. Done means a re-check proved the issue is gone — the same verified-closure rule behind a findings workflow that runs discovery to closure.

Set SLAs by severity, then measure them

An SLA nobody measures is a wish. Pick deadlines that match real-world exposure and publish them:

  • Critical, internet-facing or actively exploited: 72 hours.
  • High: 7 days.
  • Medium: 30 days.
  • Low: quarterly batch, or accept the risk explicitly.

The numbers are less important than the fact that they exist and are tracked. The same exploitability-first logic from vulnerability management that scales applies: a medium on a customer-facing service can outrank a critical on an unreachable box, so let context bend the deadline.

Aging is the metric that doesn't flatter you

Open count is a vanity number — close ten lows, open one critical, and the total barely moves while your real exposure just got worse. Track the numbers that tell the truth instead:

  • Mean time to remediate (MTTR), sliced by severity. Rising MTTR on criticals is a capacity or ownership problem no tool fixes.
  • SLA-breach rate. What fraction of findings blew past their deadline?
  • Oldest open critical. Your single worst exposure, named and dated.

Closure has to be provable

The most common lie in security operations is "fixed." Someone marks a finding resolved, the change didn't take, and it resurfaces next scan as a "new" critical that's actually months old. Make resolution append an evidence artifact — a clean re-scan, a config diff, a screenshot of the enforced setting — and make reopen automatic when a closed issue reappears. That trail is exactly what an auditor samples, so disciplined remediation doubles as audit evidence collected continuously.

Remediation tracking isn't project management theater. It's the difference between a backlog where nothing dangerous is old and a backlog where the scary items quietly turn one, then two, then six months old.