YOUR CYBER INSURER IS YOUR REAL AUDITOR

Please answer all questions. Answers form part of the policy.

Every year your auditor spends weeks sampling your controls. Every year your CEO spends about four minutes ticking boxes on a cyber insurance application. Only one of those documents can void a million-dollar policy, and it isn’t the SOC 2 report.

Cyber insurance security requirements have quietly become the strictest control standard most small and mid-sized companies face. The questions are blunt, the answers are signed by an executive, and nobody checks them until you file a claim. By then it is too late to fix anything.

A thread on r/grc this month asked whether anyone else was mapping their controls straight to what their insurer wants. The honest answer is that most teams should be, and most aren’t. This issue is the map.

The signature on page four

In April 2022, an electronics manufacturer called International Control Services bought a cyber policy from Travelers. The application, signed by the CEO, said the company used multi-factor authentication to protect access. In May, ransomware hit a server.

During the investigation Travelers found that MFA protected the firewall and nothing else. It went to federal court asking to rescind the policy entirely. By August, both sides had agreed to a judgment declaring the policy void from inception. There was no payout.

That distinction matters. A SOC 2 auditor who finds a gap writes an exception, and you fix it. An insurer who finds the same gap after a loss can argue the policy never existed. Your audit is a conversation. Your application is a warranty.

Takeaway for this week: find last year’s application and read it the way a claims adjuster would. Every “yes” is a statement you need to be able to prove.

The 12 controls underwriters ask about

Applications vary by carrier, but they draw from a common pool. Marsh McLennan distilled it into twelve control categories that insurers treat as minimum requirements, then paired its claims data with client self-assessments to measure which ones actually reduce losses. Here is that list, framed as the questions you’ll see, with where each one already lives in your SOC 2 and ISO 27001 program.

If you already hold a SOC 2 or ISO 27001 certificate, the good news is visible in those chips. Every question on the list maps to a control you already claim to operate. The bad news is in the next section.

Where the application is stricter than your audit

SOC 2 is principles-based. You define the control, and the auditor tests whether you did what you said. An insurance application defines the control for you, and it tends to use words like “all” and “every.” That is how a clean SOC 2 report and a false insurance answer can coexist.

Scope is the one that catches people. Your SOC 2 boundary is drawn around the product. The insurer is covering the entire legal entity. The finance laptop that never made it into your audit population is squarely inside the policy.

The claim your audit ignores

Here is the part nobody mentions. The single most common cyber insurance claim is not ransomware. In Coalition’s 2026 claims report, business email compromise and funds transfer fraud made up 58% of all claims. Funds transfer fraud alone averaged $141,000 per incident.

Most SOC 2 reports say almost nothing about how your finance team verifies a change to a vendor’s bank details. It is outside the system boundary. Your insurer, on the other hand, increasingly asks exactly that, and some policies reduce or exclude social engineering losses if the answer is no.

Closing these is cheap. Write a callback procedure for any change to payment details, using a phone number already on file. Put it in your finance runbook, train the people who touch payments, and keep the training roster. It maps loosely to ISO A.5.14, but the real reason to do it is that it covers the most common way businesses actually lose money.

One evidence set, three audiences

Your auditor, your insurer and your customers’ security questionnaires are all asking about the same twelve or so controls. Most companies answer them from three different places, written by three different people, a few months apart. That is how the answers drift, and drift is what voids policies.

Here is the sequence we use before a renewal:

1. Pull last year’s application from your broker. You probably don’t have a copy. Ask for it anyway, because it is the baseline you warranted.
2. Map every question to a control and a piece of evidence. Use the crosswalk below. Anything that maps to no control is a gap in your program, not in the form.
3. Test the strict version. Don’t ask whether MFA is on. Pull the list of accounts without it, including service accounts and shared mailboxes.
4. Answer narrowly and honestly. “Yes, except three legacy systems, isolated and scheduled for retirement in Q1” is a better answer than a clean yes. Underwriters price disclosed exceptions. They rescind hidden ones.
5. Have security sign off before the executive does. The person signing the declaration is almost never the person who knows whether it is true.
6. Keep the evidence with the application. Screenshots and exports dated to the day you submitted. If you ever file a claim, that folder is your defense.

The payoff goes beyond the claim. Carriers price on these answers, and a strong, evidenced application is leverage at renewal. It is also the same work that makes your next audit and your next enterprise questionnaire faster.

If you want a second set of eyes on your application before you sign it, that’s part of what our vCISO service does. We’ve also written about why a passed audit doesn’t mean you’re safe and how boring controls stop famous breaches. Your insurer read the same case files.