If you are filling in a cyber insurance renewal form and the underwriter suddenly asks about your web application firewall, patch cadence and MFA coverage, you are dealing with cyber insurance requirements for web applications. Insurers no longer price policies on revenue and industry alone. They scan your public attack surface, compare it against your answers, and adjust premiums, sublimits or exclusions to match. This article covers what underwriters actually check, how to prepare evidence, and where teams lose coverage without noticing.
Why Underwriters Started Looking at Your Web Stack
The ransomware wave of 2020-2021 pushed loss ratios on cyber policies high enough that carriers rebuilt their underwriting. Questionnaires that used to fit on one page grew to 10-20 pages. Most major carriers, including Coalition, At-Bay, Beazley and Chubb, now run some form of outside-in scanning before they quote, and several keep scanning during the policy period.
That scanning is mostly passive. It fingerprints server banners, checks SSL/TLS configuration, looks for exposed admin panels and matches software versions against known CVEs. A WordPress site with an outdated plugin flagged in the CISA Known Exploited Vulnerabilities catalog can trigger a request for remediation before binding. In some cases the quote is declined outright.
Core Cyber Insurance Requirements for Web Applications
Wording differs between carriers, but the same controls come up again and again for anything internet-facing. Expect questions in these five areas:
Multi-factor authentication on every administrative interface, including CMS logins, hosting control panels, cloud consoles and CI/CD platforms.
Patch management with defined timelines, usually 14-30 days for critical vulnerabilities and faster for actively exploited ones.
Vulnerability scanning on a regular schedule, with evidence that findings get tracked to closure.
Encryption in transit, meaning TLS 1.2 or higher, no expired certificates and HSTS on authenticated areas.
Tested backups stored offline or in an immutable form, with a documented restore time.
On top of that, many forms ask about end-of-life software, exposed RDP or SSH, payment page integrity and whether you have a written incident response plan. E-commerce applicants often get extra questions tied to PCI DSS 4.0. Requirements 6.4.3 and 11.6.1, which cover inventory and change detection for payment page scripts, became mandatory on 31 March 2025, and underwriters have picked up the same language.
The Myth That a Signed Questionnaire Guarantees Payout
A common belief is that once the policy is bound, the insurer pays whenever something goes wrong. It doesn’t work that way. The questionnaire becomes part of the contract, and a material misrepresentation can be grounds for rescission. In 2022, Travelers asked a US federal court to rescind a policy issued to International Control Services after a ransomware claim, arguing that the insured had stated MFA was in place when it only protected the firewall and not other access points. The case ended with the policy being voided.
The takeaway for web teams is simple. “Yes, we use MFA” has to be true for every admin path, including the forgotten staging environment and the legacy FTP account a contractor set up in 2019.
A Practical Preparation Process
An experienced application security lead treats renewal as a small audit project, not a form-filling exercise. A typical timeline starts 60-90 days before the renewal date.
Step 1 – Inventory the external surface. List every domain, subdomain, API endpoint and third-party hosted page. Certificate transparency logs (crt.sh) and DNS records usually turn up assets nobody remembers. Dangling CNAMEs pointing at decommissioned Azure or AWS resources are a frequent surprise.
Step 2 – Run the scan the insurer will run. Do an external vulnerability scan covering OWASP categories such as SQL injection, XSS, security misconfiguration and outdated components. Check security headers, TLS versions and exposed version banners too, since underwriter tools flag those immediately.
Step 3 – Fix, then document. Remediate critical and high findings first. Keep timestamped evidence such as scan reports, ticket IDs and change logs. A structured walkthrough like a full website security posture audit gives you a repeatable format for this.
Step 4 – Verify every MFA claim. Go through each login surface one by one: WordPress wp-admin, the hosting panel, the domain registrar, GitHub or GitLab, the CDN dashboard and the payment gateway. Service accounts and API keys need their own answer, because an MFA question doesn’t cover them automatically.
Step 5 – Write the incident plan down. Underwriters ask whether one exists and who owns it. A short, tested document is worth more than a 40-page template nobody has read. If you are starting from scratch, see how to build an incident response runbook for web teams.
Common Mistakes That Cost Coverage
The first mistake is answering the questionnaire from memory. A CTO ticks “patched within 14 days” because that is the policy, while the actual median for plugin updates sits at 45 days. At claim time, forensic investigators reconstruct the real timeline from server logs and version history.
The second is scanning only the main domain. Underwriter tools enumerate subdomains, so a marketing microsite on an unpatched Drupal 7 install, which reached end of life in January 2025, counts against the whole organization even if it holds no customer data.
The third is treating a vulnerability scan as a penetration test, or the other way round. Some carriers require an annual pentest for applications that process payments or health data, while others only want continuous scanning. Read the exact wording, and if you’re unsure what each term means, check the difference between vulnerability scanning and pen testing before you sign.
Edge Cases Where Standard Advice Shifts
Teams under 10 people with a single brochure site often qualify for simplified small-business policies with short questionnaires. That lowers the paperwork, but the external scan still runs, and an exposed admin login can still raise the premium.
Healthcare, finance and companies in scope for the EU NIS2 Directive face stricter expectations, including documented risk assessments and supplier security reviews. Air-gapped or on-premises internal applications usually fall outside web-facing questions, but the VPN or portal that reaches them does not. Fully managed SaaS platforms like Shopify shift infrastructure patching to the vendor, but your own apps, scripts and admin accounts remain your responsibility on the form.
FAQ
Do insurers really scan my website before issuing a policy?
Most mid-market and larger carriers do. They use passive external scanning to check software versions, TLS configuration, exposed services and known vulnerabilities, and some repeat the scan during the policy term.
Can a claim be denied if a vulnerability existed when I bought the policy?
Not automatically. A denial or rescission is more likely when the application form misstated your controls, for example by claiming MFA or patch timelines that weren’t actually in place.
How often should I scan to meet insurer expectations?
Quarterly scanning is a common minimum in policy wording, but weekly or daily scanning gives you much stronger evidence and catches newly disclosed CVEs before an underwriter or attacker does.
Summary
Cyber insurance requirements for web applications come down to provable controls: MFA everywhere, patching on a defined timeline, regular vulnerability scanning, solid TLS and a written response plan. Underwriters check what they can see from the outside, and claims adjusters check everything else after the fact. The most useful step you can take is to run the same external scan an insurer would, 90 days before renewal, so every answer on the form matches what you can actually prove.