Pick one start point and write it in the policy. The most defensible is the time the advisory is published or the issue is first detected in your inventory, whichever is earlier, with severity adjusted by reachability. Teams that leave it undefined end up arguing about whether they were late.
Why the start point matters
A target of seven days means different things depending on when counting begins. If the clock starts when a developer notices, a finding can sit for months with no breach of policy. If it starts at public disclosure but your tools only scan weekly, you are late before you know.
Options compared
| Start point | Pros | Cons |
|---|---|---|
| Advisory published | Objective and public, simple to audit | You may not know you are affected yet |
| First detected in your inventory | Reflects your actual knowledge | Depends on scan frequency, can hide detection lag |
| Triaged and confirmed | Removes false alarms from the count | Triage delays become invisible |
| Ticket created | Easy to measure in a tracker | Weakest, since the ticket can be delayed |
A practical combination is to start the clock at the earlier of publication or detection, and measure triage time separately as its own target.
Split the clock into stages
- Detect: from publication to your inventory showing the match.
- Triage: from detection to a decision on severity, reachability and owner.
- Fix: from decision to the patched version running in production.
Measuring each stage tells you where time goes. If detect is slow, scan more often. If triage is slow, you need owners and better context. If fix is slow, look at release processes.
Adjusting for context
Raw severity scores are a starting point. Policy can shorten the target if the issue is known to be exploited, or lengthen it if the vulnerable code is not reachable and the service is not exposed. Write which signals can move a deadline and who can approve a longer one. Government catalogs of known exploited vulnerabilities are one input many organizations use, but check the current terms of any catalog before quoting its deadlines in your own policy.
What to report
- Median and 90th percentile time per stage, per severity.
- Share of findings that met target.
- Count of overdue items by owner team.
- Exceptions in force and their expiry dates.
Report percentiles as well as averages. A few very old items hide inside a good looking average.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which signals make a finding more urgent than its score alone suggests.
Quick check
Should weekends count?
Say so in the policy. Many teams count calendar days for critical items and working days for lower severities.
What if no fix exists yet?
Pause the fix stage but not the clock for mitigation. Apply compensating controls within the target and record an exception.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
