Microsoft 365 Outage: Legal Reporting Thresholds, Court Deadlines and SLA Credits

Diplomacy & Law, an international-law publication, has published an analysis of what the outage means legally. Its conclusion is cautious, and largely correct: a global outage doesn't automatically mean anyone broke a law, missed a regulatory duty or owes damages. It doesn't automatically get you more time on a deadline either. For Windows admins and IT leaders, the practical questions are about dependencies, keeping records and what your contracts say.

Here is what the evidence supports, where it stops, and what to do with it.

What broke, and when​

Microsoft tracked the incident under two IDs. The incidents to follow are EX1550543 (Exchange Online) and MO1550821 (everything that depends on Exchange). Some tenants also saw a third ID. LazyAdmin's timeline lists a separate Teams incident (TM1550488), Americas only, on Thursday afternoon UTC before the main event took hold.

Microsoft's updates, mirrored by monitoring vendor ENow, show the diagnosis changing over time:

• Early hours: Microsoft first blamed the connectivity errors on high load. It said engineers paused deployments, shifted traffic onto alternate routes and reviewed whether reversing several recent configuration updates could speed recovery.
• The load wasn't real demand: Microsoft later said the load came from a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure, according to the mirrored service-health text. It did not come from an overall rise in traffic.
• Health checks made it worse: Microsoft found that failed health checks were taking servers out of service. It tested a workaround and reported that an alternative health check method on a subset of affected infrastructure let those servers come back.
• Overloaded connection process: Microsoft then reported that a process responsible for establishing secure connections was becoming overwhelmed on the affected servers, and that it had begun reverting a recent network configuration change that correlates with the start of impact.
• Overnight into Friday: LazyAdmin records that at 04:22 UTC, Microsoft reported partial recovery in some regions, but said it wasn't sustained yet. It also notes that some machines were stuck in a bad state, which stopped a network change from syncing.

Treat "correlates with" carefully. The network change lined up with the start of the outage, but that doesn't prove it caused it. Cybersecuritynews made the same point, noting that the later rollback assessment therefore remains a recovery option, not proof of the root cause. Diplomacy & Law also describes an "upstream authentication and routing component" in the recovery work. That detail didn't appear in the mirrored updates checked for this article, so treat it as their reading for now.

Was it an attack? Nothing published says so. Microsoft said it is not aware of any malicious activity causing the outage, and the company plans to publish a post-incident report detailing the root cause and further safeguards once the disruption is mitigated.

Where recovery stood: Diplomacy & Law says Microsoft's 11:01 UTC update on November 13 reported finished recovery work on parts of its Asia-Pacific infrastructure, with other regions still in progress. A later Microsoft update, mirrored by a Japanese university IT help desk, was still cautious: service health remains variable and capacity has not yet fully returned to baseline. The same update confirms an important safeguard for mail: the email timeout window has been extended to 48 hours to preserve delayed messages.

That timeout extension only buys time. Queued mail gets longer before it expires, but nothing guarantees every queued message will be delivered. Admins should still run message traces once the service is back.

Summary: This was an Exchange Online capacity failure made worse by health checks that kept removing servers. A recent network change is the leading suspect but isn't confirmed. As of November 13, recovery was partial and no root-cause report had been published.

Why so much more than email failed​

The products listed under MO1550821 show how much of Microsoft 365 depends on Exchange. Cloud distributor Sherweb's status page kept adding services as the day went on. By Thursday evening the list covered Exchange Online, Teams, SharePoint Online, Copilot, Defender XDR, Planner, To Do, Purview, Power BI, Defender for Office 365, Intune, Microsoft 365 Apps Admin Center - Universal Print - Windows 365 - Microsoft Graph.

The damage wasn't uniform across those services:

Windows 365 is the one PC admins should note. Your Cloud PC isn't just a VM in Azure if it depends on a Purview key path. That dependency chain can end at the same infrastructure that took down Outlook.

Summary: Microsoft sells these as separate products, but many of them share infrastructure. When Exchange went down, security, compliance, AI and even some Cloud PC sign-ins went with it, though the damage varied by feature.

Who was hit​

Diplomacy & Law collected official notices from North America, Europe and the Asia-Pacific region:

• United States: the City of Richmond, Virginia, reported municipal service disruption. Workhorse Group postponed an earnings-related announcement. Communications used by members of the U.S. House were affected.
• Canada: the Laurentides health network in Quebec reported Microsoft 365 problems. The Alberta courts issued an advisory about court communications and filing.
• UK and Europe: West Northamptonshire Council, Renfrewshire Council and NHS Fife reported problems. Euronext reported email difficulties affecting listing-related communications. Maersk warned customers to expect slower correspondence.
• Australia: ASIO and the Australian Federal Police reported effects. The Supreme Court of Victoria said it couldn't send or receive email, but its RedCrest e-filing systems stayed up and hearings were expected to go ahead. The Department of Foreign Affairs and Trade sent urgent sanctions enquiries to the Australian Sanctions Office by phone.
• Elsewhere in the region: Diplomacy & Law cites reported problems at government bodies and institutions in Japan, Singapore and the Philippines, and at financial institutions in Taiwan.

Its most useful point is that an email outage at an exchange operator doesn't mean trading stopped. Likewise, a health board losing Outlook doesn't mean hospitals stopped treating patients. Downdetector-style counts have a similar limit: they are complaint counts, not verified numbers of affected users.

The legal map: what triggers duties, and what doesn't​

Diplomacy & Law's main argument is that duties under these laws depend on specific triggers. The outage's scale doesn't settle whether any of them were met. Here is a summary of its framework.

EU financial sector: DORA​

The Digital Operational Resilience Act has applied since January 17, 2025. It requires covered financial entities to manage ICT risk, classify incidents and report the major ones. According to Diplomacy & Law, the first reporting deadline under Delegated Regulation (EU) 2025/301 is generally within four hours of classifying an incident as major. It must also be no later than 24 hours after the entity became aware of the incident, subject to the regulation's qualifications. Intermediate and final reports follow.

Two points stand out:

1. Classification comes first. Reporting depends on whether the firm's own assessment finds the incident major. That assessment looks at clients affected, downtime, geographic spread, how critical the function is and economic impact. A bank that lost Outlook while its payment systems kept running may be in a very different position from one whose client communications stopped.
2. Microsoft's designation is not a finding. Diplomacy & Law notes that EU supervisors listed Microsoft Ireland Operations Limited as a critical ICT third-party provider in November 2025. That puts Microsoft under supervisory oversight. It isn't a ruling that Microsoft breached anything during this outage.

NIS2 and GDPR​

Diplomacy & Law points to Implementing Regulation (EU) 2024/2690. Under it, a cloud incident can count as significant if the service is completely unavailable for more than 30 minutes. It can also count if availability is limited for more than an hour for more than 5% of EU users or one million EU users, whichever is smaller. Public reporting doesn't establish those user numbers per service, so nobody outside Microsoft can say yet whether those thresholds were crossed.

Under GDPR, a loss of availability of personal data can count as a personal-data breach, not just theft or disclosure. Notification depends on risk to individuals, though, and compensation requires infringement, damage and causation. Diplomacy & Law cites the CJEU's Österreichische Post ruling on that point. Nothing published shows any data was exposed.

United Kingdom​

Diplomacy & Law reports that the UK's Critical Third Parties (Designation) Regulations 2026 designated Microsoft Ireland Operations Limited with effect from July 13, 2026. That would place it under oversight by the Bank of England, PRA and FCA, with incident-reporting duties of its own. The regulators expect final reports generally within 30 working days of resolution. The ICO's NIS guidance sets an availability threshold of more than 750,000 UK user-hours, with notification generally within 72 hours. As with DORA, having these powers isn't the same as finding a breach.

Australia​

Australia announced a memorandum of understanding with Microsoft on digital resilience on June 10, 2026. Diplomacy & Law says it includes cooperation on "priority recovery" after major disruptions to Microsoft's services. It also says clause 1.2 explicitly makes the memorandum non-binding. That rules out using it to claim damages. Australia's legally binding commitments sit in the government's separate five-year Microsoft agreement, which began July 1, 2026, and in statutes such as the Security of Critical Infrastructure Act.

North America and international law​

Diplomacy & Law notes that SEC Form 8-K Item 1.05 disclosure applies to material cybersecurity incidents, and that an outage alone doesn't automatically count. Canada's PIPEDA breach reporting applies only where there is a "real risk of significant harm." On the most dramatic question, the answer is no: a private US company's outage abroad isn't an "internationally wrongful act" by the United States under the ILC's rules on state responsibility.

Summary: Every one of these regimes depends on thresholds. Whether any were crossed depends on facts specific to each institution and each service, and those facts aren't public yet.

What admins should actually do now​

Here is what follows from the evidence:

1. Record everything now. Save the incident IDs (EX1550543, MO1550821 and TM1550488 if you were affected), timestamps, affected workloads and your own impact logs. Regulators, auditors and SLA claims will all ask for them.
2. Use the status page when the admin center is down. Microsoft said details were in the admin center, as well as status.cloud.microsoft if the admin center is not available to you.
3. Check that queued mail actually arrived. Use message traces once the service is back. The 48-hour timeout protects queued mail but doesn't guarantee delivery.
4. Don't assume deadlines moved. Look at how the Supreme Court of Victoria handled it: email was down, but e-filing stayed up and hearings were expected to go ahead. Find each court's or regulator's alternative channel and keep proof that you tried to use it.
5. Regulated firms: run your own classification. Use your DORA, NIS or CTP procedures to decide whether the incident was major. Don't skip the assessment because the outage was global, and don't automatically file because it was global either.
6. SLA credits are a contractual remedy, not compensation. Exchange Online's financially backed availability commitment is 99.9% a month. Credits are tiered against that figure and must be claimed through the admin center within the window your agreement sets. Microsoft's standard terms generally require claims by the end of the month after the incident. LazyAdmin has published a claim walkthrough. Credits generally won't cover lost productivity or other consequential losses.
7. Map your Exchange dependencies. Copilot connectors, Graph-based automations, Purview labelling, Defender for Office 365 and Windows 365 Customer Key setups all ended up depending on mail infrastructure in this incident. Your business-continuity plan should cover them, and it should include contact channels that don't run through email.

The bigger picture​

The cause is still unknown, and the root-cause report Microsoft has promised is what matters most. If it confirms the network configuration change, people will compare this outage to every other "change gone wrong" in recent cloud history. If it doesn't, Microsoft still has to explain why health checks kept removing servers while load piled onto the rest.

Either way, Diplomacy & Law's main point holds. Courts, spy agencies and sanctions offices now depend on shared commercial infrastructure. EU, UK and Australian regulators have spent the past two years building oversight frameworks for exactly this kind of event. What those frameworks actually lead to will depend on each institution's facts and on what Microsoft's report says.