Could you get cyber insurance — and would a claim be paid?

Insurer proposal forms and ransomware supplementals near-universally require MFA on remote network access, web-based email (Microsoft 365 / Google Workspace) and privileged/administrative accounts. Credential theft and password reuse are the dominant intrusion vectors, so MFA is the single highest-signal control — its absence is a frequent ground for declinature or for reducing/avoiding a claim where the proposal form declared it was present. App-based or hardware MFA is preferred over SMS.

Beyond the headline accounts, insurers increasingly expect MFA across all internet-accessible business services (finance/ERP, cloud storage, SaaS admin consoles) and on the password vault, since a single un-protected high-value account undermines the rest. Conditional-access policies that enforce MFA by default are the practical way to achieve this at scale.

Proposal forms typically ask for a patch-management process with defined timescales (e.g. critical patches within 14 days). Internet-facing services running software with known, exploitable CVEs fall below that bar and are a recurring root cause in ransomware claims. Our in-depth scan fingerprints internet-facing services and flags known vulnerabilities, so a detected CVE is citable evidence against a 'we're fully patched' claim.

End-of-life / unsupported software (operating systems, frameworks, appliances no longer receiving security updates) is a standard insurer knock-out: because vulnerabilities will never be patched, the risk is unbounded. Insurers often require EOL systems to be decommissioned, replaced, or fully isolated/segmented with compensating controls — its presence is commonly an automatic declinature, which is why it's treated as a clear fail here.

While not always a proposal-form line item, encryption-in-transit is part of the 'reasonable security' baseline insurers expect and a quick external tell of hygiene: TLS on every page, modern protocol versions (1.2/1.3) with legacy 1.0/1.1 disabled, a valid certificate and HSTS. Our passive and in-depth scans observe exactly these, so a weak or missing TLS configuration contradicts a 'yes' here.

Insurers expect a defined backup regime covering business-critical data and systems with a sensible frequency tied to how much data you could afford to lose. Backups are the primary recovery control behind business-interruption and ransomware cover, so their existence and scope are core proposal-form questions.

The ransomware supplemental specifically asks whether backups are segregated/offline or immutable and whether restoration is tested. Online backups reachable with the same credentials are routinely destroyed in ransomware events, so an air-gapped or immutable copy — and evidence you've actually restored from it — is what distinguishes a recoverable business from a total loss (and a paid claim from a disputed one).

Insurers ask whether endpoints run anti-malware, and increasingly whether you run EDR/MDR (endpoint detection & response, ideally monitored) — which can detect and contain intrusions rather than just block known signatures. Coverage gaps (servers, BYOD) are a common weakness the proposal form probes.

Email is the dominant initial-access vector, so insurers ask about inbound filtering for spam, phishing and malicious attachments/links — including attachment sandboxing and link rewriting where available. The major cloud-mail platforms provide much of this natively; the question is whether it's enabled and tuned.

SPF, DKIM and an enforced DMARC policy (p=quarantine or p=reject) stop attackers forging your domain in the From address — a frequent enabler of business-email-compromise and invoice fraud. A DMARC policy of p=none (or none at all) provides no enforcement. Our scan reads these DNS records directly, so a missing or unenforced DMARC contradicts a 'we're protected against spoofing' claim — and it's the one control on this form you can fix yourself in an afternoon.

A correctly configured perimeter firewall (and host firewalls) is a baseline expectation: default-deny inbound, only required services exposed, and management interfaces not reachable from the internet. Misconfiguration — not absence — is the usual problem the proposal form is trying to surface.

Internet-exposed Remote Desktop (RDP/3389) is one of the most exploited ransomware entry points, and exposed databases (MySQL, PostgreSQL, MongoDB, Redis) or remote-admin (SSH/VNC) dramatically enlarge the attack surface. Insurers ask specifically about RDP exposure. Our exposure and in-depth scans enumerate open ports, so a sensitive service reachable from outside contradicts a claim that admin/database access is restricted.

Remote and third-party access should be brokered through a VPN or zero-trust access solution with MFA enforced, rather than directly-exposed services. Insurers probe how remote workers and suppliers/MSPs connect, since over-privileged or unprotected remote access is a frequent breach pathway.

Because social engineering precedes most claims, insurers ask whether staff receive recurring security-awareness training and, often, simulated phishing tests. The aim is a measurable reduction in click-through and an increase in reporting; some carriers bundle a training platform as a policy benefit.

Insurers expect at least a basic, documented incident-response plan: roles and contacts, escalation steps, how to engage the insurer's breach-response panel, and regulatory reporting (e.g. the ICO's 72-hour duty). Many cyber policies provide 24/7 incident response — knowing how to invoke it is part of being 'ready'.

Detection capability — endpoint/EDR alerting, cloud sign-in and audit logging, and ideally monitored detection (MDR/SOC) — determines whether an intrusion is caught early or discovered only at the ransom note. Insurers increasingly differentiate pricing and terms on detection maturity, and dwell time is a key driver of claim severity.