The outage that borrowed tomorrow's incident
On Thursday this week, Microsoft 365 started failing for a large number of customers. Outlook, Teams, SharePoint and Copilot went down for millions of users, with Downdetector logging over 129,000 error reports at the peak. The disruption ran into a second day, with Microsoft reporting "encouraging recovery signals" on Friday while some users still had intermittent problems. Microsoft's own explanation pointed to infrastructure strain, elevated load across multiple regions, and it said it found no sign of malicious activity.
No attacker. No ransomware note. No encrypted file shares. Just an availability failure, and still, for the best part of two days, a meaningful slice of the corporate world lost its primary way of telling people what was going on.
It wasn't just email
By Friday, the disruption was being described as affecting business, schools, medical facilities and transport in at least 74 countries. The headline inconvenience was a backlog of unread email. The operational detail underneath it is sharper:
A Taiwanese financial firm reportedly fell back to faxing trade confirmations.
Staff at Morgan Stanley and Goldman Sachs in Hong Kong had their work disrupted through to lunch.
Airline customer support desks, including IndiGo and Akasa Air, couldn't help customers because support ran through the same inbox that was down: "unless a lot of people call up… we can't help them until we can get access to their emails."
Workhorse Group postponed its quarterly earnings call to 16 November because of the outage.
Analysts quoted by ABC expect the outage to cost Australian businesses billions of dollars, with small businesses hit hardest.
None of those are IT tickets. They are board-reportable, customer-facing, regulator-adjacent business processes that happened to be running on the same infrastructure as everyone's inbox.
Crisis management is a business process too
Follow that thought one step further and ask what happens to the processes a crisis team itself depends on, and the picture gets uncomfortable fast.
A crisis team's own workflow is a business process like any other, usually with its own email sign-off chain, its own status page, its own ticketing system, its own calendar invites for the next bridge call. If Workhorse Group had to move an earnings call because a chunk of the world couldn't reach its inbox, consider what happens to a decision that needs sign-off from a general counsel who is just as locked out, or a regulatory notification that has to land inside a 72-hour window that doesn't pause because Outlook has.
If airline support staff were reduced to waiting for the phone to ring because they couldn't read email, imagine the incident commander who can't reach the retained digital incident response & forensics vendor, the backup vendor, or half of their own crisis team, because the distribution list, the calendar invite and the shared incident log all live in the same tenant that just went down. If banking staff lost half a day of ordinary work to this outage, a crisis team losing the same half day isn't an inconvenience. It's half a day added straight onto the regulatory clock, the negotiation window, or the time before customers find out some other way.
This week gave the industry a dry run for exactly that: a stress test, with no attacker and no real stakes, of what happens when the infrastructure underneath the business and the infrastructure underneath its own crisis response are the same infrastructure.
The plan says "notify the incident bridge." What if the bridge is down?
Every continuity and incident response plan I have ever reviewed names its communication channels somewhere near the front: email the stakeholder list, post to the Teams incident channel, update the status page, call the bridge number. Sensible things to write down. What is rarely written down is the assumption sitting underneath all of it: that the channel will be there, and that the person trying to use it will be able to log into it.
This week, for a lot of organisations, neither was true. Not because of an attack, just because of load on Microsoft's infrastructure. If that is what an ordinary outage can do to your primary communication channel, it is worth sitting with what a deliberate one can do.
Two failure modes wearing the same coat
An availability outage and a destructive cyberattack can look identical from the outside, in the first few minutes: the tools you normally reach for stop responding. But they are not the same problem, and the second one is worse in a way that matters a great deal to anyone writing a crisis communications plan.
In an availability outage, the channel is gone, but the identity behind it is intact. The moment Microsoft's infrastructure recovers, your account, your credentials and your trust in the person on the other end of the Teams call all come back exactly as they were.
In a destructive cyberattack, you can lose both at once. If the attacker has been in your identity provider, Active Directory or Entra ID, the outage isn't just "Teams is down". It's "the thing that proves you are you, and that the person messaging you is who they say they are, is the thing we can no longer trust." The channel might technically still work. That is arguably worse, because now you have to assume the attacker can read it, use it, or impersonate someone on it, right up until you have rebuilt identity somewhere they don't control.
Why this gets under-planned
Most business continuity plans were written for a different kind of disaster: a fire, a flood, a power cut, a failed data centre. In those scenarios, the organisation's identity is never in question. Nobody wonders whether the person calling the bridge is really a colleague. The plan can safely say "email the team" and "post to the intranet" because the only thing actually broken is a building or a server rack.
That plan then gets copied, largely unchanged, into the cyber playbook. Communications is often the shortest section, because it was drafted by people thinking about a disaster where the channels survive. Nobody goes back and asks the one question that would have changed every line of it: is this channel, and the identity I'll use to get into it, hosted on the thing that might just have been encrypted?
It is a bit like wiring the fire alarm's control panel into the circuit it's meant to warn you about. Nobody does that on purpose. It happens because the alarm and the thing it is watching were built by the same team, at the same time, using the same infrastructure, and nobody asked the awkward question until the day it mattered.
Five things worth doing before you need them
Map every crisis channel to what it depends on. Email, Teams, the status page, the SMS gateway, the conference bridge: for each one, write down the identity provider, the hosting, and the network path it needs. If that list is short because most of it traces back to the same tenant, you have found your single point of failure before an attacker did.
Keep at least one channel genuinely out-of-band. Not a different app on the same identity, a channel on separate infrastructure and separate identity: a personal mobile number, a dedicated crisis messaging tool with its own login, a conference bridge dialled by phone number rather than a corporate calendar invite.
Pre-stage the contact details you'll need, outside the systems that might fail. A printed or offline copy of the incident call tree, held by the people who will actually need it, not stored only in the directory that might be the first thing an attacker targets.
Decide in advance how you'll know it's really them. If identity can't be trusted, a phone call from an unfamiliar number claiming to be the CISO isn't automatically the CISO. A pre-agreed verification method, even something as simple as a shared phrase or a callback to a known number, costs nothing to set up and a great deal to improvise under pressure.
Rehearse the scenario where the plan's own channel is the casualty. Most tabletop exercises assume the plan works and test the decisions made through it. Run one where the first thing that happens is the incident bridge itself goes dark, and watch how long it takes the room to remember the channel they were supposed to fall back to.
The lesson was free this time
Nobody had to decide whether to pay anyone. By Friday, Microsoft had the lights back on, and most people's biggest complaint was a backlog of unread email. That makes this a rare thing in cyber resilience: a full-scale rehearsal of a real dependency, with none of the real cost.
The organisations that get value out of this week won't be the ones writing a strongly worded note to their Microsoft account executive. They'll be the ones asking what would have happened if this outage had been deliberate, and whether their crisis communications plan survives an attacker who also owns the identity behind it. That's a cheap question to ask this week. It gets a lot more expensive to ask for the first time during the real thing.
