At 4:40 on a Thursday afternoon, the controller of a 60-person marine contractor had a nine-page ransomware supplemental open on one monitor and an email from the broker on the other. The quote expired in six days. Question 7 asked whether multi-factor authentication was required for remote access to the network, including VPN. She knew roughly eighty percent of the answer. Microsoft 365 — yes. The VPN — yes, since March. The backup appliance's service account, the emergency administrator credential nobody had signed into in fourteen months, and the estimating package the field crews ran on tablets — she had no idea, and the one person who would know was offshore until Monday.

She selected "Yes" — because the form gave her a radio button and not a paragraph, and because "No" felt like a lie in the other direction. Both instincts were reasonable. Neither is what the underwriter was asking for.

Is a partial yes a lie?

That is the question, and almost nobody writes about it. Published advice on cyber applications is either "answer honestly" — which is not advice, it is a moral position — or a list of controls to buy. The real situation of nearly every business under 200 people is that the true answer to most of these questions is "mostly, with three exceptions, two of which are deliberate."

Give the format its due first. The yes/no structure is not a trap. It exists because an underwriter has to compare your risk against several thousand other submissions, and prose does not compare. A binary forces a specific factual claim instead of a paragraph that can be read four ways later. That is a real virtue.

It is also asking a question with a scope you have not defined. "Required for all remote access" contains two words doing quiet work. Required is a statement about policy configuration, not deployment — a control can be required and still have an exclusion group. All is a statement about a denominator you may never have counted.

The three ways an honest business gets this wrong are consistent across every question on the form:

  • You answer for the systems you think about. Microsoft 365 and the VPN are what anyone pictures when they read "remote access." The RMM tool, the vendor's support tunnel into the phone system, the internet-facing backup console, and the ERP web portal are also remote access, and none of them came to mind.
  • You answer for the intent rather than the state. The policy says MFA is required. Six accounts are in the exclusion group because they broke something in 2023 and were never revisited. The intent is true. The state is not.
  • You answer for today without knowing when today started. You turned MFA on for the VPN in March. The application was signed in January. If a claim turns on when the control existed, "we have it" and "we had it then" are different sentences.

What evidence proves the answer was true on the day you gave it

At claim time, nobody asks whether you are secure. They ask whether a specific representation on a specific form was accurate on a specific date. That is an evidentiary question, and evidence has to be captured before you need it.

For the identity questions, that means a timestamped export of the conditional access or MFA policy set — policy names, who they apply to, and critically, the exclusion groups and their membership. It means a sign-in log sample showing the authentication method actually satisfied, not merely required. Screenshots taken during application week and filed alongside the application are worth more than a perfect configuration you can only demonstrate today.

The accounts that genuinely cannot do MFA

Here is where "just turn it on everywhere" stops being possible.

Microsoft's own documentation on workload identities — the service principals behind your backup connector, your line-of-business integrations, your automation — states the limitation plainly: they "can't perform multifactor authentication." They authenticate with secrets or certificates. There is no phone to prompt. The correct handling is not MFA; it is credential rotation, scope restriction, and conditional access on IP range or risk where licensing allows.

The break-glass account is the same problem inverted. Microsoft's guidance for emergency access accounts is to exclude them from conditional access policies that block or restrict sign-in, because an emergency account subject to an MFA requirement "might be unusable during the exact emergency scenarios it's designed for." The current recommendation is to protect those accounts with a phishing-resistant credential — a FIDO2 passkey or certificate-based authentication — held separately from your normal admin factor.

So the security best practice and the application question point in opposite directions. You have deliberately excluded an account from MFA enforcement, on the vendor's advice, and the form has no box for that. Which is exactly why the right answer is neither a bare "yes" nor a bare "no."

"Deployed to all endpoints" has a denominator problem

Real forms differ here in a way that matters. Some ask yes/no: does the applicant use an endpoint detection and response tool "on all endpoints." Others want a number — one widely used proposal form lists EDR among monitoring options, then asks the applicant to "provide percentage of endpoints covered by EDR, MDR, or XDR above."

The percentage version is harder and more useful, because it forces the denominator into the open. Most EDR consoles report enrolled devices, not actively reporting devices. A machine onboarded in 2023, broken by an OS upgrade, and silent since February still appears in the inventory. Read the top-line count and your coverage looks like 100 percent. Filter by last-seen within seven days and reconcile against your actual asset list, and you get the number the underwriter is buying.

Three failure modes: counting workstations and forgetting servers; trusting the console total instead of reconciling it against an independent asset inventory; and counting devices that are enrolled but silent. The evidence you want is a dated CSV export of the agent inventory with last-seen timestamps, checked against a device list from a different system.

Offline, immutable, and air-gapped are three different words

Carriers use these as if they were synonyms. They are not, and the differences are the whole point of the control.

Air-gapped has a formal definition. The NIST glossary, drawing on CNSSI 4009, describes an air gap as an interface where two systems "are not connected physically" and "any logical connection is not automated" — data crosses only manually, under human control. Tape that leaves the building qualifies. A cloud bucket does not, whatever the marketing says.

Offline is looser, and usually means the backup target is not continuously mounted or reachable from the production domain. Meaningful against an attacker holding domain admin, but it is a network statement, not a storage guarantee.

Immutable is a storage-layer property with grades almost nobody checks. S3 Object Lock in governance mode can be overridden by anyone holding the s3:BypassGovernanceRetention permission; in compliance mode, a protected version "can't be overwritten or deleted by any user, including the root user." Azure's time-based retention behaves the same way — an unlocked policy can be shortened or deleted, while a locked policy cannot be deleted and its retention cannot be decreased.

That distinction is not academic. Governance mode and unlocked policies fall to a sufficiently privileged account — the exact account a ransomware operator spends three weeks acquiring. If your "yes" on immutability rests on an unlocked policy, the word is true and the protection is not. One proposal form handles this well, asking how backups are protected and offering three checkboxes: immutable or WORM technology; completely offline or air-gapped and disconnected from the network; and cloud-hosted backups segmented from the network. Check the one that is true.

A related question appears on several forms and catches nearly everyone: does the applicant require MFA for access to the backup environment. Read that again against the service account problem above.

The questions with dates in them

Patch cadence, end-of-life software, and training frequency are the same question in different clothes. Each asks you to certify a rate, and rates decay quietly.

  • Patching. Forms ask whether critical patches are installed within a stated window — thirty days is common — or ask your target time to deploy the highest-priority patches. The honest failure is answering for your workstation policy while firewall firmware, the hypervisor, and the NAS sit outside the patching tool entirely.
  • End-of-life software. Better forms skip yes/no entirely; one asks the applicant to "please outline your use of end-of-life or unsupported hardware, software, or systems." That free-text box is an invitation, not a trap. The Server 2012 box running the machine controller is not disqualifying. Failing to mention it is.
  • Training. The question is frequency, and the evidence is a completion roster with dates and names, not a receipt for a training subscription. Enrollment is not completion.
  • Privileged separation. One form asks whether network administrators have separate accounts for regular and privileged access "with separate login, password, and authentication." If your IT provider reads email and holds domain admin on the same account, the answer is no — and you want to know that before a claim does.

A qualified yes with an exception schedule beats an unqualified yes

On most of these questions, the honest answer for a real small business is: yes, with a documented exception schedule attached.

That is not hedging, and it is a stronger position than an unqualified yes for structural reasons. An unqualified yes is a single claim that is either true or false. A yes with an attached list of five named exceptions — the account, the reason, the compensating control, the remediation date — is a claim you can show you made accurately, because you disclosed the very facts that would otherwise be used to contradict it. Underwriters price exceptions. They handle surprises badly.

Keep that list as a real document with a revision date. Name the system, the account or device, why the control is absent, what stands in for it, and who owns closing it. Attach it, reference it in the free-text field, and file the version you attached — not the current one — with the signed application.

None of this is a knock on the carriers. They ask short questions because short questions are the only thing that scales across a portfolio, and the controls they ask about are, with few exceptions, the right ones. The gap is not in the underwriting. It is that the form has no field for "yes, except," and most applicants do not realize they are allowed to write one in.

One boundary, stated plainly: none of this is legal advice or a coverage opinion. What a specific answer means for a specific policy is governed by that policy's language, the application it incorporates, the law of the governing state, and qualified insurance and legal counsel. Getting the answers right is not about predicting an outcome. It is about making sure that when someone reads your application two years from now, the environment it describes is the one that actually existed.