UK data sovereignty

What data sovereignty actually means

Three terms get used interchangeably in sales copy, and they should not be, because they answer three different questions.

Data residency is geography: the country where your data physically sits, on disks in a datacentre you could in principle drive to. Residency matters for latency, for some contractual commitments, and for parts of a data protection analysis. It is the easiest of the three to offer, which is why it is the one most often offered.

Data sovereignty is jurisdiction: whose law can reach your data. This follows the legal ownership of the provider, not just the postcode of the datacentre. If the company operating the service, or its ultimate parent, is subject to another country's legal system, then that country's courts and agencies may be able to compel disclosure, wherever the disks are. Residency tells you where the data lives; sovereignty tells you who can knock on the door.

Operational sovereignty is control in practice: who can actually access and administer your data day to day. Which engineers hold administrative credentials, in which country they sit, whose software the platform depends on, and whether a foreign vendor could change terms, cut off updates or remotely disable something you rely on. A service can be UK-resident and UK-owned and still depend operationally on a proprietary stack controlled from elsewhere.

The short version: residency is where the data is, sovereignty is whose law applies to it, and a provider can offer the first without the second.

Why residency alone is not sovereignty

The clearest illustration is the US CLOUD Act, passed in 2018. Its core provision, 18 U.S.C. 2713, requires a provider of electronic communication or remote computing services to preserve or disclose data within its "possession, custody, or control", and it says this applies "regardless of whether such communication, record, or other information is located within or outside of the United States".

That is the whole point in one sentence of statute. A provider subject to US jurisdiction, which includes US-parented companies operating UK regions, can be legally required to produce data it controls even when that data has never left a British datacentre. The obligation attaches to the company, not to the location of the disks.

This is not a theoretical reading. In June 2025, Microsoft France's director of public and legal affairs, Anton Carniaux, was asked under oath at a French Senate hearing whether he could guarantee that French citizens' data would never be transmitted to US authorities without French agreement. His answer, as reported by The Register, was "No, I cannot guarantee it". He also said Microsoft resists requests that are not well founded, and that the situation had not arisen; both halves of that testimony deserve to be quoted together.

The honest counterpoint, because this page is not an exercise in fear: the hyperscalers are serious engineering organisations, and a UK region from one of them is a reasonable choice for many workloads. UK regions genuinely keep data at rest in the UK. Strong encryption is standard, customer-managed keys can put some technical distance between the provider and your plaintext, transparency reports are published, and US providers do challenge orders they consider unlawful. What a UK region of a US-parented provider changes is residency, latency and some compliance paperwork. What it does not change is which legal system the operator ultimately answers to. If your risk register cares about that question, a region setting cannot answer it.

The UK legal position

First, plainly: this is not legal advice, and nothing on this page promises a legal outcome. We are engineers describing the landscape so you can brief the people whose job the legal judgement is. Framed as the questions your DPO will ask:

Who is processing our personal data, and on what terms? Under UK GDPR and the Data Protection Act 2018, your business is typically the controller and a hosting provider is a processor. A controller may only use a processor under a written contract containing the terms required by Article 28(3): documented instructions, confidentiality, security measures, sub-processor rules, assistance with data subject rights, deletion or return at the end of the contract, and audit rights. The ICO publishes guidance on what these contracts must contain. If a provider cannot show you an Article 28 agreement, that conversation is over before sovereignty comes up.

Does the data leave the UK? A transfer of personal data outside the UK is a restricted transfer, and it needs a lawful basis: UK adequacy regulations covering the destination, or appropriate safeguards such as the ICO's International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses. The ICO's international transfers guidance is the reference. Note that this analysis applies to your backups and your support arrangements as much as to your primary storage.

What about our EU clients' data? Data can flow freely from the EU to the UK because the European Commission has found UK protection essentially equivalent. Those adequacy decisions were renewed on 19 December 2025 and now run to 27 December 2031, with a review after four years. Keeping data in the UK therefore keeps it inside a framework the EU currently recognises.

Can data go to the US lawfully? Yes, through several routes, including the UK-US Data Bridge: the UK Extension to the EU-US Data Privacy Framework, in force since 12 October 2023 and still operating at the time of writing. It permits transfers to US organisations that have self-certified under the framework, which currently means organisations under FTC or Department of Transportation jurisdiction. Two things are worth noting to your DPO: a transfer being lawful under UK GDPR is a separate question from whether US law can compel access once the data is there, and the framework's own durability is a matter for legal advice, not a hosting page.

What genuine UK sovereignty looks like

Sovereignty claims should be checkable. These are the criteria we think a sceptical DPO should apply, and how we measure against each one. Where we do not meet a criterion, we say so on the same line.

A UK-registered company with no overseas parent. Jurisdiction follows ownership, so start at Companies House, not the marketing site. Node Digital Ltd is registered in England and Wales, company number 14796571, and its ownership chain runs through a UK-registered holding company to a named UK-resident individual, all on the public record. The people who run the platform are named engineers, introduced on our team page, not an anonymous operations layer.

The provider runs its own infrastructure in UK datacentres. A UK company reselling a hyperscaler inherits the hyperscaler's jurisdiction for everything that touches it. Our default platform is hardware we own in a UK datacentre, from the hypervisor up, and we have documented the stack layer by layer in how the platform is built. One deliberate exception, stated rather than buried: our disaster recovery copy is exported to an independent standby foundation in a separate cloud region, because surviving the loss of a primary site matters too.

Open source software. Sovereignty is also about the software layer. Every application in our catalogue is open source: the code is inspectable, there is no proprietary vendor who can change licensing terms underneath you or switch a service off remotely, and your data lives in open, standard formats, so the exit path is real. You can leave with the software and the data and run them elsewhere. Our open source position sets out how we behave towards the projects involved.

A signed Article 28 data processing agreement. Every customer gets one as standard, and you do not have to email anyone to read it: you can generate a completed copy in your browser now. It includes the processing details, the security measures, and a sub-processor annex, with at least 14 days notice before any sub-processor change.

Per-service data-location statements. A single "UK hosted" badge over a whole catalogue usually hides exceptions. We state locations per service, and the sharpest example is AI: every model on the AI gateway is labelled UK-hosted or partner-routed, and the UK residency guarantee applies only to the first class.

And the criterion we deliberately do not claim: certifications we do not hold. We do not claim ISO 27001 certification. Our security controls are aligned to ISO 27001, our monitoring and audit posture is described on the security pages, and if certification status changes we will say so plainly. Similarly, if you ask us to deploy into a cloud tenancy you own on AWS, Azure or Google Cloud, we will do it well, and we will tell you plainly that data in that tenancy sits under that provider's jurisdiction, not the position described above.

Sovereignty, app by app

The abstract argument lands differently depending on which system holds the data. A quick tour of the estate:

Files and documents

Your file store is usually the single largest concentration of confidential material in the business. Nextcloud in your own UK tenant keeps contracts, board papers and client files under UK jurisdiction, with the comparisons against the incumbents written up in Nextcloud vs Dropbox and Nextcloud vs Google Drive.

Email

Email is where legal privilege, HR matters and every password reset live. We host mailcow, a full open source mail platform, inside your tenant rather than in a US productivity suite.

Helpdesk

Support tickets accumulate customer personal data faster than almost any other system. Zammad keeps the whole ticket history, and the attachments inside it, on UK infrastructure.

Analytics

Website analytics is the app where the transfer question bites first, because the data is your visitors', collected on your behalf. Matomo processes analytics data first-party, inside your tenant, which changes the questions your DPO has to answer about transfers and consent compared with sending visitor data to a US advertising company. The full comparison is at Matomo vs Google Analytics.

Team chat

Internal chat is candid by design, which is exactly why its jurisdiction matters. Mattermost keeps messages and shared files in your tenant; see Mattermost vs Slack for the comparison.

Passwords

Credentials are the keys to everything else, and we treat them accordingly: Passbolt is the same open source password manager we use to escrow the platform's own secrets.

AI

AI is where sovereignty is hardest to buy, because mainstream AI APIs process prompts on US-controlled infrastructure. Our AI gateway serves UK-hosted open models on GPUs we own in our UK datacentre: prompts and completions to those models are processed on our infrastructure and never leave it. The same gateway also offers partner-routed models, processed on a vetted partner's infrastructure, and we label every model in the catalogue with its class. The UK residency guarantee applies to the UK-hosted models only, and we would rather scope the claim precisely than wave it over the whole catalogue.

A buyer's checklist

Questions to put, in writing, to any provider you are evaluating, including us. A hyperscaler can answer several of these perfectly well; the point is to surface the answers, not to rig the quiz.

1. Who is your ultimate parent company, and in which country is it incorporated? This, not the datacentre address, determines whose law the operator answers to.
2. Whose infrastructure does the service actually run on? Your own hardware, a rented hyperscaler region, or a reseller arrangement? Each inherits a different jurisdiction.
3. Where does our data sit at rest, and does that include backups and replicas? Backups in another jurisdiction are still your data in another jurisdiction.
4. From which countries do your support and operations staff access customer data? Administrative access from abroad is a transfer question too.
5. Will you sign an Article 28 data processing agreement, and can we read it before we buy?
6. Who are your sub-processors, and how much notice do we get before the list changes?
7. For AI features, where are prompts and outputs processed, and is that stated per model or per feature?
8. What happens to our data when we leave? Formats, export tooling, deletion timescales, and whether the software itself is something you could keep running.
9. What contractual data-location commitment are you actually offering, as opposed to a current-state description that can change with an update to a terms page?

A provider that answers all nine in writing is taking sovereignty seriously, whatever the answers turn out to be. Evasion on questions 1, 3 or 8 tells you more than any badge on a homepage.

When this does not matter (and when it does)

Honestly: plenty of workloads are fine on US clouds. A marketing site, a dev sandbox, public documentation, anonymised telemetry: if the data is not sensitive and your clients' regulators are indifferent, US hosting is often cheaper and entirely sensible, and we will not pretend otherwise to win a deal.

Sovereignty earns its cost where the data or the duty is heavier: legal privilege and client files at law firms; patient and care data in healthcare; client money and audit trails in financial services; sensitive IP and trade secrets; public sector and public procurement; and any organisation whose own risk register, insurer or largest client has started asking the questions in the checklist above. If clause 32 of your biggest contract specifies where data may be processed, sovereignty stopped being abstract the day you signed it.

If you are unsure which side of the line you are on, talk to your DPO first. When you get to providers, we are easy to interrogate: the platform is documented, the DPA is generatable, and the company records are public.

---

Frequently asked questions

What is the difference between data residency and data sovereignty?

Data residency is geography: the country where your data is physically stored. Data sovereignty is jurisdiction: whose laws can compel access to that data, which follows the legal ownership of the provider as well as the location of the data. A provider can offer UK residency while remaining subject to another country's law, so the two are not interchangeable.

Does a UK region of a US cloud provider count as sovereign?

It provides UK residency, not UK-only jurisdiction. Under the US CLOUD Act (18 U.S.C. 2713), a provider subject to US jurisdiction can be required to disclose data in its possession, custody or control regardless of where that data is stored. A UK region is still a reasonable choice for many workloads; it just answers the residency question, not the sovereignty one.

Is this page legal advice?

No. We are engineers, not lawyers, and nothing here is legal advice or a promise of a legal outcome. Treat this page as a plain-English map of the questions to ask, then put those questions to your data protection officer or legal adviser. What we contribute as a provider is the factual inputs: a signed Article 28 data processing agreement, a sub-processor list, and clear statements of where each service processes data.

Can we see where our data actually is?

Yes. Our default is our own infrastructure in a UK datacentre, described layer by layer on the how-it-is-built page. Our data processing agreement records processing locations and sub-processors, and where a specific service departs from the UK default (partner-routed AI models, or the disaster recovery copy held in a separate cloud region) we label it rather than leaving it to a footnote.

What about the AI models?

The AI gateway serves two classes of model and labels every model with its class. UK-hosted models run on GPUs we own in our UK datacentre, so prompts and completions are processed on our infrastructure and never leave it. Partner-routed models are processed on a vetted partner's infrastructure, so those requests do leave, and the UK residency guarantee does not apply to them. Each model page states which side of the line it sits on.

What if we need a hyperscaler deployment anyway?

We can deploy the same open source platforms into a cloud tenancy you own on AWS, Azure or Google Cloud, and sometimes that is the right call. We are plain about the consequence: data in that tenancy sits under the cloud provider's jurisdiction as well as yours, so the sovereignty position is that provider's, not the one described on this page. You still keep the open source benefits, including the exit path.

What should we ask any provider about data sovereignty?

Six questions cover most of it: who is your ultimate parent company and where is it incorporated; whose infrastructure does the service actually run on; where does data sit at rest, including backups; where do support staff access it from; who are your sub-processors; and what happens to our data when we leave. A provider that answers all six in writing is taking the question seriously, whatever the answers are.

Questions your DPO is asking?

Tell us what your risk register or your data protection officer needs answered and an engineer will reply directly, with specifics rather than a brochure.

Name*

Company Name*

Phone Number*

Email Address*

Message*

Get more detail