Why Your Cyber Insurance Claim Might Get Denied

There's a particular kind of bad day where a business discovers two things at once: that it has been breached, and that the insurance policy it has been paying for since 2023 isn't going to pay out.

The second discovery is often the more expensive one. The breach costs what it costs. The denied claim turns a survivable incident into an existential one, and it usually comes down to something the business genuinely didn't understand it had agreed to.

Cyber insurance has changed enormously over the past few years. The early policies were written loosely, priced optimistically, and sold to businesses that had very little security in place. Then ransomware losses arrived at scale, insurers paid out far more than they'd modelled, and the market corrected hard.

Premiums rose, coverage narrowed, and — most significantly — underwriting got real.

The result is that a cyber policy today is much closer to a contract with conditions than a safety net. It pays out when you've done what you said you'd do. Here's what that actually means in practice.

The application form is a legal document

Most cyber claim problems start here, months or years before anything goes wrong.

The application asks a series of questions about your security posture. Do you enforce multi-factor authentication on remote access and email? Do you maintain offline or immutable backups? Do you have endpoint detection and response deployed? How quickly do you apply critical patches? Do you conduct

security awareness training?

Somebody fills this in. Often it's an office manager or a finance lead, sometimes with input from whoever handles IT, sometimes not. They answer generously, because the answers feel broadly true and because accurate answers mean a higher premium.

That form becomes part of the contract. If you said MFA was enforced on all remote access and it turned out to be enforced on most remote access, the insurer has grounds to argue material misrepresentation — and in some cases to void the policy entirely rather than simply deny the claim. Not reduce the payout. Void it, from inception, as though you'd never been covered.

This has been litigated. The well-known example in the US involved a food company whose insurer sought to rescind a $5 million policy after a ransomware incident, arguing the applicant had misrepresented its MFA deployment. The case settled, but the underlying principle is established and insurers are increasingly willing to test it.

What to do about it: treat the application as a technical document requiring technical input. Whoever actually administers your systems should answer the technical questions, and where the honest answer is "partially" or "on most systems," say so. A higher premium is dramatically cheaper than a void policy. And keep a copy of what you submitted — you need to know what you promised.

The controls insurers now expect

Underwriting standards have converged on a fairly consistent set of requirements. Most insurers now treat these as minimum conditions rather than discount factors, meaning their absence doesn't raise your premium so much as make you uninsurable.

Multi-factor authentication on email, remote access, VPN, and privileged accounts. This is close to universal now and it's the most common single reason a claim runs into trouble. Notably, some policies specify MFA on all administrative accounts including cloud consoles — a detail businesses frequently miss because the console gets used rarely and by one person.

Backups that survive an attack. Not just backups — offline, immutable, or otherwise segregated backups, tested with documented restores. Insurers know ransomware operators target backup infrastructure first, and a policy condition requiring backups usually implies a standard higher than "it syncs to a NAS on the same network."

Endpoint detection and response on all endpoints and servers. Traditional signature-based antivirus increasingly fails to satisfy this.

Patch management with defined timelines for critical vulnerabilities, typically two weeks and sometimes shorter for actively exploited issues. Policies may require you to evidence your patching cadence.

Privileged access management. Administrative accounts separated from daily-use accounts, minimum necessary permissions, regular review. A single account used for both email and domain administration is an underwriting problem.

Email security — filtering, anti-phishing, and increasingly domain authentication through SPF, DKIM, and DMARC.

Security awareness training at a defined interval, usually annual at minimum, often with simulated phishing.

An incident response plan that exists as a document, names people, and — ideally — has been exercised. Some insurers now ask specifically whether it's been tested.

Network segmentation, particularly for larger organisations or those running operational technology.

This list is worth reading twice, because it's also — almost exactly — a reasonable security baseline. Insurers aren't inventing arbitrary hurdles. They've priced thousands of claims and worked out what correlates with not having one.

The exclusions people don't read

Even with a valid policy and honest answers, certain categories of loss are carved out. These vary between insurers, but some appear consistently.

War and state-sponsored attack. This is the big one, and it's been moving. Following the NotPetya litigation — where insurers initially denied enormous claims on war exclusion grounds — the market rewrote these clauses rather than abandoning them. Lloyd's mandated state-backed cyber attack exclusions across standalone cyber policies from 2023. The practical concern is that attribution is difficult, contested, and largely out of your hands. A ransomware group with loose government ties sits in genuinely ambiguous territory, and the wording of your particular exclusion determines who bears that ambiguity.

Read this clause specifically. Ask how attribution is determined and who decides.

Prior known circumstances. If you were aware of a vulnerability, an intrusion, or a suspicious event before the policy incepted and didn't disclose it, resulting losses are typically excluded. This catches businesses that had "something odd" happen, never investigated it properly, and later discover it was the beginning of the intrusion.

Unsupported software. Many policies exclude losses arising from end-of-life operating systems or applications no longer receiving security updates. If you're running something past its support date because a critical application needs it, you need to know whether it's covered — and the honest answer is often no.

Failure to maintain stated controls. The controls you described at application aren't a snapshot; they're an ongoing obligation. If MFA was enforced when you applied and someone disabled it for a department six months later, you may have a coverage gap you don't know about.

Insider acts. Deliberate acts by employees are frequently excluded or sub-limited, which matters given how many incidents involve someone inside.

Betterment. Insurance restores you to your prior state. It doesn't fund the security upgrades you decide to make afterwards, even though those upgrades are exactly what the incident proved you needed.

Reputational and consequential loss. Direct costs — forensics, notification, legal, restoration, business interruption — are typically covered. The customers who quietly don't renew next year are not.

Procedural mistakes that break otherwise valid claims

This is the category that stings most, because the policy was fine and the controls were in place.

Not notifying immediately. Policies require prompt notification, often within a specified window. Businesses regularly spend two days investigating internally before calling, reasoning that they should understand the problem before reporting it. That delay alone can prejudice the claim.

Engaging your own forensics firm. Almost all policies require you to use panel providers — approved forensics, legal, and negotiation specialists. Hiring your trusted local IT consultant first feels natural and can make those costs unrecoverable. Call the insurer's notification line before you engage anyone.

Paying a ransom without consent. If your policy covers extortion payments, it will require prior approval. Paying first and claiming later generally fails. There are also sanctions considerations that the insurer's panel is better placed to assess than you are at 2 a.m.

Inadequate documentation. Business interruption claims require you to demonstrate the loss, which means records of downtime, affected operations, overtime, lost orders, and recovery costs. If nobody was keeping notes during the incident, you'll be reconstructing it from memory months later, and the insurer will discount accordingly.

Destroying evidence. Rebuilding compromised machines before forensics has imaged them can make it impossible to establish what happened — and if you can't establish what happened, you may not be able to establish that it was a covered event.

What the policy actually needs to cover

Worth checking your own against this list, because coverage varies considerably at the SMB end of the market.

First-party costs — the money you spend: incident response and forensics, legal advice, notification and credit monitoring, data restoration, business interruption, extortion payments where covered, and PR support.

Third-party liability — what others claim from you: regulatory fines where insurable in your jurisdiction, defence costs, and claims from customers or partners whose data you held.

Pay attention to sub-limits. A policy with a £1 million aggregate limit might cap business interruption at £100,000, or exclude it entirely for the first 12 hours of downtime. That waiting period matters enormously, because most SMB incidents resolve inside a few days — a 24-hour waiting period on a three-day outage removes a third of your claim.

Also check the business interruption trigger. Some policies only respond to your own systems failing. If your operations depend on a cloud provider or a managed service and they go down, that's contingent business interruption, and it's frequently a separate extension you have to buy.

Getting a better position before renewal

The practical value of understanding all this is that underwriting is negotiable if you show up prepared.

Document your controls properly. An insurer presented with evidence — MFA enforcement reports, backup test logs, patching records, training completion data — underwrites differently from one presented with assertions. This affects both premium and the strength of your position if you ever claim.

Fix the specific gaps the application reveals. The form is effectively a free gap analysis. Any question you can't answer confidently is a genuine weakness, whether or not you ever buy the policy.

Test a restore and write down the result. Date, what was restored, how long it took, whether it worked. This single document does more for your credibility with an underwriter than almost anything else, and it's something most businesses have never produced.

Write the incident response plan. A one-page document with names, phone numbers, and decision authority satisfies most requirements and is genuinely useful. Run through it once a year and note that you did.

Review the policy annually against reality. Your systems changed. Your headcount changed. You adopted new SaaS tools and maybe an AI assistant with access to your files. Coverage written against last year's environment may not fit this year's.

Ask your broker the awkward questions. What's the state-sponsored attack exclusion wording and who determines attribution? What's the business interruption waiting period? Are ransom payments covered, and under what conditions? What's the panel requirement for forensics? Is contingent business interruption included? A broker who can't answer these clearly is not the right broker.

The reframe worth making

Businesses tend to treat cyber insurance as a hedge against not being secure enough — a way to buy down risk they haven't otherwise addressed.

The market no longer works that way. Insurers price and underwrite on the assumption that you've implemented the baseline, and the policy exists for the residual risk that remains after you have. It's the last layer, not a substitute for the others.

Which produces a slightly odd but useful conclusion: the work of becoming insurable is most of the work of becoming secure. MFA, tested backups, EDR, patching discipline, access control, an incident plan — that's the same list either way. Businesses that do it get cheaper premiums, stronger claims, and considerably fewer incidents to claim on.

The policy is worth having. It's just not the part doing the heavy lifting.

At Lunara Limited, we help businesses get their controls to the standard insurers expect — and produce the documentation to prove it at renewal. If you're not confident your current answers on the application would survive scrutiny after a claim, that's worth checking before you need to find out.