When the Outage Is Your Cloud Provider's: What the Azure Incident of 30 September Teaches About Disaster Recovery
More than one in four incidents starts at a vendor and takes more than twice as long to resolve. The Azure outage of 30 September shows why: when the problem sits on the other side of the contract, the in-house team can only wait. What can be controlled is the preparation.
On the night of 30 September, several European companies lost connectivity between their offices and the cloud. None of them had changed anything. In-house teams opened incidents, confirmed that their configuration was correct, and then watched the provider's status page. There was nothing else to do.
That is the point of this article. Not the outage itself, which happens to every provider, but what it reveals about where control sits when the failure is not ours.
What happened on 30 September
According to the Microsoft Azure status history, between 20:30 UTC on 30 September and 02:15 UTC on 1 October 2026, roughly five hours and forty-five minutes, several networking services experienced connectivity failures across multiple regions. Affected services included private connectivity gateways (ExpressRoute), virtual private network connections (VPN Gateway), Azure Firewall, Application Gateway and Azure VMware Solution. Among the regions still impacted at the end of the incident, Microsoft lists North Europe, UK South, UK West and France Central.
The cause given in the incident summary was a recent change to a regional gateway management service, which generated higher-than-expected load while an unrelated operating system maintenance was progressing through several regions. The change was reverted and the maintenance paused.
Note the type of service affected. It was not an application. It was the connection between the company and the cloud. When that connection drops, applications can be perfectly healthy and still unreachable.
Why these outages take longer
The Azure outage is not an isolated case. It is a measured pattern.
The report analysed around 178,000 public status page records, covering roughly 109,000 unplanned incidents at more than 390 companies across 13 sectors, from 2018 to June 2026. The same study counted 223 downstream companies affected by the AWS outage of 20 October 2025.
The gap between 96 and 247 minutes is not technical. It is about control. In an internal failure, the team diagnoses, fixes and confirms. In a vendor failure, the team diagnoses that it cannot fix. Everything that shortens that time has to have been decided beforehand.
Resilience cannot be bought from the provider
Cloud providers' service level agreements cover the availability of their service, usually with invoice credits when they fail. They do not cover the continuity of their customers' operations. A credit of a few percentage points on a monthly invoice does not make up for a night of lost sales or a stalled production line.
This is the shared responsibility model read from its less comfortable side. The provider answers for the infrastructure it operates. How each company spreads its workloads across regions, how many connections it has to the cloud, and what it does when one of them drops remain the responsibility of whoever designs the architecture.
In practice, many organisations discover the dependency on the day it fails. The architecture grew region by region, service by service, and nobody drew the map of who depends on whom.
The four questions of a dependency map
A useful dependency map does not need a new tool. It needs four answers for each critical service.
- Which provider and which region does it depend on? Including indirect dependencies, such as the private connection, the identity provider or the domain name service.
- What keeps working when that region goes down? Nothing, a degraded version, or an alternative in another region. The honest answer is often "nothing".
- How much time and how much data can be lost? These are the recovery time objective (RTO) and the recovery point objective (RPO). If nobody set them, the architecture set them by default.
- Who decides to activate the alternative, and how fast? An alternative that requires a board meeting at two in the morning is not an alternative.
These four questions separate a recovery plan from a document called a recovery plan. The difference between having copies of the data and being able to operate again is explained in Backup is not disaster recovery.
What NIS2 already requires
The European NIS2 directive, transposed in Portugal by Decree-Law 125/2025, in force since 3 April 2026, addresses this directly. Article 21(2) lists among the minimum risk management measures business continuity, including backup management and disaster recovery, and supply chain security, including relationships with direct suppliers and service providers.
A cloud provider is, for practical purposes, part of that chain. And, according to Portugal's National Cybersecurity Centre, the management bodies of entities in scope must now formally approve risk management policies, oversee their implementation and ensure response and recovery in the event of an incident.
For suppliers to an entity in scope, the same requirement arrives through the contract, as explained in NIS2 in Portugal: what changes for suppliers to essential entities.
Where to start
A multicloud programme is not needed to reduce the risk. Four steps cover most of the exposure.
Inventory critical services and their dependencies. Answer the four questions above for the five to ten services the business cannot do without.
Test the loss of a region. Not on paper. Cut access to a region, in a test environment or a controlled window, and time how long it takes for operations to resume. The number that comes out of that test is the real RTO.
Have more than one path to the cloud. A single private connection is a single point of failure, even when the provider has internal redundancy. A second connection, or a tested virtual private network fallback, changes the picture.
Write down who decides. Name, deputy and activation criteria. An incident at two in the morning is not the moment to discover that nobody has the authority to move traffic to another region.
Frequently asked questions
Does running workloads in two regions of the same provider solve it? It solves part of it. It protects against the loss of one region, not against a problem that spans several regions at once, like the one on 30 September. The decision depends on what an hour of downtime costs for each service.
Is a multicloud strategy mandatory? No. For most companies, a tested second region and a timed recovery plan reduce more risk per euro invested than a full multicloud architecture.
Isn't the provider responsible for the outage? For the failure of its service, yes, under the terms of the contract. For the continuity of each customer's operations, no. That continuity is designed and tested on the customer's side.
Conclusion
The outage of 30 September lasted less than six hours and was resolved by the provider. For the companies affected, the useful question is not why Azure failed. It is what would have changed if, the day before, someone had answered the four questions of the dependency map.
To map the critical dependencies of a cloud operation and test recovery, it is possible to book a Clarity Session, with no commitment.