Opinion · Cloud strategy · Vendor risk

How a foreign war reached your customer stack

Marketing campaigns paused. Banking apps fell over.
None of those vendors had been hit. Their cloud had.

In early 2026, kinetic strikes on hyperscaler infrastructure in the Gulf — two data centres struck directly, a third damaged by proximity — took dozens of services from one of the world's largest cloud providers offline. The interesting question for the boardroom was not how long the outage lasted. It was what came down with it.

For enterprises in the region, the list was longer than most had mapped. The visible part — services on the provider's public status page — was contained and contractual. The longer list was the SaaS layer that quietly runs on top of that provider. The region's dominant ride-hailing platform went dark across the Gulf. Leading fintech payments providers reported outages. Customers of two of the region's largest banks found services degraded. A major global data-warehouse vendor reported disruption. None of these companies were running on a damaged data centre. They were running on the same underlying cloud, which was.

The dependency chain you have not mapped

Most enterprise architecture diagrams stop at the SaaS layer. They show Marketing Cloud, CRM, CDP, analytics, support, identity — and the integrations between them. What they rarely show is the layer beneath: the hyperscaler each vendor procured for itself, in a contract you do not see and have not signed. Ask, of each SaaS product central to customer engagement, which hyperscaler does this run on, in which region, under which contract? Few companies can answer for more than a quarter of the SaaS stack their business runs on.

Lock-in makes the dependency irreversible

Concentration alone is manageable. What makes it intractable is what sits on top. Inside each SaaS product, your team has spent months or years building the operational asset that defines the product's value — journey trees, propensity models, suppression rules, channel routing, identity graphs, segment libraries, ticket taxonomies. None of it migrates in a CSV. All of it is encoded in vendor-specific objects.

When the hyperscaler underneath a vendor goes dark, you have three options. Wait for the hyperscaler to come back. Ask the vendor to fail over to a different region — which they may or may not be able to do, on a timeline you have no contractual control over. Or move to a different vendor entirely — the 12-to-24 month, seven-figure exercise that, in calmer weeks, no one will start.

Two lock-ins, stacked. The cloud you cannot change without changing the vendor, and the vendor you cannot change without rebuilding what you have built.

The regulator's question is no longer about uptime

When a hyperscaler region goes dark for geopolitical reasons, the regulator's question set shifts. Not where was the data centre — but where was the data physically located, who had legal access to it, under whose laws, with what oversight. In-region is not in-country. Encrypted is not governed by local law. A regional data centre operated by a foreign-headquartered company sits inside your borders but remains subject to that parent's legal process.

Under the DPDP Act in India, post-Schrems II GDPR in the EU, and sectoral data protection laws across the GCC, Indonesia, and Brazil, the standard has moved from encrypt the data and host it regionally to store, process, and govern under entities subject to local law. Most enterprise SaaS architectures, including most Marketing Clouds, were designed to satisfy the older rule. The architecture that passes an availability audit does not necessarily pass a sovereignty audit.

Use the moment

No enterprise should change vendors tomorrow. Almost no enterprise should. The argument is narrower: the questions worth answering are easier to ask in the week after an incident than in the calm before the next one. Build the inventory of which vendor sits on which hyperscaler in which region. Quantify the concentration. Cost the realistic recovery time — not the contractual SLA. Ask the residency question in writing, and get a number for what it would take to leave each vendor at the application layer and at the cloud layer beneath it. The exercise commits the organisation to nothing. The output is something the board has not had: a clear-eyed view of the dependencies it has accumulated and the cost of leaving them unmanaged.

The geopolitical event is doing work for you. The moment will not come twice.