How to Build a Cyber Insurance Evidence Packet That Gets Approved on First Pass

A good evidence packet does not drown the underwriter in raw exports. It makes the control story easy to verify, easy to follow, and hard to misunderstand.

There is a gulf between knowing what evidence you need and actually having it. Most brokers understand the 8-15 controls that carriers will ask about during underwriting. You can list them: MFA, EDR, backups, incident response, business continuity. But knowing that your client needs an MFA report is not the same as knowing which platform to export from, in what format, with what freshness date, and how to structure it so the underwriter doesn't send back a follow-up request.

The difference between a first-pass approval and a three-email back-and-forth is assembly discipline.

Key takeaways

• First-pass approval is usually a packaging problem as much as a control problem.
• The best packets are current, mapped to the carrier's actual questions, and explicit about scope and exceptions.
• A packet should organize proof, not merely attach files.
• The goal is not to pretend every control is perfect. The goal is to make the file defensible and readable.

What "first-pass ready" actually means

A first-pass-ready packet usually has four traits.

1. It is current

The evidence has dates that make sense for the renewal. Old exports, stale screenshots, and last year's backup test create immediate friction.

2. It is mapped

The underwriter should not have to guess which artifact answers which question. The packet should connect evidence to the actual carrier asks.

3. It is scoped

The packet should make clear what is included, what the denominator is, and whether there are known exceptions.

4. It is honest

A packet that admits the open issue and explains the remediation plan is stronger than a packet that overstates the control and creates doubt everywhere else.

The five sections every good packet should include

You do not need a 60-page submission binder for every account. You do need a consistent structure.

Section 1: Executive summary

This is the front page. It should tell the reader:

• which insured and domain the packet covers,
• which carrier or market the packet is targeting,
• which controls are verified externally,
• which controls are supported by attached evidence,
• and where any known exceptions or follow-ups exist.

A short cover memo adds real value. If you want a prebuilt structure, use the client renewal memo template at /templates/client-renewal-memo.

Section 2: Outside-in readiness summary

Start with the public layer because it is easy to understand and fast to validate. Include:

• email-authentication posture,
• TLS quality,
• subdomain or exposure observations,
• and any carrier-relevant blockers surfaced from the public scan.

This is the fastest way to align the packet with what the market can already see.

Section 3: Control-by-control evidence

This is the center of the file. For each control family the carrier cares about, include:

• the question or control label,
• the supporting artifact,
• the artifact date,
• and one sentence on what it proves.

The packet becomes stronger immediately when the evidence is narrated instead of simply attached.

Section 4: Manual documents and governance artifacts

This is where the file includes the items no scan can generate by itself:

• incident response plan,
• MFA or access-control policy,
• continuity documentation,
• awareness-training proof,
• any business-process artifacts the form depends on.

The templates library at /templates is built for this layer.

Section 5: Exceptions, open items, and next steps

Do not hide the exceptions. Organize them. A short, explicit exception section helps the underwriter understand the real environment and prevents one caveat from contaminating the whole packet.

Step 1: Identify Which Controls Your Carrier Asks About

You don't need evidence for all 15 possible controls. Your carrier's supplement will ask for specific ones.

Start here:

1. Get the supplement. If you don't have it, your carrier's underwriting portal will have it, or ask your carrier contact.
2. Upload it to the Control Coverage Calculator at /tools/control-coverage.
3. Review the grid. You'll see:
   • Which 6-12 controls your carrier covers
   • Which ones you already have reusable evidence for (from prior submissions)
   • Acceptance likelihood per carrier, so you know which controls are dealbreakers vs. nice-to-haves

This is your bill of materials. Everything else flows from this grid.

Why this matters: Spending time on controls your carrier doesn't care about is wasted effort. The calculator tells you exactly what to focus on.

Step 2: Categorize Each Control by Evidence Type

Not all evidence comes from the same place. You need to know where to source each one.

The 15 controls fall into four categories:

Scan-Verifiable Controls

These are externally checkable. The carrier (or their vendor) can verify them without you sending anything.

Examples:

• Email security posture (SPF, DKIM, DMARC records)
• TLS/SSL certificate validity
• Open ports and exposed services
• DNS security settings

What to do: Run /scan before submission. This produces a clean report showing your external posture. Email carriers appreciate this—it cuts their verification time in half.

Platform-Exportable Controls

These require pulling a report from your client's security or IT platform and formatting it correctly.

Examples:

• MFA enrollment and enforcement status (Entra, Okta, Duo)
• EDR deployment coverage (CrowdStrike, SentinelOne, Microsoft Defender)
• Backup configuration and retention (Veeam, Nakivo, native cloud backups)
• Patch management status (Microsoft WSUS, Intune, third-party)
• Web filtering/email security (Cisco Umbrella, Fortinet, Proofpoint)

What to do: Use the step-by-step export guides at /guides. Each guide covers the specific menu path, what to include in the export, and what freshness standard to target (usually 30 days or less).

Policy-Dependent Controls

These require a written document. Your client may have one (and you need to find it), or they may need a template to start from.

Examples:

• Incident response plan
• Business continuity and disaster recovery plan
• Patch management policy
• Access control and review procedures
• Wire transfer verification procedures

What to do: If a formal policy doesn't exist, download a template from /templates. Customize it for the client, have their authorized officer review it, get it signed, and include it in the packet.

Attestation-Only Controls

These must be signed by someone with authority (usually the CFO, COO, or IT director). A template supports the attestation, but the signature is what makes it evidence.

Examples:

• Security awareness training completion rates
• Vendor risk assessment process and completion
• Data classification completed for sensitive data
• Encryption status for sensitive data at rest and in transit

What to do: Use the template as a starting point. Have the client customize it with their specific data, their specific vendor assessment results, or their specific encryption inventory. Then have the authorized person sign it.

Step 3: Pull Platform Evidence with Attention to Freshness

Freshness kills more evidence packets than anything else.

An MFA report from six months ago does not prove MFA is enforced today. A backup report from Q1 doesn't prove your client can actually restore from Q2. Underwriters know this. They will ask for updates.

Golden rule: Evidence should be no more than 30 days old at submission.

For each platform-exportable control, here's the workflow:

1. Check the export guide at /guides for your specific platform (M365, Entra, Duo, Okta, CrowdStrike, SentinelOne, Veeam, etc.).
2. Follow the menu path. Every platform changes their UI. The guides stay current.
3. Export with a timestamp. Rename the file to include the export date: MFA_Enrollment_Report_20260328.pdf.
4. Note the enforcement setting. "MFA enabled" is weaker than "MFA enforced." Carriers want enforcement.
5. Store in your evidence folder with a freshness tracking spreadsheet (more on this below).

Special note on MFA evidence: This is the most commonly requested control. If you're gathering evidence for multiple clients, start here. See /blog/export-mfa-evidence-entra-duo-okta-cyber-insurance for a detailed walkthrough.

Step 4: Fill Documentation Gaps with Templates

If your client doesn't have a formal incident response plan, business continuity plan, or data classification inventory, templates save time and reduce back-and-forth.

Important: A template is not evidence by itself. It's a starting point. It becomes evidence when your client:

1. Reviews it
2. Customizes it with their actual data (real names, real processes, real dates)
3. Approves it
4. Gets it signed by an authorized officer

Here are the three controls where templates add the most value:

Incident Response Plan

What carriers look for: A written procedure for detecting, responding to, and documenting security incidents. They want to see escalation paths, notification timelines, and forensic preservation steps.

What the template covers: Incident classification, response roles, external notifications, documentation, and post-incident review.

Customization required: Names of the incident response lead and secondary contacts, timelines specific to the client's industry/size, integration with their actual SOAR tool (if they have one), or escalation path if they don't.

Acceptance likelihood: High (80%+) if signed and recent. Medium (50-60%) if it looks boilerplate.

Wire Transfer Verification Procedures

What carriers look for: A written process proving that legitimate transactions are verified before execution. Carriers know wire fraud is a top loss driver.

What the template covers: Dual authorization requirements, out-of-band verification (phone call, in-person confirmation), fraud alert triggers, and audit logging.

Customization required: Your client's actual wire limits, their actual approval hierarchy (CFO, COO, etc.), their specific communication method for out-of-band verification, and evidence of a recent transaction log.

Acceptance likelihood: High (85%+) if signed and tied to a sample transaction log. Medium (40-50%) if no supporting transaction evidence.

Backup Recovery Testing Log

What carriers look for: Proof that backups are not just configured—they're actually tested and restored. This is the difference between "we have backups" and "backups work."

What the template covers: Test schedule, systems tested, restoration success/failure notes, and approver sign-off.

Customization required: Your client's actual backup schedule, their actual systems (which servers/databases did you test?), actual test dates (must be recent), and actual restoration results.

Acceptance likelihood: Very high (90%+) if the test dates are within 90 days and results are documented. Very low (10-20%) if there's no test log at all.

Download all templates from /templates. Each one shows acceptance likelihood by carrier, so you can prioritize.

What each artifact should do

The easiest way to improve packet quality is to force every attachment to answer one simple question: "What does this artifact prove?"

If the answer is unclear, the file is too raw.

Here is the rule of thumb:

The packet improves the moment the artifacts stop being "attachments" and start being "proof objects."

Step 5: Organize Into a Submission Packet

A submission packet is more than a folder. It has structure.

Create a folder named [Client]_Cyber_Evidence_[Date] and organize it like this:

ClientName_Cyber_Evidence_20260328/
├── 1_SCAN_RESULTS/
│   └── External_Posture_Scan_20260328.pdf
├── 2_MFA/
│   └── MFA_Enrollment_Report_20260315.pdf
├── 3_EDR/
│   └── EDR_Deployment_Report_20260320.pdf
├── 4_BACKUP/
│   ├── Backup_Configuration_Report_20260310.pdf
│   └── Backup_Test_Log_20260325.xlsx
├── 5_PATCH_MANAGEMENT/
│   └── Patch_Status_Report_20260328.pdf
├── 6_EMAIL_SECURITY/
│   └── Email_Security_Config_20260315.pdf
├── 7_INCIDENT_RESPONSE_PLAN/
│   └── Incident_Response_Plan_Signed_20260301.pdf
├── 8_BUSINESS_CONTINUITY/
│   └── Business_Continuity_Plan_Signed_20260201.pdf
├── 9_WIRE_TRANSFER_VERIFICATION/
│   └── Wire_Transfer_Procedures_Signed_20260228.pdf
├── MASTER_INDEX.xlsx
└── ATTESTATION_FORM_SIGNED.pdf

The MASTER_INDEX.xlsx is critical. Create a spreadsheet with these columns:

Flag anything stale, missing, or not yet signed. This makes the final review step much faster.

Step 6: Client Review and Officer Attestation

Before you submit anything, your client's authorized representative must review the entire packet.

This is not a formality. This is where rescission risk lives.

The person signing is attesting that:

• The evidence is accurate and current
• The controls are actually in place (not just documented)
• They understand the representations they're making to the insurer

If a backup report is outdated but presented as current, that's a material misrepresentation. If MFA is listed as "enforced" but is actually "enabled but optional," that's a misrepresentation. Carriers rescind policies over these gaps.

Before client sign-off:

1. Walk them through the MASTER_INDEX. Show them what's fresh, what needs updating.
2. Have them confirm the platform export dates are accurate.
3. Have them review any custom policy documents (incident response, business continuity, wire transfer procedures). Make sure the names and escalation paths are correct.
4. Get written sign-off from their C-level or ops lead that everything is reviewed and accurate.
5. Store the signed attestation with the packet.

See /blog/where-applications-create-rescission-risk for a deeper dive on what underwriters scrutinize during renewals.

The most common packet mistakes

The same mistakes show up over and over. Avoid these, and you'll drastically reduce underwriter requests for updates:

Mistake 1: Too many raw attachments, no narrative

A folder dump is not a packet. The underwriter still has to interpret everything manually. Fix: Narrate each artifact. Say what it proves and why it matters.

Mistake 2: No dates, no freshness context

An export without a date is weak. A report from nine months ago is weaker. Freshness should be visible without opening every file. Fix: Set a 30-day freshness target for all platform exports. Rename files with export dates. Use the MASTER_INDEX to flag anything aging.

Mistake 3: No denominator

"EDR deployed everywhere" means very little unless the packet says what "everywhere" actually means. "MFA enabled" is weaker without context on how many users, which applications, and whether it is enforced or optional. Fix: Always include scope and denominator. EDR: total devices and protected count. MFA: user base and enforcement status. Backups: systems covered and test frequency.

Mistake 4: Policy without implementation proof

A written policy is valuable. It is not the same thing as the control being in force. Policy and technical proof work best together. Fix: Pair governance artifacts (incident response plan, MFA policy, business continuity plan) with technical proof showing the control is actually operational.

Mistake 5: Technical proof without business-process proof

This is especially common on funds-transfer, continuity, and response-plan questions. Some controls live partly outside the console. The packet should reflect that. Fix: For wire transfer controls, include both the policy and a sample transaction log. For continuity, include both the plan and testing evidence. For incident response, include the plan and a reference to a tested incident handling procedure.

Mistake 6: No exception section

If there are exclusions, migration states, open remediation items, or pending documentation, say so clearly. Silence creates suspicion faster than nuance. Fix: Create an explicit "Exceptions and Next Steps" section. Acknowledge gaps, explain remediation timelines, and show ownership of the open items.

A practical build order that works

If you are assembling the packet from scratch, use this sequence:

Step 1: Collect the public layer

Run the domain through the scan at /scan and capture the outside-in summary. This is what carriers can already see.

Step 2: Pull the technical exports

Use the guides at /guides to gather the highest-yield technical evidence: identity (MFA), endpoint (EDR), backup, email, and training. Focus on controls your specific carrier cares about (use /tools/control-coverage to verify). Aim for 30-day freshness on all exports.

Step 3: Generate or refresh the documents

Use templates for the governance layer. The MFA policy template and incident response plan template at /templates are especially useful where the file needs clean, current artifacts. Customize with real names, actual processes, and current review dates.

Step 4: Map the evidence to the actual supplement

Use the control coverage tool at /tools/control-coverage if the form is complex or if you are reusing evidence across markets. This ensures you are not spending time on controls the carrier doesn't care about.

Step 5: Package and submit

Organize everything into a structured folder with the MASTER_INDEX tracking freshness and attestation status. Use the submission workflow at /submit so the broker can attach one readable packet instead of juggling scattered artifacts.

What underwriters usually appreciate most

It is not volume. It is coherence.

A smaller packet with current evidence, clear labeling, and a short explanation for each control will usually outperform a much larger packet that forces the reviewer to reverse-engineer the story. The best submission says, in effect:

Here is what we checked. Here is what it proves. Here is what is documented separately. And here is anything you should know before binding.

That is the packet that tends to clear on first pass.

Next Steps

First-pass approvals happen when underwriters don't have to ask questions. They don't have to ask questions when evidence is organized, current, and complete.

Start here:

• Know which controls matter: /tools/control-coverage
• See external readiness: /blog/free-cyber-insurance-readiness-scan
• Build by control: /blog/cyber-insurance-supplement-decoder
• Export MFA correctly: /blog/export-mfa-evidence-entra-duo-okta-cyber-insurance

Build it:

• Download templates: /templates
• Get platform guides: /guides
• Package it up: /submit

Understand the context:

• Complete evidence reference: /blog/complete-guide-cyber-insurance-evidence-2026
• Backup immutability: /blog/how-to-prove-backup-immutability-for-cyber-insurance-renewals
• Rescission risks: /blog/where-applications-create-rescission-risk
• Carrier-specific controls: /blog/8-controls-3-carriers-cyber-insurance-checklist-2026
• Renewal timing: /blog/90-day-cyber-insurance-renewal-countdown

Ready to package your readiness results into something a carrier can actually review? Start with the /submit workflow or browse templates at /templates.