The patch SLA clock should start when the vendor becomes aware of the flaw, or when it is publicly disclosed, whichever is earlier. Starting it at "release of a fix" lets the vendor take unlimited time to build one. Write the start event into the contract in plain words and add a separate clock for telling you.
Four possible start events
Most patch clauses name a deadline and skip the starting line. The result is a number that cannot be measured. Here are the usual candidates.
| Start event | Who controls it | Risk to you |
|---|---|---|
| Public disclosure or CVE publication | Mostly outside the vendor | Fair, but the vendor may have known for months |
| Vendor awareness (report received or internal finding) | The vendor | Best for you, hard to verify without records |
| Fix available | The vendor | Weak: the clock starts after the work is done |
| Your written request | You | Slow, and leaves you chasing |
A clause that starts at "fix available" really measures how quickly the vendor ships a fix it already has. That is a delivery SLA, not a patch SLA. Both are useful, but they answer different questions.
Use two or three clocks, not one
Think of the process as a short chain:
- Awareness to acknowledgement.
- Acknowledgement to mitigation or fix.
- Fix to delivery in your environment.
- Delivery to your own deployment.
The first three belong to the vendor. The last belongs to you, and a contract that mixes them invites blame. For a hosted service the vendor does all four, so the clause should say so. For on-premises software, the vendor should commit to the first three, and you commit internally to the fourth.
NIST SP 800-40 Rev. 4 treats patching as preventive maintenance and recommends an enterprise strategy that makes it routine. That framing helps in negotiation: patching is a normal cost of operating the product, so a commitment to timelines is not an unusual ask.
Words that make the clock measurable
- Name the record the vendor will use to prove awareness, such as the date stamp on its internal ticket.
- Require that advisories carry the dates of report, fix and disclosure so you can audit later.
- Say that the clock does not pause for "investigation" beyond a short stated period.
- Say that the clock keeps running if the vendor ships a fix that does not work.
- Say what the vendor does when no full fix is possible in the window: a workaround, a configuration change or a feature switch.
CISA's Secure by Demand guide asks whether customers can install patches easily and whether the manufacturer enables automatic updates. A clause that sets the clock but ships fixes that are painful to install does little for you, so pair the timeline with delivery terms.
A short test for any clause you read
Take a past incident, such as a flaw in some product you already use. Walk through the clause. Could you say, from public records alone, whether the vendor met it? If not, the start event is vague.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fix being available changes what you can do next.
Safeguard can help you track your side of the clock: vulnerability findings, policies and, where you enable it, autonomous remediation with fix PRs, which is off by default and every category starts on Manual.
Quick check
Should the clock start at fix release?
Not on its own. That measures delivery speed only. Start from awareness or disclosure, then add a delivery clock.
Who owns the last step, deploying the patch?
For on-premises software, you do. For a hosted service, the vendor does, and the contract should say so.
Sources
Last reviewed: 19 October 2026.
