Implement the CIS M365 Benchmark for Small Business

A 90-day rollout sequence that respects how the controls actually depend on each other.

By , Founder & Principal Security Consultant · Published · Last updated

TL;DR

  • The CIS M365 Foundations Benchmark works on Business Premium for Level 1, and trying to do every section in parallel is the single biggest reason rollouts stall.
  • The right order is identity first, then email, then app permissions and sharing, then auditing and mobile, then storage and Teams, then validation. Each stage assumes the prior stage held.
  • Plan for roughly 90 calendar days. Actual configuration time runs 30 to 60 hours depending on tenant size and how much pre-existing config you find.
  • Run a discovery scan before you change anything (CIS-CAT, M365DSC, or a Secure Score export) so you can prove the delta at the end.
  • Treat the benchmark as a living standard. A quarterly drift check and an annual reassessment are part of the deployment, not optional follow-on work.

Why the order matters more than the controls

Every CIS rollout that fails fails for the same reason. Someone opens the benchmark PDF, picks the dozen most obvious-looking controls, and tries to flip them all in a weekend. Three weeks later the help desk is buried in lockouts, the sales team can't share quotes with their distributor, and the leadership team is asking whether security is worth the disruption.

The benchmark itself doesn't tell you the order. It's a reference document, not a deployment plan. Each control assumes a healthy state in the controls around it. Conditional Access without MFA enrolled is a brick wall. Anti-phishing impersonation protection without DMARC is a tripwire that fires on legitimate mail. External sharing restrictions without sensitivity labels just push the problem onto the user, who then emails the file to themselves.

A workable rollout sequences the sections so each one rests on the last. That's what the 90-day plan below does. If you want the line-item verification list rather than the deployment plan, the sibling post is the CIS M365 Benchmark checklist for small business. If you're comparing CIS against the Secure Score number Microsoft shows in your admin center, the framing is in CIS Benchmark vs Microsoft Secure Score.

Days 0–7: Inventory and license check

The first week is reconnaissance. Don't change anything. You're trying to find out what you actually have so you can prove the delta at the end.

Confirm the licensing floor. CIS Level 1 is achievable on Microsoft 365 Business Premium for tenants up to 300 seats. Above that, you need Business Premium plus add-ons or an E3/E5 SKU to cover audit retention and Defender features. If you're on Business Standard or Business Basic, stop here and price the upgrade. Trying to implement Level 1 without Business Premium leaves you missing Conditional Access, Defender for Office 365, and Intune. The gap can't be papered over with policy.

Inventory the current state of the tenant: existing Conditional Access policies and their assignments, MFA enrollment by user, audit log retention setting, default external sharing tier in SharePoint and OneDrive, anti-phishing policy assignments, and the list of users with privileged roles. A spreadsheet is fine. The goal is a snapshot you can compare against in week 13.

Establish a baseline Secure Score and export it. The number is imperfect but it's the easiest before/after artifact to hand to a board. Pull it via PowerShell so you have the supporting data, not just the screenshot.

Connect-MgGraph -Scopes "SecurityEvents.Read.All"

$score = Get-MgSecuritySecureScore -Top 1
$controls = Get-MgSecuritySecureScoreControlProfile -All

$score | Select-Object CurrentScore, MaxScore, ActiveUserCount, CreatedDateTime |
  Export-Csv "secure-score-baseline-$(Get-Date -f yyyyMMdd).csv" -NoTypeInformation

$controls |
  Select-Object Id, Title, ControlCategory, MaxScore, ImplementationCost, UserImpact, Tier |
  Export-Csv "secure-score-controls-$(Get-Date -f yyyyMMdd).csv" -NoTypeInformation

Then run a real discovery scan. Two practical options: CIS-CAT Pro, if you have a CIS SecureSuite membership, or Microsoft365DSC, which is free and produces a configuration export you can diff against the Microsoft-published CIS reference. Either tool will surface settings that the admin portals hide three menus deep. Without a discovery scan, you can't tell remediation from luck. You'll fix something that was already fine and miss something that was broken.

End of week 1, you should have: confirmed licensing, a tenant snapshot, a Secure Score baseline export, and a gap report. That's the foundation everything else stands on.

Days 7–21: Section 1, Identity controls

Identity is first because every other control assumes a trustworthy account. If the wrong people can sign in, the rest of the benchmark is decoration.

Enforce MFA universally. Not "for admins." Not "for users with privileged data." Universally. Every account that authenticates against the tenant uses a second factor or an equivalent phishing-resistant method (FIDO2 key, Windows Hello, certificate-based). The exceptions list is exactly two break-glass accounts, locked in a vault, with 64-character passwords and Conditional Access exclusions documented.

Build the Conditional Access baseline. The same five-policy pattern that anchors the M365 security checklist for 2026 applies here: CA-001 require MFA for all users, CA-002 block legacy authentication, CA-003 require compliant or hybrid-joined device for admins, CA-004 sign-in risk policy for high-risk sessions, CA-005 location-based controls for impossible travel. Stage every policy in Report-only for at least seven days before flipping to On.

Block legacy authentication explicitly. CA-002 covers most of it, but the Exchange Online authentication policy backstop catches the gaps where Conditional Access scoping misses. Full sequence is in how to block legacy authentication in Microsoft 365.

Separate admin from daily-driver. Anyone with Global Administrator, Exchange Administrator, SharePoint Administrator, or any other privileged role gets a second account for that role. The daily-driver mailbox doesn't hold privileges, and the admin account doesn't read mail. This is the single most violated CIS control in real-world tenants and the one that does the most damage when it's missing.

Configure two break-glass accounts. Cloud-only, MFA-excluded, password in a sealed envelope or a vault, names that don't follow your naming convention so they don't show up in casual user enumeration. Document the recovery procedure now, before you need it at 2 a.m.

Days 21–35: Section 6, Email security

Email is second because it's the most-attacked surface and because identity has to be solid before you start filtering at the protocol layer.

DMARC, in sequence. Publish DMARC at p=none with reporting addresses (rua and ruf), watch the reports for two weeks, fix any legitimate sending sources that fail alignment, then move to p=quarantine with a small percentage tag, then to full quarantine. Don't jump to p=reject until you've sat at quarantine for at least 30 days with clean reports. Skipping the staging is how you bounce the CEO's mail to the board.

Anti-phishing impersonation protection for named executives. List the people most likely to be impersonated (CEO, CFO, anyone authorized to release funds) and add them to the protected senders list in the Microsoft Defender anti-phishing policy. Set the action on impersonation to "Move to Junk" or "Quarantine" depending on your appetite for false positives.

Safe Links and Safe Attachments. Both default policies in Defender for Office 365 are decent starting points. The CIS recommendations tighten a few specific settings (block instead of warn on detection, scan attachments before delivery rather than dynamic delivery). Roll those out organization-wide.

Tenant-wide automatic forwarding restriction. The mail-flow rule that blocks external auto-forwarding is the single highest-ROI email control after MFA. The forwarding rule is the most common persistence mechanism in compromised mailboxes. The cross-network detail is in the CIS benchmark email security controls breakdown on EmailShield365.

Authentication policies that block basic auth at the mailbox layer. Already covered if you completed the legacy auth backstop in week 2. Verify it's still in place and inherited by every mailbox provisioned since.

Many cyber insurance applications now ask for a CIS-aligned baseline by name. The mapping between the benchmark and what underwriters actually score is on InsurableIT: CIS M365 Benchmark report for auditors and underwriters.

Days 35–49: Sections 2 and 3, Application permissions and data management

With identity and email locked down, the next exposure is the apps users authorize against the tenant and the files they share outside it.

Restrict OAuth user consent. The default in many tenants is "users can consent to apps," which means a phishing email asking the user to "verify your Outlook" can hand a third-party app full mailbox read access without ever touching a password. Change the user consent setting in Entra ID to "Allow user consent for apps from verified publishers, for selected permissions" or, more conservatively, disable user consent and require admin approval for every app registration. The CIS Level 1 control is the verified-publishers tier. Level 2 is admin approval only.

Tighten default external sharing. The CIS recommendation is "Existing external users" or "Only people in your organization" as the default. "Anyone" links are a Level 2 finding for a reason. Existing folders and sites that already have anonymous links keep working. Only new sharing actions are constrained.

Anonymous link expiration. Where anonymous links are still allowed for specific business reasons, they expire automatically after 30 days. CIS recommends seven days for tightest posture. The expiration is the safety net that limits damage when someone forwards a link to the wrong recipient.

Sensitivity labels for "Confidential" content. Even on Business Premium you can publish a small set of labels (Public, Internal, Confidential) and use auto-classification rules for credit card numbers, Social Security numbers, and similar pattern matches. Auto-classify is a Business Premium feature. Full manual labeling and Confidential watermarking work everywhere. The point isn't perfect classification on day one. It's giving users a button to press and a record of who pressed it.

Days 49–63: Sections 5 and 8, Auditing and mobile

The first half of the rollout was preventive. The second half is detective and operational. You're building the ability to see what's happening and the controls to keep mobile devices from undoing the work above.

Extend audit log retention to 365 days minimum. The default is 180 days on most Business Premium tenants and 365 on E5. You can extend Business Premium retention via add-on or via the audit retention policy if your seat count justifies it. The reason to extend: post-breach forensic timelines routinely run beyond 180 days, and the control you wish you had is always the one that aged off two weeks before you went looking.

Alert policies for the four canonical persistence indicators: external auto-forwarding rules created, OAuth app consents granted, mailbox permissions added (especially Send As and Full Access), and privileged role assignments changed. Each of those is a single alert policy in the Microsoft Defender or compliance portal. Configure them all in one sitting, route the alerts to a monitored mailbox or a SIEM, and document the triage process.

Intune compliance policies. The CIS minimum for managed devices is BitLocker (Windows) or FileVault (Mac), supported OS version, password complexity, and screen lock timeout. Roll those out in Intune as a compliance policy, then reference the policy from the device-compliant Conditional Access rule built in week 2.

App protection policies for BYOD. App protection (formerly MAM) restricts copy/paste between corporate and personal apps, requires a PIN to open Outlook on a personal phone, and remotely wipes corporate data without touching the rest of the device. Two policies cover the essentials: one for iOS, one for Android, both targeting the Microsoft mobile app suite.

Days 63–77: Sections 7 and 9, Storage and Teams

By this point identity, email, app consent, and auditing are in place. The remaining gaps are usually in storage defaults and the Teams configuration that nobody touched on tenant creation.

SharePoint and OneDrive default sharing alignment. CIS Level 1 wants SharePoint at "New and existing guests" or tighter, OneDrive at the same or tighter, and the default link type set to "People with existing access" or "Specific people." The default link type is the lever that decides whether a casual share is broad or narrow. Flip it once and every Share dialog from then on opens at the safe default.

Teams external access restrictions. The benchmark wants federated Teams chat allowed only with specific domains rather than open federation, and guest access scoped to specific teams rather than tenant-wide. Open federation means anyone with a Teams account anywhere can message your users. Closing it removes a vector that very few SMBs actually use deliberately.

Guest access review. Run a one-time audit of every guest account in the tenant, who invited them, when they last signed in, and whether they still need access. Most tenants find 30% of guests haven't signed in for 90 days. Remove them. Then schedule the access review to recur quarterly via Entra ID access reviews or, if that's not licensed, via a calendar reminder and the same PowerShell query.

Days 77–90: Validation and attestation

The last two weeks are about proving what you did and packaging it for the people who will ask.

Re-run the discovery scan from week 1. Same tool, same scope, fresh report. The diff against the baseline is your evidence package. Where the new scan still flags findings, document the rationale: license-gated, business-required exception, or scheduled remediation.

Export the post-implementation Conditional Access policy state. Underwriters and auditors increasingly ask for the actual policy bodies rather than a summary slide. This script gives you the JSON they want.

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

$ts = Get-Date -Format yyyyMMdd
$policies = Get-MgIdentityConditionalAccessPolicy -All

$policies |
  Select-Object Id, DisplayName, State, CreatedDateTime, ModifiedDateTime,
                @{n='Conditions';e={$_.Conditions | ConvertTo-Json -Depth 6 -Compress}},
                @{n='GrantControls';e={$_.GrantControls | ConvertTo-Json -Depth 6 -Compress}},
                @{n='SessionControls';e={$_.SessionControls | ConvertTo-Json -Depth 6 -Compress}} |
  Export-Csv "ca-policies-evidence-$ts.csv" -NoTypeInformation

$policies | ConvertTo-Json -Depth 10 | Out-File "ca-policies-evidence-$ts.json"

Document gaps and the remediation plan. Anything still failing the benchmark gets a row: control number, current state, target state, planned remediation, owner, target date. That document is your roadmap for the next quarter and the artifact you hand to your insurance broker at renewal.

Run a tabletop exercise on a CIS-aligned breach scenario. The scenario doesn't need to be elaborate. A stolen executive password followed by an OAuth consent grant exercises detection, response, and containment well enough. The point is to find out which CIS control would have caught the attack and which one didn't, while the implementation is fresh.

Prepare for annual attestation. Whether the attestation goes to a cyber insurer, a customer's vendor risk team, or your own board, the package is the same: discovery scan diff, Secure Score before/after, Conditional Access policy export, alert policy inventory, and the gap remediation plan. A real-world example of what that package looks like is in the M365 security implementation case study.

The five most common rollout mistakes

Every failed implementation we've reviewed makes at least one of these five errors, and most make two or three.

  1. Skipping the pre-implementation discovery scan. Without a baseline you can't tell what you fixed from what was already fine, and you also can't prove the delta to anyone who asks. Always scan first.
  2. Doing all sections in parallel. Identity has to settle before email policies bind correctly. App consent has to be locked before SharePoint sharing controls matter. Parallel rollouts produce cascading lockouts. Sequential rollouts produce a stable tenant.
  3. Not testing Conditional Access in Report-only mode first. Every CA policy goes into Report-only for at least seven days. Watch the workbook, fix the false positives, then enforce. The seven-day wait is the cheapest insurance you'll buy.
  4. Manually applying CIS recommendations without scripting. Hand-clicked settings drift back within months as new admins are onboarded and exceptions get carved. Codify every change in PowerShell or DSC so the configuration is versioned and reproducible.
  5. Treating it as one-time work. CIS publishes new versions of the benchmark. Microsoft adds new settings. Users add new apps. Quarterly drift checks and an annual full reassessment keep the baseline real. Without them, the implementation date is the last day the tenant met the standard.

The handoff to ongoing maintenance

Day 90 isn't the finish line. It's the handoff. Four practices keep the baseline alive:

  • Quarterly CIS drift check. Re-run the discovery scan, diff against the day-90 export, and remediate anything new. One day of work per quarter, scheduled.
  • Annual full reassessment. The benchmark version that was current on day 90 won't be current twelve months later. Pull the latest CIS M365 Foundations Benchmark, re-map your controls, refresh the documentation.
  • Named control owner per CIS section. Someone owns identity. Someone owns email. Someone owns Teams. Without owners, drift accumulates anonymously. With owners, drift is somebody's job to explain.
  • Change-management process for deviations. Any time someone wants to weaken a CIS-aligned control (widen sharing, exclude a user from MFA, allow basic auth on a mailbox), that's a documented change with a business case, an expiration date, and an owner. The post-breach pattern after most CIS-aligned tenants get hit is "we excused this control once and never re-enabled it." That's what a change-management process prevents. Recovery context is on post-breach CIS M365 benchmark recovery on BreachShield365.

Sample timelines and budget by SMB size

Calendar time and effort scale with seat count, but not linearly. The discovery and policy work is mostly fixed, while the user-facing remediation grows with people. Numbers below cover labor (internal or contracted), tooling (CIS-CAT or M365DSC, plus a baseline endpoint manager), and any license uplift if the starting tier is below Business Premium.

  • 25-person organization: 60 to 90 calendar days, roughly $8,000 fully loaded. Most of the work is config and documentation, and user-facing remediation is small enough to absorb in a single training session.
  • 50-person organization: 75 to 110 calendar days, roughly $14,000 fully loaded. Two waves of MFA enrollment and one round of legacy-auth scanner remediation typically extend the timeline by two weeks beyond the 25-person case.
  • 100-person organization: 105 to 150 calendar days, roughly $25,000 fully loaded. Multiple departments, more BYOD diversity, more inherited apps consented over the years. The discovery and OAuth review stage alone can take three weeks.

Above 100 seats the math shifts, and you're closer to the lower end of the mid-market range and the playbook needs more formality (change advisory board, documented runbooks, possibly an external assessor for the day-90 attestation). The 90-day frame still works as a target. It just consumes more of someone's full-time attention. The DIY-versus-managed framing is in managed M365 security vs. DIY.

Get the free M365 Security Settings Guide

No spam. Unsubscribe anytime.

Common questions

Do we really need 90 days, or can we compress it?

You can compress the configuration work to roughly two weeks of focused effort. What you can't compress are the staging windows: seven days of Conditional Access in Report-only, two weeks of DMARC at p=none before quarantine, the propagation delay on Intune compliance policies. Those windows aren't bureaucratic. They're how you avoid bouncing legitimate mail and locking out users. A 30-day compressed timeline is realistic for a 25-person org. A true 90-day timeline gives you margin to fix what discovery uncovers without rushing.

Can we get to CIS Level 1 on Business Premium, or do we need E5?

Business Premium covers the overwhelming majority of Level 1. The gaps are around extended audit retention beyond 180 days, advanced eDiscovery, attack simulation training, and some sensitivity-label automation. For most SMBs those gaps are either Level 2 territory or addressable with add-ons (Defender for Office 365 P2, audit retention add-on) at meaningfully lower cost than full E5 conversion. Don't let licensing uncertainty stall the rollout. Do the controls Business Premium supports, then evaluate add-ons against actual usage.

Where do we start if we already have some CIS controls in place?

Run the day-1 discovery scan anyway. Most tenants we audit have three to five Level 1 controls in place, two more partially in place, and a dozen still default. The scan tells you which is which. Don't trust memory. Controls get added and silently disabled. The scan is honest about state in a way an admin's recollection isn't.

What's the difference between this rollout plan and the CIS checklist?

This post is the time-sequenced deployment plan: what to do, in what order, over 90 days. The CIS M365 Benchmark checklist for small business is the line-item verification list: what each control is, what setting fulfills it, how to confirm. Use this post to plan the rollout. Use the checklist as the verification artifact at day 90 and at every quarterly drift check.

Who should own the rollout if we don't have a security team?

The IT generalist or MSP that runs the tenant should own the configuration work. A business sponsor (typically the COO or operations lead) should own the user-communication piece and the change exceptions. If that combination isn't available internally, an external M365 security baseline deployment compresses the timeline and absorbs the configuration risk. The framing is in managed M365 security vs. DIY. Either way, someone names the control owner per section by day 90, or the implementation starts drifting on day 91.

Ready to start the 90-day plan?

Begin with a tenant risk check to confirm the day-1 baseline. The output maps directly to the CIS sections in the rollout above, so you start week one knowing exactly where the gaps are.

Run Your Tenant Assessment