Remediation SLA tracking, measured by verified fixes

Every remediation SLA rests on a definition of “done,” and most programs pick the cheapest one available: the ticket closed before the deadline. It’s easy to measure and easy to hit, which is exactly the problem. You can score 95% SLA attainment while a real share of those closures never held — the patch reverted, the wrong instance got fixed, the re-scan was never run. The number went green; the risk didn’t go away.

A deadline is only as honest as the event that stops the clock.

Move the clock to the re-test

Tie SLA completion to an independent verification and the metric changes character. The clock stops when a re-test — a re-scan, a second scanner, an API probe — confirms the vulnerability no longer responds, so attainment measures fixes that held rather than tickets that closed. A closure that fails verification doesn’t quietly count; the work reopens and the SLA shows it as overdue again, which is the moment you actually want to know.

That reframes “overdue” from a paperwork state into a risk signal. An overdue item is a live vulnerability past the window you committed to, surfaced while there’s still time to do something about it.

One deadline per vulnerability, across every tool

SLAs slip hardest in the gaps between systems — the finding Tenable sees, the ticket in Jira, the closure in a third tool, none of them agreeing on whether the clock is still running. Folding everything into one queue gives each vulnerability a single deadline that follows it across scanners and trackers, so a fix isn’t “done” in one system and “open” in another. When you report SLA attainment to your board or an auditor, the number reflects verified closure across the whole estate.

The point of an SLA was always to bound how long real risk sits open. Measuring verified fixes is how the number starts meaning that again. See how verification works or inspect a sealed evidence package.