Far too long. Attackers exploit a newly disclosed critical vulnerability in around five days on average; suppliers take roughly 65 days to patch a critical flaw; Cyber Essentials asks for 14. Three clocks, and the slowest one is the window an attacker gets to work in. This post defines patching latency, shows why a questionnaire cannot see it, and explains why patch speed predicts a breach better than a policy does.
Why is the UK government’s “84% cut in fix times” the wrong thing to celebrate?
The 84% headline measures the easy vulnerabilities, not the dangerous ones. In February 2026 the UK government’s Vulnerability Monitoring Service cut median fix times for domain vulnerabilities from 50 days to 8, but only from 53 to 32 days for the rest, and as PublicTechnology noted, a median hides the tail of actively exploited criticals. If the public sector takes 32 days on that harder category with dedicated government scanning, a supplier with no such infrastructure takes longer.
What is patching latency, and how is it different from MTTR?
Patching latency is the measured delay between a fix becoming available for a critical vulnerability and the moment a supplier applies it across its estate, observed over time rather than promised in a policy. MTTR (mean time to remediate) is the internal average a security team reports for its own remediation. Patching latency is the external, observed version of that figure for a supplier you do not control. For third-party risk, supplier patching latency is the lag you measure from outside to rank suppliers by how long they leave a known door open.
MTTR is something a supplier calculates and reports to you. Patching latency is something you measure whether the supplier reports it or not. One is an attestation; the other is a behaviour.
What is the gap between a supplier’s patch SLA and its real patching behaviour?
The gap is the distance between a 30-day policy on paper and a remediation record measured in months. Breach risk turns on whether a supplier meets its SLA on the vulnerabilities attackers are already using.
The independent data says they often do not. Verizon’s 2024 DBIR found organisations took 55 days on average to remediate half of their critical vulnerabilities once a patch existed, against a 5-day median to mass exploitation of flaws on the CISA Known Exploited Vulnerabilities catalogue. The 2025 DBIR reported a 32-day median to patch edge and VPN KEVs, with only around 54% of edge KEVs ever fully remediated.
The buying organisation inherits that gap: when a supplier in your data path leaves a known critical flaw open for months, the exposure is yours to explain to a regulator, not just theirs.
Why can’t a questionnaire or audit catch patching latency?
A questionnaire records what a supplier says about its patching on the day it answers; it cannot watch what the supplier does over the months that follow. An audit certifies a control existed during a defined window. Neither sees the next critical CVE land, the patch ship, or the days before the supplier applies it.
The TalkTalk breach is the clearest UK example. The ICO fined the company £400,000 in October 2016 after attackers exploited a database flaw that had a fix available since 2012 and had sat unpatched for over three years. A questionnaire in any of those years could have recorded a tidy patch policy. The behaviour was the breach.
How long do suppliers actually take to patch a critical vulnerability?
Independent research puts the real figure in months, not the days the standards ask for. Edgescan’s 2025 statistics report measured average remediation of around 65 days for critical network and device flaws and around 74 days for critical application flaws. Separate research by Bitsight across 1.4 million organisations found a median of 137 days to remediate critical KEVs and 238 days for high-severity flaws, with more than 60% still unpatched past CISA’s deadlines.
The window is widening from the attacker’s end too. Mandiant’s average time-to-exploit fell from 63 days in 2018 to around 5 in 2023, while supplier remediation has not sped up to match.
This produces what we call a permanent window. A supplier with chronically slow remediation runs a standing gap between every disclosure and its fix, and that gap is the attacker’s working space.
The standards set the targets that behaviour is failing to meet:
Framework | Required window for a critical patch | Authority and scope |
14 days for high-risk or critical updates | IASME / NCSC; UK organisations seeking certification; auto-fail from 27 April 2026 if missed | |
30 days (one month) for critical patches | PCI SSC; mandatory for organisations handling cardholder data | |
~2 weeks for KEV CVEs from 2021 on; 6 months for older | CISA; binding on US Federal Civilian agencies only |
The targets cluster around two weeks to a month; the measured behaviour runs to two, three, sometimes four months on the same class of flaw.
What does the questionnaire say versus what reality shows?
Questionnaire vs. Reality
- Questionnaire Says: “We have a 30-day critical-patch policy.”
- Reality Shows: Median time-to-patch on observed CVEs: 87 days. Maximum: 214 days.
The policy may be a sincere intention. The reality is the record of what happened when real critical vulnerabilities landed, and that record is the one an attacker reads. An attacker ranks suppliers by it; you should rank them the same way.
How does Elasticito measure supplier patching behaviour from the outside?
Elasticito measures patching behaviour externally through Black Kite, scoring each supplier’s patch management posture continuously rather than asking it to self-report. The signal comes from the supplier’s public estate, so it does not depend on a questionnaire at all.
Black Kite’s Ransomware Susceptibility Index rolls patch management in as one of its scored indicators. Companies with an RSI between 0.8 and 1.0 are 96 times more likely to experience a ransomware attack than those scoring below 0.2. Slow patching is one of the strongest externally measurable predictors of breach and ransomware risk, and unlike a point-in-time audit it is a live signal you can verify yourself.
For a CISO, the action is to tier suppliers by remediation behaviour, not contract value. A small supplier that patches criticals in 12 days is a lower live risk than a strategic one that takes 130. Rank on the measured lag, set it as a contractual threshold for critical suppliers, and re-check it continuously. That record also helps under UK GDPR Article 32 and DORA’s third-party ICT rules, which expect you to know whether a supplier patches in time, not just that it promised to.
FAQ
How long does it take to patch a critical vulnerability?
Independent research puts real-world remediation of a critical vulnerability at roughly 65 days on average for network and device flaws (Edgescan, 2025), and a median of 137 days for the critical vulnerabilities attackers are actively exploiting (Bitsight, 2024). Internet-facing criticals are fixed faster, around 35 days. Against this, attackers exploit a new critical flaw in around five days on average, so the defender’s clock runs an order of magnitude slower.
What is patching latency, and how is it different from MTTR?
Patching latency is the observed delay between a fix shipping for a critical vulnerability and a supplier applying it, measured over time from the outside. MTTR (mean time to remediate) is the internal average a team reports for its own fixes. The difference is who measures it and how: MTTR is self-reported and can be scoped to flatter the number; patching latency is observed from the supplier’s public estate, so it reflects what actually happened rather than what was stated. For third-party risk, patching latency is the version you can verify without the supplier’s cooperation.
Does slow patching predict a breach?
Yes, slow patching is one of the strongest externally measurable predictors of breach and ransomware risk. Attackers prioritise known, exploitable vulnerabilities with public exploits, and a supplier that consistently leaves those unpatched is presenting the exact targets they hunt for. Black Kite’s data shows organisations with a Ransomware Susceptibility Index of 0.8 to 1.0 are 96 times more likely to suffer a ransomware attack than those below 0.2, with patch management as a scored input. Slow patching is not a guarantee of compromise, but as a live, observable signal it ranks suppliers by risk far better than a policy statement does.
What is an acceptable patch SLA for a critical vulnerability?
Use 14 days as the benchmark for a critical vulnerability, because that is the line UK certification now draws. From 27 April 2026, Cyber Essentials v3.3 makes failure to patch high-risk or critical flaws within 14 days an automatic fail. PCI DSS allows 30 days for critical patches in the cardholder data environment, and CISA’s federal directive sets roughly two weeks for recent KEV-listed CVEs. Two weeks to one month is the defensible range; anything beyond a month for an actively exploited critical leaves a window attackers can use.
What patch latency should I demand from a critical supplier?
Demand 14 days for critical vulnerabilities, and measure it rather than accept the claim. Write the window into the contract and verify it through continuous external monitoring, not an annual questionnaire. A 30-day SLA may suit a non-critical supplier; for one inside your data path, the gap between a 14-day promise and a 90-day record is the exposure you accept on its behalf.
Conclusion: Why how fast a supplier patches beats what its policy claims
A supplier’s patch policy tells you its intention; its measured time to patch a critical vulnerability tells you what an attacker will actually find.
To see how your suppliers’ patching behaviour compares to what they promise, join Elasticito on 15 July 2026 for Your Questionnaire Won’t Save You: Discover the Vendors Most Likely to Breach You Next.
Created: 2026-06-04 / Reviewed: 2026-06-04
