Use calendar days for urgent vulnerabilities and business days only for routine ones. Attackers do not observe weekends, so a clock that pauses on Friday evening gives them free time on the issues that matter most. Write the counting rule into the policy so nobody argues about it later.
What the choice really changes
A remediation SLA is a deadline measured from a start event. Two decisions sit inside it: when the clock starts, and which days count toward it. This post is about the second decision. (For the first, see when the SLA clock starts.)
If a fix is promised within three business days and the issue lands on a Thursday, the real elapsed time can be five calendar days. For a low severity library issue that is fine. For something under active attack it is a long time.
Decision table
| Situation | Count | Why |
|---|---|---|
| Actively exploited, internet facing | Calendar days, around the clock | Exploitation does not pause |
| High severity, no known exploitation | Calendar days, or business days with a stated cap | Keeps the deadline predictable |
| Routine, medium or low | Business days | Matches when change windows and reviewers are available |
| Fix needs a planned outage window | Business days, plus the next window | The window sets the pace |
NIST SP 800-40 Rev. 4 separates routine patching from emergency patching and says emergency patching needs to be handled as efficiently as possible to prevent imminent exploitation. That distinction maps cleanly to the table: emergencies use a wall clock, routine work uses a working calendar.
Holidays and freezes
A change freeze is a legitimate reason to defer routine work. It is not a reason to pause an emergency. Put both in the policy:
- List the freeze periods, and state that emergency changes are allowed during them with a named approver.
- State that the SLA clock for urgent issues keeps running during a freeze.
- State that routine items due during a freeze move to the first working day after it, and record that move.
Without the second point, a freeze becomes a quiet way to miss deadlines.
Measure the same way you promise
If the policy counts business days, report on business days. If it counts calendar days, report on calendar days. Mixing them makes compliance numbers look better than they are and invites disagreement in audits.
Also look beyond the average. A compliance rate can hide a long overdue tail, so report the oldest open items beside the percentage.
Say who is on call
A calendar day SLA only works if someone can act on the weekend. Name an on call owner for urgent vulnerabilities, and decide in advance what they are allowed to do alone, such as applying a mitigation or disabling a feature behind a flag.
Try it yourself
Open the demo and look at how findings are grouped and aged, then ask which of your own items would sit on a calendar clock and which on a working one.
Click through it at your own pace, or open it full screen.
Quick check
Should every severity use the same counting rule?
Not necessarily. Urgent items should run on calendar days. Routine items can use business days if the policy says so.
Does a change freeze stop the SLA clock?
It can defer routine work, but urgent and actively exploited issues should keep their clock and have an emergency change path.
Sources
Last reviewed: 19 October 2026.
