This describes technical controls that commonly appear in underwriting questionnaires and why they are asked. It is not insurance, legal or broker advice, and it is not a statement about what any particular insurer requires or will pay. Policy terms vary enormously; read yours, and take professional advice on coverage.
Why the questions got specific
Cyber insurance underwriting used to be broad and qualitative. It is now narrow and technical, and the questions have converged across the market to a recognisable set.
The reason is that insurers accumulated claims data and worked out which controls correlate with claims that do not happen. The questionnaire is not a security framework and does not claim to be one — it is a set of proxies that have predictive value at portfolio scale.
That distinction is worth holding onto. Answering the questionnaire well is not the same as being secure, and being secure is not the same as answering it well. But the overlap is substantial, and the questions are a useful mirror because they were chosen by people paying for the consequences.
The controls that recur
Multi-factor authentication, and specifically where. Early questionnaires asked whether MFA was in use. Current ones ask where: remote access, email, privileged accounts, and administrative access to backups. Those four are asked separately because claims analysis found them individually predictive. Answering "yes, broadly" to a question that expects four specific answers is the most common way to create a problem later, since a claim will establish precisely which systems had it.
Backups, and whether they are reachable. The question is rarely "do you back up". It is whether backups are offline or immutable, whether they are in a separate trust domain, and when a restore was last tested. Each clause exists because ransomware operators target backups first, and a backup reachable with production credentials has repeatedly proved to be part of the loss rather than the recovery from it.
Endpoint detection and response, with coverage. Not whether a tool is licensed but what proportion of endpoints and servers it actually runs on. Partial deployment is normal and is worth stating accurately, because the gap is where an incident starts.
Email security. Phishing remains the dominant entry vector for the claims insurers see, so questions cover filtering, attachment handling, external-sender marking and domain authentication.
Privileged access management. Whether administrative rights are standing or granted on request, how many accounts hold them, and whether their use is logged separately.
Patching, expressed as a window. Not whether you patch but how quickly critical internet-facing vulnerabilities are remediated, which is a question about process rather than intent.
Network segmentation. Whether a compromise of one segment reaches everything — flat networks turn single compromises into total ones, which is visible in loss data.
An incident response plan that has been exercised. The word doing the work is "exercised". An untested plan is a document, and insurers have learned to ask when it was last run.
End-of-life software. Whether unsupported operating systems or applications remain in production, and where.
Answer carefully, in writing
The most consequential advice here is procedural rather than technical.
Answers on a proposal form may be relied upon by the insurer. If an answer is inaccurate — even through optimism or ambiguity rather than intent — that can become a coverage dispute at the worst possible moment. "MFA on remote access" means something specific; a deployment with an exception for a legacy VPN used by one vendor is a different answer, and the honest version is the one you want on file.
Where a control is partial, say so and describe the gap. Underwriters see partial deployments constantly; what they cannot price is a surprise. A qualified answer with a remediation date is ordinary. A confident answer that turns out to be wrong is a problem.
Keep evidence for the answers you give — configuration exports, coverage reports, the date of the last restore test and the last tabletop. If a claim occurs, that evidence is what turns an assertion into a fact.
Using the questionnaire as a roadmap
The list above is a reasonable prioritisation for an organisation without one, which is an underappreciated use of it. It is short, it is specific, and it was assembled by people with financial exposure to being wrong.
It is not sufficient. It says little about application security, cloud identity, supply chain or data governance, all of which produce incidents. It skews toward controls that are auditable from outside rather than toward everything that matters.
Treated as a floor, it is a good one. Treated as a definition of adequate security, it will leave the parts of your estate the questionnaire does not ask about exactly as they are.