Control by control
The six requirement areas, in depth
For each area: why carriers require it, what a strong answer looks like in Microsoft 365, Entra ID, and Azure terms, and where the evidence lives.
1Multifactor authentication
Carriers ask whether MFA is enforced for email, for remote access, and for all privileged accounts, and they mean all three. The rationale is loss-driven: a large share of the ransomware and business email compromise claims carriers pay begin with a credential that worked without a second factor, whether phished, purchased, or sprayed. MFA on those three surfaces removes the cheapest entry paths, which is why many carriers treat it as close to non-negotiable for ransomware coverage.
The word that matters is enforced. "MFA is enabled" or "available to users" is not the same answer as "MFA is required for every account on this surface." Carriers increasingly probe the difference, and a claim investigation certainly will.
What good looks like
- Entra ID Conditional Access policies that require MFA for all users, not per-user MFA settings applied inconsistently.
- Legacy authentication protocols (POP, IMAP, SMTP AUTH, older Exchange protocols) blocked, since they bypass MFA entirely.
- Privileged roles covered explicitly, including break-glass account handling that is documented rather than exempted silently.
- Remote access paths (VPN, RDP gateways, virtual desktop) behind MFA, with no internet-exposed RDP.
Where the evidence lives
Entra ID Conditional Access policy definitions, per-policy user and app scoping, sign-in logs showing legacy auth blocked, and the list of accounts excluded from MFA policies with the reason for each exclusion.
2Backup and recovery
Carriers ask whether backups are immutable, kept offline or segregated from the production network, and restore-tested on a defined cadence. The rationale is direct: ransomware severity is largely a function of whether the victim can restore without paying. Modern ransomware operators delete or encrypt reachable backups before detonating, so a backup that shares credentials or a network path with production often does not survive the incident it exists for.
Restore testing matters as much as immutability. A backup that has never been restored is an assumption, and carriers ask for the testing cadence, commonly at least annually, because untested backups fail at recovery time often enough to show up in their loss experience.
What good looks like
- Azure Backup or equivalent with immutability enabled: immutable vaults, or Blob Storage with time-based retention locks.
- Backup infrastructure segregated from production credentials, so a compromised admin account cannot delete recovery points.
- Soft delete and multi-user authorization on vault operations.
- Documented restore tests with dates, scope, and time-to-restore results, at least annually and ideally more often for critical systems.
Where the evidence lives
Azure Backup vault configuration, immutability and soft-delete settings, retention lock policies, and restore test records. The test records are attestation-plus-artifact evidence: a dated report of what was restored and how long it took.
3Endpoint detection and response
Carriers ask what percentage of endpoints and servers run EDR, and whether alerts are monitored around the clock. The rationale is dwell time: most large ransomware losses involve days or weeks between initial access and encryption, and EDR is the control most likely to turn that window into a contained incident instead of a claim. Coverage percentage matters because attackers find the unmanaged machines; an EDR deployment that skips servers or covers most laptops protects the assets attackers care about least.
Monitoring is the second half of the question. An EDR that fires alerts nobody reads is a recording device, so carriers ask who watches it, whether that is an internal team or a managed detection and response provider.
What good looks like
- Microsoft Defender for Endpoint (or an equivalent EDR) onboarded on effectively all workstations and servers, with the gap list known and shrinking.
- Servers explicitly included, including Azure virtual machines through Defender for Servers.
- Alert routing to a monitored queue with defined response ownership, in-house or via an MDR provider.
Where the evidence lives
Defender for Endpoint onboarding and device inventory, Defender for Cloud coverage for Azure VMs, and the monitoring arrangement (SOC or MDR contract) as attested evidence.
4Privileged access
Carriers ask how many global administrators exist, whether privileged access is granted just-in-time, and whether access is reviewed periodically. The rationale is blast radius: when an attacker lands on a privileged account, a bad day becomes a total loss, and incident reports carriers see are full of environments where a routine account held standing admin rights nobody remembered granting. Fewer privileged accounts, granted temporarily and reviewed regularly, is the difference between an incident and an enterprise-wide one.
What good looks like
- A small, known set of Global Administrator accounts in Entra ID, commonly held to a handful, each attributable to a person or a documented break-glass purpose.
- Privileged Identity Management (PIM) for just-in-time elevation instead of standing role assignments.
- Periodic access reviews of privileged roles with recorded outcomes, so departed staff and stale grants are provably removed.
- Separate admin accounts, distinct from daily-driver mailbox accounts.
Where the evidence lives
Entra ID role assignments (the global admin count is a direct read), PIM configuration and elevation history, and access review completion records with dates and reviewers.
5Email security
Carriers ask whether SPF, DKIM, and DMARC are configured and enforced, and what phishing controls and training are in place. The rationale is that phishing and spoofed email remain the most common opening move in the funds-transfer-fraud and business email compromise claims carriers pay. Email authentication is also one of the few controls a carrier can verify externally without asking: your DNS records are public, and a DMARC policy of none tells an underwriter you monitor spoofing but do not stop it.
What good looks like
- SPF and DKIM configured for every sending domain, with DKIM signing enabled in Exchange Online.
- DMARC at an enforcement policy (quarantine or reject), not p=none left in monitoring mode indefinitely.
- Anti-phishing policies in Microsoft Defender for Office 365: impersonation protection, Safe Links, Safe Attachments.
- Recurring phishing awareness training with completion tracked.
Where the evidence lives
Public DNS records for SPF, DKIM, and DMARC (externally verifiable), Exchange Online and Defender for Office 365 policy configuration, and training completion records as attested evidence.
6Incident response
Carriers ask whether a written incident response plan exists, whether it has been tested, and how long logs are retained. The rationale is severity control on both sides of the claim: organizations that rehearse response contain incidents faster and cheaper, and logs are what lets forensics establish what happened, when, and how far it spread. An environment with no retained logs turns a bounded investigation into a worst-case assumption, which carriers pay for.
What good looks like
- A written plan with named roles, contact paths, and carrier and breach-counsel notification steps, reviewed on a schedule.
- A tabletop exercise or live test within the last year, with dated notes on what was found.
- Audit and sign-in logging enabled across Microsoft 365 and Azure, with retention configured deliberately rather than left at defaults.
Where the evidence lives
The plan document and review history, tabletop records, Microsoft 365 unified audit log settings, Entra ID sign-in log retention, and Azure diagnostic settings routing logs to a workspace with a defined retention period.