By Ryan Windt | Head of Growth Marketing | Updated April 2026
Most businesses treat a cyber insurance application the way they treat a software end-user license agreement. Scroll through it, check the boxes, and move on. It is a form. It will get approved. The policy will show up in email.
That approach works right up until you have a claim. Then the carrier opens an investigation, compares your application answers to what forensics actually found in your environment, and the conversation changes.
Claim denials in cyber insurance are rarely about the incident itself. They are almost always about the application. What you said you had. What you actually had. And the gap between the two.
This guide explains what carriers are actually verifying when they underwrite your policy, where the most common misrepresentation problems occur, and how to fill out an application in a way that protects your coverage when you need it.
Why the Application Is a Legal Document, Not a Questionnaire
When you sign a cyber insurance application, you are making representations to the carrier. Those representations become part of the insurance contract. If a material representation turns out to be false, even if the inaccuracy was unintentional, the carrier has grounds to deny your claim, rescind the policy, or both.
This is not unique to cyber insurance. It applies across all lines of coverage. What makes cyber different is that carriers now have tools to verify your answers in ways that were not available five years ago. External vulnerability scans, post-loss forensic reports, and third-party risk intelligence all give underwriters visibility into your actual security posture, not just the one you described on page three of the application.
According to Corvus Insurance, approximately 73 percent of carriers now conduct external scans on applicant networks as part of the underwriting process. That scan happens before your policy is issued. A second one can happen after a loss. If those two snapshots tell different stories, the denial conversation starts.
The lesson is direct: the cyber insurance application is not a hurdle to clear. It is a binding description of your security environment that will be referenced if you ever file a claim.
The Controls Carriers Ask About Most
Cyber insurance applications have converged on a set of core controls. The exact questions vary by carrier, but the underlying requirements are largely consistent across the market. These are the areas where misrepresentation issues most commonly arise.
Multi-Factor Authentication
MFA is the most commonly asked about control on every cyber application in the market. Carriers ask about it because it is the single most effective mitigation against credential-based attacks, which remain the primary entry point in most breach scenarios.
The question is almost never “do you have MFA?” It is much more specific than that. Carriers want to know where MFA is enforced, which systems it covers, and whether privileged accounts are included. Common application language looks like this:
- Is MFA enforced for all users accessing email remotely?
- Is MFA enforced for all administrator and privileged accounts?
- Is MFA enforced for all remote access tools including VPN and RDP?
- Is MFA enforced for cloud platforms and SaaS applications?
The most common misrepresentation pattern is answering yes to these questions based on partial implementation. MFA is enabled for email but not for the VPN. It is enforced for most users but not for service accounts or legacy admin credentials. It was deployed two years ago and nobody has audited coverage since.
After a breach, forensics will map exactly which accounts lacked MFA and whether that gap contributed to the incident. If it did, and the application said MFA was enforced everywhere, the carrier has a documented basis for denial.
The City of Hamilton in Canada learned this the hard way. Following a ransomware attack, their carrier denied an $18 million claim after forensics showed MFA had not been fully implemented across affected systems, despite representations on the application that it had been.
What to document: Run a report from your identity provider or MFA platform showing enrollment status by account type. Capture screenshots showing MFA policies applied to remote access, admin accounts, and cloud platforms. Keep that documentation dated and on file before you submit your application.
Endpoint Detection and Response
EDR is the second most scrutinized control after MFA. Carriers ask not just whether you have it, but where it is deployed and who is monitoring it.
The typical application questions are:
- Do you have EDR deployed on all endpoints and servers?
- Is EDR actively monitored, either by internal staff or a managed security provider?
- What percentage of endpoints have EDR installed?
The misrepresentation risk here is scope. EDR is installed on employee laptops but not on servers. It is deployed on devices managed by IT but not on contractor devices or remote worker machines that connect to the network. Coverage is 80 percent when the application implied 100 percent.
Post-loss forensics will pull a full inventory of devices in the environment and check EDR agent status on each one. Devices without EDR where the attacker moved laterally become exhibit A in the denial conversation.
What to document: Export a deployment report from your EDR platform showing agent status across all managed endpoints and servers. If coverage is not at 100 percent, know why before you fill out the application and be prepared to explain it accurately.
Backup Integrity and Immutability
Backup questions on cyber applications have gotten significantly more detailed over the past two years. Carriers no longer just want to know whether you have backups. They want to know whether those backups are protected from the same attack that could hit your primary systems.
Application questions in this area typically include:
- Do you maintain offsite or cloud-based backups?
- Are backups stored with immutability or object lock enabled?
- Are backups tested through periodic restore drills?
- Are backup systems segmented from your primary environment?
The failure mode here is backing up consistently but not protecting the backups. Ransomware operators know that the first thing to do after gaining access is to find and destroy or encrypt the backup environment. If your backups live on the same network with the same credentials as your primary systems, they are not protected. Carriers know this and ask about it specifically.
If your application says you have tested immutable backups and forensics after a ransomware event shows that your backups were encrypted along with everything else, the carrier will ask why.
What to document: Capture screenshots of object lock or immutability settings in your backup platform. Document your most recent restore test with a dated log. If you use a cloud backup provider, get written confirmation of their immutability settings.
Remote Desktop Protocol and External Exposure
RDP exposed to the internet is one of the most common ransomware entry points and one of the most common application misrepresentation issues. Carriers ask whether you have open RDP access and expect the answer to be no, or that it is tightly controlled behind a VPN with MFA.
Carriers who run external scans at underwriting can detect exposed RDP directly. If their scan finds an open RDP port and your application said you do not have externally exposed remote access, that discrepancy exists in the file before your policy is even issued.
What to document: Have your IT team or MSP run an external scan of your environment before you submit an application. Know what is visible. If RDP access exists, know exactly how it is controlled and document the access policy.
Privileged Access Management
PAM has moved from a nice-to-have to an explicit underwriting question at a growing number of carriers. The question typically focuses on whether standing administrative access is limited, whether privilege is granted on a just-in-time basis, and whether admin credentials are stored in a privileged access management solution.
This is an area where many organizations are still catching up, and carriers are beginning to use PAM posture as a pricing signal even when it is not yet a hard requirement for coverage.
What to document: If you have a PAM solution, document which privileged accounts it manages and whether standing admin access has been eliminated for critical systems. If you do not yet have a formal PAM program, be honest on the application and be prepared for it to affect your pricing.
The Late Reporting Problem
MFA gaps and misrepresented controls are the most common technical reasons for claim denial. Late reporting is the most common procedural one.
Cyber policies are claims-made policies, and most of them require you to report an incident within a specific timeframe after discovery. That window varies by policy but is often 30, 60, or 90 days from when you knew or should have known about the incident.
“Should have known” is broader than it sounds. If your systems sent alerts that went unreviewed for three weeks before anyone noticed the active intrusion, the carrier may argue that the discovery date was three weeks earlier than you reported. If you investigate an incident internally for 45 days before notifying the carrier, and the policy requires 30-day notice, coverage may be jeopardized for the costs incurred during that gap.
What to do: Know your reporting window before an incident occurs. Make sure the person responsible for filing a claim knows where to find the policy, what the notice requirement is, and who at the carrier to contact. When in doubt, report early and update with information as it becomes available. Late notice is far more damaging to coverage than a preliminary report with incomplete details.
How to Approach the Application the Right Way
The businesses that have the fewest problems at claim time treat the cyber insurance application as an audit, not a form.
Before filling out an application or renewal, run through these steps.
Verify, do not assume. Do not answer questions about MFA, EDR, or backup coverage based on what you think is true. Pull the actual data. Export the actual reports. If you cannot generate documentation that supports your answer, that is a signal that your answer may not be accurate.
Involve the people who actually manage the systems. In most small and mid-size businesses, the person filling out the cyber insurance application is not the person who manages the IT environment. That creates a reliable gap between what gets attested and what is actually in place. Loop in your IT team, your MSP, or your security provider before you submit answers on their behalf.
Document what you have at application time. Create a simple file that captures the state of your key controls at the time you submit the application. MFA coverage reports. EDR deployment exports. Backup configuration screenshots. Restore test logs. Date and save all of it. If a claim is ever investigated, having contemporaneous documentation of your control posture at application time is the single most valuable thing you can have.
Disclose open issues rather than hoping they go away. If you had an incident in the past 24 months, disclose it. If you know about a vulnerability you have not yet remediated, disclose it. If you are aware of a third-party notification about potentially compromised credentials, disclose it. Carriers price known issues into the policy. They deny claims over undisclosed ones. The asymmetry strongly favors transparency.
Treat your policy as a living document. If your security environment changes materially after you bind coverage, including if you lose MFA coverage on a class of accounts, if EDR deployment drops significantly, or if you change backup providers, notify your carrier or broker. Policies have conditions that require mid-term notification of material changes in risk. Letting a significant change go unreported is the same class of problem as misrepresenting it on the original application.
What Happens During a Claims Investigation
When you file a cyber insurance claim, the carrier will engage a forensic firm to investigate the incident. That investigation is thorough, and it is not limited to the incident itself.
Forensics will typically map how the attacker gained initial access, how they moved laterally through the environment, which accounts they used, which systems they compromised, and when each step occurred. That map will then be compared against your application.
If the attacker entered through an account that lacked MFA and your application said MFA was enforced on all accounts, that comparison happens. If they found your backup environment accessible from the same compromised credentials and your application said backups were immutable and isolated, that comparison happens.
The forensic report does not just inform remediation. It informs the coverage determination. Understanding that before you fill out an application is the most useful thing you can do to protect your claim.
The Bottom Line
Getting cyber insurance is not the goal. Having coverage that actually pays when you need it is the goal. Those are not the same thing if the application that created the policy does not accurately reflect your security environment.
The application questions are not difficult to answer accurately. They require a bit more work than checking boxes, but the work is the same work you should be doing anyway to maintain a documentable security posture. Pull the reports. Verify the coverage. Save the documentation. Disclose what you know.
If you want help understanding what underwriters are actually looking for and how your current environment measures up before you apply, we can typically turn around a quote in under 24 hours. You will know exactly where you stand before you sign anything.