US Cloud Sovereignty Isn't a Trump Problem, It's a Three-Company Problem: Why UK SMBs Need to Understand Infrastructure Dependency

Compliance & Risk Management
Written By Mauven MacLeod

When I arrived at the studio this morning, Noel was rocking gently under his desk. Not in the foetal position exactly, but close. He'd spent the previous evening watching those Trump cloud sovereignty cartoons go viral across LinkedIn, and the combination of rage and existential concern had rendered him temporarily non-verbal.

"You write this one," he managed, shoving his laptop at me. "I can't be trusted to stay objective."

Fair enough. Let's talk about those images rationally.

The Cartoons Everyone's Sharing

You've seen them by now. Trump as puppet master, controlling AWS, Azure, and Google Cloud like marionettes. Trump with his hand hovering over a cable connecting Europe to US infrastructure, ready to pull the plug. They're provocative. They're viral. And they're both right and catastrophically wrong at the same time.

They're right that UK businesses run on American infrastructure controlled by American laws. They're wrong that this is about Donald Trump specifically, or any administration, or even really about politics at all.

This is about structural infrastructure dependency that's been building for 15 years. It predates Trump. It survived Biden. It will outlast whoever comes next. And every single day, UK SMBs make compliance decisions based on fundamental misunderstandings about where their data lives and whose laws actually govern it.

Let me explain what those cartoons should depict, and why the real problem is so much older and bigger than any one president.

The Three Companies That Run UK Business IT

Here are the numbers that should terrify you more than any political imagery:

Amazon Web Services, Microsoft Azure, and Google Cloud control approximately 66% of the global cloud infrastructure market. In the UK SMB sector, that dependency is even higher. Research from 2024 suggests over 80% of UK small businesses rely on at least one of these three platforms for critical business functions.

Three companies. All headquartered in the United States. All subject to US legal jurisdiction regardless of where they physically store your data.

When your IT director assures you that your data "never leaves the UK" because you've selected the "UK South" or "London" region in your cloud console, they're technically correct about the physical storage location. But they're practically wrong about everything that actually matters for compliance and business continuity.

Let me walk you through why.

What "UK Region" Actually Means (And Doesn't Mean)

When you select a UK region in AWS, Azure, or Google Cloud, you're making a decision about physical data storage geography. The servers are genuinely in the UK. The data at rest is genuinely stored on British soil.

But the company that owns those servers, manages that infrastructure, and controls access to that data? That company is American. It operates under US law. It answers to US courts. And when push comes to shove, US legal jurisdiction trumps (pardon the expression) physical geography every single time.

This isn't theoretical. This is established case law.

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act), passed in 2018 under a different administration, explicitly grants US law enforcement the power to compel US-based companies to provide data stored anywhere in the world. It doesn't matter if your data lives in a London datacentre. If the parent company is American, US courts can order disclosure.

Your "UK region" selection is a business continuity decision about latency and disaster recovery. It is not a legal jurisdiction decision about data sovereignty. But most SMBs don't understand the difference, and most vendors have no incentive to clarify it.

The Schrems II Problem Nobody Wants to Discuss

In July 2020, the European Court of Justice invalidated the EU-US Privacy Shield framework in a case known as Schrems II. The ruling was clear: US surveillance laws create risks that EU data protection standards cannot adequately address.

This wasn't about Trump. This was about structural problems with US intelligence gathering powers that exist regardless of who occupies the White House.

The practical consequence? Every UK business using US cloud providers must now conduct transfer impact assessments and implement supplementary measures to protect data transfers to the US. In theory.

In practice? Most SMBs have no idea Schrems II even exists. They see "GDPR compliant" badges on vendor websites and assume someone else has done the legal thinking for them.

Here's the uncomfortable truth: your cloud vendor can be fully GDPR compliant in their data handling practices while simultaneously being subject to US laws that conflict with GDPR's fundamental principles. Both things can be true at the same time. And when they conflict, you're the one holding the compliance risk.

Why This Isn't a UK vs US Problem

Before we go further, let's establish something critical: American businesses face exactly the same structural risks.

A US small business running on AWS is just as dependent on a single vendor's infrastructure. They face the same concentration risk. If AWS has a major outage (and it has, repeatedly), they're just as vulnerable.

The jurisdictional issues are different for US businesses. They don't have GDPR compliance concerns or cross-border data transfer risks. But they have identical exposure to market concentration, vendor lock-in, and infrastructure dependency.

This isn't UK businesses being victimised by American tech companies. This is everyone being dependent on three companies that have built monopolistic infrastructure control over 15 years of market consolidation.

Those cartoons make it look like a geopolitical conflict. It's not. It's a market failure that affects businesses on both sides of the Atlantic equally.

The Historical Context Everyone Forgets

Let's take the politics out of this entirely and look at historical precedent.

In 2013, during the Obama administration, Edward Snowden revealed the extent of NSA surveillance programs accessing data from major tech companies. That was a different president, a different political climate, and exactly the same structural problem.

In 2016, the FBI and Apple went to court over iPhone encryption. The US government demanded backdoor access to devices. Apple refused. That legal battle could happen again tomorrow with any administration.

In 2018, Microsoft fought a years-long legal battle over whether US courts could compel them to hand over data stored in Ireland. That case was eventually rendered moot by the CLOUD Act, but it demonstrated that these conflicts predate and transcend any single political moment.

The cartoons showing Trump as puppet master suggest this is new. It isn't. The powers those images depict have existed through multiple administrations of both parties. The infrastructure dependency they represent has been building since AWS launched in 2006.

What's new is that more people are finally noticing.

What Actually Keeps Me Up at Night

It's not Donald Trump specifically. It's not even US government access to data, though that's a real concern worth managing.

What keeps me up at night is the sheer concentration of risk.

Three companies control the infrastructure that runs modern business. When AWS has a major outage, significant portions of the internet simply stop working. UK businesses lose access to critical systems. Customer transactions fail. Operations grind to a halt.

This happened in December 2021. It happened again in 2022. It will happen again in 2026.

And when it does, there's no alternative. You can't spin up equivalent infrastructure on a competitor's platform overnight. You're locked in by architecture decisions made years ago, integration complexity that would take months to unpick, and staff training investments you can't replicate quickly.

The jurisdictional issues matter. The compliance risks are real. But the operational dependency is even more dangerous because it affects everyone, regardless of where they're located or which regulations they're subject to.

The Vendor Knowledge Gap

Here's what compounds the problem: most of the people selling you cloud services don't understand these issues either.

Your MSP tells you they're "GDPR compliant" because they use UK datacentres. They genuinely believe this. They're not lying to you. They're just wrong about what compliance actually requires.

Your account manager at AWS or Azure points to their certifications and assurances. Those certifications are real. The compliance frameworks are genuine. But they address data handling practices, not legal jurisdiction conflicts.

I've reviewed hundreds of cloud service contracts for UK SMBs. The number of businesses that actually understand the jurisdictional clauses, liability limitations, and data access provisions in their agreements? Less than 5%.

Everyone assumes someone else has done the legal thinking. The vendor assumes you've consulted with lawyers. Your IT director assumes the vendor's compliance team has handled it. Your board assumes your IT director knows what they're doing.

Meanwhile, the actual risk sits in a gap between all these assumptions, and nobody's actually managing it.

Why We Maintain the Myth

From a behavioral psychology perspective, this is fascinating. We've built an entire industry on a collective fiction that "cloud" means your data is somehow floating free of jurisdiction, geography, and legal constraints.

Vendors perpetuate this fiction because questioning it complicates sales. "Your data lives in the UK!" is simple messaging. "Your data is physically in the UK but legally subject to US jurisdiction under the CLOUD Act, and you need to conduct transfer impact assessments under Schrems II guidance while implementing supplementary measures that may or may not be adequate depending on your data sensitivity" doesn't fit on marketing materials.

SMBs perpetuate it because acknowledging the complexity is overwhelming. If you genuinely understood the jurisdictional risks in your current cloud architecture, you'd have to either accept significant compliance exposure or undertake expensive infrastructure diversification. Neither option is appealing.

So we collectively agree to believe the myth. Your IT director gets to claim "UK datacentres." Your compliance officer gets to tick the "GDPR compliant" box. Your board gets to avoid asking uncomfortable questions about what happens if geopolitical tensions actually did lead to infrastructure disruption.

Everyone maintains the fiction because reality is expensive and complicated.

What You Can Actually Do About This

Right. Let's get practical.

First, understand what you actually bought. You didn't buy data sovereignty. You bought physical storage location within a US company's infrastructure. Know the difference.

Second, read your contracts. Specifically the jurisdictional clauses, data access provisions, and liability limitations. Most contracts explicitly state that the vendor may be compelled to provide data access under US law. This isn't hidden. It's just written in legal language nobody reads.

Third, conduct actual transfer impact assessments. The EDPB (European Data Protection Board) has published guidance on how to assess whether your data transfers to US providers meet GDPR standards post-Schrems II. Your compliance isn't based on vendor assurances. It's based on your own documented risk assessment.

Fourth, implement supplementary measures. This might mean encryption with keys held outside US jurisdiction. It might mean data minimization so you're not storing sensitive personal data in US-controlled systems. It might mean contractual clauses requiring vendor notification before any government data access requests.

Fifth, plan for disruption. Not political disruption. Operational disruption. What happens when AWS has another major outage? Do you have failover capabilities? Can you restore critical functions from backups? How long can your business operate without cloud access?

These aren't expensive or complicated measures. They're basic due diligence that most SMBs skip because they've bought into the "it's handled" myth.

The Accountability Question

Here's where I agree with Noel's under-desk rocking: the lack of accountability in this space is maddening.

Your cloud vendor's liability for data breaches or access failures is typically capped at a month's service fees. For a business paying £500/month for cloud services, that means maximum liability of £500 for a breach that could cost you hundreds of thousands in ICO fines, customer compensation, and reputational damage.

Your MSP likely has similar liability limitations. The risk sits with you, but the infrastructure control sits with vendors who have legally minimized their exposure.

This is why I've advocated for HSE-style director liability in cybersecurity. When directors face personal consequences for failure to conduct proper due diligence, suddenly these conversations happen at board level instead of being delegated to IT directors who lack the authority to challenge vendor relationships.

But we're not there yet. So in the absence of regulatory accountability, you need to create it internally.

How to Turn This Into a Competitive Advantage

Right. Let's flip this from threat to opportunity.

1. Vendor Diversification as Market Differentiator

Most of your competitors are entirely dependent on a single cloud provider. If you've invested in multi-cloud capabilities or hybrid infrastructure, you can offer customers guaranteed service continuity that competitors can't match.

This matters for procurement. Businesses evaluating suppliers increasingly ask about infrastructure resilience. "We maintain operational independence across multiple providers" is a concrete differentiator.

2. Compliance as Sales Tool

If you've actually done the work on transfer impact assessments, supplementary measures, and documented risk management, you can demonstrate compliance rigor that most competitors fake.

For customers subject to GDPR or handling sensitive data, this becomes a qualification criterion. You're not just claiming compliance. You're documenting it in ways that auditors and data protection officers actually care about.

3. Geographic Data Sovereignty Offerings

Some businesses genuinely need data to stay within UK jurisdiction. If you can offer services that actually meet this requirement (using UK-owned infrastructure, not just UK regions of US companies), you've created a niche market offering.

This is particularly relevant for government contractors, healthcare providers, or businesses in regulated industries where data sovereignty isn't optional.

How to Sell This to Your Board

Your board doesn't care about Trump cartoons. But they care about risk exposure and competitive positioning.

Frame it as enterprise risk management:

"We've conducted a review of our infrastructure dependencies and identified concentration risk across our cloud provider relationships. Current architecture creates single points of failure that could disrupt operations for extended periods. We're recommending diversification investments to mitigate this exposure."

Quantify the compliance risk:

"Post-Schrems II, businesses using US cloud providers must demonstrate they've assessed data transfer risks and implemented supplementary measures. Our current posture exposes us to ICO enforcement action. We need budget for transfer impact assessments and potential architecture changes to ensure we're defensible."

Position it as competitive advantage:

"Our competitors are entirely dependent on [single cloud provider]. By implementing multi-cloud capabilities, we can offer customers service level guarantees they can't match. This becomes a procurement differentiator in tender responses."

Use concrete numbers:

"AWS had 47 hours of significant service disruption across 2024. At our current dependency level, that represents approximately £X in lost revenue and £Y in productivity costs. Diversification investments would reduce this exposure by Z%."

Boards understand risk quantification. They understand competitive positioning. They understand regulatory exposure. Frame infrastructure dependency in those terms, and you'll get the budget.

What This Really Means

Those Trump cloud cartoons are going viral because they tap into a genuine anxiety about infrastructure dependency and loss of control. The anxiety is justified. The political framing is misleading.

This isn't about any particular president or administration. It's about 15 years of market consolidation creating structural dependencies that most businesses don't understand and can't easily escape.

The vendors aren't going to fix this. They have no incentive to clarify the jurisdictional complexity or highlight the concentration risk. The regulations aren't going to fix this quickly. Schrems II highlighted the problem in 2020, and we're no closer to solutions in 2026.

So it falls to you. Understand what you actually bought. Document the risks you're accepting. Implement practical measures to mitigate exposure. And stop believing the myth that someone else has handled the hard thinking.

Your data is in the UK. Your legal jurisdiction is in the US. Your business continuity depends on three companies. None of this changes based on who's in the White House.

Act accordingly.

Noel has emerged from under his desk and is making tea. I suspect next week's podcast will be... spirited.

Mauven MacLeod
Previous

Four Game-Changing Cyber Stories in One Episode
Next

When the Cybersecurity Guardian Uploads State Secrets to OpenAI: The CISA ChatGPT Incident