Cyber insurance requirements have changed completely over the last three years. After the wave of ransomware claims that pushed loss ratios to unsustainable levels, insurers stopped writing policies against a simple questionnaire. They now demand verifiable minimum technical controls before binding a policy. If your organization cannot evidence those controls, the proposal is declined, the premium spikes or, worse, a future claim is refused because of a mismatch between what you declared and what you actually deployed. This guide breaks down what underwriters really ask for in 2026, which technical documentation counts as evidence, and why a recent pentest or audit has become the proof that makes the difference.
What insurers require before binding a policy
The 2026 proposal form no longer asks whether you run "antivirus". It asks about a concrete list of controls whose absence is grounds for immediate decline. These are the minimum requirements that appear almost universally:
- MFA on every critical access path: email, remote access (VPN, RDP), privileged accounts, and cloud administration consoles.
- EDR or XDR deployed across endpoints and servers, ideally with managed 24/7 monitoring (SOC or MDR).
- Offline or immutable backups, segregated from the domain, with regularly tested restores.
- Patch management with a defined cadence: critical vulnerabilities remediated within short windows, prioritizing entries in the CISA Known Exploited Vulnerabilities (KEV) catalog.
- A documented and tested incident response plan, in many cases backed by a response retainer.
- Recurring phishing simulations and security awareness training for all staff.
- Email filtering and anti-phishing at the mail gateway.
- Evidence of a recent pentest or audit, typically within the last 12 to 24 months.
The underlying principle is simple: the insurer wants to transfer residual risk, not the risk created by nonexistent security hygiene. Every control on this list reduces the probability or impact of the ramp's most expensive claims: ransomware, business email compromise, and data breaches.
Coverage checklist and proposal-form questionnaire
Before you sit down with your broker, self-assess your posture using the same logic the underwriter will apply. The table below maps the control areas, what the questionnaire typically asks, and the technical evidence that supports each answer.
| Control area | What the questionnaire asks | Supporting evidence |
|---|---|---|
| Authentication | MFA on email, VPN, RDP and admin accounts? | IdP policy, config screenshots, MFA coverage report |
| Endpoint | EDR/XDR on 100% of workstations and servers? | EDR console, agent inventory, per-host coverage |
| Backups | Immutable or offline copies and tested restore? | Restore test logs, 3-2-1 architecture |
| Vulnerabilities | Patch cadence and exposure management? | Scan report, remediation SLA, KEV coverage |
| Response | Tested IR plan and response capability? | IR playbook, latest tabletop minutes, retainer contract |
| Access | PAM, least privilege, legacy protocols disabled? | Privilege review, PAM policy |
| People | Awareness training and phishing simulations? | Campaign metrics, click rate, training coverage |
| Validation | Pentest or audit in the last 12-24 months? | Pentest executive report, closed remediation plan |
This checklist doubles as a work map: every row where you cannot produce evidence is a gap the insurer will penalize with premium loading, exclusions, or an outright decline. Risk-analysis methodologies like the one we cover in What Is Magerit help you prioritize which gaps to close first based on their real impact.
MFA: the requirement that decides the underwriting
No single control weighs more on the underwriting decision today than multi-factor authentication (MFA). It is the first filter and, in practice, a knockout requirement. The question is no longer "do you have MFA?" but "where exactly is it deployed?". Underwriters demand MFA explicitly across four surfaces:
- Email (Microsoft 365, Google Workspace and webmail), the usual origin of business email compromise.
- Remote network access: every VPN and, above all, all RDP access, which should never be exposed directly to the internet.
- Privileged and domain-administrator accounts, including service accounts where technically feasible.
- Cloud administration consoles and management-system access.
On top of that, a growing number of insurers downgrade or reject SMS or voice-based MFA because of its exposure to SIM swapping and MFA fatigue (push bombing). The trend is to require phishing-resistant methods: FIDO2, passkeys, certificate-based authentication or, at minimum, number matching on push notifications. The technical rationale is direct: MFA neutralizes reuse of stolen credentials, the vector we analyze in What Is Credential Stuffing. Without MFA, a single credential dump turns any remote access into an open door, precisely the entry point that precedes most ransomware deployments described in What Is Ransomware.
What cyber insurance does NOT cover
Understanding the exclusions matters as much as meeting the requirements, because they determine when the policy actually responds. The most common 2026 exclusions are:
- International sanctions: no insurer will pay a ransom to a sanctioned entity (OFAC lists and EU equivalents). Paying in those cases is also potentially illegal.
- Unpatched known CVEs: if the incident exploits a known vulnerability for which a patch has been available for some time, the "minimum standards / failure to maintain" clause can trigger a denial.
- Misrepresented controls: if you declared universal MFA on the proposal form and forensics prove it did not exist, the insurer can rescind the policy for misrepresentation and void coverage retroactively.
- War and nation-state acts: the war exclusion clauses revised across the Lloyd's market since 2023 restrict cover for attacks attributable to hostile state operations.
- Prior known / prior acts: incidents or breaches you were already aware of before binding the policy.
This is why consistency between what you declare and what you deploy is critical: the leading cause of denial is not a lack of cover, but the mismatch between the questionnaire and the technical reality.
Types of cyber insurance: first-party vs third-party
A cyber policy usually combines two broad blocks of cover worth distinguishing:
- First-party cover: your organization's own losses. It includes business interruption, data and system restoration, forensic costs, crisis management, notification costs and, in many policies, ransomware extortion.
- Third-party cover: liability toward affected third parties. It includes privacy and data-breach liability, legal defense and, where legally insurable, regulatory penalties.
The European nuance is relevant: in the EU, GDPR fines are generally not insurable on public-policy grounds, unlike markets such as the United States. Keep that in mind when assessing limits and sublimits.
The European angle: NIS2 and DORA as underwriting evidence
This is where a European company holds an advantage over the US-centric incumbents that dominate the SERP. The controls the underwriter demands overlap almost entirely with the Article 21 measures of NIS2 and with the ICT risk-management requirements of DORA: MFA, vulnerability management, continuity, incident response and supply-chain security.
The practical consequence is twofold. First, if you are already progressing on NIS2 or DORA compliance, much of the underwriting evidence is already generated (gap analysis, security policy, continuity plan). Second, a recent pentest report or cybersecurity audit serves simultaneously as regulatory evidence and as technical proof for the insurer. The same effort covers two fronts. If you also want to understand what the policy actually pays out and at what price, we break it down in what cyber insurance covers.
How to prepare with Secra
At Secra we position penetration testing and auditing as the technical evidence insurers require to bind or renew cover. We run a cyber insurance readiness assessment that maps your real posture against the proposal form, identifies the gaps that penalize your premium, and delivers the report that evidences your controls.
- GRC Consulting: we align your underwriting evidence with NIS2 and DORA.
- Penetration testing: the recent report that validates your controls before the underwriter.
Frequently asked questions
Is MFA mandatory to obtain cyber insurance?
In practice, yes. MFA is a knockout requirement on most 2026 proposal forms, demanded explicitly on email, remote access (VPN and RDP), privileged accounts and cloud consoles. Without MFA, the proposal is declined or the premium rises significantly.
Does an old pentest count as evidence for the insurer?
It depends on how old it is. Most underwriters ask for evidence of security testing performed within the last 12 to 24 months. An older report loses evidential value because it no longer reflects current exposure after infrastructure changes, new vulnerabilities or recent CVEs.
Can a claim be denied for declaring controls I did not have?
Yes. It is one of the most common causes of denial. If forensic analysis proves that a control declared on the proposal form did not exist (for example, universal MFA), the insurer can rescind the policy for misrepresentation and void coverage retroactively.
Does cyber insurance cover GDPR fines in the EU?
Generally, no. In the European Union, GDPR administrative penalties are usually deemed uninsurable on public-policy grounds, unlike markets such as the United States. The policy can still cover the defense, forensic and notification costs associated with the breach.
What is the difference between first-party and third-party cover?
First-party cover indemnifies your organization's own losses (interruption, restoration, forensics, extortion). Third-party cover responds for liability toward affected third parties (privacy liability, legal defense). A complete policy usually combines both.
About the author
Secra Solutions team
Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.

