On 10 June 2026 CISA issued BOD 26-04, which supersedes and revokes BOD 19-02 and BOD 22-01. The older rule was simple: two weeks for newer KEV entries and six months for older ones. The new one sets remediation timelines from four factors: public exposure, KEV status, whether exploitation can be automated, and whether the impact is partial or total control. It applies to federal civilian agencies, but CISA strongly encourages everyone to adopt similar practices.
If a customer or assessor has asked for your vulnerability remediation SLA, you need a short written policy and proof that you follow it. This post gives you a template and explains each choice.
What's affected
Any company that must show a remediation timeline in a questionnaire, a SOC 2 or ISO 27001 audit, a PCI DSS assessment or a customer contract. The template covers application dependencies, container images, operating systems and infrastructure.
How to check if you're exposed
Pull the last 90 days of closed vulnerability tickets and compare each one with the clock your policy promises. Count the ones that missed it. If you have no written clock, any answer you gave in a questionnaire is a promise you cannot show you kept.
A quick check with a CSV export:
import csv, datetime as dt, collections
days = collections.defaultdict(list)
for r in csv.DictReader(open("closed.csv")): # columns: id,severity,opened,closed
o = dt.date.fromisoformat(r["opened"]); c = dt.date.fromisoformat(r["closed"])
days[r["severity"]].append((c - o).days)
for sev, d in days.items():
print(sev, "avg", sum(d) / len(d), "max", max(d))
That prints the average and worst days to close per severity. Compare the worst case with your promised limits.
What to do now
- Fix the clock start. Decide whether the clock starts when the vulnerability is published, when your scanner first sees it, or when a fix exists. BOD 26-04 starts its clock at the earlier of the KEV addition or the day the agency identifies the issue on an asset. PCI DSS 6.3.3 starts at patch release. Pick one rule per source and write it down.
- Define severity. Name your scale. The CVSS 4.0 qualitative ranges are Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0. Say whether you use the base score alone or adjust for your environment.
- Add two modifiers: exposure and KEV. A vulnerability on the CISA KEV list, or on a service reachable from the internet, moves up a tier.
- Publish the clocks. Use the table below.
- Write an exceptions process. Each exception needs an owner, a reason, a compensating control, an expiry and an approver.
- State how you report. Monthly count of open items by tier and the number past their clock, to a named group.
- Keep evidence. Ticket history with open and close dates, scan results before and after, and exception records. Retain them for the period your auditor or contract requires. PCI DSS asks for retention of penetration testing and remediation results for at least 12 months.
Clock table
| Tier | Trigger | Remediate or mitigate within |
|---|---|---|
| Emergency | On KEV and internet-facing | 3 days |
| Critical | Critical score, or on KEV and internal | 14 days |
| High | High score | 30 days |
| Medium | Medium score | 90 days |
| Low | Low score | Next scheduled maintenance, reviewed twice a year |
Where these numbers come from: the 3 day tier echoes BOD 26-04's three day timeline for the highest-risk combination. The 30 day High tier follows PCI DSS 6.3.3, which says critical or high-security patches are installed within one month of release and other patches within an appropriate time frame such as three months. The 14 day Critical tier echoes the old BOD 22-01 two week rule. These are choices, not rules. A smaller team might choose longer clocks it can actually meet. A promise you consistently keep is worth more than a short one you routinely miss.
Policy text you can adapt
Purpose: ensure vulnerabilities in our systems and software are fixed in a
timeframe that matches their risk.
Scope: production services, the dependencies and images they use, and the
infrastructure that hosts them.
Rating: we use CVSS 4.0 qualitative ratings. We move a finding up one tier if
it is listed in the CISA KEV catalog or affects an internet-facing service.
Clocks: Emergency 3 days, Critical 14 days, High 30 days, Medium 90 days.
Clocks start when the vulnerability is identified in our systems or when a fix
is published, whichever is earlier.
Mitigation counts as remediation when it removes the exposure, for example by
disabling the feature or blocking access, and a permanent fix is scheduled.
Exceptions: require a written reason, a compensating control, an approver from
engineering leadership and an expiry no longer than 90 days.
Reporting: the security lead reports open items and items past clock monthly.
Evidence: tracker history and scan results are retained for 12 months.
How to avoid this trap
- Never publish a clock you have not met for the last quarter. Check the closed-ticket data first.
- Measure from a clear start event, so a long scanner delay does not eat the window silently.
- Make exceptions expire. An exception with no end date is a permanent change to the policy.
- Count mitigation separately from fix. State the rule so a firewall rule does not look like a patch in your reports.
Why it matters
An SLA is a promise. Assessors and customers compare it with your records, so a modest clock you meet beats an ambitious one you cannot. BOD 26-04 shows the broader trend: clocks tied to exposure and exploitation, not to a score label alone.
Revisit the table once a year. CISA says it will reassess its timelines once per fiscal year, which is a reasonable cadence for your policy too.
Try it yourself
Take your five oldest open vulnerabilities. Assign each one a tier using the table, work out whether it is past its clock, and decide whether to fix it, mitigate it or write an exception. If you need a place to record the exceptions, try the walkthrough below.
Click through it at your own pace, or open it full screen.
Quick check
Why does the policy define when the clock starts?
Different starts (publication, discovery, fix release) can differ by weeks. A written start event makes your closed-ticket data comparable with your promise.
What does PCI DSS 6.3.3 say about critical and high patches?
It says critical or high-security patches and updates, identified through the risk ranking process, are installed within one month of release. Other applicable patches follow an appropriate timeframe, for example three months.
