The CLOUD Act and Your UK Business: The Unquantified Legal Risk Nobody Is Testing
This week on The Small Business Cyber Security Guy podcast, I sat down with Noel, Mauven, and Graham to discuss something that affects every UK organisation using Microsoft 365, Google Workspace, or any US-headquartered cloud service. What started as a conversation about Palantir and government contracts became a broader examination of a legal conflict that sits, untested and unresolved, in the middle of your technology stack.
I want to be precise about what follows. I am not going to tell you the NSA is reading your timesheets. I am not going to suggest you rip out Microsoft 365 by Friday. What I am going to do is walk you through a legal exposure that your solicitor, your IT provider, and your regulator have almost certainly never explained to you clearly. And I need you to sit with the implications before you decide what to do about it.
What the CLOUD Act Actually Says
The Clarifying Lawful Overseas Use of Data Act was enacted in March 2018. The name sounds bureaucratic. The mechanism is not.
Here is the core provision: if a company is subject to US jurisdiction, it can be compelled by a US court to preserve or disclose data in its possession, custody, or control, regardless of whether that data is stored inside or outside the United States.
Read that again. The location of the server is irrelevant to the legal obligation.
If you are a UK business using Microsoft 365, your email, your documents, your Teams chats, and your SharePoint files live on infrastructure operated by a US-headquartered company. The fact that Microsoft markets "UK data residency" and stores your data in London or Cardiff data centres does not change the fundamental legal reality: Microsoft Corporation is subject to US jurisdiction, and a US court can compel it to produce data it controls.
The same applies to Google Workspace, AWS, Salesforce, HubSpot, Zendesk, and every other US-headquartered SaaS platform in your stack.
The UK-US Bilateral Agreement: A Door That Swings Both Ways
The UK and the United States signed a bilateral data access agreement under the CLOUD Act on 3 October 2019. It entered force on 3 October 2022, making it the first such agreement worldwide.
Here is what most analysis omits. Under this agreement, the UK has issued more than 20,000 orders to US technology companies. Over 99.8% of those were wiretap orders under the Investigatory Powers Act. The United States has made just 63 requests to UK providers.
That asymmetry tells you something important. The UK government is an active, enthusiastic user of this mechanism. It has issued requests at a rate exceeding 300 to 1 compared to US requests flowing in the other direction. Attorney General Merrick Garland renewed the agreement three years early in November 2024, reportedly to prevent the incoming Trump administration from modifying it.
The UK government's position is therefore inherently conflicted. It is simultaneously a beneficiary of CLOUD Act access (having issued 20,000+ orders) and obligated to protect UK data subjects from unauthorised foreign government access to their personal data. Those two commitments coexist uncomfortably.
The Legal Conflict That Nobody Has Tested
UK GDPR Article 48 is explicit. It restricts the recognition of foreign court judgments or administrative decisions that require a data controller to transfer or disclose personal data, unless the transfer is based on an international agreement such as a mutual legal assistance treaty.
The CLOUD Act operates outside the traditional mutual legal assistance framework. It allows US courts to issue orders directly to US companies, compelling production of overseas data. The UK-US bilateral agreement provides a streamlined pathway for certain law enforcement requests, but it does not resolve the broader tension.
Section 26 of the UK Data Protection Act 2018 provides exemptions for national security and defence. These exemptions are broad. But they do not address the scenario most relevant to commercial organisations: a US court order issued for purposes that fall outside UK national security exemptions, compelling a US provider to produce data belonging to a UK business or its clients.
A CMS law firm white paper published in February 2026 acknowledged that while US providers can apply to quash CLOUD Act demands through a comity analysis mechanism, this mechanism has never been tested in practice. The legal safeguard that is supposed to protect against conflicts of law has not been used. Not once.
Meanwhile, in July 2025, Microsoft France's chief legal officer admitted under oath before the French Senate that Microsoft cannot guarantee data sovereignty for European customers if the US government demands access. Microsoft stated it has contractually committed to resisting unfounded requests, but acknowledged that in specific and limited cases, it responds to US government demands.
The reality is this: you have a legal conflict between two jurisdictions, affecting every UK organisation using US cloud services, with no court precedent to resolve it, no regulatory enforcement testing it, and no clear guidance from the ICO on how organisations should assess it.
What the ICO and NCSC Have (and Have Not) Said
The ICO updated its international transfers guidance on 15 January 2026, introducing a three-step test for restricted transfers aligned with the Data (Use and Access) Act 2025. The Transfer Risk Assessment framework requires organisations to assess government access risks in destination countries.
However, the ICO does not explicitly mention the CLOUD Act in its published guidance. The risk must be inferred through the general Transfer Risk Assessment framework. No ICO enforcement action has targeted CLOUD Act exposure. No fine, no reprimand, no formal investigation has addressed the question of whether UK organisations using US cloud providers are adequately assessing this specific jurisdictional risk.
The NCSC similarly does not address the CLOUD Act by name. Principle 2 of its Cloud Security Collection states that organisations must understand the "legal circumstances in which their data could be accessed without their consent." That is the closest the UK's national cybersecurity authority comes to acknowledging this issue.
I want to be careful not to overstate the current enforcement risk. The ICO has not said this is a priority. No UK organisation has been penalised for failing to assess CLOUD Act exposure. But the absence of enforcement is not the same as the absence of risk. It means the risk is unquantified, sitting in a regulatory blind spot.
Encryption Is Not the Answer You Think It Is
On the podcast, Noel made a point that deserves expansion. Everyone reaches for encryption as the answer to data sovereignty concerns. The logic seems sound: if data is encrypted and you hold the keys, compelling the provider to produce it achieves nothing useful.
The problem is that most UK businesses do not actually control their encryption keys.
BitLocker is the most immediate example. When Windows devices join Entra ID (formerly Azure AD), BitLocker recovery keys are automatically backed up to Microsoft's cloud. In a documented US fraud case, Microsoft produced BitLocker recovery keys to federal investigators under valid legal process, enabling decryption of seized laptops. If your organisation uses BitLocker with default Microsoft 365 settings, your disk encryption keys are accessible to Microsoft, and therefore accessible to US legal process.
Microsoft 365 service encryption presents a more complex picture. All data at rest is encrypted using Microsoft-managed keys by default. The Customer Key feature allows organisations to supply their own root keys through Azure Key Vault. However, Microsoft automatically generates and retains an "availability key," a third key stored in Microsoft's own secret stores that customers cannot access or delete. Microsoft explicitly states that Customer Key authorises the service to use keys for "value-added services like eDiscovery, anti-malware, anti-spam, and search indexing."
Double Key Encryption (DKE) is the only Microsoft 365 feature that genuinely prevents Microsoft from accessing content. It requires two keys: one Microsoft-controlled, one exclusively held by the customer. Both are needed for decryption. But the limitations are severe. eDiscovery cannot read DKE-protected content. SharePoint search and indexing do not function. Copilot cannot process it. It works only with desktop Office applications on Windows. Sensitivity labels must be applied manually. An E5 licence is required. Microsoft's own documentation states DKE "is intended for your most sensitive data" and "isn't intended for all data."
The principle Noel stated on the podcast holds: if your provider can help you recover your data when you have locked yourself out, that same capability can be compelled by a court to help someone else access your data when you would rather they did not.
Why This Matters for a 30-Person Firm in Birmingham
I can hear the objection forming. This is government-level paranoia. Nobody is coming for my invoices.
From a threat intelligence perspective, the concern is not that the NSA cares about your quarterly accounts. The concern is threefold.
First, you have contractual obligations you may be breaching. If you have signed contracts promising clients their data will remain in the UK, or that it will be protected in accordance with UK GDPR, and your data sits on a US-owned platform where the CLOUD Act may apply, you have potentially made a promise you cannot keep. The ICO does not care whether you were confused by the marketing.
Second, your Data Protection Impact Assessments are probably incomplete. Under UK GDPR, you are required to understand where personal data goes, including international transfers and the risks involved. If your DPIAs do not address the jurisdictional reach of US law over your cloud providers, they have a gap. That gap becomes relevant the moment a regulator, a client, or a journalist asks the right question.
Third, this is now a board-level governance risk. It sits alongside financial solvency and health and safety. Directors are expected to at least ask: what are our data sovereignty exposures? Do we understand our reliance on foreign jurisdiction vendors? Do we have high-sensitivity data in systems where we do not control the keys? "We never discussed it" is not a defence that inspires confidence.
For charities handling sensitive case files, professional firms with client confidentiality obligations, NHS supply chain organisations processing patient-adjacent data, or engineering companies protecting intellectual property and bid documents, the exposure is real, specific, and currently unassessed.
Europe Has Noticed. The UK Has Not.
The contrast with European government action is stark. France banned all non-European videoconferencing tools from government use on 26 January 2026, replacing Zoom, Teams, and Google Meet with the sovereign Visio platform. Germany's Schleswig-Holstein state is migrating 30,000 workstations from Microsoft to open-source alternatives, saving an estimated €15 million annually. The Dutch Parliament passed eight motions in March 2025 demanding exit strategies from US cloud providers. Switzerland's Privatim declared US cloud services unsuitable for sensitive government data in November 2025.
The UK has produced no equivalent sovereign cloud strategy, no government migration programme, and no explicit regulatory position on the CLOUD Act conflict for commercial organisations. The CMA's cloud services market investigation, published July 2025, found competition in UK cloud services is "not working well," with AWS and Microsoft each holding 30 to 40% of a £10.5 billion market and fewer than 1% of customers switching providers annually.
That gap between European action and UK inaction is the risk amplifier. When your European trading partners, clients, or regulators begin asking about your data sovereignty posture, the answer cannot be "we never thought about it."
How to Turn This Into a Competitive Advantage
If you are reading this and thinking "this sounds like a problem," you are right. But problems that your competitors have not yet addressed are opportunities.
Win public sector contracts. As European governments demand data sovereign solutions, UK public sector procurement will follow. Organisations that can demonstrate a clear data sovereignty posture, including vendor jurisdiction mapping, encryption key control, and documented exit plans, will have a measurable advantage in tender responses.
Differentiate on trust. If you serve clients with sensitive data (legal, healthcare, financial, charitable), being able to articulate your data sovereignty position clearly is a trust signal. "We have assessed our CLOUD Act exposure and taken specific steps to manage it" is a statement none of your competitors are making.
Reduce regulatory exposure ahead of the curve. The ICO has not enforced on this yet. When it does, and the direction of European regulation makes this increasingly likely, organisations that have already assessed and documented their position will be ahead.
How to Sell This to Your Board
Keep this brutally simple. Directors need three things.
The risk statement: "US law allows American courts to compel US technology companies to hand over data regardless of where it is stored. This includes data we hold on Microsoft 365 and other US platforms. UK GDPR restricts this, but no court has tested the conflict and no regulator has enforced on it. This is an unquantified legal exposure in our technology stack."
The cost of inaction: "If a client, regulator, or journalist asks us about our data sovereignty position and we cannot answer, the reputational and contractual consequences are immediate. We do not need a breach for this to become a problem."
The ask: "We need to conduct a CLOUD Act exposure audit (one afternoon with IT), identify our crown jewel data sets, and assess our encryption key control posture. This is a governance item, not an IT project."
What This Means for Your Business
Conduct a CLOUD Act exposure audit this month. List every system touching client or staff data, note the vendor's headquarters, and flag every US-owned platform. Thursday's post will provide a step-by-step guide.
Check your BitLocker key escrow settings. If recovery keys are backing up to Entra ID automatically, you need to understand what that means for your data sovereignty claims.
Review your client contracts and DPIAs. If you have promised UK data residency or UK GDPR compliance without assessing CLOUD Act exposure, you have a gap that needs documenting.
Ask your IT provider one question: "Which of our systems are operated by US-headquartered companies, and do we control the encryption keys?" If they cannot answer clearly, that tells you something.
Put data sovereignty on your next board agenda. Not as an IT item. As a governance item.
Listen to the Full Discussion
This article expands on themes from Season 2, Episode 7 of The Small Business Cyber Security Guy podcast. The full conversation with Mauven MacLeod and Graham Falkner covers the Palantir government contracts story, European digital sovereignty movements, and the practical audit framework in more detail.
Coming up this week: Wednesday, Mauven examines why your cloud stack is not just stationery. Thursday, the step-by-step CLOUD Act Exposure Audit guide. Friday, the Switzerland vs UK Palantir case study that should make every business owner uncomfortable.
