Setting a Vulnerability Remediation SLA Your Team Can Actually Hit

Federal guidance for internet-facing systems sets critical vulnerabilities at 15 days and high-severity at 30, with a tighter 14-day window for known, actively exploited vulnerabilities regardless of severity rating¹. These numbers were set for large agencies with dedicated security staff, so treat them as an upper bound for internet-facing systems, not a floor you're free to relax further.

A five-person engineering team can reasonably commit to these same windows for critical and known-exploited vulnerabilities, since those represent genuine emergencies regardless of team size, while being more flexible on the medium and low tiers where the federal guidance itself allows more time. Older vulnerabilities get a longer patch window under this same guidance than ones identified more recently, since a recently assigned CVE actively being exploited is treated as the higher-urgency case¹.

A critical vulnerability in a service that's reachable from the public internet is a fundamentally different risk than the same vulnerability in a tool only accessible from your internal network behind its own authentication. Apply the tightest timelines to internet-facing and customer-data-handling systems specifically, and allow a longer window for genuinely internal tooling.

Be honest about what actually counts as internal-only. A service reachable only through your VPN today but planned to be exposed publicly next quarter should already be held to the tighter standard, since the classification needs to reflect where the system is headed, not just where it sits today. A common mistake is classifying a system as internal because it was originally built that way, without revisiting the classification after a later change quietly made it reachable from outside, an added public webhook endpoint, a partner integration exposed through a new route.

A remediation SLA is only real if you can produce, on demand, the discovery date and the fix date for any given finding. Set up that tracking, a ticket with both timestamps, before you publish the SLA to customers or an auditor, not after you've already made the commitment and have no way to prove you're meeting it.

This also surfaces whether your timeline is realistic before it becomes a public promise. If a dry run shows your team consistently takes 20 days to close critical findings, better to discover that internally and either fix the process or adjust the number than to publish a 15-day SLA you're already missing. A dry run also tells you whether your ticketing tool actually captures both dates cleanly, since a manual field someone forgets to fill in defeats the purpose just as surely as never setting up tracking at all.

Every remediation program misses its own SLA occasionally, a fix requires a larger refactor than expected, a dependency has no patch available yet. Decide in advance how you'll handle this: a documented exception with a revised timeline and a reason, reviewed by someone other than the engineer who missed it, rather than quietly letting the finding age past its deadline with no record.

An SLA with zero documented misses over a long period is more likely to mean nobody's tracking accurately than that the team is perfect. A credible program has a small number of documented, explained exceptions. Review the exceptions themselves on a regular cadence too, since a pattern of the same kind of finding repeatedly missing its deadline points at a process gap worth fixing directly rather than another one-off exception to approve.

Set your remediation SLA in this order:

1. Start from the federal tiers for internet-facing systems and treat them as an upper bound rather than a floor to relax.
2. Apply the tightest timelines to internet-facing and customer-data systems, and allow a longer window for genuinely internal tooling.
3. Set up tracking that records both the discovery date and the fix date for every finding before you publish the SLA.
4. Decide in advance how missed deadlines are handled, with a documented exception and a revised timeline.
5. Have someone other than the engineer who missed the deadline review each exception.