Our cyber-insurance renewal asked for a WAF, MFA and tested backups
The questionnaire is longer than last year and the broker says the answers have to be true. What the underwriter is actually checking, which controls carry weight, how to produce the evidence, and why saying yes to something that is not true is the expensive option.
The renewal used to be a form with six questions and a signature. This year it is nine pages. It asks whether you have multi-factor authentication on email, remote access and admin accounts, whether your backups are immutable and when you last restored one, whether there is endpoint detection on every machine, whether the website sits behind a web application firewall, and whether you can prove any of it. Your broker says the premium depends on the answers, and that the answers have to be true, because a claim gets denied when the reality does not match the form.
I ran this remediation across a whole client portfolio as the director of web technology and security at an agency, and I have filled in more of these questionnaires than I would like. Here is how to read one and what to do with it.
What the underwriter is actually checking
The questionnaire looks like a security audit. It is a risk model. The underwriter has a short list of controls that, in their claims data, separate the companies that pay out from the ones that do not. Everything on the form maps back to that list.
| What they ask | What they mean | How much it weighs |
|---|---|---|
| MFA on email, VPN, remote desktop and every admin login | Can a stolen password alone get someone in? | The most. Many carriers will not write the policy without it |
| Endpoint detection and response on every workstation and server | When ransomware runs, does anything notice and stop it? | Nearly as much. Antivirus from a decade ago does not count |
| Backups that are offline or immutable, with a restore tested and dated | When ransomware deletes the backups first, is there still a copy? | A lot. “We have backups” with no restore date is read as “we hope we have backups” |
| Patching cadence for operating systems, applications and the website platform | How long does a known hole stay open? | Moderate. They want a process, with a number of days |
| A WAF and DDoS protection in front of the website | Is the public site a way in, and will it stay up? | Moderate, higher if the site takes orders or holds data |
| Email authentication: SPF, DKIM, DMARC | Can someone send email as you? | Moderate. It is cheap and its absence says something |
| Privileged access: who is an admin, and is that reviewed | How many keys to the building exist? | Moderate |
| An incident response plan, with names | When it happens, does anyone know what to do? | Moderate, rising |
| Security awareness training | Will someone click the link? | Lower, but asked every year |
| Vendor and third-party access | Who else can get in? | Lower, rising for anyone with integrations |
The pattern is that identity, endpoints and backups are the floor. Everything below them adjusts the premium. Everything above them decides whether you get a policy at all.
Where the trouble starts
The trouble is the yes that is nearly true. MFA is on for email but not for the hosting account. Backups exist but nobody has restored one since the system was set up. The WAF was turned on by whoever built the site, in a mode that logs and blocks nothing. The admin list has four people who left.
Each of those is a yes on the form and a no in reality, and the gap is where claims get denied. The insurer’s investigators are good at finding it, because after an incident the evidence is all over the logs. The questionnaire is, in effect, a sworn statement about your systems. Treat it like one.
The first 48 hours
- Translate the questionnaire into a list of actual controls on your actual systems. One line per question, with the system it applies to, and an honest pass, fail or unknown next to each.
- Find out who holds what. Hosting, DNS, the website platform, email, the backup tool, the endpoint software. Half of the unknowns are unknown because nobody is sure who has the login.
- Mark the deadline and work backward. Renewals have dates. The floor controls come first because they take the longest to roll out across people.
- Stop anyone from answering yes to something unverified. A late answer costs a conversation with the broker. A false one costs the claim.
What the remediation looks like
This is the sequence on the process page, with the gates. In practice it runs in the order the underwriter weighs things.
Identity first. MFA on every account that can change anything, including the hosting panel, the domain registrar, the DNS provider, the website admin and the payment processor. This touches people, so it is scheduled, with a week of support while everyone enrols. Then the access review: every admin account that belongs to someone who left is removed, and the list is written down with a date.
Backups second. A backup that has never been restored is a theory. The fix is a restore, done for real into a separate environment, timed, and recorded. If the backups can be deleted by the same credentials that run the system, they are not immutable, and the tool or the configuration changes until they are.
Then the website. For most businesses that means Cloudflare or an equivalent in front of it, with the firewall actually in blocking mode, rate limits on login and forms, security headers that pass an external check, and a patching routine for the platform and its plugins. I have written elsewhere about what a form should do when someone submits it; the security half of that is the same work.
Then email authentication, which is an afternoon of DNS and stops a whole class of fraud that insurers see constantly.
Then the paperwork: an incident response plan with real names and phone numbers, a one-page patching policy, and a vendor list.
The evidence pack
The underwriter does not want your word. They want a screenshot of the MFA policy, a configuration export from the firewall, the restore log with a date, the DMARC record, the admin list with the review date. I assemble these into one pack, organised by the question they answer, so the person at the insurer who reads it can tick the boxes without emailing your broker four times.
Keep the pack. Next year’s questionnaire is the same questionnaire with two new questions, and most of the evidence only needs a fresh date.
Where it goes wrong
Three things, repeatedly.
The first is buying a tool to answer a question. An EDR licence that is installed on half the machines is a fail that cost money. The control is the coverage, and the evidence is the console showing every endpoint.
The second is the person who holds the keys. A business where one external developer has the only admin login to the site, the host and the domain is a business the underwriter will price accordingly, and for good reason. Access has to be yours, with the developer as a named user you can remove.
The third is answering the questionnaire from memory. Memory says MFA is on. The hosting panel says otherwise.
What it is worth
A renewal with honest yes answers on the floor controls is cheaper than one with gaps, and far cheaper than one with a denied claim behind it. The remediation itself is usually a few weeks of work spread across people and systems, most of it configuration, some of it conversations. The pack at the end is what turns next year’s nine pages into an afternoon.
If the questionnaire has landed and the answers are not all yes yet, that is the normal starting point. The mistake is signing it anyway.