FrogPro
IT Operations

Microsoft 365 outage: This is how I manage business continuity

My approach to managing a Microsoft 365 outage: decisions, continuity procedures and protection for production, warehousing and offices.

Klaudiusz Żabiński in an operating manufacturing and office environment during a cloud service disruption

A global provider can lose availability. With the right preparation, that does not have to stop the business.

A major Microsoft 365 incident began on 12 November 2026, primarily affecting access to Exchange Online mailboxes and selected scenarios that depend on Exchange. Not every feature in Teams or other services stopped working. Microsoft confirmed service restoration on 14 November and initially pointed to a technical issue related to network infrastructure changes rather than a cyberattack. Microsoft publishes current incident information through Microsoft 365 Service Health.

For nearly 14 years at LOTTE Wedel, I worked with Microsoft’s corporate ecosystem, including Microsoft 365, and was responsible for infrastructure and service continuity in manufacturing and retail environments. Today, as an external consultant, I support companies with infrastructure, IT operations and technology risk. That experience shapes how I work: technology must support the business, and the organisation must be able to operate when a provider’s service is unavailable.

When I manage an outage, I do not start by predicting when the provider will restore service. I first establish which processes must continue, what is still working and which safe fallback procedures we can activate:

What must keep working when Microsoft 365 is unavailable?

I. Before an outage: prepare the processes and decisions

1. Identify what must keep working

I run a Business Impact Analysis (BIA) with process owners. Together, we establish how long production can operate without selected services, whether the warehouse can receive and dispatch goods, how Sales can log urgent orders, and which ERP, WMS and MES integrations depend on Entra ID, Microsoft Graph or Power Automate.

For each critical process, I agree the maximum tolerable disruption, relevant RTO and RPO targets, and a safe operating level in emergency mode. I do not promise a restoration time for Microsoft’s service. I prepare a way to complete the most important work without it.

The objective is to keep the processes whose interruption would hurt the business most.

2. Map dependencies and prepare safe alternatives

I review authentication and single sign-on, Microsoft Graph integrations, Power Automate flows, documents stored only in SharePoint, and security or device-management functions that depend on Microsoft services. For each dependency, I determine whether we can reduce it or need to accept and manage it.

For critical operations, I verify whether local systems, approved copies of key documentation and independent access paths can support work. I separate processes that can wait from those that need to continue.

3. Provide independent crisis communications

I provide a communication channel that does not depend on email or the same identity infrastructure as the affected service. I pair it with current contact lists, SMS notifications and phone escalation paths. Executives, IT, production, logistics and Sales receive information suited to their decisions.

I test the channel’s availability, data protection and security, along with how we inform customers and suppliers. During a crisis, IT should not spend the first hour working out how to contact its own organisation.

4. Secure controlled emergency access

For Microsoft Entra ID, I maintain at least two cloud-only emergency access accounts, independent of federation, protected by phishing-resistant authentication, monitored and regularly tested. Microsoft recommends excluding these accounts from Conditional Access policies that block sign-in and validating them regularly. Microsoft Learn guidance.

These accounts do not resolve every provider outage, so I prepare independent access paths for critical systems too. I do not disable MFA or Conditional Access protections indiscriminately under pressure. Resilience must not create new security gaps.

5. Separate backup from service continuity

Independent Microsoft 365 backups, defined retention and restore tests are necessary, but a mailbox backup does not restore an unavailable email service. For processes that must continue, I prepare a preconfigured email continuity service or another approved communication path. I test message flow, domain protection, retention and security, and I do not improvise MX record changes during an outage.

Microsoft also describes ways to reduce the impact of service incidents, including independent notification channels and locally available critical documents, in its Microsoft 365 business continuity guidance.

6. Agree fallback procedures for production, the warehouse and offices

For each process, I define what can continue safely, who approves the action and how we reconcile data after the outage. Sales needs a way to log urgent orders; the warehouse needs a procedure for essential receipts and dispatches; production needs clear criteria for continuing or stopping work orders.

Fallback procedures must prevent duplicate orders and inventory discrepancies. When there is no safe alternative, I deliberately limit the affected operation rather than increase risk.

7. Assign roles and exercise decisions

I assign an Incident Manager, technical leads, a business representative, a communications owner and process owners. We exercise partial and extended service outages. I check emergency channels, access to documentation and the organisation’s actual ability to keep work moving, not simply whether a procedure exists.

II. During an outage: how I manage the business impact

First 15 minutes: confirm the incident and coordinate the response

I activate critical-incident management when key processes are at risk. The team checks Service Health, independent status sources and our own availability tests. I assign clear ownership for email, identity, applications, infrastructure and security; pause unjustified changes; and maintain a record of decisions and impact.

Once a global issue is confirmed, I do not order mass password resets, Outlook profile rebuilds or reinstalls without evidence of a local fault. I direct specialists to work that can materially limit the impact.

15 to 60 minutes: activate the agreed fallback mode

I activate the relevant business continuity procedures. If selected Teams features remain available, we use them within the approved scope. If they are unreliable, we switch to the independent channel. Executives receive an initial report covering affected processes, what still works, active fallback procedures, decisions needed and the time of the next update.

Employees receive clear instructions. I do not share unconfirmed restoration estimates or lower security standards for convenience.

From the first hour: keep priority operations running

Process owners report the organisation’s actual ability to work, rather than only listing unavailable applications. If local ERP, MES and WMS remain available and their dependencies have been checked, production and the warehouse continue within the agreed scope. Sales uses approved alternative channels, and each emergency order receives an identifier for later reconciliation.

During a prolonged outage, I work with company leadership to assess whether fallback mode can safely continue through another shift, how the backlog is growing and when continuing becomes riskier than pausing a process. I do not wait passively for the provider. I manage what remains within the organisation’s control.

III. Restoration: verify before closing the incident

A provider’s recovery notice does not automatically close the incident for our organisation. I check mail flow and important message status using Message Trace, then review integration queues, API errors and pending retry jobs.

Process owners reconcile data from the fallback period, checking for duplicate orders, missed transactions and inventory discrepancies. I end emergency mode only after confirming service stability, data consistency and users’ ability to work normally.

After the incident, I review process impact, communications, delayed operations, costs and corrective actions with named owners and deadlines. I also check the service-level agreement, while treating any compensation as separate from continuity planning.

IV. Measure readiness in practice

I agree readiness measures with the business and validate them through exercises. Example targets include:

AreaExample target
Incident classificationWithin 15 minutes
Emergency communicationsWithin 30 minutes
First executive reportWithin 60 minutes
Activation of critical-process proceduresWithin the agreed RTO
Reconciliation of emergency transactions100% reconciled or explained
BCP exercisesAt least twice a year
Emergency access account testsAt least every 90 days

These are example targets, not universal guarantees. The most important measure is business-facing: how many critical operations can the organisation safely complete while a provider is unavailable?

V. The first 90 days: from review to exercises

In the first month, I review critical processes, Microsoft 365 dependencies and the organisation’s actual readiness. In the second, I reduce the highest risks in communications, emergency access, data protection and operating procedures. In the third, I exercise the scenarios, close the gaps and present the next investment priorities to the executive team.

I do not aim to duplicate all of Microsoft 365. I assess each investment against actual risk, business impact and the cost of potential downtime.

Technology is a tool. Business continuity is a responsibility.

Technology availability matters when it enables an organisation to produce, sell, fulfil orders and serve customers. In an outage, I connect technical decisions to business priorities: I anticipate risk, activate agreed procedures and make decisions under time pressure.

I do not control a provider’s availability. I take responsibility for preparing IT and the organisation so that an outage does not automatically stop the business.

Sources