Measure the waiting time at each handoff, not only the total time to fix. Four timers cover most of it: detection to triage, triage to owner acceptance, fix to verification, and evidence request to delivery. The longest wait shows where teamwork breaks down, and it is usually a gap between teams, not inside one.
Why total time hides the problem
Time to fix is useful but blunt. A fix that took twelve days might have taken one day of work and eleven days of waiting. If you only track the total, you may push engineers to work faster when the real delay is a ticket sitting in a queue.
The four timers
| Timer | Starts | Stops | What a long wait suggests |
|---|---|---|---|
| Triage wait | Finding recorded | Severity and response decided | Product security capacity or unclear rules |
| Acceptance wait | Assigned to owner | Owner acknowledges | Wrong owner, missing owner field |
| Verification wait | Fix merged | Rescan confirms | No automatic rescan, unclear responsibility |
| Evidence wait | Request sent | Evidence delivered | Duplicate asks, no register |
Add a fifth if platform changes matter to you: change announced to impact reviewed.
Collect them from timestamps you already have
Most trackers record created, assigned and closed dates. Add status change timestamps and you can compute the waits without new tools. NIST SP 800-218 task PO.4.1 suggests tracking the criteria and measures for security checks throughout the life cycle, and the example list includes key performance indicators, so these timers are a natural fit.
Read the numbers carefully
Use medians and the slowest ten percent, not averages, because a few outliers distort a mean. Compare across quarters, not across teams as a league table. If you publish team by team numbers as a ranking, people will game them or stop reporting honestly.
Turn numbers into change
- Pick the longest wait.
- Find the cause by reading five slow tickets.
- Change one thing: an owner field, an auto rescan, an intake form.
- Measure again next quarter.
NIST CSF 2.0 outcome ID.IM-03 covers improvements identified from operational processes, and this loop is a lightweight way to produce them. The post on making every dashboard number traceable to evidence covers trusting the data behind these timers.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which events in the flow carry a timestamp you could measure.
Where Safeguard fits
Safeguard records findings, scan times and remediation activity, which gives you timestamps for the first and third timers. A free scan shows what is recorded.
Quick check
What is a good target for each wait?
There is no universal figure. Set a target from your current median, improve it gradually and agree it with the teams involved.
Should we show the numbers to engineers?
Yes, as trends for the whole process. Use them to fix the system, not to rank individuals.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1, task PO.4.1.
- NIST Cybersecurity Framework 2.0, outcome ID.IM-03.
Last reviewed: 19 October 2026.
