Cyber Insurance: What Insurers Now Check Before They Cover You

Cyber insurance used to be an easy line item. You answered a short questionnaire, ticked a few boxes about antivirus and backups, and the policy was issued. That era is over. The application has quietly turned into a technical audit, and the questions now assume a level of operational maturity that plenty of otherwise well-run businesses have never documented anywhere.

This matters for two reasons. The obvious one is that weak answers mean a higher premium, narrower cover, or a declined application. The less obvious one is that the answers become part of the contract. If you attest to a control that is not actually running everywhere, you have handed your insurer a reason to argue about the claim at the worst possible moment.

The application form became an audit

What sits at the eligibility gate

A small set of controls has hardened into a pass or fail test with most carriers. If these are missing, the conversation often stops before pricing:

• Multi-factor authentication on email, remote access and privileged accounts. Not only for administrators, and not only on the VPN.
• Endpoint detection and response, or a managed service on top of it, deployed across every endpoint and server rather than most of them.
• Backups that are immutable or offline, and restore-tested. Immutable means an attacker holding your production credentials still cannot delete or encrypt the backup.

Insurers arrived at this list by paying claims. These are the controls that most reliably turn a full ransomware event into a bad week, so they are where underwriters draw the line.

What shapes your premium

Beyond the gate, a longer list influences pricing and exclusions rather than eligibility. Underwriters commonly ask about patching cadence and whether unsupported operating systems are still in service, how many people hold administrative rights, email authentication, security awareness training, log retention, network segmentation, and how you assess the suppliers who hold your data or connect to your systems.

Notice that this is essentially a security programme, described in insurance language. Nothing on the list is exotic. What is new is that somebody outside your business is now scoring it.

Where the evidence catches people out

Underwriting has moved from self-attestation to proof. Many carriers now scan your internet-facing estate as part of quoting, so exposed remote desktop, expired certificates and forgotten test subdomains show up whether you mentioned them or not. Others ask for deployment reports, screenshots of policy settings, or restore-test logs.

The gap that trips businesses up is rarely a missing product. It is a missing record. Somebody knows the backups run. Nobody can produce a document showing a restore was tested last quarter and how long it took. The control exists, the evidence does not.

Where claims actually get disputed

Backups that were never restore-tested

A backup that has never been restored is a hypothesis. Organisations regularly discover mid-incident that the job was completing successfully while quietly skipping a database, or that recovery would take three weeks against a stated objective of one day. We have written before about the ways a backup plan can fail exactly when you need it, and insurers have read the same claims history.

Controls that lapsed between renewals

Policies are annual. Estates change weekly. A new server ships without the agent installed, an exception is granted for a legacy application and never revisited, or a service account is created outside the MFA policy because a supplier integration needed it. At renewal the questionnaire is often completed from memory against last year's answers, and the drift goes undeclared.

This is where continuous vulnerability management and properly monitored endpoints earn their keep. Not because the report looks good, but because you see the gap in the month it appears rather than in the month you claim.

The identity assumption

Answering yes to MFA is not the same as being resistant to the attacks that now target it. Push approval and SMS codes can both be relayed or socially engineered, which is worth understanding properly before you attest to phishing-resistant authentication. Our piece on MFA fatigue attacks covers the difference.

A practical way to prepare

Treat the questionnaire as a gap assessment you happen to be doing for somebody else. Before the broker sends it back:

1. Answer it honestly in private first. The uncomfortable version is the useful one.
2. Turn every yes into a piece of evidence. A report, an export, a dated test result. If you cannot produce one, the answer is not yet yes.
3. Close the eligibility gate before anything else. MFA coverage, endpoint coverage, immutable and tested backups.
4. Write the response plan down and rehearse it. Most policies expect one, and a plan nobody has walked through is not much use at two in the morning. Our incident response work usually starts here.
5. Include your suppliers. Third-party questions are now standard, and structured vendor risk assessment is easier than reconstructing who had access after the fact.

The takeaway

The useful way to read a modern cyber insurance application is not as paperwork. It is a list, written by people who pay for the consequences, of the controls that reduce loss. Becoming insurable and becoming more resilient turn out to be very nearly the same project, so the work counts either way. If your renewal is coming up and you are not confident the answers would survive scrutiny, it is worth looking now rather than in the week the form is due.