Set fix windows by service tier and exploitation status, not by severity alone. Use a short window for known exploited issues in production, a medium window for reachable issues in customer facing services, and a scheduled window for the rest. Write them down, measure misses, and adjust. This is a planning aid, not legal advice.
What a window is for
A fix window is a promise to yourselves and your customers about how long a known issue may stay open. It turns an argument into a lookup. It also gives an escalation path: past the window, someone more senior is told.
Windows that nobody meets are worse than none, because they teach people to ignore the policy.
What to base windows on
- Exploitation. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities seen exploited in the wild. CISA strongly recommends all organizations prioritize remediation of listed items. Federal civilian agencies have prescribed deadlines under a directive. Everyone else is not bound, so your own window is a choice.
- Exposure. Internet facing, handling customer data, or internal only.
- Reachability. Whether the vulnerable code is actually used.
- Fix availability. If no fixed version exists, the window becomes a mitigation window.
Notice what is missing: raw severity as the only driver. FIRST's CVSS guidance states that a Base score measures severity and should not be used alone to assess risk.
A sample structure
The words below are deliberately relative. Fill in numbers that your team can meet.
| Tier | Known exploited, present | Reachable | Not reachable |
|---|---|---|---|
| Customer facing, holds data | Shortest window | Short window | Scheduled upgrade |
| Customer facing, no data | Short window | Medium window | Scheduled upgrade |
| Internal tools | Medium window | Scheduled upgrade | Scheduled upgrade |
How size changes the structure
- 1 to 10 people: two windows are plenty. Urgent and scheduled.
- 11 to 50: add tiers by service type.
- 51 to 200: add escalation steps and a formal exception path.
- 200 plus: windows live as policy in version control and are checked in the pipeline.
Define when the clock starts
The same window can mean very different things depending on the start. Published date, detected date, and triaged date all differ. Pick one and write it down. See when does the SLA clock start.
What to do when you miss
- Check whether the window was unrealistic. If more than a small share miss, lengthen it or add capacity.
- Check whether alerts lacked owners.
- Record exceptions with expiry.
- Report the miss rate, not just the count.
If a customer asks
Buyers often ask for your patching timelines. State the windows you actually operate, with the scope, and say how exceptions are handled. Do not promise numbers you do not meet. See answer vulnerability management SLA questions.
Try it yourself
Click through it at your own pace, or open it full screen. Check how fix availability changes what the next step is.
Safeguard's policies and gates can enforce windows, and the free scan at gold.safeguard.sh/scan shows your current open findings against them.
Quick check
Should windows be the same for every severity?
No. Tie them to exploitation, exposure, and reachability, with severity as one input.
Are the CISA deadlines required for my company?
CISA's page says the directive applies to federal civilian executive branch agencies, and that other organizations are encouraged but not bound. Check your contracts for stricter terms.
Sources
Last reviewed: 19 October 2026.
