A cyber insurance policy is the one part of your security program you hope never to test, which is exactly why claims go wrong: the first time anyone reads the policy closely is the week after the incident. Claims aren’t usually denied because the carrier is looking for an excuse. They’re denied or cut down because something the business said on the application wasn’t true on the day of the loss, because notice came late, or because the loss fell into a category the policy quietly limited. All of those are avoidable, and most of the avoiding happens months before anything goes wrong.
1. The application said yes, and the truth was no
This is the big one. Carriers now ask pointed questions: multi-factor authentication on email, on remote access, on admin accounts? Endpoint detection and response? Backups separated from the network and tested? The answers aren’t a survey; they’re representations the policy is issued on. If a loss happens and the carrier’s forensics show that MFA wasn’t actually on the server the attacker used, the carrier can seek to rescind the policy, treating it as if it never existed.
That isn’t theoretical. In a widely cited 2022 case, Travelers sued to rescind a policy after a ransomware claim because the insured’s application stated MFA was in place on its servers when it was not, and the policy was voided by agreement. The same logic applies to every “yes” on your renewal.
What to do: have the person who actually runs your systems answer the technical questions, and keep the evidence behind each answer: a screenshot of the MFA policy, the EDR console, the backup test log. If the honest answer is “partially,” say so, or fix it before you sign. Deploying MFA properly takes a week; a rescinded policy takes the whole claim.
2. The control was true in March and lapsed in September
Most policies carry language about maintaining the security measures you described, and some carriers write specific conditions, such as requiring that backups be kept offline or that critical patches be applied within a set window. A control that was switched on for the application and quietly fell over later is, from the carrier’s point of view, the same as one that never existed.
The best-known example involved a hospital system whose carrier sued to recover a settlement it had paid, citing a “failure to follow minimum required practices” exclusion after the hospital’s data sat on an unprotected server. The dispute was eventually resolved on procedural grounds, but every carrier read the filings.
What to do: treat the application as a list of promises with owners. Put a quarterly check on the calendar: is MFA still enforced for everyone, are the immutable backups still immutable, did the last restore test actually run. A managed IT provider should be producing this evidence as a by-product of its normal reporting.
3. Notice came too late
Cyber policies are claims-made and require prompt notice, often “as soon as practicable” and sometimes within a fixed number of days of discovering an incident. Businesses routinely blow this by trying to handle things quietly first, waiting to see if the ransom note is real, or letting the IT vendor restore from backup before anyone calls the broker. By the time the claim is filed, the carrier argues it was prejudiced: the evidence is gone and the forensic firm it would have chosen never got the chance.
What to do: write the carrier’s hotline into your incident plan and make the call on the first day, before restoration, before paying anything. Carriers generally want to be involved early, and many policies only cover forensic, legal and negotiation vendors drawn from the carrier’s approved panel. Hiring your own first can leave you paying for both.
4. The loss fell under a sublimit
A $1 million policy rarely pays $1 million for the things that actually happen to small businesses. Social engineering and funds-transfer fraud, the fake wire instructions, the invoice from a spoofed vendor, are typically sublimited to $100,000 or $250,000, sometimes with a separate deductible and a requirement that you verified the request by phone before paying. Business interruption may carry a waiting period of eight to twelve hours before it starts counting. Regulatory fines and PCI assessments may be capped or excluded.
What to do: read the declarations page, not the brochure, and match the sublimits to your real exposure. If your controller approves vendor payment changes and your largest wire is $400,000, a $100,000 social engineering sublimit is a known gap. Fix it with coverage, or with a callback procedure that makes the fraud unlikely, or both.
5. An exclusion applied
Three exclusions do most of the damage. War and state-sponsored attack exclusions were rewritten across the market after a pharmaceutical company won a long fight over whether a Russian-attributed malware outbreak was an act of war; newer policies now spell out what’s excluded, and attribution clauses matter. Prior known circumstances exclude incidents you knew about, or should have, before the policy started, which catches businesses that discover an old intrusion during onboarding with a new provider. Unencrypted device and end-of-life software exclusions turn a lost laptop or an unsupported server into an uncovered loss.
What to do: ask your broker to walk you through the exclusions in plain English, and align the technical side: full-disk encryption on every laptop, no unsupported operating systems on the network, a documented look for existing intrusions when you change IT providers.
6. The paper trail wasn’t there
Even a valid claim needs documentation: when the incident was discovered, what was affected, what it cost, what was done. Businesses without logs can’t establish scope; businesses without a timeline can’t establish timing; businesses that wiped and rebuilt the affected machines before anyone imaged them destroyed the evidence the carrier needed. The first 72 hours of a ransomware incident decide most of this.
What to do: preserve before you restore. Keep the carrier’s forensic firm in the loop on what gets rebuilt and when, and keep a running log, even a shared document with timestamps, from the first hour.
The pre-renewal review that prevents all six
Ninety days before renewal, sit down with your broker and the person who runs your IT, and go through the policy and the application together: every technical “yes” verified with evidence, every sublimit compared to a real-world scenario, every exclusion mapped to a control you either have or will add. The requirements carriers now expect and a 90-day renewal plan cover the groundwork. Your broker owns the policy language; your IT provider owns the evidence; the two should be in the same conversation at least once a year.
A claim that pays isn’t luck. It’s an application that was true, controls that stayed true, a phone call made on day one, and a file that proves it.