Digital sovereignty: what the UK conversation is actually about

In June 2025, under oath before the French Senate, Microsoft France’s legal leadership admitted it could not guarantee that French public sector data held in French data centres would never be handed to US authorities without France’s consent.

One sentence, and it did more for the sovereignty debate than a decade of white papers, because it confirmed the thing procurement teams had been politely not asking: where the servers sit and who the operator answers to are different questions, and the second one wins.

That is a large part of why “sovereignty” is suddenly everywhere in UK government technology conversations. In January 2026, 45 MPs signed an Early Day Motion calling for a UK digital sovereignty strategy, pointing at a public sector that runs more than 90% of its cloud on three US providers. The House of Commons Library now maintains a briefing on the subject. The Competition and Markets Authority is pursuing Strategic Market Status action against AWS and Microsoft under its new digital markets powers. Meanwhile the department that owns the question, DSIT, said in February 2026 that data sovereignty is a “complex and evolving policy area” it has not yet defined, with no timescale for doing so. A mandate is forming faster than a map.

The EU is further along and moving with more force. The European Commission’s own IT department has published a Cloud Sovereignty Framework and awarded cloud contracts worth up to €180 million largely to European firms. In June 2026 the Commission put forward a technological sovereignty package centred on a proposed Cloud and AI Development Act, with a tiered assurance framework for which providers may handle sensitive public workloads, while the EuroStack initiative argues for building European alternatives outright, in a market where US providers hold roughly 85% share. Whatever you make of the politics, the direction of procurement travel on both sides of the Channel is the same.

So much for the weather. The practical problem, for a UK business or public body, is that “sovereignty” is one word doing the work of four different questions, and the questionnaire row that asks “is the data stored in the UK?” answers only the first and weakest of them.

Question one: where does the data sit?

This is residency, and it is the one everybody asks. It buys real things. Data that never leaves the UK needs no transfer mechanism, which removes a category of legal paperwork; for context, the government’s UK Business Data Survey 2026 (DSIT, run by Ipsos across 4,450 UK businesses, fieldwork October 2025 to January 2026) found only 10% of businesses handling digitised data transfer it internationally at all. Residency answers public sector procurement questions cleanly, where UK-only hosting is often the price of entry. It is a genuine trust signal in a wary market: the same survey found 73% of UK businesses would be uncomfortable with their data training external AI models.

What residency does not buy is everything the questionnaire implies. Which brings us to the second question.

Question two: whose law binds the operator?

This is jurisdiction, and it is the question the French Senate testimony settled in public. Under the US CLOUD Act, a provider subject to US jurisdiction can be required to produce data in its possession, custody or control regardless of where the server sits. A UK region operated by a US-parented provider is reachable by that route. Residency moves the data; it does not move the company holding it.

For completeness, the adjacent worry that surfaces in these conversations, EU-UK data flows, is currently settled: the European Commission renewed both UK adequacy decisions on 19 December 2025, running to 27 December 2031. Verified today, 31 August 2026. That is about legal flow between the EEA and the UK, and has nothing to do with which country your servers are in.

Question three: who actually operates the system?

Residency and jurisdiction are still only paperwork questions next to this one. The ICO treats giving someone outside the UK access to personal data as a restricted transfer, and support is the usual back door: data “resident” in London that a follow-the-sun engineering team administers from three other jurisdictions is not meaningfully staying home. The same goes for encryption keys. If your provider holds the keys, it can technically comply with a disclosure demand without your involvement; if you hold them, the conversation is different. Key custody changes the CLOUD Act calculus far more than server location does.

Question four: could you leave?

The quietest question and, in the long run, the one governments are really circling. Sovereignty you cannot exercise is decoration. If exiting your provider is not economically or technically survivable, then whatever the contract says, decisions about your systems are being made somewhere else. This is why the CMA’s lock-in concerns and the EU’s assurance tiers both keep returning to portability, open standards and exit terms. OpenUK’s June 2026 white paper calls the other side of this ledger the “sovereignty tax”: local alternatives can cost more and do less, and pretending otherwise discredits the whole argument. Sovereignty is a risk decision with a price, not a slogan.

What to actually do

We are not lawyers, and the legal analysis belongs with your data protection adviser; the Commons Library briefing is a sound orientation. The systems view, from people who design and build for regulated and public-sector environments, is this.

Do not start by trying to “be sovereign”. Start by classifying which of your workloads carry a genuine sovereignty requirement, from regulation, procurement or risk appetite, and answer the four questions for those workloads only. For a lot of organisations the honest answer is that most workloads carry none, and the sovereignty budget belongs on the two or three that do.

Public bodies are in the least comfortable position here, holding a forming mandate with no map attached: expected to take sovereignty seriously before the department that owns the word has defined it. The workload-by-workload approach is the defensible middle. It produces a documented, risk-based position you can show an auditor now, and it adapts cheaply when the definitions finally land, instead of betting the estate on guessing them in advance.

Where a requirement is real, engineer the claim so it is true in the strong sense: primary data, backups, replicas, logs, support access and key custody all inside the boundary, with evidence available on request. A sovereignty claim that quietly excludes the backup region or the overseas admin rota is a written representation you cannot stand behind, made to buyers with audit functions.

Decide it at design time. This is the cheapest moment by an order of magnitude. It is the discipline we apply in our own product work: Idonara, our recruitment platform, committed to UK data residency on day one because its buyers are UK HR and public-sector teams for whom the question is real, and that decision shaped the architecture rather than fighting it.

If the sovereignty question is live in your organisation, in either direction, bring it to a free 30 minute AI readiness teardown and we will tell you plainly which of the four questions your current setup answers, which it does not and what closing the gap would roughly take. If the honest answer is that sovereignty is not your real problem, you will hear that too.

The postcode is the easy part. Sovereignty is the other three questions.