A vendor vulnerability response SLA is three separate clocks, not one. The notification clock covers telling customers what you know. The fix clock covers shipping a patch or mitigation. The publication clock covers the public advisory and VEX record. Mixing them makes every promise either too slow or impossible to keep.
Why one number fails
Teams often write "critical issues within 7 days" and mean all three things at once. Then a vendor misses it, because the fix took 12 days, even though customers were told on day one and had a workaround. Or the vendor hits it by shipping a rushed patch, while customers heard nothing until the release notes.
Separate clocks let you promise what you can control and report honestly on each.
The three clocks
| Clock | Starts when | Ends when | Typical owner |
|---|---|---|---|
| Notify | You confirm a product is affected, or that it is under investigation | Customers who need to act have been told | Support or security communications |
| Fix | Triage confirms the issue | A patch or mitigation is available to customers | Engineering |
| Publish | The fix is available | Advisory and VEX are public | Product security |
Define the start event in writing. The questions of whether a clock starts at discovery, publication or triage are covered in when does the open source vulnerability SLA clock start.
Setting targets
- Start from how customers use the product. A product that reaches the internet needs a faster notify clock than an internal tool.
- Give each severity band its own notify target, and make it shorter than the fix target. Telling people early costs little.
- Add a rule for known exploitation. If a flaw is being used in attacks, shorten all three.
- Put "under investigation" inside the notify clock. A short honest message beats silence.
- Say what happens when the clock cannot be met: who is told, and what the new date is.
Calendar or business days
Say which. A promise of "5 days" over a weekend means different things to different readers. The trade offs are in calendar days vs business days.
What to measure
- Median and worst case time on each clock, per severity.
- The number of items that missed a clock and why.
- How many customers acted on a notice, if you can see it.
Report the overdue tail, not just the compliance rate. A rate of 95 percent can hide the one item that matters, as explained in the overdue tail post.
What the EU text says about timing
The EU Cyber Resilience Act asks manufacturers to address and remediate vulnerabilities without delay, and to disseminate security updates without delay with advisory messages. For actively exploited vulnerabilities it sets 24 hour, 72 hour and 14 day reporting steps to authorities. Those are regulatory clocks, and they sit alongside your customer clocks, not in place of them.
Quick check
Should the notify clock be shorter than the fix clock?
Usually yes. Customers can often reduce risk with a workaround or a configuration change once they know, so telling them early has value even when no patch exists.
Does publishing the VEX have to wait for the fix?
Not always. An under investigation or affected statement with an action statement can go out earlier. Publish the final fixed status when the fix is available.
Safeguard's policies, gates and guardrails and compliance evidence automation can record when each stage happened, which makes the metrics above easier to produce. A free scan is a way to see the inventory these clocks run on.
Sources
- Regulation (EU) 2024/2847, EUR-Lex, Annex I Part II and Article 14
- OpenVEX specification
Last reviewed: 19 October 2026.
