Quick answer up front: a cyber insurance policy won’t pay when the application promised security measures that weren’t actually in place when it mattered — multi-factor login everywhere, tested backups, a patch cadence that deserves the name. The questionnaire you fill in at signup isn’t a formality. It’s the actual contract. And if you’re honest, it’s a pretty good security checklist.
Why is the questionnaire the actual contract?
When you take out a cyber policy, the insurer asks about your security posture: Do you have MFA on all remote access? How often do you apply updates? Are there tested backups kept offline? These boxes get ticked “yes” quickly, because it lowers the premium and because you meant to do it anyway.
Every one of those answers is a contractual assurance. Say “yes, MFA everywhere” and the attacker later walks in through the one RDP connection that didn’t have MFA, and you’ve breached a duty of care. The insurer is allowed to cut the payout: partially for gross negligence, entirely for intent.
So you pay premiums for years for cover you don’t get at the one moment you need it. That’s the most expensive way to hold an insurance policy.
When won’t cyber insurance pay?
Most reductions and refusals come down to the same handful of points:
| Reason | What’s behind it |
|---|---|
| False statements in the application | ”MFA everywhere” ticked, but there were gaps. The single most common cause. |
| Outdated software | A known hole, patched months ago, left open. Negligent, so the payout is cut. |
| No tested backup | The backup existed but wouldn’t restore, or sat on the same network. |
| Reported too late | Contractual notification windows (often only a few days) allowed to lapse. |
| Provider without approval | Hiring an incident responder the insurer doesn’t cover. |
| Ransom paid unilaterally | Paying without coordination, and sanction or war exclusions often apply regardless. |
None of these are exotic. They’re exactly the things you put off until “later.”
Reverse the order
The usual sequence is: sign the policy, click through the questionnaire, hope. It works better the other way around. Take the application questionnaire before you sign, and treat every question as a task:
- Is MFA really on every remote access point — VPN, RDP, webmail, admin panels?
- When did you last actually restore a backup, not just create one?
- Does at least one copy sit out of an attacker’s reach, meaning offline or immutable?
- Do you know which systems are running unpatched, and why?
Answer those four honestly with “yes” and you get two things at once: a policy that holds when it counts, and a security level that clears most attacks before they land. The insurance is then the safety net and not the plan. As a bonus, the premium drops, because honest “yes” answers save real money. And if you’re currently checking whether NIS2 applies to you anyway: the homework overlaps almost entirely — do it properly once, use it twice.
Want to walk through the application questionnaire honestly before you sign? Get in touch — in an independent consultation we’ll find where the assurances and the reality still diverge.