How to Answer the Coalition Cyber Insurance Application

Coalition’s application looks short. The agency-facing PDF is only six pages, and the core underwriting section that most SMBs care about fits on a single page.[1] That is exactly why teams underestimate it.

The danger is not the length of the form. The danger is the legal weight behind the answers.

Coalition’s own application says the form will attach to and become part of the policy, that all information must be accurate, truthful, and complete, and that a material misstatement or misrepresentation in the application or other underwriting materials can support disclaimer of claims or rescission of the policy.[1] Coalition’s broker help center also makes clear that the carrier treats the application as part of a streamlined quote-to-bind workflow; appointed brokers can quote and bind online in under four minutes, and the US fillable PDF includes the signature bundle for binding.[2]

That combination creates a familiar trap for MSPs and SMB IT leads:

• The questionnaire feels simple.
• The environment is not simple.
• The signer is making a legally meaningful statement about controls that may span Microsoft 365, VPN appliances, remote access, endpoint encryption, backup platforms, and internal finance procedures.

This guide walks through Coalition’s current agency-facing cyber application and explains what Coalition is really trying to learn, what you can verify quickly, what usually needs manual checking, and where teams get themselves into trouble. It is written for the person who actually has to get the answers right: the MSP engineer, the IT manager, the vCIO, or the operations lead supporting renewal.

Start with the legal architecture, not the checkboxes

Before getting into individual questions, three lines on the application matter more than the rest.

First, Coalition states that the application will attach to and become part of the policy if coverage is issued.[1]

Second, the signature section requires an authorized representative to declare that the application has been completed after reasonable inquiry and that the statements are true and complete to the best of that person’s knowledge.[1]

Third, Coalition explicitly reserves the right to disclaim a claim or rescind the policy if there is a material misstatement or misrepresentation in the application or in other underwriting materials, including supplemental applications and questionnaires.[1]

That is the correct mental model for the rest of the form. This is not a casual intake form. It is a representation about what is true in the environment at the time of underwriting.

The questions that are mostly business disclosure, not technical verification

Not every Coalition question requires a deep technical review. Several are still critical, but they are more about business facts and disclosure discipline than endpoint telemetry.

Q1: prior incidents, claims, or losses

Coalition asks whether the named insured experienced a cyber incident, claim, or loss in the past three years that could have been covered under similar insurance, including suspected data breaches, privacy complaints, investigations, or attempted extortion demands.[1]

The instinctive mistake is to read this too narrowly. Many organizations only disclose events that became full-blown insured losses. That is risky. The wording is broader than that. If there was a ransomware attempt, a BEC incident, a privacy complaint, or even a regulatory inquiry that plausibly fits the wording, disclose it and explain remediation. A disclosed event with remediation context is usually less dangerous than an event that looks hidden later.

Q2: awareness of circumstances that could give rise to a claim

Coalition asks whether the insured has knowledge or information regarding any fact, circumstance, situation, or event that could reasonably give rise to a claim or loss under the proposed insurance. The form then states that if such knowledge exists, any claim or loss arising from it is excluded.[1]

This is the “known facts” trap. It is not a security-control question. It is a disclosure question. If an organization already knows that a compromise may have occurred, or is in the middle of a serious incident, answering “No” because the forensic report is not complete yet is exactly the kind of thinking that turns into coverage disputes later.

Q4: PCI, PII, and PHI

Coalition asks whether the insured collects, processes, stores, transmits, or has access to payment card information, personally identifiable information, or protected health information other than its own employees’ data.[1]

Do not answer this from memory. Answer it from a data inventory conversation. If the client touches card data at all, even through integrated processors, or holds customer records, the answer is often “Yes.” The exact volume bands matter because they shape Coalition’s view of data exposure.

Q7: funds transfer controls

Coalition’s current form splits this into three parts:

• validation for funds transfer requests over $5,000,
• validation for funds transfer requests over $25,000, and
• validation for any request to change banking details.[1]

That lower $5,000 threshold matters. A finance process that was “good enough” when controls only kicked in at $25,000 may no longer fit the form. This question is not about cyber tooling. It is about operational anti-fraud procedure. If the client’s real process is “we usually call if it looks suspicious,” that is not the same as a documented secondary verification control.

Q3: device encryption

Coalition asks: “Does Named Insured implement encryption on laptop computers, desktop computers, and other portable media devices?”[1]

This is a deceptively simple question because it sounds like a policy question. In practice, it is an inventory and coverage question.

Coalition’s broker help article is interesting here because the online quoting flow describes this question as Yes/No/Sometimes, even though the current agency-facing PDF renders the paper version more simply.[2] That tells you something important: partial encryption is a known real-world condition, and Coalition knows it.

What Coalition is really trying to learn

Coalition is trying to determine whether a lost or stolen endpoint is likely to turn into a reportable data event. Full-disk encryption on company-managed endpoints materially changes that exposure profile.

What counts as defensible evidence

For Windows environments, a fast spot check is manage-bde -status, which Microsoft documents as the command for returning BitLocker protection status, encryption method, percentage encrypted, and related details.[3] At scale, Microsoft Intune’s encryption report is better because it centralizes encryption status for managed devices, and Microsoft Graph’s managedDevice resource exposes an isEncrypted property for managed devices.[4][5]

For macOS, Apple supports FileVault as the built-in full-disk encryption mechanism and explicitly documents both device-management-based control and the fdesetup command-line tool in its enterprise deployment guidance.[6]

Where people get this wrong

The usual failure mode is assuming the policy decision equals the control state. “We require BitLocker” is not the same as “all laptops are encrypted today.”

Common examples:

• new devices not yet enrolled,
• older laptops exempted from MDM,
• executive devices manually configured outside policy,
• lab or spare devices ignored because “nobody really uses them.”

If you have 50 managed endpoints and 47 are encrypted, that is not the same answer as 50 out of 50. If the answer is mixed, say so and fix it before signing.

Q5: backups

Coalition asks whether the insured maintains at least weekly backups of all sensitive or otherwise critical data and all critical business systems offline or on a separate network.[1]

This is one of the most important questions on the form because it goes straight to ransomware survivability.

Coalition’s broker help article also flags backups as one of the additional questions frequently asked in cyber underwriting.[2] On renewals, Coalition’s standard process can include a pre-filled renewal application, an updated Cyber Risk Assessment, and security findings, which means the control story around recoverability does not end when the original application is signed.[7]

If you need the technical version of this backup question, How to Prove Backup Immutability for Cyber Insurance Renewals breaks down exactly what carriers tend to mean by offline, isolated, and tested recoverability.

What Coalition is really trying to learn

Coalition is not merely asking whether backup software exists. It is trying to assess whether the business can recover if its production environment is encrypted or disabled.

There are three separate ideas bundled into this one question:

1. Frequency — are backups happening at least weekly?
2. Scope — do they cover sensitive data and critical systems?
3. Isolation — are they offline or otherwise separated so the same event cannot wipe production and backups together?

What a careful verification process looks like

Before answering “Yes,” verify all three.

Check job history, not just the configured schedule. A weekly schedule is not the same thing as a successful recent backup.

Check scope. Teams often protect file shares and M365 but forget line-of-business servers, appliances, or critical databases.

Check isolation. This is the hardest part because “separate network” can mean very different things architecturally. If the only backup target is a NAS joined to the same domain and reachable from the same compromised admin accounts, you should pause before calling that a clean “Yes.” If the design relies on cloud or off-site repositories, or on storage with immutability or strong access separation, the answer is generally easier to defend.

The restore-test problem

Coalition’s base PDF does not ask for restore-test dates. But sophisticated underwriters care about the difference between “backups completed” and “recoverability demonstrated.” If you can produce a recent restore test, you are in a much stronger position even when the form does not explicitly ask for it.

Q6: MFA — the control that causes the most trouble

Coalition splits MFA into four separate sub-questions:

• 6a Email
• 6b VPN
• 6c RDP, RDWeb, RD Gateway, or other remote access
• 6d Network/cloud administration or other privileged user accounts[1]

Coalition’s broker help article condenses the online quote flow slightly by grouping VPN and remote access together, but the agency-facing PDF is the clearer underwriting source because it forces you to think about those access paths separately.[1][2]

This is the most important section of the form.

Why Coalition splits MFA by access path

Because “we have MFA” is not a meaningful underwriting answer.

An environment can truthfully have MFA in one place and still be dangerously weak in another:

• email protected, remote desktop not protected,
• admin accounts protected, VPN appliance not protected,
• Microsoft 365 protected, third-party remote access tool not protected,
• standard users protected, exceptions quietly excluded.

Coalition is trying to determine whether the access paths attackers actually use are controlled.

Q6a: email MFA

If email is Microsoft 365, the challenge is that there is no single Microsoft report that says, in carrier language, “MFA is enforced for every user who can access email.”

Microsoft has at least four relevant evidence surfaces:

• the Security Defaults setting,
• the list of Conditional Access policies,
• the userRegistrationDetails report, which tells you who is registered and capable for MFA,
• the sign-in logs, which show how MFA requirements were actually satisfied in specific events and which policies applied.[8][9][10][11]

Those do not answer the same question.

Security Defaults are a baseline control, but Microsoft’s own documentation says they require all users to register, require administrators to use MFA every time, and require users to do MFA “when necessary” based on context like location, device, role, and task.[8] That is strong, but it is not the same thing as a custom policy you have personally reviewed for every relevant access path.

Conditional Access is more expressive, but it introduces exclusions. Microsoft documents that exclusions override includes and are commonly used for emergency or break-glass accounts.[12] The Graph policy object itself exposes excludeUsers and excludeGroups for exactly this reason.[13]

That is where many MSPs get burned. They see a policy named “Require MFA for All Users,” stop reading, and miss the exclusion group.

Then there is the userRegistrationDetails report. Microsoft’s Graph documentation is explicit that this report returns authentication methods registered for a user and properties like isMfaRegistered and isMfaCapable.[10] That is registration evidence, not enforcement proof. A user can be registered and still not be forced through MFA on the path that matters to the insurer.

Finally, sign-in logs help, but Microsoft warns that interpreting MFA correctly requires reading both the MFA details and the underlying authentication context, because some events may show as single-factor if an MFA claim was already satisfied earlier in the token flow.[11]

That is the real M365 MFA reporting gap. Microsoft gives you the ingredients. It does not give you one clean, carrier-ready answer.

Q6b: VPN MFA

If the VPN is Entra-integrated, you may be able to validate this through Conditional Access scope and sign-in events. If the VPN lives on a standalone appliance or third-party identity stack, Microsoft 365 by itself will not prove the answer.

This is a common place where teams round up to “Yes” based on intent rather than verification. If VPN MFA is enforced through Duo, Okta, or the appliance itself, verify it there. If it is not, do not let strong M365 MFA make you overstate the VPN answer.

Q6c: RDP and other remote access

Coalition is specifically naming RDP, RDWeb, and RD Gateway because those are not abstract risks. They are common ransomware ingress points.

If remote desktop is exposed and not protected with MFA, do not rationalize it. Fix it before filling out the form.

If remote access happens through Entra-aware tooling, you may be able to prove the control in M365. If it happens through standalone RDS, third-party remote support tooling, firewall rules, or vendor VPN, you need to verify those paths directly.

Q6d: privileged accounts

This question is stronger than “Do admins have MFA?” Coalition’s preferred affirmative response on the PDF is: “On administrative accounts and all cloud services where supported.”[1]

A defensible workflow here is:

1. enumerate all directory and cloud admin role holders,
2. identify shared or legacy admin accounts,
3. verify MFA on every privileged identity,
4. confirm exceptions are truly emergency-only and tightly controlled.

Microsoft’s Security Defaults guidance also recommends maintaining emergency access accounts and treating them separately, which is one reason exclusions show up in real tenants.[8][12] But “we have two break-glass accounts” is not a blank check to leave half a dozen operational exceptions outside MFA.

The control Coalition checks even when the base PDF does not spell it out: email security and external posture

Coalition’s base PDF does not ask explicit DMARC, SPF, or DKIM questions.[1] That does not mean Coalition is indifferent to email security.

Coalition’s own materials say it routinely scans an organization’s external digital footprint, including domains, IPs, ports, applications and services, data leaks, and phishing risks.[14] Coalition Control also describes ongoing monitoring of the external digital footprint and related risks.[15] On renewals, Coalition can include security findings and an updated Cyber Risk Assessment as part of the underwriting cycle.[7]

So even if the base PDF is lighter than some other carriers’ forms, do not treat email security as optional hygiene.

At a minimum, you want an externally defensible story around:

• valid MX records,
• SPF presence and sane enforcement,
• DKIM configured where supported,
• DMARC present with a meaningful policy.

That is exactly why a lightweight public scan is valuable. You can check the parts Coalition can see from outside before you ever start deeper internal control verification.

For the DNS-specific version of that workflow, see DMARC, SPF, and DKIM for Cyber Insurance.

What happens if you get the Coalition application wrong

Coalition’s form does not hide the consequence.

It says the application becomes part of the policy, requires reasonable inquiry, and reserves the insurer’s right to disclaim claims or rescind the policy for material misstatement or misrepresentation in the application or other underwriting materials.[1]

That matters for two reasons.

First, you do not need bad intent to end up in trouble. A wrong answer can still be material even if it was given in good faith.

Second, a short form does not mean a small verification burden. The shorter the form, the more likely it is that each yes/no answer is carrying a lot of underwriting weight.

A practical Coalition prep checklist

Before you send this application back, do these five things:

1. Run an endpoint encryption report
   Confirm managed Windows and macOS encryption status. Do not rely on policy intent.

2. Review backup evidence from the system of record
   Verify frequency, scope, recent success, and isolation.

3. Do an MFA reconciliation, not a portal glance
   Review Security Defaults, Conditional Access policies, exclusions, and sign-in evidence. Check VPN and remote access outside Microsoft if those paths exist.

4. Inventory privileged accounts
   Enumerate admin roles and confirm MFA for every privileged identity.

5. Review finance-side funds transfer controls
   Confirm the client really has a secondary verification process at Coalition’s thresholds, especially the $5,000 trigger.

The right way to think about this application

The Coalition application is not hard because it is long.

It is hard because each checkbox compresses a larger operational question:

• Is every relevant endpoint encrypted?
• Are backups truly recoverable after ransomware?
• Is MFA enforced everywhere the carrier asked, not just somewhere?
• Do privileged identities really have stronger control?
• Are the finance controls documented or just assumed?

If you treat the form like paperwork, you end up guessing.

If you treat it like a defensibility exercise, the workflow gets clearer: verify first, answer second.

BindLedger is built for that exact step. The public scan checks the external email-security basics Coalition can already see. The M365 workflow is designed to reconcile MFA methods, find Conditional Access exclusions, enumerate privileged accounts, and turn that work into a clean attestation record before anyone signs.

Verify before you sign

If you are preparing a Coalition submission right now, start with the fastest evidence you can gather cleanly:

• run an external email-security check for MX, SPF, DKIM, and DMARC,
• verify M365 MFA properly instead of reading one portal screen,
• and document exceptions before the application goes back to the broker.

BindLedger is built for that workflow. The free scan gives you a quick Coalition-style view of externally visible email-security posture. The M365 verification workflow is designed to handle the harder part: MFA reconciliation, privileged-account review, and evidence-backed answers before binding.