What Happens When You Fail a CIS M365 Audit

What "failing" a CIS audit actually means

The phrase "we failed our CIS audit" gets used like the assessment came back with a stamp on it. It did not. CIS Microsoft 365 Benchmark assessments produce a finding for every control in scope, and each finding lands in one of three buckets: Compliant, Not Compliant, or Not Applicable. There is no aggregate score, no minimum threshold, no overall pass.

What people mean by "failing" is that one or more controls came back Not Compliant in a part of the benchmark that someone external cares about. MFA enforcement marked Not Compliant on the application asking about cyber insurance renewal. Audit log retention marked Not Compliant on the SOC 2 control matrix. Anti-phishing baseline marked Not Compliant on a customer's vendor questionnaire.

The reframe that helps: a finding is a fact about the configuration, not a judgement about the business. The auditor or assessor is telling you the setting is not where the benchmark recommends. What happens next depends entirely on who is reading the report and why they asked for it.

For the broader picture of which CIS controls apply specifically to email security and what each one is testing, see the sibling guide on CIS Benchmark email security controls in M365.

The four contexts where CIS findings get flagged as "failure"

A Not Compliant finding by itself does nothing. It is words on a page until somebody reviewing the page makes a decision based on it. The four audiences that read the page are different, and they decide differently.

1. Cyber insurance underwriting

Carriers do not run their own CIS assessments. They send a security questionnaire that maps to CIS controls, ask for documentation (screenshots from the admin portal, PowerShell output, attestation letters from your IT provider), and sometimes commission a third-party scan of your tenant. If the package shows Not Compliant findings on controls the carrier weights heavily (MFA on all admin and user accounts, audit log retention beyond default, anti-phishing baseline, conditional access for legacy auth), the underwriter has three levers.

Premium increase is the most common. We have seen 18 to 35 percent renewal hikes on a single round of findings at the SMB tier. Sub-limit reduction is the second lever. The carrier writes the policy with a lower cap on social engineering or wire-fraud coverage, often dropping a $250,000 sub-limit to $50,000. Denial is the rare outcome, usually reserved for tenants with multiple Tier-1 findings and a prior loss history.

The path most underwriters offer when they see fixable findings is a remediation timeline acknowledgement. You sign a letter that says "we have these gaps, here is the plan, here are the dates." The policy binds at standard terms, conditional on you producing evidence of remediation by the named date. Miss the date and the policy gets re-rated at renewal or, in a few carrier forms, mid-term.

2. SOC 2 Type 1 or Type 2 audit

A SOC 2 auditor maps your CIS findings into the Trust Services Criteria, primarily CC6 (Logical and Physical Access) and CC7 (System Operations). A Not Compliant finding on, say, audit log retention does not necessarily produce a qualified opinion. It produces a control deficiency in the report.

The auditor has a structured choice. They can document the gap as a deficiency and describe a mitigating control (you do not retain logs in M365 for a year, but you ship them to a SIEM that does). They can document it as a deficiency without a mitigation and let the customer reading the SOC 2 report draw conclusions. Or, in a Type 2 with multiple unaddressed Tier-1 findings across the period, they can issue a qualified opinion. The qualified opinion is the version that loses you contracts.

Most SMBs operating well-run tenants land in the first category. The mitigating control language exists precisely so that real businesses with imperfect baselines can still pass.

3. Customer security questionnaire and vendor risk review

When you sell to enterprise customers, their security team runs you through a vendor risk review. Higher-tier customers (banks, healthcare systems, defense suppliers) increasingly run this annually. They ask for a current CIS Benchmark report or its equivalent (SOC 2 Type 2, ISO 27001 certificate, HITRUST CSF). Findings that look fine to your insurance carrier might not look fine here.

The customer side outcome is tier downgrade. You move from "approved vendor" to "approved with conditions" or "limited engagement," which can mean smaller contract sizes, longer procurement cycles, exclusion from RFPs you would have won, and a 30 to 90-day window to remediate before a contract review. Some customers maintain a rated list and remove vendors whose ratings drop two consecutive years.

A cross-domain perspective on what auditors and customers actually want to see in the report is in the InsurableIT guide on preparing a CIS M365 Benchmark report for auditors.

4. Regulatory audit (HIPAA, PCI-DSS, NIST 800-171)

The CIS Benchmark itself is not a regulation. It gets pulled into regulatory audits because the regulation often points to a benchmark like CIS as the implementation guide for a control. HIPAA Security Rule 164.312 talks about access controls and audit controls in general terms, and the auditor uses CIS to decide what "reasonable" means. PCI-DSS 4.0 references industry-accepted hardening standards, with CIS as one of the named ones.

Regulatory consequences scale with the framework. HIPAA penalties run from corrective action plans (most common) to civil monetary penalties up to $1.5 million per violation category per year (rare, reserved for willful neglect). PCI consequences are usually contractual through the acquiring bank: increased per-transaction fees, mandated remediation by a Qualified Security Assessor at your cost, and in extreme cases loss of card-processing privileges. NIST 800-171 in the defense supplier context is increasingly tied to CMMC, where a finding can mean losing eligibility on contracts.

The eight CIS M365 controls that fail most often

After working through enough tenant assessments, the same eight findings keep showing up. Each one has a specific reason it gets missed.

1. Audit log retention beyond the 90-day default. Microsoft's default unified audit log retention is 90 days for most license tiers, 180 days for E5. The CIS Benchmark recommends one year minimum. Most tenants never change the default, so when an auditor asks for sign-in logs from eight months ago to investigate a flagged account, they do not exist.
2. Conditional Access named exclusions are undocumented. Almost every tenant has an exclusion group on the main CA policies, usually for break-glass accounts and a couple of service accounts. The benchmark requires documented justification for each exclusion. The list lives in admin memory, not in writing, until the auditor asks.
3. SMTP AUTH still enabled tenant-wide. Tenants provisioned before 2020 default to SMTP AUTH on. Microsoft's 2022 basic-auth deprecation excluded SMTP submission. The control quietly stays open on every legacy tenant unless someone explicitly disables it. The remediation steps are in the SecureYourTenant guide on blocking legacy authentication in Microsoft 365.
4. OAuth user consent unrestricted. Default M365 lets users grant any third-party app permission to read mail, send mail, and access files. The benchmark requires admin approval workflows for app consent. This is the single most missed control on tenants under 100 seats.
5. Mailbox auto-forwarding to external addresses not blocked. The Defender outbound spam policy now blocks this by default for newer tenants, but older tenants still allow it. The finding compounds: external forwarding is also the most common indicator of an active mailbox compromise.
6. Sensitivity labels not deployed for confidential data. The benchmark expects a working label taxonomy applied to documents and emails containing regulated data. Most tenants either have not deployed labels at all or have a handful of labels with no enforcement policy.
7. Mobile device management absent for BYOD. Personal phones connecting to mailboxes need either Intune App Protection or full MDM enrollment. Tenants whose growth outpaced their device strategy fail this when staff connect new phones to Outlook with no enrolment requirement.
8. Anti-phishing impersonation protection not tuned per executive. Defender's impersonation protection has to be configured with named protected users and protected domains. The default policy does almost nothing useful. The detail on tuning this control sits in the sibling Microsoft 365 email security checklist.

Two PowerShell checks worth running before you even see the auditor's report. They will surface the two highest-frequency Tier-1 findings.

Audit log retention check. This pulls the current retention policy across the unified audit log. Anything under 365 days is a finding under most CIS profiles.

Connect-ExchangeOnline
Connect-IPPSSession

# Confirm unified audit log ingestion is on
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

# Inspect current retention policies
Get-UnifiedAuditLogRetentionPolicy |
  Select-Object Name, RecordTypes, RetentionDuration, Priority |
  Sort-Object Priority |
  Format-Table -AutoSize

# Per-mailbox retention (default is 90 days unless changed)
Get-Mailbox -ResultSize Unlimited |
  Select-Object UserPrincipalName, AuditEnabled, AuditLogAgeLimit |
  Where-Object { $_.AuditLogAgeLimit -lt "365.00:00:00" } |
  Export-Csv mailbox-audit-retention.csv -NoTypeInformation

Anything in the CSV is a per-mailbox finding. The fix is a one-liner per mailbox or a tenant-wide default change.

OAuth consent policy verification. This check tells you whether users can still consent to arbitrary apps and whether an admin consent workflow is in place.

Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"

# Authorization policy: allowed user role permissions
Get-MgPolicyAuthorizationPolicy |
  Select-Object DefaultUserRolePermissions |
  Format-List

# Permission grant policies currently assigned to users
Get-MgPolicyPermissionGrantPolicy |
  Select-Object Id, DisplayName, Description |
  Format-Table -AutoSize

# Admin consent request workflow status
Get-MgPolicyAdminConsentRequestPolicy |
  Select-Object IsEnabled, NotifyReviewers, RemindersEnabled, RequestDurationInDays, Reviewers |
  Format-List

The benchmark expects DefaultUserRolePermissions.PermissionGrantPoliciesAssigned to allow only verified-publisher consent or no user consent at all, and the admin consent request policy to be enabled. If either side is wrong, that is two findings on the next assessment.

The 7-step remediation playbook

Once a finding lands, the work is structured. Skipping steps produces remediations that close one finding and open two new ones at the next assessment.

Step 1: Acknowledge the finding in writing

Send the auditor or carrier a short note. "We have received the report dated <date>. We have identified the following findings as accurate: <list>. We will respond with a remediation plan by <date within 10 business days>." Do not argue the finding in this note. The acknowledgement is procedural; the substance comes later. Auditors and underwriters read this language as a sign you are running an organized response.

Step 2: Assess scope and dependencies

One finding rarely sits alone. A finding on "external auto-forwarding allowed" usually correlates with a finding on "OAuth consent unrestricted" and a finding on "audit log retention insufficient" because all three describe the same lax-default configuration era. Pull every related control out of the report. Look at adjacent benchmark sections. The cost of remediation drops sharply when you fix related controls together rather than in three separate change windows.

Step 3: Build a remediation plan with named owners and dates

Each finding gets a row in a tracker: control ID, description, owner (a human, not a department), target completion date, success criteria, evidence to be retained. The success criteria are how you know it is fixed. The evidence is what you will show the next auditor. "MFA enforced on all user accounts" is not a success criterion. "Conditional Access policy CA-MFA-AllUsers shows state=enabled in Get-MgIdentityConditionalAccessPolicy and grant=mfaRequired with no user exclusions outside the documented break-glass list" is a success criterion.

Step 4: Communicate the plan to the auditor, carrier, or customer

Send the plan back to whoever produced the finding. Insurance underwriters use this to bind coverage on a remediation timeline. SOC 2 auditors use it to set the test-of-design date for the next audit cycle. Customers use it to keep you on the approved-vendor list while you remediate. The plan is not a confession. It is a contract about what changes by when.

Step 5: Implement

The technical work itself is usually 4 to 40 hours per finding for a well-run M365 tenant. The longer end is anything involving a rollout sequence (Conditional Access changes, DMARC enforcement, Safe Links policies) where you stage the change in Report-only mode and watch it for a week before flipping. The shorter end is policy toggles and PowerShell one-liners.

Step 6: Verify implementation independently

Do not trust the same person who built the change to certify that it works. Either a different admin runs the verification PowerShell, or the original admin runs it and a manager signs off after reviewing the output. The point is the second pair of eyes. The failure mode this prevents is "I configured it and it looked right" when the policy was actually scoped to the wrong group.

Step 7: Document the new state for the next audit

Save the verification PowerShell output, screenshots from the admin portal, the Conditional Access policy export, the DKIM record, the DMARC policy. Tag it with the date and the control ID. The next time someone asks for evidence, you do not re-run the assessment. You hand them the file. Auditors and underwriters reading evidence prepared this way bill for less of their time, which gets remembered at renewal.

What not to do when the report lands

A handful of moves consistently make the situation worse. None of them are obvious until you have watched a few audits go sideways.

• Do not argue the finding without alternative facts. "We disagree with this finding" without a specific technical or scoping reason reads as defensive. Auditors weigh disagreement based on evidence. Pure pushback degrades the working relationship and rarely changes the outcome.
• Do not claim a remediation is impossible without explaining the alternative. Saying "we can't disable SMTP AUTH because the printer needs it" is a non-answer. The right move is "we cannot disable it tenant-wide because of MFP-X, so we are scoping the exception to a single mailbox locked to the printer's static IP, and here is the policy." The compensating control is the answer. Refusal alone is not.
• Do not sign attestations you cannot substantiate. Insurance applications and customer questionnaires increasingly include attestation language: "I certify that <control> is in place." If the control is not actually in place, you are signing a representation that the carrier can later use to deny a claim, or the customer can use to terminate. Attest to what is real; remediate what is not.
• Do not try to game the assessment. Turning on a control the day before the assessment, generating a screenshot, and turning it off afterwards is a fast way to fail an audit and a slow way to lose your insurance broker. The control history is in the audit log, and the auditor will look.
• Do not freelance the timeline with the carrier. "We will fix it eventually" is not a remediation plan. Concrete dates make the carrier's job easy. Vague language makes them write a worse policy. Be specific even when it is uncomfortable.

For a closely related view of how compromised tenants get through the same workflow after a real breach has happened, the BreachShield365 deep dive on post-breach CIS M365 Benchmark recovery walks through how findings interact with active incident response.

The cost of failure versus the cost of remediation

A 35-person professional services firm renewed cyber coverage in early 2026 with four CIS findings: audit log retention insufficient, OAuth user consent unrestricted, anti-phishing impersonation untuned, and DMARC policy stuck at p=none. The carrier's renewal terms changed.

Renewal premium increased 28 percent (from roughly $9,400 annual to $12,032), social engineering sub-limit dropped from $250,000 to $50,000, and the wire-transfer fraud sub-limit was excluded entirely until remediation evidence was submitted within 90 days. In dollar terms, the renewal-year impact was about $2,600 in additional premium plus a $200,000 reduction in social-engineering coverage capacity.

Estimated remediation cost: roughly $9,000 in third-party engineering time across two weekend windows, plus about 40 hours of internal staff time for staging, communication, and testing. The four findings shared infrastructure (anti-phishing tuning and DMARC enforcement got done in the same Defender session, while audit retention and OAuth consent are policy toggles), so the per-finding cost was much lower than four times a single finding.

The harder number is the contingent loss. Without remediation, a successful BEC wire of $80,000 (around the median reported figure for SMB invoice fraud incidents) hits the new $50,000 social-engineering sub-limit. The firm covers $30,000 out of pocket and consumes the sub-limit for the policy year. The same incident under the previous $250,000 sub-limit would have been fully covered. The expected-value math on remediation comes out heavily positive even at low BEC probabilities.

A small-business framing of the same trade-off, written for tenants that have not yet seen an audit, is in the SecureYourTenant guide on the CIS M365 Benchmark checklist for small business.

Common questions

Does failing CIS automatically mean failing SOC 2?

No. SOC 2 evaluates whether your control objectives are met given the design and operation of your environment, with mitigating controls allowed. A CIS Not Compliant finding becomes a SOC 2 problem only if the auditor cannot find a mitigating control and the deficiency is significant enough to warrant a qualified opinion. Most CIS findings produce control deficiencies in the SOC 2 report, not qualified opinions. The deficiency is visible to readers of the report, which is its own kind of pressure to remediate, but it is not the same as a fail.

How long do we have to remediate before the carrier or customer takes action?

Insurance carriers commonly accept 60 to 120-day remediation windows on Tier-1 findings, with the policy bound at standard terms conditional on evidence by the named date. Customer questionnaires often run 30 to 90-day windows depending on the contract size and the customer's own audit cycle. Regulatory frameworks vary widely. HIPAA corrective action plans run 12 to 24 months, PCI runs 90 days from finding to validated remediation, and NIST 800-171 plans of action and milestones often run 6 to 18 months. In every case, the timeline starts when you acknowledge the finding, not when the report was issued.

If our IT provider runs the assessment, are they allowed to also do the remediation?

For SOC 2 Type 2, no. The firm doing the assessment cannot also do the remediation, because that breaks auditor independence. For an internal CIS Benchmark review or an insurance-driven assessment, yes. The same provider can identify findings and fix them, and most SMBs prefer this for continuity. The hybrid pattern that comes up most often: an internal team does the day-to-day operations, an outside firm runs the annual independent assessment, and a third party (or the original outside firm) handles remediation projects. Independence on the assessment is what keeps the report credible to insurance and customers.

Our auditor flagged a control as Not Applicable. Is that a problem?

Not Applicable is a legitimate outcome and the right outcome for many controls. Examples: a control about Teams Phone configuration is Not Applicable if you do not license Teams Phone, and a control about Power BI tenant settings is Not Applicable if you have no Power BI deployment. The finding becomes a problem when Not Applicable was claimed for a control that does apply. Audit reviewers spot-check Not Applicable findings by sampling tenant configurations. An incorrectly-categorised Not Applicable can produce a worse outcome than an honest Not Compliant, because it implies the assessment process itself was sloppy.