Read a time-to-patch report by asking five things before you trust the number: which vulnerabilities are in scope, when the clock starts, what counts as done, whose systems were measured, and which kind of average was used. A figure that cannot answer all five is a headline, not a benchmark.
Why one number is never enough
"Organizations take 32 days to patch" sounds like a fact. It is a summary of a specific set of vulnerabilities, a specific population and a specific method. Change any of those and the number moves, sometimes by months. The goal is not to distrust every report. It is to know what a number can support before you quote it in a meeting or hold your own team to it.
The five questions
| Question | What to look for | Why it changes the answer |
|---|---|---|
| Scope | All CVEs, only exploited ones, only one device class | Exploited edge flaws get more attention than the long tail |
| Clock start | Disclosure, patch release, scan detection, ticket created | Starting at detection hides the time before you knew |
| Definition of done | Patched, mitigated, closed in a tool | Mitigation and ticket closure are not the same as a fix |
| Population | Telemetry customers, survey respondents, one sector | Who is measured decides what is typical |
| Statistic | Mean, median, half-life, percent closed | Each summarizes the same data differently |
Scope: which vulnerabilities were counted
The 2025 Verizon DBIR looked at edge device vulnerabilities, and press coverage of it reported that 54% were fully remediated within a median of 32 days (Infosecurity Magazine). That is a statement about a narrow, high-profile class. It does not describe your internal libraries or a low-severity backlog.
Clock start and definition of done
Some reports start from public disclosure, some from the day a patch exists, and some from the day a scanner first saw the flaw. A patch release date is not a deployment date either. Google Project Zero's policy, for example, counts the vendor's 90 days from when the vendor is notified, with a shorter 7 day deadline when a flaw is already exploited in the wild (Project Zero). That is a disclosure clock, which is a different thing from how long a customer takes to install the fix.
Population and statistic
Telemetry from one vendor's customers is not the whole market. Survey answers reflect who responded. And a mean, a median and a half-life of the same data can each tell a different story, which later posts in this series cover one by one.
A quick routine
- Find the methodology section, not the summary.
- Write down the five answers in one line each.
- Decide whether your own data can be measured the same way.
- Quote the number with its scope attached, for example "median time to fully remediate a set of edge device CVEs".
Safeguard can help with the inventory side of this. Its SBOM and dependency scanning and reachability analysis show which vulnerable components you run and which ones your code actually calls, and you can try the free scan at gold.safeguard.sh/scan.
Quick check
Is a bigger sample always more trustworthy?
No. A large sample of the wrong population, or one that only counts vulnerabilities that were eventually fixed, can mislead more than a small and well described one.
Can I compare my average to a report's median?
Not directly. Convert yours to the same statistic and scope first, or compare trends in your own numbers instead.
Sources
- Infosecurity Magazine, Verizon DBIR reveals jump in vulnerability exploitation
- Google Project Zero, Vulnerability Disclosure Policy
Last reviewed: 19 October 2026.
