A cyber insurance application asks a business to answer questions about its cybersecurity controls. An answer, however, is not the same thing as an implemented and supportable control. The application asks whether multifactor authentication is enforced. The underwriter may want to know whether that answer holds up: for which users, on which systems, and with what evidence behind it. The distance between those two things is where most underwriting problems begin.
This article describes the cyber insurance requirements a business should expect to encounter, the control areas that appear most often, and the difference between stating that a control exists and being able to prove that it is implemented across the relevant environment. It is written for business leadership, not for insurance professionals, and it does not attempt to describe any single carrier's program.
Requirements are not uniform across carriers
There is no universal checklist of cyber insurance requirements. What a carrier asks for, and what it requires as a condition of coverage, depends on the carrier itself and on the account in front of it. The National Association of Insurance Commissioners has documented a market in which underwriting has tightened and insurers increasingly expect applicants to maintain specific security controls, but the specific expectations differ from one insurer and one policy to the next.
The variables that shape requirements include:
- The carrier and the specific policy form
- The industry and its typical exposure
- Revenue and employee count
- The policy limits requested
- The sensitivity and volume of the information held
- Prior incidents and claims history
- The technology environment, including cloud services and remote work
- Operational technology in manufacturing and industrial settings
- The overall risk profile the underwriter assigns to the account
A ten-person professional services firm requesting modest limits will face a different set of questions than a multi-site manufacturer requesting higher limits after a prior incident. Both are real underwriting processes. Neither defines what every business must do. When a specific carrier publishes the controls it emphasizes, that publication describes one insurer's program, not an industry mandate.
Requirements also arrive through more than one channel, and a business should recognize each of them. The application itself is the first channel. Supplemental questionnaires, often specific to ransomware or to particular controls, are the second. The third is underwriting correspondence after submission: a deficiency notice, a request for evidence, or a quotation conditioned on completing specific work. Some carriers also run external scans of internet-facing systems during the underwriting period, which means a requirement can effectively arrive as a scan finding the business must explain or fix. A requirement communicated in any of these forms carries the same practical weight, because each one stands between the account and the coverage decision.
The control areas that appear most often
Certain control areas recur across applications and supplemental questionnaires because they correspond to the loss patterns carriers actually pay for: ransomware, business email compromise, and funds-transfer fraud. For each of the areas below, the underwriting question is rarely whether the business has heard of the control. The question is whether the control is implemented across the relevant environment and whether the business can support that claim.
Multifactor authentication
Saying it exists: the business has MFA on email. Proving it: identifying every system the carrier's question reaches, including email, remote access, administrative accounts, and critical cloud services, and showing enforcement reports from the identity provider for each. Partial MFA coverage answered as an unqualified yes is one of the most common gaps an assessment finds.
Endpoint detection and response
Saying it exists: the MSP deployed an EDR product. Proving it: an endpoint console report showing agent coverage against a current asset inventory. EDR installed on office laptops but absent from servers, shop-floor machines, or unmanaged devices is coverage in name rather than in operation.
Backups and restoration testing
Saying it exists: everything is backed up. Proving it: backup job logs, a description of what is included and excluded, evidence of isolation or offline copies where the application asks about them, and records of an actual restoration test. A backup that has never been restored is an assumption. Many questionnaires now ask about testing directly.
Privileged and administrator accounts
Saying it exists: only IT has administrator access. Proving it: a current list of privileged accounts across domain, local, cloud, and application tiers, showing who holds them, whether any are shared, and whether MFA applies. Shared administrator credentials and forgotten service accounts routinely contradict this answer.
Remote access
Saying it exists: remote access goes through the VPN. Proving it: a complete inventory of remote access paths, including VPN, remote desktop tools, vendor support connections, and MSP management tools, with the authentication controls on each. Remote access that was never inventoried cannot be accurately represented.
Email security
Saying it exists: the mail platform has filtering. Proving it: the configuration of anti-phishing and anti-spoofing controls, such as SPF, DKIM, and DMARC, and any advanced filtering in use, shown from the actual tenant rather than from a product brochure.
Patch and vulnerability management
Saying it exists: systems are patched automatically. Proving it: patch compliance reports across servers and endpoints, the handling of systems that cannot be patched, and vulnerability scan results with evidence that findings are tracked to closure. External scan services used by carriers frequently surface the gap between the automatic-patching answer and the observable state of internet-facing systems.
Security awareness training
Saying it exists: employees receive training. Proving it: completion records tied to the current employee roster, the training content, and the schedule. Training that occurred once, years ago, for some employees, is difficult to represent as a current program.
Incident-response planning
Saying it exists: there is an incident-response plan. Proving it: the plan itself, with named roles, current contact information, and some evidence it has been reviewed or exercised. A template downloaded and never assigned is a document, not a capability.
Encryption
Saying it exists: data is encrypted. Proving it: which data, where, and how. Full-disk encryption on laptops, encryption of backups, and transport encryption are separate questions, and an unqualified yes usually blends them together.
Logging and monitoring
Saying it exists: systems keep logs. Proving it: which logs are collected, from which systems, how long they are retained, and whether anyone reviews them or receives alerts when something abnormal occurs. Default logging that overwrites itself in days, on systems nobody watches, is technically logging. The question behind the question is whether an intrusion would be noticed while it is happening, and the honest answer depends on retention, coverage, and a human or service on the receiving end.
Vendor and MSP controls
Saying it exists: the MSP handles security. Proving it: the service agreement showing what the provider is actually responsible for, the provider's access method into the environment, and the controls on that access. The MSP's own remote access is part of the attack surface the underwriter is evaluating, and the same applies to any other vendor with a standing connection: software support firms, equipment manufacturers, payroll processors, and building system integrators. An accurate answer requires a list of those connections, which many businesses have never compiled.
Funds-transfer verification
Saying it exists: accounting is careful. Proving it: a written procedure requiring out-of-band verification for payment instruction changes, and evidence that staff follow it. This control corresponds directly to business email compromise losses, which is why it appears on so many applications.
What evidence looks like in practice
None of the proof described above requires exotic tooling. It requires the business to know its own environment and to retain ordinary records. Typical evidence includes:
- Configuration exports from firewalls, identity providers, and mail platforms
- Identity-provider MFA enforcement reports
- Endpoint-console coverage reports matched to an asset inventory
- Backup job logs and restoration-test records
- Vulnerability scan reports with remediation tracking
- Records of incident-response reviews or exercises
- Privileged account and access lists
- Network diagrams that match the environment as built
- Written policies and procedures that match daily practice
- Training completion records
- Vendor and MSP contracts describing security responsibilities
- Security monitoring or alerting reports
The pattern across all of it is the same: the evidence must describe the environment as it operates, not the environment as it was planned. Guidance from CISA's Cross-Sector Cybersecurity Performance Goals and the NIST Cybersecurity Framework covers most of these areas, which is one reason a business that has organized itself around a recognized framework usually finds the insurance questionnaire easier to support.
Who is responsible for what
Underwriting problems often persist because no one in the transaction owns the technical facts. The roles are distinct. Management owns the application and the accuracy of its answers, because the application is a representation made by the business. The broker manages the insurance relationship, communicates the carrier's questions and requirements, and returns material to underwriting; the broker is not positioned to validate technical controls inside the client's environment. Internal IT and the MSP operate the controls and hold most of the raw evidence, but they are describing their own work when they answer, which is why their statements are a starting point rather than an independent conclusion. The underwriter evaluates the account and retains sole authority over coverage, premiums, limits, and exclusions.
The gap in that structure is independent validation: someone whose job is to determine what the environment actually supports, without a stake in the answer. Internal IT and the MSP are describing their own work when they answer, which is not a criticism; it is simply the reason their statements begin the inquiry rather than end it. The broker cannot fill the gap without stepping outside the insurance role. Management can fill it only to the extent it has the technical depth and the time, which in most small and midsize businesses it does not. This is the specific space an independent reviewer occupies, and it is the reason underwriters distinguish between what an applicant asserts and what an applicant can demonstrate.
When an independent assessment is appropriate
Most businesses do not need outside help to complete an application. The triggers for professional assistance are specific:
- Management cannot determine whether its technical answers are fully supported
- The carrier has issued a deficiency notice or requested additional evidence
- The quotation came back conditional, restricted, or declined
- External scan findings conflict with the application answers
- The environment spans multiple locations, operational technology, or legacy systems
- Responsibility between the MSP and the business is unclear
- The renewal questionnaire has become materially harder than the last one
In those situations an independent review establishes the current state, identifies which requirements the environment actually meets, and defines the remediation work that stands between the account and a supportable submission. The process that follows a broker referral is described in What Does a Cyber Insurance Audit Actually Examine?, and the practical mechanics of answering the form itself are covered in How to Complete a Cyber Insurance Questionnaire Without Guessing and The Cyber Insurance Application Is Asking for Evidence, Not Assurances.
The Cyber Insurance Readiness Assessment exists for exactly that situation: an independent, evidence-based review of the controls affecting underwriting, a remediation roadmap, and validation of the completed work, documented in a report the business and its authorized broker can return to the carrier. The carrier retains the underwriting decision in every case.