Data Sovereignty After the Data Privacy Framework: Why EU Hosting Becomes an Architecture Question
The EU-US Data Privacy Framework remains valid for now, but is under review. Why hosting location, operator control and key sovereignty are not compliance checkboxes but architecture decisions with a long half-life.
Anyone transferring personal data to the United States has relied since 2023 on the adequacy decision for the EU-US Data Privacy Framework (DPF). In September 2025 the General Court of the European Union (EuG) dismissed a challenge against it, leaving the framework a valid legal basis. But the matter is not closed: in late October 2025 an appeal was lodged with the Court of Justice (Case C-703/25 P). Another reversal, a “Schrems III”, is not ruled out.
This uncertainty is no cause for panic, but a good occasion to lift a question from the compliance level to the architecture level.
Why this is more than a checkbox
The comfortable way to handle data transfers is to treat them as a contractual matter: as long as a valid decision or standard contractual clauses are in place, the transfer is covered. That is legally true, but it misjudges the actual risk. Every legal basis for third-country transfers has been provisional for years. Safe Harbor fell in 2015, the Privacy Shield in 2020, and the current framework is under judicial review. Anyone aligning their architecture to a legal basis that wobbles every few years builds in a dependency they do not control.
The more robust question is not “is the transfer covered” but “does the transfer happen at all”. Data that does not leave the EU and is not subject to third-country access needs no adequacy decision.
Three architecture decisions
Hosting location. Where the data physically resides is the first and most visible decision. A data centre in Frankfurt rather than a US region is the foundation, but not sufficient on its own, because location alone says nothing about control.
Operator control. What matters is who has legal and actual access to the data and the infrastructure. A server located in the EU but operated by a company subject to a third-country law with far-reaching disclosure duties only solves the problem halfway. The question of the operator’s applicable law therefore belongs to the architecture, not just the contract.
Key sovereignty. Whoever holds the keys controls access. Encryption in which only the customer holds the keys makes third-party access technically ineffective, even if it were legally compelled. Key sovereignty shifts control from a promise to a technical property.
Sovereignty as a default, not a retrofit
These three decisions are hard and expensive to change after the fact. They belong at the start of an architecture, not in a project that only kicks off once a court overturns the next decision. This is exactly what sovereignty by design means: not the after-the-fact securing of a transfer, but a design that makes the problematic transfer unnecessary in the first place.
In our platform, EU hosting in Frankfurt is the default, not the premium option. The point itself, though, is independent of any provider: whoever settles location, operator control and key sovereignty early makes themselves independent of the next judicial turn.
The Data Privacy Framework may survive the current review or it may not. An architecture that does not depend on the answer is the calmer choice either way.