Cyber Insurance Supplement Decoder: What Every Carrier Question Is Really Asking

A broker receives a carrier supplement. 40 questions. The email has already been opened three times. By question 12, it's clear that three different questions are asking about the same thing, but in different words. By question 30, the client is asking, "Didn't we already answer this?"

They did. But the supplement doesn't say so.

The real problem isn't that carriers ask too much. It's that they ask the same controls in different languages. Multi-factor authentication gets asked as:

• "Do you use MFA for all remote access?"
• "What authentication methods are required for VPN connections?"
• "Are cloud-based administrative accounts protected by secondary authentication?"

These are all the same control. They just don't look like it.

Understanding what each question is really asking saves weeks of back-and-forth. More importantly, it tells you which evidence you've already got, which you need to gather, and which questions are auto-answered by your security scan. That's not just efficient. It's the difference between signing a supplement with confidence and hoping you didn't accidentally expose yourself to a rescission claim.

Key takeaways

• Most supplement questions are really control questions in disguise
• The hard part is translating them into evidence, owner, and next action
• A good decode shows: what the underwriter is learning, what proof answers it, and who owns it
• The faster you decode, the less back-and-forth the account creates

Why supplements feel harder than they should

Short cyber insurance questions often compress four separate decisions into one sentence:

• What control is really being tested – MFA? Backups? EDR?
• What proof would make the answer defensible – Policy export, screenshot, or attestation?
• Who owns that proof – MSP, client, or shared?
• What caveats or exceptions exist – Does "all endpoints" mean all, or are there legitimate exceptions?

Without translation, the workflow gets messy fast. Teams chase screenshots that don't answer the question. Clients sign things broad. Brokers interpret under deadline.

For the legal reason that matters, read Where Cyber Insurance Applications Create Rescission Risk. The gap between wording and operational reality is where trouble starts.

Six common question types and what they really mean

Here is the plain-English decode for the kinds of questions that show up most often.

That is the decode most teams need. Not a legal essay. Not a giant framework. Just: what does this mean, what clears it, and who owns it?

Six Real Questions Decoded

Here are six questions you'll recognize from recent supplements. Each one is decoded in detail to show what it's really asking, what control it maps to, what the underwriter is actually looking for, and what evidence answers it.

"Do you use multi-factor authentication for all remote access to your network?"

What they literally want: Proof that remote access requires more than a password.

What they're really asking: Does your MFA cover VPN, RDP, SSH, and cloud admin access? Or is it just for email? Does "all remote access" mean what you think it means?

The control: Multi-Factor Authentication (MFA) – Administrative Access

What the underwriter is looking for: Evidence that attackers can't reach your critical systems with a stolen password alone. Bonus points if MFA is enforced consistently—not bypassed for "trusted devices" or "internal networks."

Evidence that answers it:

• Azure AD Conditional Access policy export (shows MFA enforcement rules)
• Okta admin dashboard screenshot (shows MFA coverage)
• VPN configuration export (shows RADIUS MFA enforcement)
• Duo security posture report (shows what's protected, what's not)

Can your scan verify this? Partially. A scan can check if MFA is installed, but it can't verify enforcement rules, exceptions, or coverage gaps. You'll need the policy export to prove enforcement is actually required.

---

"Do you maintain offline or immutable backups?"

What they literally want: Proof that you have backups that can't be encrypted by ransomware.

What they're really asking: Are your backups stored somewhere an attacker can't reach? Or are they just synced to the same cloud account?

The control: Backup and Recovery – Immutability

What the underwriter is looking for: The difference between "we have backups" (common) and "we have backups an attacker can't destroy" (what actually matters in a ransomware scenario). Air-gapped or immutable-flagged backups are the difference between recovering in hours and not recovering at all.

Evidence that answers it:

• Veeam console screenshot showing immutability enabled
• Commvault configuration showing WORM (Write Once, Read Many) settings
• AWS backup vault screenshot showing immutability and retention lock
• NetApp Snapshot copy policy showing immutable copy destination

Can your scan verify this? No. This is purely a configuration review. Your scan can confirm backup software is installed, but not whether immutability is actually enabled.

---

"Do you have a documented incident response plan that has been tested in the last 12 months?"

What they literally want: An IR plan document plus proof you actually used it.

What they're really asking: Do you have a plan that's actually been practiced, or is it a PDF that lives in a folder nobody's read?

The control: Incident Response – Testing and Exercise

What the underwriter is looking for: Evidence of two things. First, the plan exists and covers the right scope (detection, containment, eradication, recovery, communication). Second, you've run a tabletop exercise or actual incident that validated the plan in the last 12 months. "We've never tested it" is worse than "we tested it and found gaps and fixed them."

Evidence that answers it:

• Incident Response Plan document (dated, signed by leadership)
• Tabletop exercise log with attendees, date, and outcomes
• Actual incident post-mortem (if you've had one) showing the plan was followed
• Training sign-off sheet (optional but strong: shows the team has read it)

Can your scan verify this? No. This requires document review and attestation that you've actually tested.

---

"Are all endpoints protected by EDR with 24/7 monitoring?"

What they literally want: Every laptop and desktop has endpoint detection and response software.

What they're really asking: Do you have managed EDR, or just installed EDR? There's a huge difference between "EDR is installed" and "EDR is monitored 24/7 by someone."

The control: Endpoint Detection and Response (EDR) – Coverage and Monitoring

What the underwriter is looking for: That you have EDR installed on 100% of endpoints (not just 95%), AND that someone is actually monitoring the alerts. Installed but ignored is almost as bad as not installed. 24/7 monitoring usually means a Managed Detection and Response (MDR) service or a dedicated SOC, not an in-house team monitoring it during business hours.

Evidence that answers it:

• CrowdStrike Falcon console screenshot showing all devices enrolled
• SentinelOne management console showing endpoint count and status
• Managed detection and response contract (showing 24/7 coverage)
• SOC coverage schedule or alert response SLA

Can your scan verify this? Partially. A scan can confirm EDR is installed on the devices it reaches. But it can't verify 100% coverage (offline devices, remote devices not on the network) and it can't prove 24/7 monitoring exists.

---

"Do you screen emails for malicious attachments and links?"

What they literally want: Some form of email security is in place.

What they're really asking: Do you have a sophisticated email gateway, or is it just spam filters? Does it scan for zero-days, phishing, or just known malware?

The control: Email Security – Advanced Threat Protection

What the underwriter is looking for: A secure email gateway (like Proofpoint, Mimecast, or Microsoft Defender for Office 365) with URL rewriting, sandboxing, and advanced threat detection. Basic Exchange/Gmail spam filters don't count.

Evidence that answers it:

• Microsoft Defender for Office 365 policy export (shows ATP settings)
• Proofpoint admin console screenshot (shows filtering rules and threat detection)
• Mimecast dashboard (shows gateway coverage and policy)
• Email security appliance configuration export

Can your scan verify this? Partially. A scan can confirm Microsoft Defender is enabled in your tenant. But it can't verify configuration details or third-party gateways unless they report to your infrastructure.

---

"Do you have a process to verify changes to payment instructions?"

What they literally want: Before a wire transfer or ACH payment happens, someone verifies it's legitimate.

What they're really asking: Do you verify payment changes by callback, dual approval, or just email? Can an attacker socially engineer your accounting team into paying them?

The control: Wire Transfer Verification – Dual Approval and Callback

What the underwriter is looking for: A documented process that requires either (a) callback to a known number to verify the request, or (b) dual approval from two people. Email-only approval is a massive vulnerability.

Evidence that answers it:

• Written Accounts Payable procedure (shows verification steps)
• Training sign-off sheet (shows staff knows the procedure)
• Screenshot of dual-approval workflow in your accounting system
• Recorded training or policy memo

Can your scan verify this? No. This is a process and policy control. It requires document and process review, plus attestation from accounting leadership.

---

What a good decode gives you immediately

A strong supplement decode should create four outputs fast.

1. Control classification

Every question should land in a recognizable control family: MFA, backups, email security, endpoint protection, incident response, awareness training, privileged access, and so on.

This is the difference between a scary PDF and a manageable workflow.

2. Evidence type

Every question should be split into one of three evidence paths:

• auto-verifiable (scan-based, system exports)
• needs manual technical evidence (configuration reviews, logs)
• needs client attestation or business-process evidence (policy documents, procedure memos)

That split changes everything. It tells the team what can move now and what requires real follow-up.

3. Owner routing

The broker should not have to guess whether a question belongs to IT, client ops, finance, compliance, or leadership. Owner routing is one of the biggest time-savers in the whole workflow.

4. Reuse potential

Not every question is new work. Some are old controls written in new language. If you see which evidence exists and what gaps are real, you stop rebuilding the packet every cycle.

The Control Coverage Calculator helps here.

Control Mapping Saves Weeks

When you decode a supplement by control instead of by question, three things change:

1. You find duplicate evidence immediately. Question 7 asks about MFA for VPN. Question 18 asks about MFA for admin access. Same evidence answers both.

2. You see gaps clearly. Incident Response is asked three ways. If you're missing an exercise log, all three questions are still incomplete.

3. You know what your scan can answer. Some controls are auto-verified by a security posture scan (patch levels, OS versions, software presence). Others require manual review (policy documentation, testing evidence, attestation).

How to know whether a question needs proof or explanation

A common mistake is assuming every question wants the same kind of answer. That is not true.

Some questions want proof of deployment. Some want proof of process. Some want proof of review and testing. Some want an honest explanation of scope and exceptions.

Here is the simplest way to tell the difference:

• If the question is about a technical control state, it usually needs exports, logs, or system proof.
• If the question is about preparedness or governance, it usually needs a document plus ownership and date context.
• If the question crosses business and technical boundaries, it often needs both.

This is why supplement decoding is not clerical work. It is workflow design.

The fastest way to reduce back-and-forth

To cut renewal chaos quickly, do not email the PDF to five people. Instead:

1. Parse the renewal email (if that is the first artifact)
2. Decode the supplement into control questions
3. Assign owners by evidence type
4. Send only specific requests each owner needs

The Renewal Email Parser helps with step 1. The Carrier Decoder handles step 2.

By the time the broker is writing evidence requests, the supplement should be translated. Otherwise the workflow lives inside everyone's head.

What Happens When You Answer Incorrectly

Answering a supplement question with inflated claims or missing context creates risk that goes beyond just delayed underwriting. If your answers are later found to be false or misleading, they can trigger a rescission clause in your policy. A control marked as "fully implemented" when it's actually "partially implemented" or "not tested" is exactly the kind of discrepancy that creates legal liability.

For a deeper dive into how applications create rescission risk, see our guide on where applications create rescission risk.

What to do after the decode

Once the supplement is decoded, the next steps become much clearer:

• Use guides and export guides for technical evidence-gathering
• Use templates for policy and documentation artifacts
• Reference How to Build a Cyber Insurance Evidence Packet to structure your delivery
• See Coalition vs. Hartford vs. Travelers: A Carrier Comparison to understand carrier phrasing differences
• Run the Free Cyber Insurance Readiness Scan to auto-verify controls before responding

At that point, the form stops being the source of confusion. It becomes the map for the packet.

The Carrier Decoder Approach

Instead of reading a 40-question supplement 40 separate times, the Carrier Decoder parses every question, maps it to its underlying control, and shows you:

• What control this question is asking about
• What evidence you already have in your scan
• What manual evidence you need to gather
• What the underwriter is actually looking for (not just what the question says)

You answer once per control. Your evidence maps to that control. Every question that touches that control gets the same, consistent answer.

Next Steps

Have the supplement in front of you right now? Upload your carrier questionnaire to the Carrier Decoder. It'll parse every question, map it to its underlying control, show you which controls are being tested, and tell you which evidence you already have.

Want to understand which controls matter most? Analyze your control coverage with the Control Coverage Calculator to see where your current evidence overlaps and where real gaps exist.

Need to build the evidence packet? Follow How to Build a Cyber Insurance Evidence Packet for a step-by-step workflow from decode to submission.

Looking for MFA evidence in particular? See How to Export MFA Evidence from Azure AD, Okta, or Duo – MFA is the most-decoded question across all carriers.

---

See Also

• How to Answer the Coalition Cyber Insurance Application
• Travelers CyberRisk Short Form Guide
• Complete Guide to Cyber Insurance Evidence for 2026