Data Breach Response Checklist: 25 Steps for M365 Breach Response

How to use this checklist

Sixty days. That's the realistic length of an M365 breach response for a 30–250 seat business, from the moment someone notices a forwarding rule they didn't write to the moment legal sign-off lands on the post-incident report.

The first 24 hours decide most of the outcome. Miss the persistence hunt and the attacker walks back in three weeks later through an OAuth app you forgot existed. Miss the notification window and your insurance carrier may decline coverage. Miss the long-term hardening and you do this again in nine months.

The 25 steps below are organized into five phases. For each one we give the action in plain language, the exact Microsoft path or PowerShell command, what success looks like, and the threat the step addresses. If you want the small-business framing for the same incident, read the companion data breach response guide for small business. If you only have 24 hours and need the short version, skip to the M365 tenant compromised recovery checklist.

Phase 1: Hours 0–24 — stop the bleeding

Speed beats elegance here. You're not running a forensic-grade investigation in the first 24 hours. You're keeping the attacker from doing more damage while you set up the people and processes that will handle the next sixty days.

Step 1. Identify scope in Entra Sign-in logs

Open Microsoft Entra admin center → Monitoring & health → Sign-in logs. Filter on the suspect user. Sort by Risk state and Location. What you're looking for: sign-ins from countries the user has never been in, impossible-travel events, or successful sign-ins from anonymizing IPs (Tor, commercial VPN exit nodes).

Note every UPN, IP, and timestamp on a working timeline doc. Do this for one user first, then expand. Most breaches start with one account and pivot from there. The list of pivot targets is your real scope.

Why this matters: you can't contain what you haven't measured. Every later step depends on knowing which accounts and which mailboxes are dirty.

Step 2. Reset passwords and revoke refresh tokens

Password reset alone doesn't kick the attacker out. They already have an active session token. You have to revoke it.

Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.AccessAsUser.All"

# Revoke all refresh tokens for the affected user
Revoke-MgUserSignInSession -UserId "[email protected]"

# Then force a password reset in the Entra portal or via Graph
Update-MgUser -UserId "[email protected]" `
  -PasswordProfile @{ ForceChangePasswordNextSignIn = $true; Password = "TempBreachReset!$(Get-Random)" }

Why this matters: session tokens persist for up to 90 days by default. Without revocation you've changed the lock and left the burglar inside.

Step 3. Kill mailbox forwarding rules

Auto-forwarding to an external address is the number one persistence trick used in BEC and account-takeover incidents. Run this query across the tenant to surface forwarding rules added in the last 30 days:

Connect-ExchangeOnline

# Inbox rules with forwarding/redirect actions
Get-EXOMailbox -ResultSize Unlimited |
  ForEach-Object {
    Get-InboxRule -Mailbox $_.UserPrincipalName |
      Where-Object {
        $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or
        $_.DeleteMessage -eq $true
      } |
      Select-Object @{N='Mailbox';E={$_.MailboxOwnerId}}, Name, Enabled,
        ForwardTo, ForwardAsAttachmentTo, RedirectTo, DeleteMessage, WhenChanged
  } |
  Sort-Object WhenChanged -Descending |
  Export-Csv suspicious-inbox-rules.csv -NoTypeInformation

# Mailbox-level forwarding (separate from rules)
Get-EXOMailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
  Select-Object UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward

Disable every rule that forwards externally. Don't delete them yet. The rule itself is evidence and the carrier's forensic firm will want it intact. The companion deep-dive on this attack pattern is on how email forwarding attacks work in Microsoft 365.

Why this matters: a single forwarding rule turns a one-day breach into a six-month data leak.

Step 4. Block sign-in for affected accounts via Conditional Access

You don't disable the user object. That breaks too much downstream and complicates the audit trail. Instead, build (or reuse) a Conditional Access policy named CA-Incident-Block-Group. Target a security group, action Block access, all cloud apps, all platforms.

Add the affected accounts to the group. Sign-ins die within minutes. The mailbox stays intact for forensics. Reverse it by removing the user from the group when the account is cleaned up.

Why this matters: CA-based isolation is reversible, auditable, and faster than disabling the account directly.

Step 5. Activate the IR plan and call insurance, counsel, and the carrier hotline

Three calls, in this order: cyber insurance hotline first (most policies require notification within 24–72 hours of discovery, and the carrier's pre-approved forensics firm is usually free), outside counsel second (privilege protection on the investigation), and your IR plan owner internally to convene the response team.

Why this matters: miss the carrier window and they may deny the claim. Skip counsel and your forensic findings become discoverable in litigation. The clock starts at discovery, not at confirmation.

Phase 2: Containment (Days 1–7) — hunt for persistence

Days 1 through 7 are about answering one question: where else are they? Modern attackers plant multiple persistence mechanisms before they exfiltrate anything. Find them all before you declare containment.

Step 6. Audit consented OAuth apps and app registrations

OAuth consent phishing is the persistence that survives password resets. The attacker tricks the user into approving a third-party app with mail.read or full mailbox access; the app keeps reading mail forever via its own refresh token, regardless of password changes.

In Entra → Applications → Enterprise applications, filter by Application type = Microsoft Applications: No and sort by Created on. Anything created in the 90 days before the breach gets reviewed. Look at Permissions and revoke anything granting Mail.Read, Mail.ReadWrite, full_access_as_app, or Files.ReadWrite.All to an app you don't recognize.

Why this matters: a malicious OAuth grant lives outside password and MFA reset. Missing it means the attacker still has mail access tomorrow.

Step 7. Audit mailbox rules across every affected mailbox

Step 3 caught the obvious external-forward rules. Step 7 catches the subtle ones: rules that auto-mark messages as read, move messages from "accounting" or "wire" or "invoice" to RSS Feeds, or auto-delete bounce messages so the user never sees the failed-delivery replies from spoofed wire-fraud emails.

Pull every rule for every affected mailbox. Read the names. Read the conditions. Suspicious patterns: rules named with a single letter or punctuation character, rules acting on keywords like "wire," "invoice," "ACH," or rules that delete messages from specific senders.

Why this matters: these rules are the operational machinery of invoice fraud. Even after the attacker is locked out, an active rule can route incoming messages straight into the trash so the victim never sees the warning signs.

Step 8. Check delegated mailbox access and Send-As grants

Attackers add themselves as a delegate on the executive's mailbox so they can read mail without ever logging in as the executive again.

Get-EXOMailbox -ResultSize Unlimited |
  ForEach-Object {
    Get-MailboxPermission -Identity $_.UserPrincipalName |
      Where-Object { $_.User -notlike "NT AUTHORITY\*" -and $_.IsInherited -eq $false }
  } |
  Select-Object Identity, User, AccessRights |
  Export-Csv mailbox-delegations.csv -NoTypeInformation

Get-RecipientPermission |
  Where-Object { $_.Trustee -notlike "NT AUTHORITY\*" } |
  Select-Object Identity, Trustee, AccessRights

Why this matters: a Send-As permission lets the attacker send wire-fraud emails from the CFO's address with no sign-in event at all.

Step 9. Review the Unified Audit Log for the attacker timeline

In Microsoft Purview → Audit, run a search across the affected UPN for the 90-day window. Operations to filter on: UserLoggedIn, New-InboxRule, Set-InboxRule, Add-MailboxPermission, Set-Mailbox (for ForwardingSmtpAddress changes), Consent to application, Add OAuth2PermissionGrant, FileDownloaded (SharePoint/OneDrive), and MailItemsAccessed.

Why this matters: this is the timeline document that goes to the carrier and to legal. It's also how you prove what data was accessed for the notification decision in Phase 3.

Step 10. Review admin role assignments from the last 90 days

In Entra → Roles & admins, click each privileged role (Global Admin, Privileged Authentication Admin, Exchange Admin, User Administrator, Application Administrator) and review every assignment. Cross-reference with the audit log: Add member to role. Anything added after the suspected initial compromise date is suspect until proven otherwise.

Why this matters: a hidden Global Admin assignment is a tenant-wide backdoor. Find it now or you find it after the second breach.

Phase 3: Notification (Days 1–60) — the legal window

Notification is where small businesses get themselves in trouble. The instinct is either to over-notify (panic email to every customer) or under-notify (hope nobody finds out). Both are wrong. Counsel decides; you execute. What follows is the framework, not legal advice.

Step 11. Run the notification decision tree with counsel

The triggers are layered:

• State breach laws. All 50 US states have one. Most require notification when "personal information" (name + SSN, name + financial account, name + medical) is reasonably believed to have been accessed. Windows range from "without unreasonable delay" to a hard 30 days (Florida, Colorado).
• HIPAA. If you're a covered entity or business associate and PHI was accessed, you have 60 days from discovery to notify individuals and HHS (and media if >500 people).
• PCI-DSS. If cardholder data was potentially exposed, you notify your acquiring bank within hours, not days. Timelines are contractual, not legal.
• GDPR. If any EU resident's data was processed and accessed, the supervisory authority gets notified within 72 hours of discovery.
• SEC cyber rule. Public companies file an 8-K Item 1.05 within four business days of materiality determination.

Why this matters: the consequence of missing the window is usually larger than the consequence of the breach itself.

Step 12. Document the attacker timeline and IOCs for insurance and legal

Compile one document with: discovery date, suspected initial compromise date, attacker IPs, user agents, geolocations, OAuth apps consented, mailbox rules added, files accessed (SharePoint/OneDrive download events), data exfiltration evidence (or absence thereof), and remediation actions with timestamps. The carrier and counsel both need this.

Why this matters: the document becomes the source of truth for everyone downstream: regulators, customers, your own board.

Step 13. Coordinate with the cyber insurance carrier

The carrier has a panel: forensic firms, breach coaches (specialized counsel), notification vendors, credit-monitoring providers, public-relations firms. Use the panel. Going off-panel without pre-approval often voids reimbursement. Keep every invoice; submit them through the carrier's portal as you go, not in a single batch later.

Renewal is the next risk. The breach will surface on your next application; carriers often raise premiums 30–60% or impose sub-limits. Get ahead of it with the cyber insurance renewal checklist.

Why this matters: the carrier is paying. Their process is the one you follow.

Step 14. Notify regulators where required

Under counsel's direction, file the notifications: state attorneys general (some require pre-notification when >500 residents are affected), HHS Office for Civil Rights (HIPAA), state insurance commissioners (NYDFS Part 500 requires 72-hour notice), the FBI's IC3 portal for criminal-investigation purposes. Keep the filing receipts.

Why this matters: regulator notifications are usually one-shot. Getting the facts wrong on the first filing is expensive to amend.

Step 15. Plan customer and partner communication

Counsel writes the notice. You handle distribution: who gets it, how (mail vs. email, both is safer), and the timing relative to regulator notifications. Stand up a dedicated email alias and a phone line; route both to a person who has talking points and an FAQ. Don't speculate on what was accessed beyond what the forensic findings support.

Why this matters: a measured notice keeps the press cycle to two days. A defensive or evasive one keeps it alive for two weeks.

Phase 4: Recovery (Days 7–30) — restore and validate

Containment held. Notifications are going out. Now you put the tenant back into a usable, defensible state.

Step 16. Restore mailbox content from backup if needed

Quick myth-busting: Microsoft 365 retention is not backup. Litigation hold preserves discoverable content for legal but doesn't restore deleted items by user action. Native retention is point-in-time-limited (14–30 days for most items). If the attacker emptied the Sent Items folder to cover their tracks and you don't have third-party M365 backup (Veeam, Datto SaaS Protection, Barracuda, etc.), the evidence is gone.

Restore from third-party backup where you have it. Where you don't, get one before the next incident.

Why this matters: the difference between a 30-day recovery and a 90-day recovery is usually whether you had a third-party M365 backup.

Step 17. Re-enroll affected devices

Any device that signed in as a compromised user is suspect. In Intune → Devices, wipe and re-enroll, or at minimum revoke device compliance and require re-attestation. Token-theft malware lives on the endpoint. Cleaning the cloud and leaving the laptop dirty re-infects on the next sign-in.

Why this matters: token theft is the modern persistence. If the laptop is dirty, the new password and new MFA enrollment buy you 24 hours.

Step 18. Restore disabled accounts with stronger MFA

Before removing the account from the CA block group, reset the password again, revoke tokens again, and re-enroll MFA. If your tenant doesn't yet require phishing-resistant methods (FIDO2, Windows Hello for Business, certificate-based auth), enrolling them on every restored account is the right time to start.

Why this matters: push-notification MFA was bypassed in the original incident. Don't restore the account behind the same control that failed.

Step 19. Re-run the persistence hunt

Repeat steps 6 through 10. Same queries, same scope. You're looking for anything new that appeared during the recovery window. Sometimes attackers re-enter through a path you missed and re-establish persistence while you were busy with notifications.

Why this matters: recovery without re-validation is hope. Hope doesn't pass an audit.

Step 20. Document residual risk for the board

One page. Three sections. What we know was accessed. What we couldn't determine. What we are doing about both. Date it, version it, store it where the board minutes live.

Why this matters: directors will be asked. Having a written, lawyer-reviewed answer ready is governance hygiene.

Phase 5: Long-term hardening (30+ days) — close the door behind you

The breach is contained, notifications are filed, the carrier is closing the claim. The temptation is to declare victory and move on. The repeat-incident rate for businesses that stop here is high. The five steps below are what separates "we recovered" from "this won't happen again."

Step 21. Deploy phishing-resistant MFA

Push-notification MFA gets phished. Adversary-in-the-middle frameworks like Evilginx and EvilNoVNC sit between the user and Microsoft, harvest the session cookie post-MFA, and replay it. The defense is FIDO2 hardware keys (YubiKey, Feitian), Windows Hello for Business, or certificate-based auth. Roll it out to admins first, then VIPs, then everyone, in that order.

Why this matters: phishing-resistant MFA is the single control that breaks the most common 2026 attack chain.

Step 22. Migrate to the CIS Benchmark baseline

Most M365 breaches we see are the same dozen-or-so misconfigurations: legacy auth still enabled, no Conditional Access for risky sign-ins, external mail forwarding allowed by default, OAuth user consent unrestricted, no privileged access workstation policy. The CIS Microsoft 365 Foundations Benchmark is the named-and-numbered fix. The implementation playbook is in implement the CIS M365 Benchmark for small business, and the long-term post-incident path is the post-breach CIS M365 Benchmark recovery plan.

Why this matters: CIS gives you a defensible baseline that auditors, carriers, and customers all recognize.

Step 23. Stand up continuous monitoring

The original breach was probably visible in sign-in logs for days before anyone noticed. Continuous monitoring closes that gap. Options range from Microsoft Sentinel (full SIEM, monthly cost scales with log volume) to Defender for Cloud Apps anomaly alerts (included in many M365 E5 SKUs) to a managed-detection vendor that watches the tenant for you.

Why this matters: the next attempt will look like the first one. Detect it on day one instead of day fourteen.

Step 24. Run a tabletop exercise within 60 days

Two hours, conference room, your IR plan, and the team that just lived through the real thing. Walk a hypothetical scenario (different attack vector this time, say ransomware or a vendor compromise). Time the decisions. Note where the plan was vague or wrong. Update the plan the next day, not "soon."

Why this matters: the IR plan you used for this incident has gaps. The fastest way to find them is while the muscle memory is fresh.

Step 25. Review and update the IR plan

Final step. Take everything the response taught you and write it back into the plan: updated contact lists, the carrier hotline number, counsel's after-hours line, the forensic firm's intake process, the regulator notification matrix with current statutes. Re-circulate to the team. Schedule the next review on the calendar: annually at minimum, after every material business change.

Why this matters: a plan that doesn't change after a real incident is a plan that hasn't been tested.

Frequently asked questions about M365 breach response

How long does an M365 breach response actually take?

For a 30–250 seat business with no in-house IR team, plan on 60 days from discovery to claim closure. The first 7 days are intense (containment + carrier engagement). Days 8 through 60 are notification logistics, recovery, and documentation. Long-term hardening adds another 60–90 days on top, usually run as a project rather than an incident. The fastest engagements we see clock in at around 21 days, but only when the business already had MFA, CIS Benchmark coverage, and third-party backup before the incident. The slowest hit 6 months when there's litigation. More detail on the day-by-day cadence is in the M365 breach FAQ.

Do I have to notify customers if I'm not sure their data was accessed?

Counsel decides, not you, and the answer depends on jurisdiction. Most US state breach laws use a "reasonable belief" standard: if the forensic evidence supports a reasonable belief that personal information was accessed, notification is required. Inability to rule access in or out (the "indeterminate" finding) is treated as access in some states (CA, MA) and as no-access-required in others. Document what you know, what you don't, and what you tried to find out. That record is what counsel uses to make the call.

What if the attacker is still active inside the tenant?

Don't tip them off. Keep their accounts under the Conditional Access block (step 4) but leave their session telemetry running. Engage the carrier-panel forensic firm before you do any wider remediation. They may want to capture live evidence (memory snapshots, audit-log subscriptions, mailbox content as-is) before you trigger any visible cleanup. This is where you stop running playbooks from the internet and start following counsel's and the forensic firm's direction.

What's the difference between this checklist and the small-business breach response guide?

This page is the operator's checklist with exact paths, commands, and timing. The small-business data breach response guide is written for a non-technical owner who needs to understand what's happening and what their role is while their IT person or MSP runs the technical work. Read both: this one for the technical execution, the other for the business framing you'll need with your team and your customers.

What does this all cost without cyber insurance?

Forensic firms typically bill $250–$500/hour for senior responders; a 60-day engagement runs $40,000–$150,000 for SMBs. Counsel adds $20,000–$60,000. Notification and credit-monitoring vendors cost $5–$15 per affected individual. A 200-person business with personal data on 3,000 customers can run $100,000–$300,000 out of pocket. Cyber insurance generally covers 80–95% of those costs against your retention. The cyber insurance renewal checklist covers what carriers look at after an incident.