Post-Breach CIS M365 Benchmark Recovery

Why CIS is the right target for the 30 to 90 day window

The first 30 days after a breach feel like firefighting. Hour-by-hour containment, notification calls, the carrier's forensic firm asking for log exports at 9pm on a Tuesday. Once that quiets down, a different question lands on your desk: what does "secure now" actually look like, and how do we prove it?

Without a named target, recovery turns into a list of one-off fixes nobody can audit. Reset some passwords. Block legacy auth. Disable forwarding. Hope that's enough. It usually isn't, and there's no way to demonstrate that it is.

The CIS Microsoft 365 Foundations Benchmark gives you a published, numbered, version-controlled target state. Around 80 controls in the current release, organized into Implementation Group 1 (the basic baseline a 30-person business can run on its own) and Implementation Group 2 (the stronger posture insurance underwriters and procurement teams expect from a 250-person business handling regulated data).

Three audiences care that you picked CIS specifically:

• Your cyber insurance carrier. The renewal application after a breach asks "what controls have you implemented since the incident?" An answer of "we now align with CIS M365 Benchmark IG1" is a sentence underwriters know how to price. "We tightened things up" is not.
• The forensic firm closing out the engagement. Their final report wants a remediation section. "Tenant remediated to CIS IG1 baseline, gap analysis attached" reads cleanly. A bullet list of ad-hoc fixes does not.
• Your customers and board. Procurement questionnaires from your own customers will land in the next 90 days asking what you did. A named framework with a defined scope is the answer that ends the thread.

The prevention-side companion to this plan is on the CIS M365 Benchmark for breach prevention. Same controls, different framing. That piece is for the tenant that hasn't been breached yet. This one is for the tenant that has, and now needs to recover into the same target state on a compressed timeline.

Days 0–14: address the attack vector first

The controls you prioritize in the first two weeks should map directly to how you got compromised. The Benchmark covers a lot of ground. You don't have time to walk it linearly. Pick the section that matches the breach pattern, fix those controls hard, then move on.

Three patterns cover the majority of SMB M365 incidents we see, and each one has a CIS section that becomes the first 14 days of work:

• Compromise via legacy authentication or password spray. Prioritize CIS section 1 (account and authentication) and section 6 (Exchange Online). Legacy auth blocked tenant-wide via Conditional Access plus an Exchange Online auth policy backstop. Per-user MFA replaced with CA-enforced MFA. Sign-in risk policies turned on. The full mechanics of the legacy-auth side are on how to block legacy authentication in Microsoft 365.
• Compromise via OAuth consent phishing. Prioritize section 1 application-permission controls. Restrict user consent to admin approval, review every Enterprise Application created in the 90 days before the breach, set up the admin-consent workflow so future requests don't pile up unattended.
• Compromise via token theft or adversary-in-the-middle phishing. Prioritize section 1 Conditional Access controls and section 5 (Defender). Phishing-resistant MFA for admins (FIDO2 keys or Windows Hello), token lifetime policies tightened, sign-in risk and user risk policies set to require password change plus MFA.

Document which pattern matched your incident and which controls you prioritized. The carrier will ask, and the audit trail of "we identified vector X, fixed controls Y" is more credible than "we did everything at once."

By day 14, the door the attacker walked through should be closed and verified shut. Sign-in logs should show zero successful authentications via the original vector. If they don't, days 0 to 14 aren't done yet, regardless of what the calendar says.

Days 14–30: Implementation Group 1 across the tenant

Once the attack vector is closed, broaden the scope. Implementation Group 1 is the basic baseline the CIS authors expect every M365 tenant to meet, regardless of size or industry. About 40 controls, most of them configuration changes rather than license upgrades.

The IG1 controls cluster into five groups, and the order below is the rollout sequence we run for SMBs in this window:

1. Identity baseline. MFA universal via Conditional Access, legacy auth blocked, no more than four Global Admins, two break-glass accounts excluded from CA and stored offline, guest-user invitation restricted, self-service password reset configured.
2. Email security baseline. Tenant-wide block on auto-forwarding to external recipients, anti-phishing policy with impersonation protection for executives and the finance team, Safe Attachments and Safe Links enabled where the license supports them, SPF / DKIM / DMARC published and in enforcement mode.
3. Audit and monitoring baseline. Unified Audit Log enabled (still default-off for some legacy tenants), audit log retention raised from 90 days to 365 days minimum, mailbox auditing on for every user and shared mailbox.
4. Data protection baseline. External sharing restricted on SharePoint and OneDrive, anonymous link expiration set, OneDrive sync limited to domain-joined or Intune-compliant devices.
5. Defender baseline. Anti-malware policies tightened, alert policies turned on for impossible travel, mass file download, and suspicious mail forwarding rules. The alert that fires on day 47 about a new forwarding rule is what catches re-entry attempts during the recovery window.

IG1 takes most SMBs five to eight working days of focused configuration work. Schedule it as a project, not as background. Half-finished IG1 is worse than no IG1 at all because you can't honestly claim either state to the carrier.

Days 30–60: Implementation Group 2 in the remaining sections

IG2 is where the post-breach posture pulls ahead of where you were before the incident. These are the controls the carrier won't strictly require for renewal but absolutely will reward with better pricing, and that procurement questionnaires from your own customers will start asking about within six months.

The IG2 additions worth landing in days 30 to 60:

• Privileged Identity Management. Admin roles become eligible-not-active by default. Activation requires justification, MFA, and a time-bound window. The standing Global Admin assignment becomes a one-hour activation when needed, logged and reviewable.
• Conditional Access policy expansion. Beyond MFA-everywhere, layer in policies for compliant device required (admins), session controls for unmanaged devices, and country-based blocks for geographies you don't operate in.
• Sensitivity labels for confidential data. A small label set (Public, Internal, Confidential, Restricted) applied to SharePoint sites and Teams that hold regulated data. Encryption tied to label for the top tier.
• Mobile device management for BYOD. Intune app protection policies on personal phones accessing mail, so a stolen phone or a sacked employee doesn't walk out with a year of mailbox content.
• Defender for Cloud Apps integration. Anomaly detection policies for impossible travel, mass download, and OAuth app risk. The catch rate during recovery is high because attackers often probe a tenant a second time within 60 days.

IG2 takes longer because some controls require licensing decisions (Entra ID P2 for PIM and risk policies, M365 E5 or stand-alone Defender for Cloud Apps for the anomaly engine). Make those decisions in week 4 so the licenses are live before you start the work in weeks 5 and 6.

The 10 controls every post-breach plan needs, regardless of vector

Across every post-breach engagement, the same ten CIS controls show up in the final remediation list. If you build nothing else, build these. Each one maps to a specific failure mode we've watched play out in real incidents.

1. MFA enforcement universal, no exclusions other than break-glass. Per-user MFA toggled on the user object is not the same thing. CIS section 1 wants Conditional Access policies that enforce MFA across all cloud apps, with a single excluded group containing two emergency accounts.
2. Legacy authentication blocked tenant-wide. Conditional Access policy for legacy clients plus an Exchange Online authentication policy as a backstop. Either alone is fragile. Together they're durable.
3. Conditional Access policies for risky sign-ins, risky users, and admin compliant-device. Sign-in risk and user risk both need their own policy. Admins need a separate policy that requires a compliant or hybrid-joined device.
4. OAuth user consent restricted to admin approval. Users can request, admins approve. Without this, OAuth consent phishing remains a wide-open door regardless of MFA strength.
5. Tenant-wide block on auto-forwarding to external recipients. Exchange transport rule, not just per-user mailbox setting. The transport rule catches both inbox-rule forwarding and mailbox-level ForwardingSmtpAddress.
6. Audit log retention raised to 365 days minimum. Default 90 days fails almost every breach investigation. License the extension or upgrade to E5. The cost is rounding error against a single forensic engagement.
7. Anti-phishing policy with impersonation protection on executives. List the CEO, CFO, CISO, and head of finance as protected users. Add the corporate domain as a protected domain. Enable mailbox intelligence.
8. Sensitivity labels rolled out for confidential and restricted data. Even a four-tier label scheme applied to the top 10 SharePoint sites is enough to demonstrate data-classification maturity to a customer auditor.
9. Privileged Identity Management for every admin role. Eligible by default, activated on demand. A standing Global Admin role is a permanent attack surface. PIM converts it to a temporary one.
10. Mobile device management for BYOD endpoints accessing M365. Intune app protection policies for personal devices, full Intune enrollment for corporate ones. The recovery is where you draw the line.

If your tenant came out of recovery with all 10 in place and verified, you're materially ahead of where you were on the day the attacker got in. That's the point of the exercise. Going back to the same posture would mean choosing to be breached again on the same vector.

Days 60–90: validation, documentation, and external attestation

The last 30 days are the part most engagements rush through. The configuration work is done, energy is low, and there's a temptation to declare victory. Don't. The validation phase is what makes the rest of the work defensible.

Five outputs in this window:

• Independent post-recovery CIS assessment. Either an external consultant or, at minimum, an internal team member who didn't run the remediation. Run a CIS-aligned scan (Microsoft Secure Score with the CIS overlay, or a third-party tool like Nodeware or Hyperproof). Score against IG1 and IG2.
• Gap analysis document. Every IG1 control: implemented, partial, or not applicable, with evidence reference for each. IG2 controls scored the same way. The gaps that remain at day 90 are explicitly accepted residual risk, signed off by leadership.
• Remediation log. Chronological record of every change made during the 90 days, with timestamp, change description, and the CIS control number it satisfies. This is the document the carrier wants attached to your renewal application.
• Post-recovery CIS attestation letter. One page. Names the framework version, names the implementation group target, names the assessment date, lists who performed the assessment, and is signed by an officer of the company. This is what gets sent to customers asking the procurement-questionnaire question.
• Evidence package for the cyber carrier. Screenshots and policy exports for the high-priority controls (MFA enforcement, legacy auth block, audit log retention, OAuth consent restriction). Carriers won't ask for all 80 controls at renewal, but they will ask for the same six or seven.

Build the evidence package as you go, not at day 89. Screenshot every policy as it's deployed. Export the configuration via PowerShell to a versioned file. Drop both into a recovery folder organized by CIS section number. The carrier's request three months later takes 20 minutes to answer instead of three weeks.

The five signals that recovery is actually finished

A to-do list emptying out is not the same thing as recovery being complete. Five concrete signals are what tell you the work has held:

• Independent post-recovery CIS assessment passes IG1. Not "we ran a self-assessment." Someone other than the team that did the work scored the tenant against the published IG1 control list. Score is at or above the threshold the assessor uses for a passing baseline.
• Audit log retention proves out at 365 days. Run a search at day 90 for events from day 1 of the recovery. They return results. If they don't, the retention setting was on but the license wasn't, which is a configuration trap we see often.
• Zero legacy auth sign-ins for 30 consecutive days. Pull the sign-in logs for the last 30 days, filter on legacy authentication clients, expect an empty result. If anything appears, the block has a hole.
• No OAuth consent grants pending admin review. The admin-consent workflow queue is empty or actively being managed. A queue full of unreviewed requests means users are routing around the control.
• IR plan tabletop scheduled and on the calendar. A specific date, a specific scenario, a confirmed attendee list. "We'll do one soon" doesn't count. Recovery isn't done until the muscle memory test is on the books.

Hit four of five and you're in good shape. Hit all five and you have a defensible, documented post-incident posture that holds up to insurance, audit, and customer scrutiny.

What "aligned with CIS IG1 + IG2" means in plain English

Boards, customers, and investors don't speak CIS. The phrase needs translation depending on the audience.

For the board: "We adopted the published security baseline for Microsoft 365 used by most regulated mid-market companies. An independent assessor verified we meet it. The full evidence package is in the data room." Translate to dollars: "This baseline reduces our likelihood of a recurrence at the same scale and supports a flat-to-modest renewal premium rather than a 60 percent increase."

For customers and partners: "We aligned our M365 tenant to the CIS Microsoft 365 Foundations Benchmark, Implementation Groups 1 and 2, with attestation dated [date]. Happy to share the executive summary on request." That single sentence resolves about 80 percent of inbound procurement-questionnaire questions.

For investors: framing depends on stage. For a Series A or B, the security narrative goes in the data room as evidence the team responds to incidents like adults. For later-stage or a strategic process, the gap analysis between current state and SOC 2 Type II becomes the next milestone.

Whoever asks, the answer is concrete: a named framework, a defined scope, a verifiable date, an attestation document, and a path to the next maturity step. That structure is the difference between a credible security posture and a defensive PR statement.

The handoff from recovery to ongoing operations

Day 91 is a real risk point. The recovery project closes, the team that lived through the incident goes back to other work, and configuration drift starts the day someone needs a "temporary" exception. Six months later the tenant looks like the pre-breach state again, and nobody can quite explain how.

Four operational habits prevent that drift:

• Quarterly drift checks. Pull the same 10 must-have controls every 90 days. Confirm each is still in the configured state. Two hours of work per quarter. The alternative is a year-long quiet regression you only notice during the next incident.
• Annual CIS reassessment. Same external assessor, same scoring rubric, same calendar slot every year. Track the trend. The board likes "year-over-year improvement" as a slide. Auditors like it as evidence.
• Annual tabletop exercise. Different scenario each year. Last year was BEC, this year run ransomware. Time the decisions, update the IR plan the following week, not the following quarter.
• IR plan refresh. Contact lists go stale within six months of a real incident. Carrier hotline, counsel's after-hours line, forensic firm's intake number, regulator notification matrix. Refresh annually and after every material business change. The deeper IR-plan deep dive is in the CIS M365 audit failure article on EmailShield365, which covers what happens when the drift goes unchecked and the next assessment fails.

The transition from project to ongoing operations is the part most SMBs underinvest in. The recovery itself is intense. The maintenance is mundane. But the maintenance is what determines whether the next breach attempt succeeds. The structured implementation playbook for the same controls in a non-incident context is on implementing the CIS M365 Benchmark for small business.

Common questions about post-breach CIS recovery

Do we have to hit IG2 in the first 90 days, or is IG1 enough?

IG1 is enough to satisfy most carriers and most customers in the immediate post-breach window. IG2 is what we recommend you target if your tenant handles regulated data (PHI, PCI, financial, EU resident data) or if your customer base includes enterprises that send security questionnaires. The honest answer for a 50-person services business with a tight timeline is: hit IG1 in days 0 to 30, plan IG2 as a 60 to 90 day extension, document IG2 progress as in-flight rather than complete. Carriers accept "in progress" if there's a written plan with dates.

How is this different from just running the regular CIS Benchmark implementation?

The technical controls are the same. The differences are sequencing, scrutiny, and documentation burden. Sequencing: a non-incident implementation walks the Benchmark linearly, while a post-breach plan front-loads the controls tied to the actual attack vector. Scrutiny: the carrier's forensic firm is reading your configuration changes in near-real-time, which raises the bar for evidence. Documentation: a non-incident rollout produces a policy document, while a post-breach rollout produces a remediation log, gap analysis, attestation letter, and evidence package. Same controls, four times the paperwork.

What if some IG1 controls genuinely don't apply to our tenant?

Mark them as not applicable in the gap analysis with a one-sentence justification. Example: a 25-person business with no SharePoint usage outside Teams documents can mark several SharePoint-specific controls as N/A because the surface doesn't exist. CIS supports this. The Benchmark itself notes that controls may not apply in every environment. The mistake is silent omission. Documented N/A with reasoning passes audit. Missing controls without explanation does not.

Will following this plan prevent the next breach?

It will close the door the attacker used and most of the adjacent doors. It won't eliminate residual risk. Four attack patterns survive a clean CIS IG2 implementation: phishing-resistant MFA defeats AiTM token theft only if every user actually uses it, OAuth consent restriction defeats consent phishing only if the admin queue gets reviewed, sensitivity labels protect data only if labels get applied, and PIM protects admin roles only if standing assignments get fully removed. The plan reduces likelihood significantly. It doesn't take it to zero. The realistic posture target is "harder to breach than 90 percent of comparable tenants," and CIS IG2 gets you there.

Who should run the independent post-recovery assessment?

Three options, in order of credibility. First choice: an external CIS-trained consultant or an MSSP with documented CIS assessment experience. Second choice: a different internal team or contractor than the one that performed the remediation, with a documented checklist they followed. Third choice (acceptable but weakest): the same team that did the work, scoring against a fixed external rubric with screenshots as evidence. The third option is fine for an internal stakeholder. It doesn't carry weight with the carrier or a customer auditor. Budget $4,000 to $12,000 for an external IG1+IG2 assessment of a typical 50 to 250 seat tenant. The cost is small relative to the renewal premium impact of the answer "yes, externally validated."