Answering the Cyber Insurance Patching Question

No single deadline answers the cyber insurance patching question. Forms and underwriters differ, so read your actual form, clarify its definitions with your broker or carrier, and answer from measured practice across the systems in scope. One published form offers bands from 7 days to over 90 days, and one practitioner reports pushback above 14 days on internet-facing systems. Neither is a universal rule, and a policy target alone does not support the answer.

What does a cyber insurance patching question actually ask?

It depends on the form, because carriers do not all ask the same question. Answer the wording in front of you, not the wording you expected.

Question 29 of the Societies Insurance Cyber Liability Supplemental Application (form SI_CM07_APP 2026.10.08) asks "Critical security patches applied within" and offers four bands: 7 days, 8-30 days, 31-90 days and Over 90 days. The question itself does not establish what Societies means by critical, when its clock starts, which assets count, whether exceptions are allowed, or how an answer affects eligibility, limits, pricing, coverage or claim payment. Do not fill those gaps with assumptions.

JMO Partners, an IT firm writing from its own renewal work, says current questionnaires focus specifically on internet-facing systems and that "anything over fourteen days gets pushed back on." That is one practitioner's observation, not a carrier rule, an industry standard or a guaranteed underwriting outcome.

Why your patch policy is not the answer

A policy says what should happen. An application question about how fast patches are applied may be asking what did happen. Keep these five facts separate:

• Policy target: the window your written standard sets.
• Actual observed remediation time: elapsed days per finding, from your records.
• Current overdue critical exceptions: what is past target today, and why.
• Internet-facing subset: the same measurements for the narrower, higher-risk group of exposed systems.
• Patches not yet available: flaws with no vendor fix. Disclosure and patch availability are different events. Record the mitigation, owner, review date and evidence, and never report these as patched.

What should you ask the broker or carrier to clarify?

Ask how the measurement works whenever the form leaves it undefined. Put the questions in writing and keep the replies with your application file.

• What counts as critical? Vendor severity, a CVSS threshold, exploited status, CISA KEV listing or another definition?
• When does the clock start? Vendor release, internal detection, scanner ingestion or ticket creation?
• When does it stop? Deployment attempted, installation confirmed, reboot completed or a clean verification scan?
• Which assets count? Endpoints, servers, cloud workloads, network appliances, SaaS, third-party-managed systems and end-of-life products?
• What is being requested? A policy target, historical performance, current posture or all three?

These choices change the number. Federal agencies, for contrast, have one defined method: BOD 26-04 counts calendar days from KEV listing or the agency identifying the flaw on an asset, whichever comes first. That shows why a clock needs defining. It does not define the clock on your form.

How do you build the evidence for a time band?

Measure a defined lookback period from your own records, one finding per asset, and count days the same way throughout. Where the broker or carrier gave no definition, state the assumption you used.

1. Export the in-scope asset inventory.
2. Collect critical findings and vendor advisories for the lookback period.
3. Join each finding to its release, ticket, deployment, reboot (where needed) and verification timestamps.
4. Calculate elapsed calendar days consistently.
5. Separate internet-facing assets.
6. List missing records, exceptions, failed deployments, offline devices, and unsupported or end-of-life systems.
7. Have the system owner and the application signer review the result.

Keep the verification step. NIST SP 800-40 Rev. 4 describes enterprise patch management as including "verifying the installation," so a pushed deployment is not by itself proof that the patch landed.

Worked example: a seven-day policy and a mixed record

This company and its assets are fictional. Its policy says critical patches go in within seven days. For July 1 to September 30, counting calendar days from vendor release to a clean verification scan, the record shows:

• VPN-01, internet-facing: released August 4, verified August 9, 5 days.
• WEB-01, internet-facing: released August 11, verified August 27, 16 days.
• FILE-01, internal: released August 11, verified August 17, 6 days.
• LAPTOP-114, offline for two weeks: released August 11, verified September 2, 22 days.
• HR-APP-01, internal: released September 8, verified September 14, 6 days.
• LAPTOP-220, failed deployment: released September 8, still open on September 30, 22 days and counting.

Three of six findings closed within 7 days. Two closed in 8-30 days, and one was open at 22 days. On the internet-facing subset, one of two took longer than 7 days.

The seven-day policy does not support selecting the 7 days band here, because half the findings took longer. The five closed findings average 11 days, the most common result falls in the 7-day band, and the slowest is at least 22 days, so each summary method tells a different story. No source here says which method a carrier uses. Disclose the distribution and the exceptions, and ask how this specific form expects one band to be selected.

Separately, suppose FW-02 has a critical flaw disclosed on September 21 with no vendor patch by September 30. Do not count it as patched. Record it on its own line with the mitigation, owner, review date and evidence, and ask how the form treats it.

What belongs in the evidence pack?

Keep one dated folder that lets the signer trace the answer back to its records.

• Patch policy
• Asset inventory
• Vulnerability or patch report
• RMM, MDM or configuration-management deployment evidence
• Change tickets
• Exception and risk acceptances
• Compensating controls with owners and expiry dates
• A short reconciliation of policy versus observed performance

Do CISA KEV due dates apply to insurance applications?

No source reviewed here makes them an insurance deadline. KEV due dates come from a binding directive for U.S. federal civilian agencies, not a universal private-sector requirement.

They are still useful prioritization evidence. CISA's KEV guidance says private organizations are not bound by BOD 26-04 but strongly recommends prioritizing listed flaws and using the catalog as an input to their prioritization framework. Some deadlines are short: the KEV catalog lists a WordPress Core flaw, CVE-2026-119977, added November 3, 2026 and due November 6, while Windows CVE-2026-81963 was added September 8 and due September 22. A broad monthly cadence is therefore not automatically enough for an exploited perimeter flaw. For the operational steps, see how to triage a KEV addition in 72 hours; BOD 26-04 has replaced the BOD 22-01 window that page mentions.

How to improve before renewal without misstating the past

• Inventory every internet-facing system and name an owner.
• Remove or isolate unsupported assets.
• Create an emergency path for exploited, KEV-listed and perimeter flaws.
• Use staged deployment with a short validation ring rather than waiting for the next monthly cycle.
• Monitor failed and offline deployments.
• Time-box exceptions and verify compensating controls.
• Measure and report actual elapsed time.

Improvements made after the measurement period are remediation. Date them and describe them that way, and do not count them retroactively. Do not delay or change the truth on a pending application to make the numbers look better.

Checklist for answering the question

• Copy the exact form wording and options.
• Get definitions for critical, clock start, clock stop and scope, or record your assumptions.
• Measure the lookback period, including open items.
• Report internet-facing results separately.
• List exceptions, missing records and unpatched flaws with no vendor fix.
• Have the signer and broker or carrier review the answer, plus counsel where appropriate.

Sample response format

This is a format for organizing facts, not legal language. Adapt it to what your form allows.

• Form option selected: [band], per [broker or carrier confirmation and its date].
• Measurement period: [start] to [end].
• Scope: [asset groups included and excluded].
• Critical definition and clock used: [definition], from [start event] to [stop event].
• Observed distribution: [count] within 7 days, [count] in 8-30, [count] in 31-90, [count] over 90, [count] open.
• Internet-facing result: [counts and slowest elapsed days].
• Open exceptions: [asset, reason, mitigation, owner, expiry date].
• Dated remediation plan: [action, owner, target date].

What this does not promise

No patch window, whether 7, 14 or 30 days, guarantees a quote, a favorable price, coverage, a limit, a renewal or claim payment. This is not legal or insurance advice. The same answer-from-evidence method applies to the MFA section and the EDR question of an application.

Sources

• Societies Insurance Cyber Liability Supplemental Application, SI_CM07_APP 2026.10.08
• JMO Partners: Cyber-insurance underwriting in 2026
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 26-04 Implementation Guidance
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning