CIS M365 Benchmark Checklist for Small Business

How to use this checklist

The CIS Microsoft 365 Foundations Benchmark is a roughly 200-page PDF. Most of it doesn't apply to a 30-person business. What follows is the slice that does: 37 controls, organized by the same section numbers CIS uses, scoped down so a working admin can walk a tenant in an evening and end up with a credible compliance position.

Each item lists: the control, the Implementation Group (IG1, IG2, or IG3), what "verified" means in plain language, and how to verify it (admin portal path or a PowerShell snippet). IG1 is the floor. IG2 and IG3 add depth for businesses with regulatory pressure or larger blast radius. If you are reading this because someone asked whether your tenant is "CIS-aligned," IG1 plus the five commonly missed items is the answer they want to see.

A note on relationship to neighboring posts. The M365 security checklist for 2026 is the broader practical baseline. This one is the formal CIS mapping. The implementation guide is the 72-hour rollout sequence. The CIS Benchmark versus Microsoft Secure Score piece explains why your Secure Score number doesn't tell you whether you're CIS-compliant.

Section 1: Account and authentication (8 items)

Identity is the floor. Eight controls, every one of them an IG1 item except where noted.

1.1: MFA enforced for all users (IG1). Verified means every licensed, sign-in-enabled user account has multi-factor authentication required by either Security Defaults or a Conditional Access policy. Verify in Entra admin center → Protection → Authentication methods → Activity: the count of MFA-capable users should equal the count of enabled users. PowerShell verification is in the snippet at the end of this section. What fails: per-user MFA configured on a handful of admins, "Security Defaults: off" because someone started building Conditional Access and never finished, and exempt accounts that aren't the documented break-glass pair.

1.2: MFA strengthened for admins (IG1). Verified means every account holding a privileged Entra role authenticates with a phishing-resistant factor: FIDO2 security key, Windows Hello for Business, certificate-based auth, or an authenticator-app push with number matching. SMS and voice-call MFA do not count. Verify under Entra → Protection → Authentication methods → Policies with admin-role users selected. What fails: an admin still on SMS because they "couldn't get the app to work" eight months ago.

1.3: Named admin accounts separate from daily-driver accounts (IG1). Verified means every human admin has two accounts: a normal mailbox account with no elevated roles, and a separate admin-firstname@ account that holds the role. Verify in Entra → Roles and administrators: open each role and confirm no member is also a daily mailbox user. This is one of the five most-commonly missed. See the section at the end for why.

1.4: Break-glass accounts documented and isolated (IG1). Verified means two cloud-only emergency-access accounts in the .onmicrosoft.com domain, excluded from every blocking Conditional Access policy, with passwords split between two physical safes, and a sign-in alert wired to a channel monitored by more than one person. Verify by listing exclusions on every CA policy and confirming both accounts appear. Verify the alert by intentionally signing one in and watching it trigger.

1.5: Sign-in risk and user risk policies configured (IG2). Verified means a sign-in risk policy that requires MFA at Medium-or-above and a user risk policy that requires password change at High. Entra ID P2 license required. Path: Entra → Protection → Identity Protection. What fails: a tenant that licensed P2 for the global admin only, so risk policies don't fire on the rest of the user base.

1.6: Conditional Access blocks legacy authentication (IG1). Verified means a CA policy named to convention (CA-Block-Legacy-Auth-001 or similar), state On, scoped All Users excluding break-glass, with Client apps set to Exchange ActiveSync clients plus Other clients, granting Block. Plus an Exchange Online authentication policy as backstop. The full procedure is in how to block legacy authentication in Microsoft 365.

1.7: Conditional Access requires compliant device for admins (IG2). Verified means a CA policy targeting the admin role groups that grants only when device is marked compliant by Intune. Path: Entra → Protection → Conditional Access, policy state On. What fails: a policy in Report-only for six months because nobody flipped the toggle after the rollout.

1.8: Conditional Access requires MFA for risky sign-ins (IG2). Verified means a CA policy with sign-in risk Medium and High that requires MFA, scoped to all users excluding break-glass. Acts as a safety net for token-replay scenarios where the user's primary MFA happened earlier in the day on a different device.

Quick verification snippet, listing every enabled user without a strong MFA method registered:

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","User.Read.All"

Get-MgUser -All -Property Id,UserPrincipalName,AccountEnabled |
  Where-Object { $_.AccountEnabled -eq $true } |
  ForEach-Object {
    $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
    $strong  = $methods | Where-Object {
      $_.AdditionalProperties["@odata.type"] -in @(
        "#microsoft.graph.fido2AuthenticationMethod",
        "#microsoft.graph.microsoftAuthenticatorAuthenticationMethod",
        "#microsoft.graph.windowsHelloForBusinessAuthenticationMethod"
      )
    }
    if (-not $strong) {
      [pscustomobject]@{ User = $_.UserPrincipalName; Status = "No phishing-resistant MFA" }
    }
  } | Export-Csv mfa-gaps.csv -NoTypeInformation

An empty CSV is the pass condition for items 1.1 and 1.2 combined.

Section 2: Application permissions (4 items)

OAuth consent phishing is the single fastest-growing post-MFA attack pattern. These four controls close the door.

2.1: User consent for new OAuth apps restricted to admin approval (IG1). Verified means Entra → Identity → Applications → Enterprise applications → Consent and permissions shows User consent set to "Do not allow user consent" or "Allow user consent for verified publishers, for selected permissions" with an admin-approval workflow configured. What fails: the default of "Allow user consent for apps" still in place, where a single phishing email then grants an attacker persistent mailbox access.

2.2: Periodic OAuth app review (IG1). Verified means a documented quarterly review owned by a named role (the security lead, or the senior admin if there isn't one), with the review walking Entra → Enterprise applications sorted by date added and revoking anything unrecognized or carrying high-risk scopes (Mail.ReadWrite, Files.ReadWrite.All, Sites.FullControl.All). Documentation should show the review date and the reviewer's name.

2.3: App registration restricted to admin role (IG1). Verified means Entra → Identity → Users → User settings shows "Users can register applications" set to No. By default this is Yes, which means any compromised user account can add an application, generate a client secret, and grant it long-lived access.

2.4: Service principal additions monitored (IG2). Verified means an alert policy in Microsoft Purview (or a Sentinel analytic rule) that fires on the audit operation Add service principal. Routes to a Teams channel or shared inbox watched by more than one admin. New service principals are how attacker-installed apps look in audit logs. Finding one within hours instead of months is the difference between cleanup and an incident response engagement.

Section 3: Data management (4 items)

3.1: Default external sharing setting evaluated and tightened (IG1). Verified means SharePoint admin center → Policies → Sharing shows External sharing at "New and existing guests" or stricter at the tenant level, with the same or stricter setting on every site that holds anything sensitive. What fails: the out-of-the-box default of "Anyone" is still in place. Anyone with a generated link can open the file with no sign-in.

3.2: Anonymous link expiration set (IG1). Verified means anonymous links default to 30 days or less, links default to Specific people rather than Anyone, and link permission defaults to View. Same SharePoint sharing panel.

3.3: Sensitivity labels deployed for "Confidential" content (IG2). Verified means at least three published labels (Public, Internal, Confidential) with the Confidential label configured to encrypt and to block external sharing. Path: Microsoft Purview → Information protection → Labels. This is one of the five commonly-missed items. Most SMB tenants have no labels at all, even on plans that license them.

3.4: DLP policy for external sharing of labeled content (IG2). Verified means a Data Loss Prevention policy that detects Confidential-labeled content shared outside the organization and either blocks the share or generates an audit record reviewed weekly. Path: Purview → Data loss prevention → Policies.

Section 5: Auditing (3 items)

A tenant with no logs is a black box during incident response. There is no item more frequently fudged on insurance questionnaires than audit retention.

5.1: Unified Audit Log enabled (IG1). Verified by running Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled from Exchange Online PowerShell. Result must be True. Tenants created after 2019 default to True, but it can be disabled, and re-enabled doesn't backfill missing data.

5.2: Retention extended to 365+ days (IG2). Verified means audit retention of at least 365 days. Default retention is 90 days on E3 and 180 days on E5. Ransomware investigations routinely need 12 months because attackers dwell 6–9 months before triggering. Audit (Premium) license, a Microsoft Sentinel deployment, or an open-source SIEM such as Wazuh consuming the Office 365 Management API all count. This is the single most-missed control at SMB scale.

PowerShell verification of audit configuration:

Connect-ExchangeOnline

# 5.1: UAL enabled
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

# 5.2: Retention on the default audit policy
Get-RetentionCompliancePolicy | Where-Object { $_.Workload -match "Audit" } |
  Select-Object Name, RetentionDuration, Enabled

# 6.8: Mailbox auditing enabled by default at the org level
Get-OrganizationConfig | Select-Object AuditDisabled

# Per-mailbox audit confirmation (sample first 5)
Get-Mailbox -ResultSize 5 | Select-Object UserPrincipalName, AuditEnabled, AuditLogAgeLimit

5.3: Alert policies for high-signal events configured (IG1). Verified means at minimum four alert policies in Purview → Audit → Alert policies: user consented to OAuth application, inbox rule created or modified to forward or delete, mailbox permission added, privileged role assigned. Each routed to a destination watched daily.

Section 6: Email and Exchange Online (8 items)

6.1: Authentication policies disable basic auth on all protocols (IG1). Verified by running Get-AuthenticationPolicy | Select Name, AllowBasicAuth* in Exchange Online PowerShell. Every AllowBasicAuth* field on the tenant default policy should be False. The companion to CA-001: protocol-layer enforcement that catches what Conditional Access misses.

6.2: SPF, DKIM, DMARC published with p=quarantine minimum (IG1). Verified by querying public DNS: SPF record with Microsoft's include and a hard fail (-all). DKIM CNAMEs published for selector1 and selector2. DMARC TXT at _dmarc. with at least p=quarantine and a real rua= reporting address. A p=none record doesn't pass. It is the staging step, not the destination.

6.3: Anti-phishing impersonation protection for executives (IG1). Verified means the Defender anti-phishing policy lists each executive (CEO, CFO, anyone authorized to wire money) by name in the protected senders list, plus protected domains for your own domain and any partner domain that has been spoofed before. Path: Defender portal → Email & collaboration → Threat policies → Anti-phishing. Another commonly-missed item. The default policy protects no specific users until you add them.

6.4: Anti-spoofing enabled (IG1). Verified means spoof intelligence is on and the default action for spoofed messages is Quarantine, not Junk folder. Same anti-phishing policy.

6.5: Safe Attachments active with Block plus Dynamic Delivery (IG1). Verified means a Safe Attachments policy applied to all recipients, action set to Block (or Dynamic Delivery for tenants with delay-sensitive workflows), redirect to a quarantine mailbox enabled. Defender for Office 365 license required.

6.6: Safe Links tenant-wide (IG1). Verified means a Safe Links policy applied to all recipients with rewrite-on, click-through warnings disabled, and Office and Teams scanning enabled. Verify by sending a test email containing a known-test URL and confirming the URL is rewritten to the Safe Links proxy.

6.7: Mailbox auto-forwarding to external recipients disabled (IG1). Verified means Defender → Email & collaboration → Threat policies → Anti-spam → Outbound spam policy has Automatic forwarding rules set to "Off (Forwarding is disabled)." This is the control that breaks the standard Business Email Compromise exfiltration loop. Confirm with the audit query for New-InboxRule entries containing ForwardTo.

6.8: Outlook Web Access mailbox audit log enabled (IG1). Verified means mailbox auditing is enabled by default at the organization level (Get-OrganizationConfig | Select AuditDisabled returns False) and individual mailboxes have AuditEnabled True with the standard set of audited operations. Microsoft enables this by default on new tenants but it can be disabled and stale tenants pre-2019 may not have it.

Section 7: Storage, SharePoint, and OneDrive (3 items)

7.1: Default external sharing matches policy (IG1). Verified means the SharePoint tenant default does not exceed the organization's documented sharing policy. For most SMBs that means New and existing guests, never Anyone. Per-site overrides should make sharing more restrictive, never more permissive.

7.2: Sharing capability audit completed (IG1). Verified means a documented audit (last 90 days) of every site's sharing capability, walked with the data owner, with overrides justified. The PowerShell pull is Get-SPOSite -Limit All | Select Url, SharingCapability, output saved as the audit artifact.

7.3: Anonymous links expire automatically (IG1). Verified means anonymous link default expiration is 30 days or less at the tenant, and individual sites that hold sensitive data either disable anonymous links entirely or set a tighter expiry.

Section 8: Mobile device management (4 items)

8.1: Compliance policies enforced (IG1). Verified means an Intune compliance policy per platform: Windows requires BitLocker, Secure Boot, antivirus, real-time protection, OS at N-1 minimum, password length 12+, lockout 15 minutes. macOS requires FileVault, system integrity protection, OS minimum, gatekeeper. iOS and Android require encryption, jailbreak/root blocked, OS minimum, six-digit PIN minimum. Path: Intune → Devices → Compliance policies.

8.2: App protection policies for BYOD (IG1). Verified means Intune app protection policies for iOS and Android applied to all Microsoft mobile apps with: prevent backup to iCloud and Google, prevent copy-paste to non-managed apps, require PIN on launch, block screen capture (Android), encrypt org data, wipe org data after 90 days offline.

8.3: Enrollment restrictions to corporate or approved BYOD only (IG1). Verified at Intune → Devices → Enrollment → Enrollment device platform restrictions: personal Windows blocked, personal Linux blocked, personal iOS/Android allowed only with app protection policies in scope.

8.4: Lost device wipe procedure documented (IG1). Verified means a written procedure (link in the runbook is fine) covering who initiates a wipe, what evidence triggers it, and how the wipe is logged. Path: Intune → Devices → All devices. The wipe action is one click. The documented decision about when to use it is the control.

Section 9: Microsoft Teams (3 items)

9.1: External access restricted to allow-listed domains or specific tenants (IG1). Verified at Teams admin center → Users → External access: external access set to either Allow only specific domains (with the list reflecting actual partner relationships) or Allow specific external domains and block all others. The default of "Allow all external domains" is a fail.

9.2: Guest access reviewed (IG1). Verified means a documented quarterly review of guest accounts in Teams admin center → Users → Guest access, with stale guests (no sign-in in 90 days) removed. Microsoft's Access Reviews feature can automate the review portion if licensed.

9.3: Meeting and chat policies aligned with sensitivity classification (IG2). Verified means meeting policies that match data classification: external participant restrictions for meetings tagged sensitive, recording restrictions on those meetings, and chat policies that block file uploads of certain sensitivity labels.

The five SMBs miss most often (and why)

Across hundreds of tenants we've seen, the same five items fail audits more often than any other on this list. If you walk this checklist top to bottom and your tenant trips on five things, this is the list it trips on.

1. Audit log retention (5.2). The default 90 or 180 days isn't enough. SMBs miss this because the fix needs either a license upgrade, a SIEM, or both, and the failure mode is invisible until the day you actually need year-old logs and don't have them.
2. Named admin separation (1.3). Founders and senior staff hate logging into a second account to do admin work. So they don't, and the daily mailbox stays a Global Admin. One phish later and the attacker has tenant-wide control instead of one person's email.
3. OAuth admin approval (2.1). The default lets users grant consent. Most SMB admins never change it because they didn't know the toggle existed. Single biggest enabler of post-MFA persistent compromise.
4. Sensitivity labels (3.3). Even tenants on Microsoft 365 Business Premium with Information Protection licensed often have zero published labels. The labeling work is non-zero. It requires a conversation about what content is what, so it gets shelved indefinitely.
5. Anti-phishing impersonation per executive (6.3). The Defender default policy doesn't list anyone as "protected." You have to manually add each executive by name, and most teams never circle back to do so. CEO-impersonation phishing is the result.

Cyber-insurance pass condition for an SMB: every IG1 item above plus those five. That combination satisfies the questions a renewal underwriter asks and matches what we see carriers actually verify when they sample tenants. The breach-prevention angle on the same controls is on BreachShield365 in how the CIS benchmark prevents M365 breaches.

Common questions

We're on Business Premium, not E5. How much of this can we actually do?

Most of it. Every IG1 item on this list works on Business Premium except sign-in risk and user risk policies (1.5), which need Entra ID P2. P2 is available as a per-user add-on for under $10 a month if you only need it on the admin accounts, and the policies still apply to all users when configured. Sensitivity labels and DLP work on Business Premium. Defender Plan 1 (Safe Links, Safe Attachments, anti-phishing impersonation) is included in Business Premium. The only items that genuinely need E5 are advanced eDiscovery, Audit (Premium) for the year-plus retention in 5.2, and continuous access evaluation. For 5.2, a SIEM such as Sentinel or Wazuh consuming the Office 365 Management API is the cheaper path.

Is "CIS-aligned" the same as "CIS-certified"?

No, and don't claim certification. CIS doesn't certify configurations directly. What you can credibly claim is "configured to CIS Microsoft 365 Foundations Benchmark Level 1," with the assessment evidence (a walkthrough of this checklist with dates, names, and PowerShell output) on file. Some auditors and carriers will accept that. Others will require a third-party assessor to attest. The configuration work is the same either way. The difference is who signs off on the result.

How long does it actually take to walk this checklist on a tenant?

Walking it (just the verification, not remediation) takes about three hours on a clean tenant, closer to an evening if you stop to capture screenshots and PowerShell output for an audit file. Remediation is the variable. A tenant that's been hardened informally over time usually trips on three to five items and closes them in a day. A tenant that's never been hardened (Security Defaults plus default sharing plus default policies) takes a full week of evenings to bring to IG1, and the rollout sequence in how to implement the CIS M365 benchmark is the order to do it in.

Does Microsoft Secure Score tell me whether I'm CIS-compliant?

No. The two measure different things and disagree often. Secure Score weights every control by Microsoft's internal model and counts partial implementations. The CIS benchmark is binary per item. We've seen tenants at 80% Secure Score that fail four of the five most-missed items above, and tenants at 55% Secure Score that pass IG1 cleanly because their gaps were in low-weighted controls. The breakdown is in CIS Benchmark versus Microsoft Secure Score.

What's the difference between this checklist and the M365 security checklist for 2026?

The M365 security checklist for 2026 is the practical baseline organized by deployment layer (identity, Conditional Access, email, endpoint, sharing, logging): what to deploy and why. This post is the formal CIS section-by-section self-assessment, the one you tick off when an auditor or carrier asks. Most of the controls overlap. The framing differs. If you're building, read the 2026 checklist. If you're proving, walk this one.