Data sovereignty in 2026: why a Frankfurt data centre isn't European enough.
Most teams believe that storing EU data in an EU region satisfies European sovereignty. It satisfies residency, which is a different and weaker thing. The gap between the two is a foreign government's legal power to compel the company that holds your data, and no amount of region selection or contract language closes it. Here is what does, and why the question reaches from the GDPR all the way to the model weights of an AI system.
Data residency and data sovereignty get used as synonyms, and the conflation is one of the most expensive misunderstandings in European IT. Residency is a location property: where the data physically sits. Sovereignty is a jurisdictional property: which legal regime can compel access to the data and to the entity holding it. An organisation can satisfy every residency obligation on paper, data in a German region, transfers papered with Standard Contractual Clauses, a tidy transfer impact assessment, and remain structurally exposed, because the provider holding that data answers to a foreign legal system that can compel it regardless of where the bytes live. The engine of the problem is the US CLOUD Act, which lets US authorities compel US-based companies to produce data wherever stored, so a database in Frankfurt owned by a US hyperscaler is legally within reach of a US warrant. For ordinary workloads that is a tolerable risk; for regulated sectors it is the line between passing and failing an audit, and several EU data protection authorities have already ruled certain US cloud arrangements non-compliant. Closing the gap takes architecture, customer-held keys, EU-native deployment, enforced geofencing, jurisdictional control of the operational layer, more than contract clauses, and in 2026 the demand for that architecture runs through the GDPR, DORA, the Data Act and the AI Act at once, all the way down to where an AI model's weights are allowed to live.
The distinction that costs millions: residency versus sovereignty.
Start with the definitions precisely, because almost every sovereignty mistake is a residency control mistaken for a sovereignty control.
Data residency is satisfied when your data is stored on servers inside a given jurisdiction. It is a configuration choice: pick the EU region, and the bytes sit in the EU. Data sovereignty is satisfied when those bytes are subject only to the laws of that jurisdiction, which is a property not of where the data sits but of who holds it and which legal system binds that holder. A US-headquartered cloud provider can give you residency by region selection alone, and it cannot give you sovereignty by the same means, because the corporate entity, its sub-processors, its key custodians and its support engineers remain reachable by the legal regime of its home country. The contract clauses that deliver each are different, and a buyer who specifies residency and assumes sovereignty has bought the weaker of the two without knowing it.
The cost of the confusion is concrete. A 2026 industry survey found roughly a third of organisations had experienced a sovereignty-related incident in the prior year, despite many describing themselves as well prepared, and reports tracking cross-border transfer enforcement have recorded fines rising year over year, driven substantially by organisations that mistook residency for sovereignty. The reason the error is so common is that residency is visible and reassuring, a region dropdown, a data-centre address, a map with a pin in Germany, while sovereignty is invisible and legal, a question about which courts can compel which entity. The pin on the map feels like the answer, and for a regulated workload it is the start of the question. The discipline is to treat "where is the data?" and "who can be compelled to hand it over?" as two separate questions with two separate answers, because the gap between them is exactly where the audits and the incidents land.
The CLOUD Act, and why region selection can't reach it.
At the centre of the sovereignty problem sits one piece of foreign legislation, and understanding its mechanism explains why every contractual fix falls short.
The US CLOUD Act gives US law enforcement the power to compel US-based technology companies to produce data they control, regardless of where in the world that data is physically stored. The key word is control, not location: the obligation attaches to the company, and follows the data wherever the company has put it. So a database in an EU region of a US-owned provider is reachable not because the data left the EU but because the company holding it is bound by US law, and a warrant served on the parent reaches the data in Frankfurt as surely as data in Virginia. This is the structural fact that region selection cannot change, because region selection moves the bytes without moving the entity, and it is the entity the foreign law compels.
It is worth being precise about what this does and does not mean, because the honest version is more useful than the alarmed one. The CLOUD Act does not mean US authorities are reading EU data routinely; it means the legal power to compel exists and cannot be contracted away. The GDPR, in Article 48, says a third-country authority's order is not in itself a lawful basis to transfer personal data, which sets up a genuine conflict for a provider caught between a US compulsion and an EU prohibition, a conflict the provider, not the customer, is structurally placed to lose. For most workloads the residual probability is low enough that a US hyperscaler with EU regions, SCCs and a transfer impact assessment remains a perfectly defensible choice under the GDPR. For data where the consequence of compelled disclosure is severe, regulated financial and health data, critical infrastructure, government, the existence of the power, not its frequency of use, is what fails the audit, and the only durable answer is to remove the entity from the foreign jurisdiction's reach rather than to promise the power will go unused.
The residency illusion, and the authorities who have already acted on it.
The belief that an EU data centre settles the matter has a name among practitioners, the residency illusion, and it is no longer a theoretical risk because supervisory authorities have started ruling on it.
The residency illusion is the assumption that storing data in a Frankfurt or Dublin region owned by a non-EU corporation satisfies European sovereignty requirements. It is comfortable because it is concrete: there is a data centre, it is on EU soil, there is an address you can point to. The illusion holds right up until the question shifts from where the data sits to who can be compelled to produce it, at which point the EU address becomes irrelevant to the answer, because the compulsion attaches to the entity rather than the location. Organisations in healthcare, banking, education and government have discovered that the residency arrangement which passed procurement does not pass an audit that asks the sovereignty question, and the discovery has tended to come at the audit rather than before it.
This is not a hypothetical exposure waiting for a test case, because the test cases have arrived. Data protection authorities in several member states, Austria, France and Italy among them, have ruled that certain US cloud arrangements violate the GDPR, turning the residency-versus-sovereignty distinction from an academic point into enforced supervisory practice. The financial stakes are concrete in two directions: GDPR penalties reach up to four percent of global annual turnover, and the NIS2 regime layers management accountability and, in some national transpositions, personal liability on top, so the cost of the residency illusion is no longer just a remediation project but a fine and a governance failure with names attached. The practical lesson practitioners draw is to record data residency and transfer paths properly in the Article 30 records of processing, including sub-processors and backup flows, and then to ask of each one the sovereignty question explicitly, because the arrangements most likely to fail are the ones nobody examined past the reassuring data-centre address.
The GDPR transfer machinery, and the Schrems III cloud over it.
The GDPR has a layered system for lawful cross-border transfers, and a buyer needs to know which layer they are standing on, because one of them is under active legal challenge.
Chapter V of the GDPR prohibits transferring personal data outside the EU unless a specific mechanism applies, and the mechanisms are layered. An adequacy decision under Article 45 is the cleanest: the Commission has found a destination country offers essentially equivalent protection, and as of 2026 adequacy covers a set including the UK, Switzerland, Japan, South Korea, Canada for commercial data, and others, plus the US under the Data Privacy Framework for organisations that self-certify and appear on the official list. Where no adequacy decision applies, Standard Contractual Clauses under Article 46, paired with a transfer impact assessment that evaluates the destination's legal environment, are the workhorse mechanism. Binding Corporate Rules cover transfers within a corporate group, and the Article 49 derogations cover narrow, specific situations. The mechanism you rely on determines how stable your transfer is, and one of the most-used is the least stable.
The Data Privacy Framework is the 2023 adequacy decision for the US, and it is the third attempt at this bridge after the Court of Justice struck down Safe Harbor and then Privacy Shield, each time over the same underlying concern about US government access. Schrems III, the litigation challenging the Framework, is already pending before the Court of Justice, with a decision expected in late 2026, and the pattern of the two prior rulings is not reassuring for anyone betting their architecture on the Framework surviving. The competent posture, the one most advisers now recommend, is to use the Framework where it applies but never to rely on it alone: sign Standard Contractual Clauses alongside it and keep the transfer impact assessment current, so that if the Framework is invalidated, the transfer falls back onto SCCs rather than becoming instantly unlawful. Building on the Framework without an SCC fallback is building on a bridge that has been demolished twice, and the architecture that does not depend on any US transfer mechanism at all is the one that is indifferent to how Schrems III is decided.
Why sovereignty became urgent: DORA, the Data Act, NIS2.
The GDPR set the baseline, but the reason sovereignty moved from a niche legal concern to a board-level procurement question in 2026 is a cluster of newer regulation that demands more than residency.
DORA is the sharpest driver for financial entities. Its third-party rules, covered in depth in the DORA field note, require clarity on where data is located, on who manages the encryption keys, on audit rights for the firm and its supervisors, and on realistic exit strategies, and those are precisely the provisions that distinguish a sovereign arrangement from a residency-only one. A financial entity whose cloud contract lacks audit rights or a workable exit, or whose key management sits entirely with a provider it cannot inspect, has a DORA problem as much as a sovereignty one, and the Register of Information makes that dependency visible to the regulator. The Data Act, now in its second year of application, pushes in a parallel direction, shifting the emphasis from protecting data to ensuring genuine control and portability over it, including the right to move data without prohibitive egress fees or proprietary lock-in, which is sovereignty expressed as operational autonomy.
Around those sit the rest of the constellation. The NIS2 directive adds cybersecurity obligations and management accountability across essential and important sectors, with audit deadlines arriving through 2026 and incident reporting on a tight clock, and it raises the stakes on where and how data and systems are operated. The Data Governance Act builds rules for trusted data sharing. The throughline is that European regulation has moved past asking only whether data is protected toward asking who controls it and which jurisdiction governs that control, and a residency-only posture that was defensible a few years ago now collides with several regimes at once. The firms feeling this most are exactly those in the regulated sectors, finance, health, critical infrastructure, public sector, where the cost of getting it wrong is an audit failure rather than a hypothetical, and where the procurement question has quietly changed from "is it in the EU?" to "who can be compelled to hand it over?"
Sovereign cloud, EU-native providers, and the honest trade-offs.
The market has responded to the sovereignty demand with a spectrum of options, and choosing well means understanding what each one closes and what it leaves open.
At one end, the global hyperscalers have built sovereign configurations that tighten the boundaries of their standard EU regions. AWS launched its European Sovereign Cloud in early 2026, with an initial region in Germany operated by EU-resident staff under a separate European legal entity, and Microsoft offers sovereign public and private variants of its cloud. These are real improvements: the operational and legal boundaries are meaningfully tighter than a standard EU region, with EU-resident operations and separate legal structuring designed to limit foreign reach. The honest caveat is that the ultimate corporate parent remains non-EU, so whether the separation is sufficient depends on how completely the legal and operational ring-fencing holds against the parent's home jurisdiction, a question that is partly legal, partly architectural, and reasonably debated. For many regulated workloads they are a strong and pragmatic answer; for the most sensitive, the residual parent question is why some organisations look further.
At the other end sit the EU-native providers, headquartered and operated wholly within the EU with no non-EU parent in the chain, names like OVHcloud and Scaleway in France, Hetzner and IONOS in Germany, UpCloud in Finland, among others. Their jurisdictional answer is the cleanest available, because the entity, its staff and its infrastructure are all under EU law and no foreign compelled-access regime reaches them, which is why EU-native deployment is one of the architectural controls genuine sovereignty rests on. The trade-offs are practical rather than legal: a narrower catalogue of managed services than the global hyperscalers, smaller geographic footprints, and more engineering carried by your own team where a hyperscaler would have offered a turnkey service. For an organisation whose sovereignty requirement is strict, that engineering is the price of removing the parent-jurisdiction question entirely, and it is increasingly a price the regulated sectors are choosing to pay, which is part of what is driving the renewed interest in EU-native infrastructure and in self-hosting across European IT in 2026.
| Option | Residency | Parent jurisdiction | Fits |
|---|---|---|---|
| US hyperscaler, EU region | EU | Non-EU (CLOUD Act reach) | Most non-regulated workloads |
| Hyperscaler sovereign config | EU | Non-EU parent, EU-resident ops | Many regulated workloads |
| EU-native provider | EU | EU only | Strict sovereignty needs |
| Self-hosted, EU-native infra | EU / yours | Yours, EU | Maximum control, maximum burden |
What delivers sovereignty: the architecture.
Sovereignty is not bought with a label; it is built with a small set of architectural controls that change what is technically possible, not merely what is contractually promised.
The governing idea is to make unauthorised access technically impossible rather than contractually forbidden, because a contractual prohibition yields to a government compulsion while a technical impossibility does not. Four controls do most of the work. Customer-controlled encryption keys, held outside the provider's reach, mean that even data lawfully compelled from the provider arrives as ciphertext the provider cannot decrypt, so the data handed over is useless without keys the foreign regime cannot reach. EU-native or single-tenant deployment puts the entity that holds the data under EU jurisdiction, removing the foreign parent from the chain rather than trusting it to resist. Policy-enforced geofencing keeps data and processing inside the boundary by technical control rather than by promise, so a misconfiguration or a default cannot quietly move data out. And jurisdictional control of the operational layer, the support engineers and the key custodians sitting under EU law, closes the route by which access is most often granted, a privileged operator acting on an instruction from headquarters.
The reason to think in these terms is that each control maps to a specific failure of the residency-only model. Region selection answers location and nothing else; customer-held keys answer the compelled-disclosure failure; EU-native deployment answers the foreign-parent failure; geofencing answers the leakage failure; operational-layer control answers the privileged-access failure. A residency-only arrangement has the region control and none of the others, which is exactly why it satisfies residency and fails sovereignty. The architecture that holds is the one where, asked "what happens if a foreign authority compels your provider?", the answer is "they receive ciphertext they cannot read, from an entity they cannot compel, operated by staff they cannot direct," and that answer is built, not promised. This is the layer where sovereignty stops being a legal abstraction and becomes an infrastructure decision, which is precisely where it should be decided.
Sovereign AI: the weights are data too.
The newest frontier of the sovereignty question is AI, and it raises the stakes because the most sensitive asset is one many teams have not thought of as data at all.
Sovereign AI extends the residency-versus-sovereignty distinction across the entire AI stack: not only where the training and inference data sit, but where the model weights live and who controls the infrastructure running them. Model weights are uniquely sensitive because training can cause a model to memorise fragments of its training data, so weights derived from sensitive personal data can themselves contain that data in latent form. Weights stored on infrastructure subject to a foreign compelled-access regime therefore carry the same exposure as the raw data, concentrated into the most valuable artefact the organisation owns. The shift the field is making, from data residency to technical sovereignty over the whole stack, is driven by exactly this realisation: securing where the training data sits while the weights run on exposed infrastructure secures the wrong thing.
For an organisation deploying AI in a regulated function, two regimes now have to be answered together. The EU AI Act governs how AI systems may be built and used, with obligations escalating through 2026 toward full enforcement of the high-risk requirements and their conformity assessments, while data sovereignty governs where the data and the weights those systems depend on may lawfully sit and who can reach them. A high-risk AI system processing sensitive data raises both at once, the AI Act's governance and conformity duties and the sovereignty of the stack the model trains and runs on, and answering them in separate workstreams is how the sovereignty gap opens, a model that satisfies the AI Act's documentation while its weights sit on infrastructure a foreign authority can compel. The principle that genuine sovereignty requires the provider, the infrastructure and the operational staff to share one jurisdiction applies with particular force to AI, because the stack is deeper, the sensitive artefact is the weights, and the consequence of getting it wrong is measured against the GDPR's turnover-based penalties. Sovereign AI is data sovereignty applied to the part of the system that is hardest to see and most expensive to get wrong.
Sovereignty is a stack, not a checkbox.
The word sovereignty gets used as though it were a single property a system either has or lacks. In practice it is layered, and a system can be sovereign at one layer and exposed at another, which is where most real-world gaps hide.
Think of sovereignty as applying separately to each layer of the stack, because a foreign reach into any one of them defeats the others. Data sovereignty is the base: where the data sits and who can compel it. Operational sovereignty is the layer above: who runs the infrastructure day to day, who has privileged access, who can be instructed by a foreign parent to act on the data, the support engineer with a console and a directive from headquarters being the access route that contractual residency never mentions. Technical sovereignty covers the software and the keys: whether the encryption keys are yours, whether the platform itself can be inspected and controlled, whether the stack can be operated without dependence on a foreign-controlled component. And legal sovereignty is the layer that binds the rest: which entity, under which jurisdiction, holds the contract and the ultimate control. A system is only as sovereign as its weakest layer, and the residency-only model is sovereign at none of them except, arguably, the location of the bytes.
This layered view explains why the architectural controls come in the set they do, each one closing a different layer. Customer-held keys close the technical layer, so that even if the data layer is compromised by compulsion the data is unreadable. EU-native deployment closes the legal layer, putting the controlling entity under EU jurisdiction. Operational-layer control, EU-resident staff with privileged access under EU law, closes the operational layer that is the most commonly overlooked and the most commonly exploited, because access in practice is granted by people, not by warrants alone. Enforced geofencing keeps the data layer from leaking by default. A serious sovereignty assessment walks the layers one at a time and asks, for each, which jurisdiction governs it and who can be compelled within it, rather than accepting a single reassuring answer about the data centre. The gaps that audits find are almost never at the data layer everyone thinks about; they are at the operational and legal layers nobody put in the procurement questionnaire, the offboarded sub-processor still in the chain, the support team in a third country, the parent entity that can lawfully direct the subsidiary. Sovereignty fails at the layer you did not check, which is the argument for checking all of them deliberately rather than trusting the layer that happens to be visible.
Assessing a provider: the signals that separate sovereignty from a brochure.
Every provider now markets sovereignty, which means the word on the website is worthless and the verifiable signals behind it are everything.
Start with the externally verifiable certifications, because they are the signals a provider cannot simply assert. The EU Cloud Code of Conduct, approved under Article 40 of the GDPR with an independent monitoring body, covers cloud governance, data location, sub-processor management, transfer mechanisms and incident response, and its adherence levels indicate increasing depth of independent verification, which makes it one of the most useful externally checkable signals short of formal certification. Above it sits the EUCS, the European cybersecurity certification scheme for cloud services, whose higher assurance levels are the stronger bar and are widely cited in public-sector and financial procurement. A provider adhering to the Code at a verified level, or certified under EUCS, has submitted its claims to outside scrutiny; a provider that only describes itself as sovereign has not.
Beyond the certifications, the decisive questions are concrete and belong in the contract, not the sales call. Which legal entity holds the contract, and under which jurisdiction does it sit? Where, physically and legally, are the support engineers and the key custodians, the people with privileged access? Can you hold your own encryption keys, outside the provider's control, so that compelled data is unreadable? What sub-processors are involved, where are they, and how are changes to them governed? And what is the documented exit path, including data export without prohibitive egress fees or proprietary lock-in, the operational autonomy the Data Act now reinforces? The answers, in writing, are what separate a sovereign arrangement from a sovereignty-themed one, and the exercise of asking them is the same due diligence DORA's third-party regime requires of financial entities, which is why the sovereignty assessment and the regulatory assessment are increasingly the same piece of work. A provider that answers all of these cleanly is offering sovereignty; a provider that deflects to its data-centre map is offering residency with a sovereignty label, and the difference is exactly the one an audit will find.
From the side that builds and runs the stack.
Most sovereignty writing stops at the legal analysis. The decisions that determine whether sovereignty holds are made one layer down, in the infrastructure, which is the layer we work in.
Sovereignty is, in the end, an architecture and an operating discipline, and both are things you build rather than procure. Holding your own encryption keys is a key-management system someone has to run; EU-native deployment is a set of providers someone has to select, build on and operate; geofencing is policy someone has to enforce and monitor; jurisdictional control of operations is an organisational fact about who has privileged access and under whose law they act. Self-hosting on EU-native infrastructure is the cleanest route to all four, because it places the entity, the operations and the keys under your own control and jurisdiction by construction, removing the foreign-parent problem entirely, which is much of why European data-residency pressure is driving a visible return to EU-native infrastructure and self-hosting in 2026. The trade is equally clear: you take on the operational burden the hyperscaler was carrying, the patching, the monitoring, the resilience, the security, and sovereignty by self-hosting is exactly as strong as the discipline you run it with.
That is the lens we bring, because we are a European operator that builds and runs infrastructure rather than reselling someone else's, and the sovereignty question is one we answer in architecture rather than in a clause. The advantage is structural: as a nearshore European provider, the entity, the staff and the operations sit under EU jurisdiction, so the foreign-parent problem does not arise, and the controls that make sovereignty real, customer-held keys, EU-native deployment, enforced boundaries, operational control, are the way we build rather than an upgrade tier. It connects directly to the rest of this cluster: the DORA third-party and exit requirements, the NIS2 security and accountability obligations, and the AI Act governance duties are all, underneath, questions about who controls the stack and which law governs it. Where it helps to have the sovereignty designed into the infrastructure, the keys, the deployment, the geofencing, the operations, by people who run it under EU jurisdiction daily, that is the work our compliance and sovereignty practice exists to do, with the security operations resting on the managed security side. Residency is a setting; sovereignty is a build, and it is built one layer below the contract, where we work.
Questions teams are asking in 2026.
What is the difference between data residency and data sovereignty?
Does storing data in an EU data centre make it GDPR-compliant and sovereign?
What is the CLOUD Act and why does it matter for EU data?
Do Standard Contractual Clauses solve the sovereignty problem?
What are the GDPR mechanisms for transferring data outside the EU?
What is the EU-US Data Privacy Framework, and can I rely on it?
What does DORA require about data location and cloud?
What is sovereign cloud, and do the hyperscalers offer it?
Who are the EU-native cloud providers?
Which architectural controls deliver sovereignty?
Is data sovereignty only a concern for regulated industries?
What is sovereign AI, and how is it different from data residency?
How does the EU AI Act interact with data sovereignty?
How do I assess whether a provider is genuinely sovereign?
Is self-hosting a route to data sovereignty?
Build sovereignty in, instead of promising it in a contract.
We design for the question that residency cannot answer: who can be compelled to hand over your data, and how to make that impossible rather than merely forbidden. Customer-held keys, EU-native deployment, enforced geofencing, operations under EU jurisdiction, on infrastructure we build and run rather than resell. From the GDPR transfer machinery to where your model weights are allowed to live, answered one layer below the clause.