A patch report may measure how long a vendor took to release a fix, or how long customers took to install it. These are different clocks with different owners. Check which one a statistic describes before you use it to judge a supplier or your own team.
Two clocks, two owners
| Clock | Starts | Ends | Owner |
|---|---|---|---|
| Vendor fix time | Vendor learns of the flaw | A patch is released | The vendor |
| Customer patch time | Patch is released | Fix is installed and verified | You |
| Exposure window | Flaw is public or exploited | Fix is installed | Shared |
Google Project Zero's disclosure policy is a clean example of the first clock. It gives a vendor 90 days after notification to make a patch available, shortens that to 7 days when a flaw is already being exploited in the wild, and publishes details 30 days after a patch ships if the deadline was met (Project Zero). It says nothing about when customers deploy.
The 2025 Verizon DBIR edge device figure, a median of 32 days to fully remediate with 54% completed according to press coverage, is a customer side measure (Infosecurity Magazine).
Why mixing them misleads
A vendor that ships fixes quickly can still have customers that install them slowly, and the reverse. If a report on vendor speed is read as a report on customer risk, you may blame the wrong party or relax when you should not.
Questions to ask the data
- Does the clock start at vendor notification, public disclosure, patch release or first detection?
- Does it end at release, install or verified fix?
- Who controls the longest segment?
- Is there a workaround clock too, for the period when no patch exists?
Using this in a vendor review
When you evaluate a software supplier, ask for their fix time from notification to release, and separately think about how your own change process will add to it. When you review your own metrics, show the two segments, so a delay in a vendor's release does not get mixed up with a delay in your approval queue.
Where dependencies fit
For open source packages, "patch available" can mean a new release, a backport to your older version, or a fork. Your inventory tells you which versions you run, and reachability analysis helps you judge which of them matter first. Safeguard offers both, and the free scan is a quick way to look.
A worked case
Imagine a vendor ships a fix 12 days after learning of a flaw, and you install it 30 days after release. The vendor segment is 12 days, your segment is 30, and the exposure window from public disclosure to your fix is longer than either. If you only look at the vendor number you will think the supplier was quick, and if you only look at yours you will not see how long the flaw was known before a fix existed.
Quick check
Is a 90 day disclosure deadline a patch time benchmark for customers?
No. It is a vendor disclosure clock. Customer patch time starts when a fix exists and ends when it is installed.
What if no patch exists yet?
Then only the exposure clock is running. Track mitigations separately and note the date a real fix appears.
Sources
- Google Project Zero, Vulnerability Disclosure Policy
- Infosecurity Magazine, Verizon DBIR reveals jump in vulnerability exploitation
Last reviewed: 19 October 2026.
