Cyber Insurance Compliance Checklist

Why the questionnaire feels like a trap

The renewal packet lands in your inbox 90 days out. Forty questions, sometimes sixty. Half of them ask things you don't have a confident answer to, like whether your tenant blocks legacy authentication or how often you review Conditional Access policies. You forward it to whoever runs IT, get back a partial answer, and sign.

That signature is an attestation. If something on it turns out to be wrong at claim time, the carrier has grounds to deny. We've seen sub-limits applied retroactively, full denials issued, and renewals declined based on answers an owner didn't realize they were giving.

The fix isn't to learn IT. The fix is to walk a structured checklist before you sign, the same way the carrier's underwriter is going to walk one when they review your answers. That's what this page is. Each item names the control, what proof of "yes" looks like, who to ask for it, and what a "no" looks like in plain language. If you want the broader picture of what carriers are demanding in 2026, the 2026 cyber insurance requirements overview covers the why and the what. This page is the how-to-verify.

Domain 1: Identity controls

Six items. This is where the most claims get denied, because identity controls are the easiest to assume are working when they aren't.

1.1 All users have MFA enforced (not just available)

Verified: Every active user account has MFA registered AND a Conditional Access policy or security default enforces it on sign-in. There's no opt-out group, no "we'll get to that user later" exception list.

How to confirm: Ask your IT lead for an export of users from the Microsoft Entra admin center showing the "MFA status" column. Every user should show "Enforced." If the column shows "Enabled" without "Enforced," that means MFA is registered but not required at sign-in. Those users can still log in without it. When the questionnaire lands and you have to translate this into the carrier's exact wording, the worksheet on how to answer the MFA section of a 2026 questionnaire shows which evidence passes and which gets flagged.

Fails: Any user shows "Disabled" or "Enabled" only. A "we use security defaults" answer with no Conditional Access backup. An exception group that hasn't been reviewed in 6 months.

1.2 Admin accounts use stronger MFA than users

Verified: Anyone with Global Administrator, Privileged Role Administrator, Exchange Administrator, or similar elevated roles uses FIDO2 hardware keys, certificate-based authentication, or a number-matching authenticator app. SMS and voice call MFA are blocked for these accounts.

How to confirm: Ask which authentication methods are allowed for admin accounts. Request the Authentication Methods policy export from Entra. SMS and voice should be set to "No" for the admin role group.

Fails: Admins use the same MFA method as everyone else. SMS is the only second factor on a Global Admin account. The answer is "we use Microsoft Authenticator" with no policy enforcing it.

1.3 Named admin accounts are separate from daily-driver accounts

Verified: Each person with admin rights has two accounts. One ordinary mailbox account they use for email and Teams. One admin-only account they use only when they need elevated rights, with no mailbox attached.

How to confirm: Ask for a list of every account holding an admin role. Cross-reference with the user list. Anyone whose only account is also their daily mailbox is an instant finding.

Fails: The owner's daily Outlook account is also Global Admin. The IT contractor's billing email is also Exchange Admin. One account, two purposes.

1.4 Break-glass accounts are documented and isolated

Verified: Two emergency-access Global Admin accounts exist, are excluded from Conditional Access policies that could lock them out, have a 64-character password stored in a physical safe, and trigger an alert anytime they sign in.

How to confirm: Ask to see the documentation. There should be a one-page record listing the two accounts, where the credentials are stored, who has authorization to retrieve them, and what alerting is in place. If nobody can produce that page, the control isn't real.

Fails: No break-glass accounts exist (when MFA fails tenant-wide, you're locked out of your own tenant). They exist but live in a password manager that requires MFA to open. They exist but no alert fires on sign-in, so nobody would know if one was used.

1.5 Legacy authentication is blocked tenant-wide

Verified: A Conditional Access policy named something like "Block Legacy Auth" is in the "On" state, scoped to all users (excluding only the break-glass accounts), and reports zero successful legacy-auth sign-ins in the last 30 days. Bonus: an Exchange Online authentication policy backstops it at the protocol layer.

How to confirm: Ask for the policy export and a sign-in log filtered on legacy clients for the last 30 days. The full step-by-step verification path is in the secure Microsoft 365 for small business guide on the technical side.

Fails: The policy is in "Report-only" mode and has been for months. Successful legacy-auth sign-ins still appear in the logs. Nobody can locate the policy at all.

1.6 Conditional Access policies are "On" and reviewed

Verified: The Conditional Access policy list shows policies in the "On" state for the core scenarios (require MFA, block legacy auth, require compliant device for admins, geofence high-risk countries). Each policy has a last-modified date within the last 12 months, indicating someone has actually looked at it.

How to confirm: Request a screenshot or export of the Conditional Access policy list. Look at the State column and the modified dates.

Fails: Half the policies are "Off" or "Report-only." Modified dates are 2+ years old. The list is empty, meaning the tenant relies on security defaults alone.

Domain 2: Email security

Five items. Email is still where 80% of incidents start, and carriers know it. They will ask about each of these by name.

2.1 Defender for Office 365 is active with anti-phishing thresholds set

Verified: Microsoft Defender for Office 365 (Plan 1 or 2) is licensed and the anti-phishing policy has impersonation protection enabled for the executive team, domain spoofing protection enabled, and the action set to Quarantine for high-confidence phishing.

How to confirm: Ask for an export of the anti-phishing policy from the Microsoft 365 Defender portal. Verify executives are in the "users to protect" list.

Fails: Anti-phishing is on but executives aren't enrolled. Action is set to "Move to junk" instead of Quarantine. The policy has never been customized from defaults.

2.2 DMARC is at p=quarantine minimum

Verified: Run a public DMARC lookup on your domain (any free DMARC checker works). The published policy reads v=DMARC1; p=quarantine at minimum, and ideally p=reject. SPF and DKIM are also published and aligned.

How to confirm: You can do this yourself in 30 seconds. Search "dmarc checker," type your domain, read the result.

Fails: The record reads p=none (monitoring only, doesn't block anything). No DMARC record at all. If your DMARC is missing, expect invoice fraud and vendor impersonation attempts targeting your customers in your name.

2.3 External sender warning is enabled

Verified: Mail from outside your tenant displays a visible "External" tag or yellow banner in the inbox before users open it. This is a tenant-level setting in Exchange Online.

How to confirm: Send a test email from a personal Gmail to your work mailbox. Open it. Is there a banner or tag? If yes, verified. If no, the setting is off.

Fails: No banner appears. Users say they didn't realize the sender was external until after they replied.

2.4 Mailbox forwarding to external domains is restricted

Verified: A tenant-wide remote domain rule blocks auto-forwarding to external addresses. Users cannot set up an Outlook rule that forwards their mail to a personal Gmail account.

How to confirm: Ask IT to demonstrate the block. They can either show the Exchange Online configuration or attempt to set up an external forward as a test user and have it fail.

Fails: External forwarding is allowed by default. Forwarding rules already exist on user mailboxes pointing to outside domains (this often signals an active compromise, not just policy laxity).

2.5 OAuth app consent requires admin approval

Verified: The user consent setting in Entra is set to "Do not allow user consent" or "Allow user consent for verified publishers, for selected permissions." Anything else means a user can grant a malicious third-party app the right to read their entire mailbox in two clicks.

How to confirm: Request a screenshot of Enterprise Applications → Consent and permissions → User consent settings.

Fails: "Allow user consent for apps" with no restrictions. This is the Microsoft default on older tenants and the source of a steady stream of OAuth phishing compromises.

Domain 3: Endpoint protection

Four items. Carriers will ask about laptops and phones, not just the cloud.

3.1 EDR is active on all managed devices

Verified: Endpoint detection and response (Defender for Endpoint, CrowdStrike, SentinelOne, or equivalent) is installed on every company laptop and desktop, the management console shows green status for each one, and an alert exists for offline devices that haven't checked in for 7+ days.

How to confirm: Ask for the device count from the EDR console. Compare to the headcount. Numbers should match within a couple of devices.

Fails: The answer is "we have antivirus." Antivirus is not EDR. Carriers know the difference and the questionnaire will use the term EDR specifically.

3.2 Device compliance policies are enforced

Verified: Intune (or another MDM) enforces BitLocker on all Windows devices, FileVault on Macs, a minimum OS version, password complexity, and device lock after inactivity. A Conditional Access policy blocks non-compliant devices from accessing M365.

How to confirm: Request the Intune compliance report. Look for compliant device percentage above 95%.

Fails: No MDM in place. Compliance percentage below 80%. BitLocker keys not escrowed (you can't recover the data if the user leaves).

3.3 BYOD has app protection or management

Verified: Personal phones accessing company email are enrolled in mobile application management (Intune App Protection Policies) or are blocked entirely. Corporate data on personal devices can be wiped without wiping the user's photos.

How to confirm: Ask whether employees access work email on personal phones, and how. If the answer is "they just install Outlook," confirm the App Protection Policy is in place.

Fails: Personal phones have full access with no MDM, no app protection, and no remote wipe capability for the corporate data.

3.4 Patch management has documented cadence

Verified: Critical and high-severity OS and browser patches are applied within 30 days, ideally 14. There's a written record of the cadence (a one-page policy is fine) and a tool that reports compliance (Intune Update Compliance, the EDR vendor's patch module, or a third party).

How to confirm: Ask for the most recent monthly patch report. Spot-check three random devices.

Fails: No written cadence. Patches applied "when we get to them." Devices three or more months behind on critical updates.

Domain 4: Backup and recovery

Four items. The 2026 ransomware narrative made this section heavier than it used to be. Carriers want to know you can recover without paying.

4.1 Backups exist beyond M365's native retention

Verified: A third-party backup product (Veeam, Datto, Afi, AvePoint, Barracuda, etc.) backs up Exchange Online, SharePoint, OneDrive, and Teams data daily. Microsoft's native retention is not a backup; it's a recycle bin with a 30-day timer in most cases.

How to confirm: Ask for the name of the backup product, the retention period, and the most recent backup status report.

Fails: "Microsoft handles it." That answer alone has caused renewal denials.

4.2 Backups are immutable or air-gapped

Verified: The backup target uses object lock, immutability, or physical separation so a ransomware actor with admin credentials cannot delete or encrypt the backups. The provider's documentation will name this feature explicitly.

How to confirm: Request the configuration page from the backup vendor showing immutability is enabled.

Fails: Backups live in the same admin scope as production. An attacker with Global Admin can wipe both at once.

4.3 Restore process tested in last 12 months

Verified: Within the last year, someone restored at least one mailbox, one SharePoint site, and one OneDrive folder from backup, documented the restore time, and verified the data was intact.

How to confirm: Ask for the restore test report. It should be one or two pages, dated, signed.

Fails: No test in the last year. The answer "we'd just restore from backup if we needed to" with no proof.

4.4 RTO and RPO are documented

Verified: A document specifies how long it would take to restore (Recovery Time Objective) and how much data could be lost (Recovery Point Objective) for each major service. RTO under 24 hours and RPO under 4 hours are reasonable targets for an SMB on M365.

How to confirm: Ask for the document. It can be one page.

Fails: No document. Numbers exist informally but nobody can produce them in writing.

Domain 5: Logging and monitoring

Four items. After a breach, the first question forensics asks is "show me the logs." If they don't exist, the investigation is over before it starts.

5.1 Unified Audit Log is enabled and verified

Verified: The Microsoft 365 Unified Audit Log is on (it's been on by default since 2023, but verify). A test query for "MailboxLogin" or "FileAccessed" in the last 7 days returns results.

How to confirm: Ask IT to run an audit search and screenshot the result count.

Fails: The audit log is disabled. Searches return zero results because logging was turned off years ago and nobody re-enabled it.

5.2 Log retention extended beyond 90-day default

Verified: Logs are retained for at least 1 year, ideally longer, via Microsoft Purview Audit (Premium), a SIEM ingest, or another archive path. Most breaches go undetected for 60-200 days; a 90-day window means the evidence is gone before you know to look.

How to confirm: Ask what the retention setting is and where logs are stored.

Fails: Default 90-day retention with nothing beyond it. Carriers flag this consistently.

5.3 Alert policies are configured for critical events

Verified: Alert policies fire on impossible-travel sign-ins, mass file downloads, new mailbox forwarding rules, role assignment changes, and external mailbox sharing. Alerts route to a monitored inbox or ticket queue, not a personal email that nobody reads.

How to confirm: Ask for the alert policy list export and the destination address.

Fails: Default policies only, with alerts going to an unmonitored shared mailbox.

5.4 Someone reviews alerts weekly

Verified: A named role (internal IT, the MSP, or a SOC service) reviews open alerts at least weekly and documents the review. There's a recurring calendar event or a ticket-queue dashboard showing the cadence.

How to confirm: Ask "who looks at security alerts and how often?" If the answer is "we'd see if something looked wrong," that's not a review process.

Fails: Nobody owns this. Alerts pile up unread. The MSP has it in their service description but no evidence of weekly review.

Domain 6: Process and governance

Five items. This is the section where M365 controls stop and organizational discipline starts. Carriers weight it heavily because it predicts how you'll respond when the technical controls fail.

6.1 Documented incident response plan

Verified: A written IR plan exists that names the incident commander, the communication chain, the decision authority for taking systems offline, the legal and PR contacts, and the carrier notification phone number. The document has a "last reviewed" date within the last 12 months.

How to confirm: Ask for the PDF. Look at the cover page for the review date.

Fails: No plan. A plan that hasn't been reviewed since 2021. A plan that names someone who left the company two years ago.

6.2 Tabletop exercise in the last 12 months

Verified: The leadership team walked through a simulated incident in the last year (ransomware, BEC, data theft, whatever scenario fits). Notes were taken. At least one improvement to the IR plan came out of it.

How to confirm: Ask for the tabletop after-action notes. They can be informal, but they have to exist.

Fails: No tabletop ever, or one done so long ago nobody remembers it. The IR plan has never been stress-tested.

6.3 Security awareness training completed by all users

Verified: Every user (including the owner, including admins) completed a security awareness training module in the last 12 months. The training platform produces a completion report by name.

How to confirm: Request the completion report. Spot-check three names.

Fails: Training is "available" but not tracked. Half the company hasn't completed it. The owner exempted themselves.

6.4 Phishing simulation results reviewed in the last 6 months

Verified: A phishing simulation campaign ran in the last 6 months. Click rates were measured. Repeat clickers received targeted follow-up training.

How to confirm: Ask for the campaign summary. Click rate, report rate, follow-up actions.

Fails: No simulations. Or simulations were run but results were never reviewed and clickers never coached.

6.5 Vendor risk reviews documented

Verified: A list of every third party with access to your data exists (the MSP, the bookkeeper, the marketing agency, every SaaS app touching M365). Each entry shows the access level, the data they touch, the security attestation on file (SOC 2, ISO 27001, signed addendum), and the last review date.

How to confirm: Ask for the vendor inventory. A spreadsheet works.

Fails: No inventory. The owner can't list every vendor with system access. No security attestations on file.

Domain 7: Documentation for the carrier

Three items. This is what you actually hand the carrier with the signed questionnaire. Most denials we see at claim time trace back to a missing item in this section.

7.1 Evidence package is ready

Verified: A folder (digital is fine) contains: the most recent sign-in log export, the Conditional Access policy export, the device compliance report, security training completion records, the most recent backup test, the IR plan PDF, and the DMARC lookup screenshot. Everything is dated within the last 90 days.

How to confirm: Walk the folder. Each item should be a file with a clear name and a recent date.

Fails: The evidence package is theoretical. "We can pull it if they ask" is not the same as having it ready.

7.2 MSP attestation letter on file (if applicable)

Verified: If a managed service provider runs your IT, they've provided a signed attestation letter on letterhead confirming the controls they manage on your behalf, with their SOC 2 or equivalent attestation attached.

How to confirm: Ask the MSP for the letter. They've usually written one before.

Fails: No letter. The MSP says "we'd answer questions if asked" but nothing in writing.

7.3 Designated security contact named

Verified: The questionnaire asks for a security contact. A named person (with title, email, phone) is listed. That person knows they're listed and would actually pick up the phone if the carrier called about a claim.

How to confirm: Read the contact field. Confirm with the person named.

Fails: The field reads "info@..." or "the owner." Carriers want a human.

The five items getting flagged most often in 2026

Of the 31 items above, five fail verification disproportionately often when we walk this with new clients. If your time to renewal is short, focus here first.

1. SMS-only MFA on admins (item 1.2). SIM-swap attacks are common enough that carriers no longer treat SMS as a real second factor for elevated accounts. The fix is a $30 hardware key per admin or switching to number-matching push.
2. Admin accounts on shared sign-in profiles (item 1.3). Owner-as-admin and IT-contractor-as-admin are the two patterns that show up over and over. Splitting one account into two takes an hour per admin.
3. Missing log retention beyond 90 days (item 5.2). The default is the failure. The fix is either a Purview Audit Premium add-on or a SIEM connector. Both are line-item costs that the carrier savings tend to cover within one renewal cycle.
4. No IR tabletop (item 6.2). Easy to skip, hard to justify when the renewal asks. Two hours, six people, one scenario. Document it.
5. OAuth consent left wide open (item 2.5). Probably the single most common silent compromise vector in 2026, and carriers are starting to ask about it specifically. The fix is one setting in Entra and takes five minutes.

For the implementation playbook on most of these, including how a similar SMB worked through the same checklist before their last renewal, see the cyber insurance implementation case study.

What to do if an item fails verification

You walked the checklist. Five items came back red. You have 30 days until the renewal questionnaire is due. What now?

Three paths, in order of preference.

Path 1: Fix it before signing. For most identity, email, and OAuth items, the fix is a configuration change that takes hours, not weeks. If the failures are technical and the time exists, fix them and re-verify before you submit the questionnaire. You answer "yes" honestly and move on. The cyber insurance renewal checklist covers the 90-day timeline so you don't get cornered into this on day five.

Path 2: Document a remediation timeline. If a control genuinely takes time to implement (a backup product migration, a new MDM rollout, an IR plan written from scratch), you can answer "in progress" with a concrete date. Most carriers accept a written remediation plan signed by leadership, especially if you've fixed the easier items already. They want trajectory, not perfection. Don't lie and don't volunteer "no" without context.

Path 3: Accept a sub-limit instead of a full denial. If a control is missing and won't be in place by the renewal date, talk to your broker about a sub-limit on the affected coverage rather than letting the whole policy lapse. Sub-limits are a worse outcome than full coverage, but they're a much better outcome than going uninsured for 90 days while you scramble. Brokers have these conversations every week. Ask early, not the day of.

What you don't do: answer "yes" to a control that isn't actually in place. The questionnaire is an attestation. Misrepresentation is a denial trigger that survives the policy renewal and follows you to the next carrier. If a 10-minute walk through this checklist surfaces uncertainty, treat that as a signal. Verify before you sign. The cyber insurance requirements FAQ answers the borderline-case questions that come up when an item is partially in place.

Common questions

Do I have to walk this entire checklist myself, or can my MSP do it?

Your MSP can produce most of the evidence, but you (or someone in leadership) should walk the verification yourself. The questionnaire is signed by you, not by the MSP. If something is wrong on the form, the MSP isn't on the hook for the misrepresentation. Reading the evidence the MSP produces takes about 90 minutes once you know what to look for. The point of this checklist is to give you the "what to look for" so the review is short.

My carrier's questionnaire has 60 items, not 31. Where's the rest?

The 31 here are the M365-tenant-and-process items that nearly every carrier asks about. The rest of a long questionnaire usually covers things outside this scope: physical security, network firewalls, on-prem servers, payment card environments, data classification policies, regulatory compliance (HIPAA, PCI, etc.), and business interruption planning. Those are real questions, just not Microsoft 365 questions. If your business depends heavily on those areas, your broker can point you to the equivalent verification framework.

How long does walking this checklist actually take?

Two hours if the evidence is already organized. Half a day if you have to gather it from scratch. The time investment pays back twice: first by catching items before the carrier does, second by giving you a reusable evidence folder for next year's renewal. Most of our clients find that year two takes 30 minutes.

What if my IT person says we have a control but can't produce the evidence?

Treat that as a fail until proven otherwise. "We have it" without exportable evidence isn't a control the carrier will accept either. The fix is to have the control produce its own evidence: a saved policy export, a recurring report, a screenshot folder with dates. If your IT lead resists producing that, the bigger issue isn't the renewal. It's that you can't prove your security posture to anyone else either, including a forensic investigator after a breach.

Will doing all 31 items lower my premium?

Sometimes. The bigger effect is on whether you get coverage at all and whether claims pay out. Carriers in 2026 are using these controls as eligibility filters first, premium adjusters second. A clean checklist gets you a renewal at competitive rates; a messy one means a non-renewal or a sub-limit, and the gap between those outcomes is much larger than the gap between two clean rates.