TL;DR:

  • Cyber insurance is not unconditional coverage — policies have specific security requirements that you need to meet to be covered.
  • The most common grounds for rejection are failure to maintain MFA on key systems, unpatched vulnerabilities, and misrepresentation on the application form.
  • Insurers increasingly audit your security posture at application and after incidents — what you said you do needs to match what you actually do.
  • Read the policy schedule carefully before you need to make a claim, not after.

Cyber insurance has become standard advice for UK small businesses. The pitch makes sense: pay a premium, get covered if something goes wrong. But the relationship between premium paid and claim paid is not as automatic as it sounds for home or car insurance.

Cyber insurers have been tightening their conditions since 2020, when ransomware payouts ballooned across the industry. The policies that looked like straightforward coverage five years ago now contain specific security requirements that businesses must actively maintain. If you don’t meet them at the time of an incident, the claim can be rejected — even if you’ve been paying premiums for years.

What Insurers Actually Require

Requirements vary between policies, but several conditions appear consistently across most UK SME cyber insurance products.

Multi-factor authentication on critical systems: This is the most common condition in modern policies. Most policies now require MFA on email accounts (especially Microsoft 365 and Google Workspace), remote access (VPN, RDP), and admin or privileged accounts. If you suffer a breach through a compromised account that didn’t have MFA enabled, and your policy required MFA, the insurer has grounds to reject or reduce the payout.

This isn’t hypothetical — credential theft is the most common initial access method in business email compromise and ransomware incidents. The insurer knows this, which is why MFA is the condition they check most carefully.

Software patching: Policies often require “reasonable” patching — keeping operating systems and key software updated. If an attacker exploits a known vulnerability with a patch available for three months before the incident, that’s harder to defend under a “reasonable security” clause. Automatic updates should be on for Windows, macOS, browsers, and Microsoft/Google productivity tools at minimum.

Backups: Most policies require that data backups exist, are tested, and are stored separately from the main network (specifically, offline or offsite — backups on the same network as the incident can be encrypted by ransomware along with everything else). An untested backup that turns out to be corrupt doesn’t help you, and it may not satisfy the backup condition.

Accurate application: The information you provided when you applied for the policy — about your employee count, security controls, data types you handle — forms the basis of the contract. If the insurer discovers at claim time that you misrepresented your security controls on the application (saying you had MFA when you didn’t, for example), the policy can be voided entirely. This applies even without deliberate fraud — an answer that was accurate when you applied may be outdated if your security posture has changed.

What Happens When You Make a Claim

When you report an incident, the insurer will typically engage a forensic firm to investigate. That investigation isn’t just about understanding what happened — it’s also establishing whether your security controls were in place as required by the policy.

Forensic investigators will look at:

  • Whether MFA was enabled on affected accounts at the time of the incident
  • Patch levels on affected systems
  • Whether backups exist and are usable
  • Whether security tools (endpoint protection, email filtering) were active and current
  • Access logs and authentication records

You’re not being presumed guilty — this is standard claims investigation. But it does mean that what you say you do needs to match what the logs show you were actually doing.

Common Scenarios Where Claims Fail

Email compromise with no MFA: A phishing email leads to a Microsoft 365 account takeover. The attacker uses the account to send fraudulent payment instructions to customers. The policy required MFA on email accounts. MFA wasn’t enabled. Claim rejected.

Ransomware with an out-of-date application: Attackers exploit a known vulnerability in an unpatched application server. The vulnerability had a patch available for 90 days. The policy required “timely patching.” The insurer argues the business failed to meet this standard. Claim disputed or reduced.

Backups not usable: Ransomware encrypts the main file share and the backup, which was mapped as a network drive. The “backup” condition is technically met — backups existed — but they were also encrypted. The insurer pays for incident response but disputes the business interruption element on grounds that recoverable backups should have been maintained.

Application mismatch: The renewal application stated that endpoint protection was deployed on all devices. A BYOD (bring your own device) policy allowed personal devices to access company systems. The incident involved a personal device without endpoint protection. The insurer argues the policy statement was inaccurate.

What You Should Do

Read your policy before you need it. The policy schedule and policy wording are not the same as the marketing summary you received when you bought the policy. The schedule lists your specific cover; the wording describes the conditions. Both matter.

Check the security conditions against your actual posture. Make a list of every technical requirement in the policy and verify that you actually meet it. If you find a gap, close it — and document when you closed it.

Keep records. If an incident happens, you’ll want evidence that your controls were in place. Screenshots of MFA settings, patch management logs, backup confirmation emails — documentation that would have taken minutes to capture at the time can be difficult to reconstruct after the fact.

Tell your broker about changes. If you change your IT provider, migrate to new systems, or change how you handle customer data, notify your broker. Material changes to your risk profile may need to be reported to maintain valid coverage.

Treat renewal as a security review. The renewal form is an opportunity to check that your stated controls are still accurate. If they’ve lapsed since last year, fix them before renewing — not after.

Cyber insurance is a useful backstop. It’s just not an unconditional one. The premium you pay covers the risk of an incident; it doesn’t cover the risk that you weren’t maintaining the security controls you said you were.