The Microsoft outage raises a bigger question: Should cloud providers help protect continuity beyond their own platforms?
We have spent years asking enterprises to prepare for cloud outages. Build redundancy, maintain backups, adopt multi-cloud strategies and establish disaster recovery plans. The responsibility has largely been placed on the organisations consuming cloud services.
But there is a question we rarely ask.
What happens when the cloud provider itself becomes the point of failure?
The recent Microsoft outage brought this question back into focus. Email, collaboration, document management and several business workflows have become deeply integrated into everyday operations. When these services are unavailable, the impact is not limited to IT. Employees lose access to essential tools, business operations slow down, customer commitments are affected and decision-making gets disrupted.
Social media may turn such outages into memes about an unexpected holiday or a quiet inbox. But behind those jokes is a much bigger reality. We have built a digital economy that depends heavily on a few major technology platforms, yet our resilience models remain largely confined to individual organisations and providers.
This is where the conversation needs to change.
When an outage becomes more than an IT problem
Imagine a hospital where patient records, clinical coordination and communication systems depend on cloud-hosted services. An extended disruption could delay access to essential information and affect the coordination of medical teams.
Consider emergency response services, utilities, transportation or manufacturing. If the digital systems supporting communication, operational visibility or coordination become unavailable, the consequences may extend beyond productivity.
An outage does not automatically translate into a threat to human life. The concern arises when critical operations depend on unavailable services and there are no effective alternatives.
The business impact is just as real.
A financial institution could face disruption to customer-facing services. A manufacturer could lose production visibility. An e-commerce business could be unable to process orders. Revenue loss is only one part of the equation. Contractual penalties, regulatory consequences, recovery costs, customer confidence and reputation are also at stake.
We often measure cloud availability in percentages and service-level agreements. But what does that downtime actually mean to the business, its customers and the people depending on its services?
That is the question resilience planning must answer.
Multi-cloud is not a magic switch
Multi-cloud adoption is often presented as the answer to cloud dependency. It certainly has a role, but simply having workloads across two cloud providers does not guarantee continuity.
Applications are built around specific platforms, identity services, databases, networking, encryption mechanisms and proprietary capabilities. Moving data is one challenge. Making the application operational in another environment is an entirely different one.
Take Microsoft 365 as an example. If Exchange Online, Teams or SharePoint becomes unavailable, having infrastructure hosted with another cloud provider does not automatically restore those services.
This distinction matters.
There is a difference between having another cloud subscription and having a tested, independent recovery capability.
Not every workload needs to operate across multiple providers. The decision should be based on business impact. Applications supporting human safety, essential operations or significant financial exposure may justify the additional investment and complexity.
For some systems, independent backups and alternative communication channels may be sufficient. For others, cross-cloud recovery may be necessary. Safety-critical operational technology also requires local fail-safe capabilities; cloud failover cannot replace them.
The objective should not be to duplicate everything. It should be to identify what cannot afford to remain unavailable.
What if cloud providers helped one another?
Here is where I believe the industry needs to think differently.
Enterprises are expected to prepare for provider failures, but the providers themselves are not generally part of a shared, cross-provider emergency recovery arrangement.
What if participating cloud service providers established reciprocal resilience agreements?
The idea is not for one provider to take over another’s infrastructure or gain unrestricted access to its customers’ data. It is to create predefined arrangements through which providers could make agreed recovery capacity or continuity capabilities available during a severe disruption.
Consider a hypothetical situation.
A major cloud provider experiences a prolonged outage affecting a set of critical services. Under a reciprocal agreement, another participating provider could make pre-agreed infrastructure capacity available to support eligible workloads, provided the applications are portable, the recovery environment is prepared and the customer has authorised the arrangement.
This would not magically restore a proprietary SaaS service such as Exchange Online or Teams. Those services would require their own continuity arrangements, supported by the provider and the relevant technical architecture.
But for workloads that can be recovered independently, such agreements could offer another layer of protection.
It is a model worth exploring.
The Cloud Resilience Exchange
What if this cooperation had a neutral industry framework?
I would call it the Cloud Resilience Exchange.
This is a proposed concept, not an existing industry service. The purpose would be to establish a common framework through which participating cloud providers could coordinate during major disruptions.
It would need to answer some difficult but necessary questions.
- When should assistance be activated? Providers must agree on qualifying outage conditions, activation authority and escalation procedures.
- What gets priority? Recovery should consider the impact on human safety, essential services and business continuity rather than simply the size of the customer.
- Where does the data go? Any recovery activity must respect data sovereignty, privacy obligations, contractual restrictions and regulatory requirements.
- Who controls access? Customer authorisation, encryption keys, identity controls and security monitoring must remain central to the arrangement.
- Who carries the responsibility? Commercial settlement, liability, accountability and service commitments must be agreed before an incident occurs.
- Does it actually work? Providers must conduct independent exercises to validate capacity, technical compatibility and recovery procedures.
The framework should not require providers to surrender control of their infrastructure. Nor should it weaken customer control over data, encryption keys or recovery permissions.
It should provide a controlled mechanism for cooperation when the consequences of an outage extend beyond one provider.
But will competitors cooperate?
This is probably the hardest part of the proposition.
Cloud providers compete for the same enterprise customers, workloads and long-term contracts. Asking competitors to support one another during a major outage may not appear commercially attractive.
There are also genuine concerns around intellectual property, customer data, regulatory obligations, capacity constraints and liability.
These challenges cannot be dismissed.
However, competition does not mean every form of cooperation is impossible. The technology industry already operates through shared standards and defined interoperability arrangements. Those arrangements are not equivalent to reciprocal disaster recovery, but they demonstrate that cooperation can exist within clear boundaries.
A resilience agreement would need a commercially viable model. Emergency capacity could be reserved or made available under agreed usage charges. Participation could be voluntary, with contractual safeguards and independent assurance.
The providers would remain competitors. The cooperation would be limited to clearly defined continuity arrangements.
The objective is not to make one provider dependent on another. It is to prevent a major provider-level disruption from becoming a wider systemic failure.
What should enterprises do in the meantime?
This proposal does not remove the responsibility of enterprises to build their own resilience.
Organisations should start by asking three questions about every critical cloud-dependent service:
Could its unavailability affect human safety? Could it interrupt essential business operations? What would the financial and reputational consequences be if recovery took longer than expected?
The answers should determine the level of resilience required.
For some services, independent backups and manual procedures may be adequate. Others may require cross-cloud recovery environments, alternative communication channels or independent identity and network capabilities.
A recovery environment that relies on the same identity provider, DNS service or network dependency that has failed is not truly independent.
Data replication must also be governed carefully. Customer authorisation, encryption, privacy, regulatory requirements and data residency cannot become secondary considerations during an emergency.
Resilience must be designed, tested and funded before an outage occurs. It cannot be improvised when the business is already struggling to operate.
The responsibility cannot stop with the cloud consumer
Cloud computing has transformed how organisations operate. It has enabled scale, innovation and business capabilities that were difficult to achieve through traditional infrastructure.
But as dependency grows, so does the responsibility to think beyond individual service availability.
Enterprises must build independent recovery capabilities for the services that matter most. Cloud providers should explore reciprocal arrangements that can support continuity beyond their own platforms. The wider industry should work towards common standards for security, interoperability and recovery.
The Microsoft outage is not an argument against cloud adoption. It is a reminder that convenience, scale and availability are not the same as resilience.
We have spent years asking enterprises how they will survive a cloud provider outage.
Perhaps it is time to ask the cloud providers the same question.
The next evolution of cloud resilience should not be about how many providers an enterprise uses. It should be about how the cloud ecosystem responds when one of its own fails.
