The Cottage Health System breach in 2024 exposed thousands of patient records through a vulnerability in an internet-facing application. The breach itself was significant. But the aftermath revealed something more consequential for their cyber insurance story: the security controls they represented in their policy application did not match what was actually happening in their environment.

Specifically, their documented patching practices and encryption implementation did not align with the operational reality of their systems.

This is the most dangerous category of coverage risk: not a control that never existed, but a control that exists in some form, was represented to the carrier during underwriting, and then turns out to be weaker or differently implemented than claimed.

That gap is where rescission risk lives.

What Happened: The Vulnerability and the Representation Gap

The technical cause of the breach was an unpatched vulnerability in a web application. But the broader discovery, documented in security audit reports and legal filings, revealed misalignment between what Cottage Health claimed about their patching practices and what was actually documented in their patch management records.

This is not the same as saying "they never patched anything." It is saying something more specific: their representations about security controls in the policy application understated or mischaracterized the actual state of their systems.

Examples of this kind of gap include:

  • Claiming "critical patches are applied within 30 days" when the actual practice is 45 days for non-emergency patches
  • Representing "all endpoints are encrypted" when some legacy systems have encryption disabled for performance reasons
  • Stating "all applications are scanned for vulnerabilities quarterly" when the actual practice is annual scans with some systems excluded
  • Indicating "database access is logged and monitored" when logging is configured but alerts are not actively monitored

Each of these is a gap between the representation and the reality. And in the underwriting context, each creates rescission exposure.

Why the Claim Faced Scrutiny

When a cyber insurance claim is filed following a breach involving a known vulnerability that should have been patched, carriers begin asking very specific questions:

  1. When was the vulnerability disclosed?
  2. When was it patched by the vendor?
  3. Did the policy application represent that patching was current?
  4. What does the actual patch management log show?
  5. If there was a gap between the representation and the evidence, was it material to the underwriting decision?

The Cottage Health situation was particularly clear because:

  • The vulnerability was well-documented and had a public patch available months before the breach
  • Their policy application represented active patch management practices
  • Their actual patch records showed the vulnerability had not been applied despite the time available
  • The misalignment between application claims and operational evidence created a direct rescission question

Carriers do not pursue rescission over minor timing issues or technical differences in how controls are described. But they do pursue it when:

  • The application answer is materially different from the operational reality
  • That difference would have affected the underwriting decision
  • The difference directly relates to the loss

In Cottage Health's case, all three conditions were met.

What Evidence Would Have Changed the Outcome

The evidence that prevents this outcome is not mystical. It is just earlier and more specific. For a complete framework on how to organize and present application evidence, see The Complete Guide to Cyber Insurance Evidence in 2026.

Before underwriting, gather:

  1. Patching cadence documentation — Actual patch records from the last 12 months showing:

    • Date patches were released by vendor
    • Date patches were tested
    • Date patches were deployed
    • Any delays and the reason (testing, compatibility, legacy system exception)

  2. Vulnerability scan results — Latest comprehensive vulnerability scans showing:

    • All systems scanned
    • Known vulnerabilities identified
    • Remediation status for each vulnerability
    • Any exceptions with documented justification

  3. Patch management policy — Your written policy covering:

    • Definition of critical, high, and medium severity patches
    • Service-level targets for each category (e.g., "critical patches within 7 days")
    • Exception process for systems that cannot be patched
    • Documented deviations from policy with business justification

  4. Encryption inventory — System-by-system documentation of:

    • What is encrypted in transit
    • What is encrypted at rest
    • What legacy systems have encryption disabled and why
    • Compensating controls for any systems without encryption

  5. Evidence trail — Enough documentation that a third party could verify your claims:

    • Patch deployment logs from your patch management tool
    • Screenshots of your vulnerability scanner results
    • Email confirmation of policy reviews and approvals
    • Signed attestation from your CTO or security leader

The companion piece here is: "Prove your patching cadence before someone checks it for you."

Because carriers will check it. They check it at renewal through questionnaires. They check it more aggressively when there is a claim. And they check it most thoroughly when they suspect a misrepresentation.

The only way to survive that check confidently is to have the evidence ready before anyone asks.

The Representation Question at Renewal

Your cyber insurance application asks about patching in various forms:

"Are all critical security patches applied within 30 days of release?"

This question is a test of precision, not a binary pass/fail. Because the honest answer is usually: "Yes, we apply critical patches within 30 days, except for these legacy systems, which we patch quarterly because they cannot be rebooted during business hours."

That answer is defensible if you have the evidence to back it up. It becomes a rescission risk if you answer "yes" but the evidence shows something different.

The same principle applies to encryption:

"Are all customer databases encrypted at rest?"

The honest answer might be: "Our primary databases are encrypted at rest. Our disaster-recovery replica for one legacy system runs unencrypted on a physically isolated network because the system does not support encrypted operation. We compensate by limiting network access to authorized administrative users only."

That answer is defensible. The claim of universal encryption without evidence to support it is not.

Practical Steps Before Your Next Renewal

  1. Audit your patch records — Pull your actual patch management logs for the last 12 months. Calculate average time-to-patch by severity level. If the average is 45 days, do not answer "30 days" on the application.

  2. Run a vulnerability scan — Get current scan results from your vulnerability scanner. Document the remediation status of every finding. Any high-severity issues that are open need a documented justification or a patch plan with timeline.

  3. Create an encryption inventory — System by system, answer: encrypted in transit, encrypted at rest, or unencrypted. For any unencrypted systems, document why and what compensating controls exist.

  4. Draft your exception list — Identify systems or practices that deviate from standard security practices. For each one, write down the business reason and any mitigating controls. This list is not something to hide; it is something to lead with.

  5. Align with your IT team — Before you sign the application, confirm that your IT leadership agrees with the claims. Get that agreement in writing.

  6. Preserve the evidence — Screenshot your patch logs, save your scan results, document your encryption configuration. Keep this evidence with your policy documents.

The Cottage Health case teaches a specific lesson: it is not enough for controls to exist. They have to be what you said they are, and you have to be able to prove it.

Check your controls now. Run the free readiness check →

Have a carrier questionnaire? Upload it to see what you're missing →