M365 Breach FAQ: 15 Questions Owners Ask After a Microsoft 365 Compromise

The questions below are the ones we hear from owners and office managers in the second and third week after a compromise. The first week is panic and triage. The second week is paperwork. By the third week most people stop asking how this happened and start asking what they are now legally on the hook for, what their carrier will pay, and how to keep this from being the headline event of the next renewal.

We grouped the answers into four buckets: how bad it is, who has to be told, how this ends, and what the rest of the year looks like. Plain English. We define M365 jargon the first time it appears. Where the honest answer is "it depends," we say that, and we say what it depends on.

Group 1 — how bad is this?

1. How can I tell if data was actually exfiltrated, or just accessed?

Access leaves one audit log signature. Exfiltration leaves a different one. When an attacker reads a mailbox in place, the Unified Audit Log records mailbox reads and sign-in events from an unusual IP. That is bad, but it is not the same as data leaving the building.

Exfiltration shows up as something else: a burst of large outbound emails from a single mailbox, OneDrive or SharePoint sync activity from a device that nobody at your company owns, file-download events in the audit log, or an inbox rule that quietly forwarded a copy of every incoming message to an outside address. If your forensic firm is only seeing sign-in and read events, the attacker had the door open but might not have walked anything out. If they are seeing sync and download bursts, treat the data as taken and notify accordingly. The Microsoft 365 Defender portal calls these "data loss" events, and your forensic team will pull them with KQL queries against the audit log.

One nuance worth knowing. A read event proves the attacker could have copied the message manually, even without a download log entry. For email specifically, regulators in most states treat unauthorized read access to PII the same as exfiltration when deciding whether notification is required. Forensics will give you the technical answer. Your breach coach decides what notification follows.

2. How long had the attacker been in our system before we noticed?

The industry term is dwell time. For small-business M365 compromises the median we see is around three weeks. Some run a few days. Plenty run past 90 days, which matters because most M365 plans only retain Unified Audit Log data for 90 days. E5 and the Audit add-on extend that. If your dwell time is longer than your retention window, parts of the timeline are simply gone.

Forensics reconstructs the timeline by working backward from the discovery event. The most common path: a strange sign-in alert today gets traced back to a successful authentication two weeks ago, which traces back to a forwarding rule created the same day, which traces back to a phishing email the user clicked the morning before. The full sequence of the chain is in the signs your M365 tenant has been hacked writeup. Knowing dwell time matters because everything that happened during the window is potentially exposed. Everything before the window is presumed safe unless evidence says otherwise.

3. Is my data on the dark web now? How would I check?

Maybe. Honest answer first: absence of evidence on dark-web monitoring is not evidence the data isn't out there. Stolen data sometimes sits on a buyer's drive for months, or gets sold privately and never appears on a public leak site at all. Dark-web monitoring catches what gets posted. It does not catch what gets traded.

That said, three layers of checking are worth doing. Free credential checks like Have I Been Pwned tell you whether specific emails or passwords have appeared in known credential dumps. Most cyber insurance carriers include 90 days of dark-web monitoring with a breach response retainer. Turn it on the day forensics confirms scope. Paid services like Recorded Future and Flashpoint scan paste sites, criminal forums, Telegram channels, and ransomware leak sites. Your forensic firm runs these as part of the engagement on a serious incident. If your data does surface, you will know within a few days, and your breach coach can advise on whether the appearance changes your notification or response posture.

4. What does "scope" of breach actually mean and why does it matter?

Scope answers three questions. Which accounts were compromised. Which data was accessed. Which systems beyond M365 were touched. The answers drive everything downstream: notification obligations, insurance payout, recovery cost, and renewal terms next year.

A single-mailbox compromise where the attacker logged in from Lagos, read email for ten minutes, and got kicked when MFA finally fired on a privileged action is one scope. The notification is one letter, maybe none, and recovery is a password reset plus a forwarding-rule audit. Tenant-wide global admin compromise where the attacker exfiltrated 40 GB of SharePoint, planted three OAuth apps with mail.read, and added a service account to Exchange Recipient Management is a different scope entirely. That one is a regulatory filing, customer notifications, a six-figure recovery, and a renewal questionnaire that just got considerably harder. The technical containment work is essentially the same. The legal and financial consequences are not. Forensics establishes scope so the rest of the response is sized correctly.

Group 2 — who do I tell?

5. Do I have to notify customers if their data was in the affected mailbox?

It depends on what data, where the affected people live, and what your contracts say. The legal trigger in almost every state is unauthorized acquisition of personally identifiable information. PII almost always includes names paired with Social Security numbers, financial account numbers with the access credentials, driver license numbers, or health information. PII usually does not include names with email addresses in a normal marketing context, or business contact details that the person made public.

Two things complicate the simple version. First, your contracts with customers may impose tighter notification standards than state law: many vendor agreements require notification of any unauthorized access, regardless of whether the law would require it. Second, a mailbox is rarely just one type of data. The same mailbox holds invoices with bank routing numbers, tax forms with SSNs, HR conversations, and unrelated customer lists. Your breach coach reviews the affected mailbox contents in a privileged setting and writes a notification matrix: who gets told, under which state's rules, on what timeline, with what content. Do not write that letter from a template you found online. The wording is regulated.

6. What about my employees — what do they need to know and when?

Employees usually find out before customers do, because they are part of containment. Tell them the same day you contain. The conversation covers three things.

What they should do: reset their own password, sign out of all sessions in M365 (Settings → My Account → Sign me out everywhere), watch for phishing attempts that name your company or coworkers, and report anything weird straight to whoever you designate. What they should not do: discuss the incident with customers, post anything on social media or LinkedIn, speculate publicly about who did it, or talk to journalists who call. Who handles outside questions: name one spokesperson, usually the owner or a designated lead, and route every inbound question through that person.

If employee personal data was in the affected mailbox or in a SharePoint folder the attacker touched, formal employee notification follows the same state-law clock as customer notification. The HR conversation about pay stubs, W-2s, and benefits enrollment data is the most common employee-side notification trigger. Treat your own people the same way you treat customers on this. The legal standard is identical.

7. When does the carrier need to know? (timing rules)

Read your policy, but the typical window is 72 hours from discovery. Some policies are tighter at 48 hours, a few are 30 days, and a small number of older policies use vague language like "as soon as practicable." Late notification is one of the most common reasons claims get reduced or denied. The clock starts when someone at the company first had reasonable suspicion of a security incident, not when forensics confirms it.

The carrier hotline number is on the declarations page of your policy. Call it before you call your own lawyer. The carrier provides the breach coach (a lawyer who specializes in incident response), the forensics firm, and the notification vendor as part of the policy. Using the carrier's panel firms is usually a coverage condition, and bringing in your own firms first can compromise the claim. If you are not sure where the policy is, your insurance broker can pull it inside an hour. If the policy is genuinely missing and you discover the breach at 6pm on a Friday, call the broker's after-hours line. Brokers expect this call.

8. What state laws actually require notification?

All 50 states have a breach notification law. The trigger in each is unauthorized acquisition of PII, but each state defines PII slightly differently and sets a different timeline. California, New York, and Massachusetts have the strictest definitions and shortest notification windows. Some states require notification only to affected individuals. Others also require notification to the state Attorney General or to the credit bureaus once the affected count crosses a threshold.

If your customer base spans multiple states, you notify under the strictest applicable rule for each affected resident. A small business with customers in California, Texas, and Illinois will likely have three different notification letters, three different timelines, and possibly three different state reporting obligations on top.

Federal layers add their own rules on top of state law. HIPAA covers protected health information regardless of state. Gramm-Leach-Bliley covers consumer financial data at financial institutions. The FTC Safeguards Rule covers non-bank entities that deal with consumer financial data, including tax preparers, mortgage brokers, and auto dealers. International customers add GDPR (72 hours to a supervisory authority) and the various Canadian and UK rules. A breach coach maps all of this for you on day one. Do not try to read 50 statutes in a weekend.

Group 3 — how does this end?

9. How long does breach recovery actually take?

Containment is the fast part. Most M365 incidents are technically contained within 24 to 72 hours: passwords reset, MFA re-enrolled, malicious sessions revoked, forwarding rules removed, OAuth-consented apps deleted, audit logging confirmed on. After containment, business operations are usually back to normal inside the first week.

Forensics is the slow part. A thorough M365 forensic engagement runs 2 to 6 weeks depending on scope. The forensic firm pulls audit logs, reconstructs the timeline, identifies every account and asset the attacker touched, looks for persistence (anything they planted that survives a password reset), and writes a report you can hand to insurance and to regulators. Notification work, where required, runs in parallel with the back half of forensics once scope is firm enough to write the letters.

Hardening the tenant against repeat attack is another 2 to 4 weeks. This is where the secure baseline gets installed: enforced MFA on every account including service accounts, legacy auth blocked, Conditional Access policies tuned to your travel patterns, restricted user consent for OAuth apps, mailbox auditing on, and a documented break-glass admin pair. The full sequence is in post-breach CIS M365 benchmark recovery. Total elapsed time from discovery to closed file is typically 8 to 14 weeks.

10. Will my insurance pay? What might they not pay?

Most cyber policies pay forensics, breach coach legal fees, notification mailings, credit monitoring for affected individuals, public relations, and business interruption losses during the response. A good policy will cover six figures of these costs at a $5,000 to $25,000 deductible.

Common reasons for partial denial or coverage dispute, in rough order of frequency. A renewal application that said MFA was enforced when it actually was not, or that claimed offline backups existed when they did not. Late notification past the policy window. Use of a non-panel forensics firm without the carrier's written permission. An act-of-war exclusion if the attacker is later attributed to a sanctioned nation-state actor. Sub-limits that are much smaller than the main breach limit: social engineering and wire fraud are commonly capped at $50,000 to $250,000 even on a $1M policy, and ransomware payment coverage is often capped lower than the breach response coverage.

If you are early in the incident, the single best thing you can do for your claim is keep the carrier informed in writing at every step. Email the breach coach a status note every few days. Save those emails. A clean paper trail makes the difference between a claim that pays in 60 days and one that grinds for nine months.

11. Can the attacker come back the same way?

Yes, unless you fix the entry path and remove every piece of persistence. These are two separate problems and people frequently fix only one of them.

The entry path is whatever the attacker used to get the first valid credential. Common ones: a phishing kit that captured a session token after a real MFA challenge (adversary-in-the-middle phishing is the dominant pattern in 2025 and 2026), a reused password from an unrelated breach, a legacy authentication protocol like SMTP AUTH that bypassed MFA entirely, or an OAuth consent screen that the user clicked through without reading. Closing the entry path means changing how authentication works, not just changing one password.

Persistence is what they planted while inside. Forwarding rules on mailboxes that send a copy of every email to an outside address. OAuth-consented third-party apps with mail.read or files.read permissions that survive a password change. Mailbox delegates added to a partner's calendar. Hidden admin accounts with names that look like service accounts. Stolen refresh tokens that keep working until they expire (default 90 days for Entra ID). Closing the entry path without removing persistence buys you days. Closing both buys you a real reset. The complete persistence-removal sequence is in the M365 tenant compromised recovery checklist.

12. How much does breach recovery typically cost?

Order-of-magnitude numbers, with the caveat that every incident is different. A 25 to 100 person business with a single-mailbox compromise, no document exfiltration, and no notification trigger usually runs $15,000 to $40,000 all-in: forensics, hardening, and the breach coach's review. Most of this is covered by a basic cyber policy.

Tenant-wide compromise with confirmed document exfiltration runs $75,000 to $250,000 once you add notification mailings (roughly $3 to $5 per affected individual at scale, more for smaller batches), 12 to 24 months of credit monitoring for affected individuals, legal review of the notification letters, public relations work if the breach goes public, and lost revenue during the response weeks. Ransomware on top of an M365 compromise can push past $500,000 once you add the ransom decision (whether you pay or not), incident response retainer, and rebuilding any encrypted endpoints. Insurance covers most of this if the policy is in force and the application was clean.

Group 4 — what now?

13. What's the difference between a "secure baseline" and "we have antivirus"?

Antivirus runs on endpoints (laptops, desktops, phones) and looks for known malicious files. Modern endpoint detection and response (EDR) tools like Microsoft Defender for Endpoint, CrowdStrike, and SentinelOne add behavioral analysis on top of file scanning. All of this is useful and you should have it. None of it would have stopped most M365 breaches we see, because the attack never touched an endpoint.

A secure baseline is the set of tenant-level controls inside Microsoft 365 itself that stop the attack before a file ever reaches an endpoint. Enforced MFA on every account, including service accounts and admin accounts. Legacy authentication blocked at the Conditional Access layer and reinforced at the Exchange Online layer. Conditional Access policies that consider the device, the location, and the sign-in risk score. Mailbox audit logging turned on for every mailbox. Restricted user consent so a regular user cannot grant a third-party app permission to read mail. Documented break-glass admin accounts that are excluded from access-blocking policies and stored offline.

Most M365 breaches start with credential theft, not malware. The attacker logs in legitimately with a valid username, a valid password, and (in adversary-in-the-middle phishing) a valid post-MFA session token. Antivirus would not have caught that sign-in because there was nothing on the endpoint to catch. The baseline would have either blocked the sign-in (Conditional Access denied an unmanaged device from a high-risk country) or contained the damage (legacy auth blocked, so the attacker couldn't pivot to SMTP AUTH, and restricted consent, so they couldn't plant an OAuth app). Antivirus and a baseline are complements, not substitutes.

14. Should I switch from M365 to Google Workspace?

Probably not, and not because of this. Google Workspace tenants get phished too. Workspace has its own equivalents to most M365 controls (2-step verification, context-aware access, data loss prevention, audit logs), and its own equivalents to most M365 attack patterns (token theft, OAuth consent abuse, forwarding-rule persistence). The platform was almost never the cause of the breach you just had. The cause was a missing or misconfigured control that the platform offered but that nobody had turned on or kept turned on.

Migrating tenants takes 6 to 12 weeks of distraction, costs $50 to $200 per seat in migration tooling and consulting, and resets your institutional knowledge of where every control lives. You will spend the first six months in the new platform learning the same lessons, often in the same order. The better path is almost always: fix the M365 baseline, document where every control lives and who owns it, and put quarterly drift checks on the calendar so the controls stay where you put them. The plain-English M365 security FAQ on SecureYourTenant walks through what a real baseline looks like for an SMB.

15. Will my carrier renew us next year after a claim?

Usually yes, but the renewal will look different. Expect a longer application, pointed questions about exactly which controls were missing during the incident, a higher premium (often 25% to 75% increase for the first renewal post-claim), possibly a higher deductible, and in some cases a sub-limit on the specific cause-of-loss for one cycle. Some carriers add a coinsurance percentage on a particular peril; a few non-renew entirely, but for a clean SMB claim that is uncommon.

The single biggest factor in renewing on reasonable terms is being able to show, in writing, what the gap was and what closed it. Underwriters read post-incident documentation. A two-page summary that names the entry path, names the persistence found, names the controls now in place, and includes screenshots or PowerShell output proving each control is enforced will move a renewal more than any narrative. Document the post-incident hardening like you mean it; you will reuse the document at every renewal for the next three years, and your premium will reflect whether you did this part well or not.