A published patch time report should inform your SLA, not set it. Build the SLA from asset exposure, evidence of exploitation and your own measured fix times, then use external reports to check that your targets are in a realistic range. Copying a number from a report imports someone else's context.
Inputs, in order of weight
| Input | Why it matters |
|---|---|
| Exposure | Internet facing assets are reachable by anyone |
| Exploitation evidence | Known exploited flaws are being used now |
| Impact | Total control of an asset is worse than partial |
| Your own median and tail | Shows what your process can do today |
| Published reports | Context on what peers achieve |
CISA's BOD 26-04 for federal civilian agencies uses a similar logic, with asset exposure, KEV status, exploit automation and technical impact deciding urgency (CISA). It is binding on those agencies, not on private companies, but it is a useful pattern.
Decision steps
- Tier your assets. Exposed and critical, exposed and routine, internal and critical, internal and routine.
- Mark exploitation evidence. Use the CISA known exploited catalog as a trigger for the top tier (CISA).
- Measure today's baseline. Median and 90th percentile days from patch release to verified fix per tier.
- Set the target in the achievable range. If your top tier median is 20 days, a 2 day SLA will be missed daily. Pair a stretch target with a plan to remove the blocker.
- Check against a report. If a report shows peers clustering at much longer times, you are fine to be ambitious. If it shows much shorter times for a comparable set, ask what they do differently.
- Write the exceptions path. An SLA without an owner, an expiry date and an approver for exceptions is a wish.
Mistakes to avoid
- Using an average from a report as a promise to customers.
- Setting one SLA for every severity.
- Starting the clock at detection in your policy while the report you cite starts at patch release.
- Measuring SLA compliance only on closed tickets, which hides the overdue tail.
When the report is useful
Reports are good at changing minds. If leadership thinks 90 days for critical exposed flaws is normal, a published result showing the spread across sectors, such as the range Tenable reported from 12 days to over 260 days for different edge flaws, can start a more useful conversation than an opinion (Tenable).
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a policy can be enforced at the point of change rather than by reminder.
Quick check
Should the SLA clock start at disclosure or at detection?
State your choice in the policy. Disclosure or patch release is the fairer start for comparison, while detection hides time you were unaware.
What if I cannot meet the target?
Record an exception with an owner and expiry, and fix the blocker. Do not quietly change the number.
Safeguard supports this with continuous monitoring of your SBOM and dependencies, zero-day discovery, and policies and gates that you set yourself. The free scan at gold.safeguard.sh/scan is a quick way to see your own starting point.
Sources
- CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
- CISA, Known Exploited Vulnerabilities Catalog
- Tenable, Verizon 2025 DBIR research collaboration on CVE remediation trends
Last reviewed: 19 October 2026.
