Start the SLA clock when your system first detects the finding, and track time since public disclosure as a second number. Triage start flatters teams by hiding queue time. Publication start is fairest to attackers but unfair to teams when scanners lag.
The three options compared
Clock starts at triage. The team controls it, so it feels fair. The problem is that it hides how long a finding waits before anyone looks. A team can reach 100 percent SLA compliance by triaging slowly.
Clock starts at detection. This is the first moment your tooling flagged the issue. It is automatic, auditable, and cannot be moved by people. Most programs should use this as the contractual SLA.
Clock starts at public disclosure. This reflects attacker opportunity. The weakness is that your scanner may not know about an advisory for hours or days, so a team can be late before they could have known.
Pick one SLA clock and one visibility clock
A workable pattern is to use detection as the SLA clock and show time since disclosure as a visibility metric next to it. Engineers get a target they can control. Security leaders still see the gap between the world knowing and your estate knowing.
If the gap grows, the fix is not to blame developers. It is to improve detection: more frequent scans, better feeds, or continuous monitoring of dependencies rather than scanning only on build.
Write down edge cases
Most disputes come from edge cases, so settle them in advance:
- Rescored findings. If severity rises, does the clock restart or does the shorter SLA apply from the original start? We suggest the original start, otherwise teams are rewarded when a score is revised.
- Findings in code nobody owns. Assign an owner within a fixed time, and count owner assignment time as its own metric.
- Fix not yet released upstream. Pause the clock only for a documented reason, and track the pause.
- Reopened findings. Treat as new events, linked to the old one.
Business days or calendar days
For internet facing, exploited items, use calendar hours. Attackers do not observe holidays. For lower tiers, business days are fine, as long as the policy says which.
Review quarterly
Compare the time spent in each phase: detected to triaged, triaged to assigned, assigned to fixed, fixed to deployed. The slowest phase tells you where to invest. Often it is the last one, deployment, which most SLA dashboards ignore.
For why an average of these durations misleads, see mean vs median vs p90.
A worked comparison
Take one finding that is published on Monday, detected by your scanner on Wednesday, triaged on Friday and fixed the following Friday. Measured from publication, the fix took 11 days. From detection, 9 days. From triage, 7 days. Same work, three different numbers, and a 7 day SLA is met under one definition and missed under the other two.
This is why the choice matters more than the target. Moving the start point later can lift your compliance rate without anyone fixing anything faster. Change the clock only with a note on the chart and a restated history, so trends stay honest.
Quick check
Is a single SLA clock acceptable for audits?
Ask your auditor, but the usual aim is a documented policy that you apply consistently. Write yours down and follow it.
Should the SLA differ by severity?
Yes, and ideally by exploit evidence and exposure too, not severity alone.
Last reviewed: 19 October 2026.
