For most of the past decade, cyber insurance renewal conversations focused on controls questionnaires: did the organisation have MFA, endpoint detection, backup procedures, and an incident response plan. Underwriters used the answers to set premiums. Few policies contained specific technical performance obligations that, if breached, would affect claims.
That model is changing. The commercial pressure forcing enterprise IT teams to confront the patching problem is not coming from regulators, whose enforcement timelines are slow. It is coming from underwriters whose claims data has made patch lag a direct actuarial variable. Insurers are inserting specific patch compliance windows into policy conditions, and the timelines they are specifying are incompatible with how most enterprises currently manage change.
What Insurers Are Actually Specifying
The language varies by insurer and policy tier, but a pattern has emerged across cyber liability policies written in 2025 and 2026. Critical CVEs, typically defined as CVSS score 9.0 and above, must be remediated within 72 hours of disclosure or availability of a vendor patch, whichever is later. High severity CVEs (CVSS 7.0 to 8.9) carry a 7-day remediation window. Medium and low severity CVEs typically fall under a 30-day standard.
The 72-hour window for critical CVEs is not aspirational language. It appears as a policy condition in the same section as other coverage prerequisites: MFA requirements, backup frequency obligations, and incident notification timescales. Breach of a policy condition is grounds for claim denial, not premium adjustment at renewal.
Some policies add a technical verification requirement: the insured must be able to demonstrate patch compliance through automated scan results or deployment pipeline logs, not self-attestation. This means “we believe the patch was applied” is not a sufficient response to a post-breach audit.
Why Monthly CAB Cycles Cannot Meet a 72-Hour SLA
The arithmetic is direct. A monthly change advisory board cycle has a maximum latency of 30 days from change submission to approval. In practice, with submission deadlines, document preparation time, and meeting scheduling, the effective latency for a change submitted after the most recent meeting is typically 14 to 21 days.
A 72-hour SLA requires that a critical CVE is identified, a patch is obtained, a change request is prepared, the change is approved, the patch is tested, and the patch is deployed to all affected systems within three calendar days.
A CAB that meets monthly cannot approve a change within 72 hours unless it convenes an emergency meeting. Emergency CAB procedures exist in most ITIL implementations, but they carry their own latency: the process of declaring an emergency, convening the required approvers, and obtaining sign-off typically takes 4 to 24 hours in a well-run organisation and longer in practice.
Even if emergency CAB approval is obtained within four hours, the remaining 68 hours must cover: identifying all affected systems (hours), obtaining and staging the patch (hours), testing in a staging environment (hours to days), deploying to production systems (hours to days for a large fleet), and verifying coverage (hours).
For a large enterprise estate, deploying a patch to every affected system and verifying coverage within 72 hours is not achievable with a manual, in-place patching process regardless of how emergency CAB procedures are designed. The constraint is not approval latency. The constraint is deployment and verification capacity on mutable infrastructure.
What Happens When You Breach a Patch SLA Condition
A breach of a policy condition does not automatically void a claim. The legal position depends on the policy wording, the jurisdiction, and whether the condition is a warranty (absolute) or a condition precedent (must be met before a specific right arises).
Regardless of the precise legal characterisation, the practical consequence of a breach is contested coverage. The insurer commissions a forensic investigation. The investigation determines whether the breach that caused the claim occurred on a system with an outstanding critical CVE beyond the policy window. If it did, the insurer has grounds to contest the claim or to reduce payment to the proportion of loss attributable to factors other than the patch SLA breach.
In 2025, several large cyber insurance claims in the UK and US were either denied or substantially reduced on this basis. The decisions are not widely publicised because they are resolved in private settlement rather than litigation, but they are visible in the underwriting community and are directly influencing how subsequent policies are written.
The consequence for organisations that have not read their current policy conditions is that they may be carrying insurance that will not pay out for the most probable class of breach: exploitation of a known, unpatched vulnerability.
The Underwriting Data Driving This
Insurers have a decade of claims data. The pattern is consistent across carriers and geographies: breach probability correlates directly with patch lag. Organisations that maintain critical CVE remediation windows above 30 days have materially higher breach frequency than organisations that remediate within 7 days.
This is not a security finding. It is an actuarial finding. Insurers are not writing policy conditions based on security best practice frameworks. They are writing them based on the correlation between patch lag and claim frequency that emerges from their own book of business.
The 72-hour critical CVE window is not derived from the Action1 report on exploitation timelines, though the Action1 data is consistent with it. It is derived from the insurer’s observation that claims arising from critical CVE exploitation cluster in the 2 to 14 day window after CVE disclosure. Requiring remediation within 72 hours removes the highest-frequency claim scenario from the covered period.
What Enterprises Need to Change Before the Next Renewal
The renewal conversation for cyber liability policies in Q3 and Q4 2026 will include more specific technical questions than previous years. Organisations that cannot demonstrate a credible path to 72-hour critical CVE remediation will face either coverage exclusions for patch-related breaches or premium increases that price the gap.
The architectural changes required to meet a 72-hour SLA are substantial and cannot be completed before a renewal that is three months away. Organisations in that position need to take two actions in parallel.
The first is a policy condition audit. Read the current policy. Identify every patch compliance obligation and map it against the current patching process. Quantify the gap: for how many critical CVEs in the past 12 months was the remediation time greater than 72 hours? This creates the evidence base for a conversation with the broker about the current exposure and the realistic timeline for remediation.
The second is an architecture programme scoped to the renewal window. Automated vulnerability scanning, golden image pipelines, and blue-green deployment for the highest-risk internet-exposed systems can be delivered in 6 to 9 months by a focused team. That covers the most probable attack surface before the next renewal and provides evidence of material progress toward full compliance.
Organisations that address neither will find that their cyber insurance renewal in Q4 2026 or Q1 2027 includes conditions they cannot meet and premiums that reflect the risk the insurer is carrying on their behalf.
