Set targets from your own data: measure the current baseline for a few cycles, decide how much exposure the business will tolerate for each priority tier, check capacity, then commit to a target slightly tighter than today. Revisit quarterly. Outside benchmarks are optional, and often not comparable.
Why outside numbers are risky
Published remediation figures come from different datasets, scopes and clock definitions. Without knowing how they were measured, you cannot compare yourself with them. A figure that sounds like an industry standard can mislead leadership into demanding a target the team cannot meet, or a target far too lax.
NIST SP 800-40 Rev. 4 frames patching as routine preventive maintenance and notes a common gap between business owners and security or technology managers about its value. It recommends building an enterprise strategy that makes patching simpler and reduces risk. That points toward targets grounded in your own context, agreed with both sides, rather than borrowed from elsewhere.
A five step method
- Measure the baseline. Run your definitions for several cycles and record the median and the share past SLA for each tier.
- Set a risk tolerance per tier. Ask business owners how long they accept the exposure for each class of system, for instance internet facing versus internal.
- Check capacity. Compare inflow per period with what the team can close. A target that exceeds capacity creates a permanent breach.
- Choose a target. Pick a value a little better than baseline and inside tolerance. Write the clock rules next to it. See when the SLA clock starts and stops.
- Review quarterly. Tighten if you consistently meet it, relax or add capacity if you consistently miss.
A table to fill in
| Tier | Baseline median | Owner's tolerated exposure | Capacity per period | Target |
|---|---|---|---|---|
| Priority one | measured | agreed | measured | chosen |
| Priority two | measured | agreed | measured | chosen |
| Priority three | measured | agreed | measured | chosen |
Every cell should come from your own data or an explicit agreement.
Special case: known exploited items
For vulnerabilities in the CISA KEV catalog that you run and can reach, many programs set the tightest tier. CISA describes the catalog as an authoritative source of vulnerabilities exploited in the wild and advises using it as an input to prioritization. How tight you go is your decision. Document the rationale.
Avoid these traps
- Copying a figure from a vendor report
- Setting a target nobody owns
- Changing the target mid quarter to turn a miss into a pass
- Setting a single target for all tiers
If you do want a comparison point, use it as context only, with the source and its definitions stated. See mean time to remediation benchmarks for the caveats.
Safeguard's policies and gates can enforce tier targets once you set them, and its free scan offers a starting snapshot to anchor the baseline.
Quick check
How many cycles do I need for a baseline?
Enough that one unusual month does not dominate. Several cycles is a sensible minimum, longer if your volume is low.
Who should approve the targets?
Security leadership and the owners of the affected systems together, so the commitment is shared.
Sources
- NIST, SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: https://csrc.nist.gov/pubs/sp/800/40/r4/final
- CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Last reviewed: 19 October 2026.
