As the Microsoft 365 outage disrupted organisations worldwide, I spoke with the CIO of a large manufacturer based in India. He has asked not to be named, but was willing to share what the episode has taught him about depending on the cloud. His reflections follow.
Here is the CIO in his own words:
I am the CIO of a large manufacturer in India. Over the last two days, the Microsoft 365 outage has been a live case study in how exposed modern enterprises are to a single platform. I am sharing the lessons I am taking from it, in case they help other technology leaders.
What happened, as far as we know
The disruption began on Thursday, 12 November, and continued into Friday, 13 November. Outlook, Teams, the web versions of Word, Excel and PowerPoint, OneDrive, SharePoint and Copilot were all affected. At its peak, Downdetector recorded nearly 130,000 Outlook problem reports from 74 countries, including India.
Microsoft has said there is no indication of a cyberattack. The problem appears to have started with a configuration change that left some servers overloaded and unavailable. Traffic moved to the remaining machines and added pressure there. Recovery then proved difficult: some servers stopped responding again once they were brought back and traffic returned. Microsoft has not yet given a definitive explanation for the duration or a firm timeline for full recovery, so I am treating the root cause as provisional.
Lessons I am taking away
1. Concentration is a risk, and it needs an owner.
Email, chat, documents, storage, meetings and now AI assistants sit on one platform for most enterprises, mine included. Each choice made sense individually: one licence, one vendor, one admin console. Together they form a single point of failure. A routine configuration error was enough to disrupt businesses, government departments, schools and airlines across the world, and I want that risk named, owned and reported, not left as a by-product of convenience.
2. An SLA is a refund policy, not a continuity plan.
Service credits do not repay lost production time, a missed dispatch or a delayed supplier commitment. Even in India, we saw SpiceJet cancel three Delhi flights and delay two others, while Air India kept its operations running by rerouting email traffic. The difference between those outcomes is preparation. For every critical process, I now ask: if this platform is unavailable for a day, what do we do?
3. Dependencies reach us through other vendors.
OpenAI and Anthropic both reported problems with their Microsoft 365 connectors. A manufacturer can be hit indirectly through a supplier portal, a logistics partner, a SaaS tool or an AI service that depends on the same platform. Second-order dependencies are the ones we rarely map. I am asking my team to list them.
4. Manufacturing makes the question sharper.
Office tools sit close to plant operations more often than we admit: production planning, supplier and dealer communication, quality approvals, shipping documents and vendor payments often move by email, shared files and Teams. I am asking each function head which of these workflows stop if Outlook, Teams and SharePoint are unavailable, and whether the plant floor and supply chain can keep running while they are.
5. AI raises the stakes.
As AI is embedded deeper into daily work, an outage stops more than communication. Processes that depend on an AI step can stop altogether. Every AI-assisted workflow needs a defined manual or simpler fallback, so that it degrades gracefully instead of halting.
6. Our crisis plan must not live on the platform that can fail.
The question I am putting to my team is simple: if Microsoft 365 is down, where is the incident plan, who has the escalation list, and which channel do we use to coordinate? If the answer is SharePoint, Outlook and Teams, then we do not have a plan. It must be reachable through channels that do not share the same infrastructure.
7. Restoration is not the same as recovery.
Even after infrastructure is restored, applications may need time to reconnect, synchronise data and return to normal. I want our recovery expectations to include that tail, not just the vendor’s technical outage window.
Actions I am prioritising
Immediately
Establish an out-of-band communication channel that does not depend on Microsoft, such as SMS broadcast, a secondary messaging platform and an offline contact tree for leadership, IT and plant heads.
Keep copies of the incident plan, contact lists and runbooks somewhere accessible when the primary platform is down, including printed copies.
Pre-agree who communicates what to employees, suppliers, dealers and customers during an outage.
Next quarter
Map dependencies across applications, identity, data flows and third-party tools, including indirect ones.
Agree a maximum tolerable downtime for key processes with business and plant leaders, not just within IT.
Identify which workflows break if email, collaboration tools or AI services are unavailable.
Review vendor contracts for outage communication commitments, not just uptime percentages.
Next year
Add selective alternatives for the most critical functions, such as a mail continuity service, locally synced essential documents or a second provider for a narrow function.
Run an exercise with the scenario “our primary cloud platform is unavailable for 24 hours,” beyond conventional disaster-recovery tests.
Report concentration risk to the board.
The balance
I am not arguing for leaving the cloud. Large providers generally offer better uptime and security than most in-house teams can, and on-premises systems fail too, just less visibly and one organisation at a time. Outages of this scale are the exception.
The answer is resilience: keep the benefits of the cloud, protect the functions where a day’s outage would be genuinely damaging, and consciously accept the risk elsewhere. Resilience costs money, so it should be applied selectively.
Closing thoughts
The lesson is not that the cloud is unreliable. It is that dependence has become highly concentrated, and that many organisations have no plan for the day their main platform is simply not there. The cost of preparing is small compared with the cost of improvising.