Data Sovereignty: Between Illusion and Real Control

Published: 25 February 2026

Data sovereignty has moved from a functional topic to a board-level risk. The trigger is geopolitical: shifting alliances, extraterritorial legislation, and a growing willingness by state actors to use digital infrastructure as a lever of power. What was once managed quietly is now pursued openly.

The reflex in Europe and in Switzerland is predictable: away from US providers, towards a European cloud. That response is understandable, but it mistakes a procurement decision for a sovereignty strategy. Hyperscalers and cloud services are deeply embedded in most organisations. The question is not whether to use them. The question is whether the organisation controls what happens to its data when it does.

Data sovereignty does not come from a country-of-origin label. It comes from control that is technically and organisationally enforced. And that is an architecture question, not a procurement decision.

Why “European” Does Not Automatically Mean “Sovereign”

Europe has harmonised rules in important areas, data protection being the most visible example. In practice, however, Europe is not a single enforcement area. Supervision, enforcement, national security and criminal procedure laws, and the implementation of EU directives differ significantly from country to country.

This is not just theory. It becomes tangible in two concrete examples.

GDPR: one rulebook, different enforcement. The GDPR applies across the EU, but it is enforced by national data protection authorities, each with different priorities, speed, and sanctioning practices. The one-stop-shop mechanism is meant to harmonise this, but in reality it regularly creates tensions between national authorities and the European Data Protection Board. The WhatsApp/Meta case illustrated this directly: the EDPB intervened via the dispute resolution procedure and significantly influenced the decision of the Irish authority; the legal review is now proceeding before the Court of Justice of the EU. Even with the same legal basis across the EU, enforcement risk is not identical.

Lawful interception: fragmented national rules. Access by law enforcement and security authorities to communications data is not regulated uniformly across the EU. Jurisdiction is a factor, but it is not the same as control. “Data in Europe” does not mean “a uniform access scenario.”

The central point is this: if you only change the provider, you primarily shift dependencies. Operating models, third-party and support access, operating locations, supply chains, lock-in and exit options all remain relevant. Geographic proximity can reduce certain risks. It is not a control mechanism.

The Real Question: Architecture Before Provider

Data sovereignty is not a matter of trust. It is a matter of architectural controllability. The board-relevant definition is straightforward:

Sovereign is whoever can technically enforce access, usage, and portability of their critical data, regardless of the provider.

The key term is “technically enforce.” The control must be designed into the system rather than assured by contract or merely expected by law, so the company can exercise it in practice.

Own infrastructure is not an ideology: for certain data categories it is the only architecture that delivers verifiable control. When a company cannot demonstrate, technically and independently, that access to its crown jewels is constrained, it does not have sovereignty. It has just a contract, and it lives in the illusion of sovereignty.

Boards should be direct with their management on this point: for the highest-risk data, “we trust the provider” is not an acceptable control. The question is not whether own infrastructure is convenient. The question is whether the risk of not having it is acceptable.

Three Questions Every Board Must Be Able to Answer

Boards do not need to know technical details. But they must ask the right questions and demand answers that can be verified.

Do we know which data is business-critical? Without classification there is no control. Many companies discuss data sovereignty without having cleanly categorised their data into crown jewels, highly sensitive personal data, regulatorily relevant data, and non-critical data. If the board does not know this classification, the company is structurally exposed.
Is control technically enforced, or only contractually claimed? Contracts and legal bases matter. But they do not replace technical enforcement. Contracts and laws can prohibit access; they do not automatically prevent it. In a crisis, what matters is whether access is technically constrained through key ownership, role and permission concepts, logging, separation of duties, and clear technical boundaries.
Are we provider-capable, or provider-dependent? Provider capability means the company can change providers without the business collapsing. Provider dependence means migration cost, time, and operational risk are so high that a switch becomes practically impossible. This is not a cloud detail. It is strategic agility.

A Pragmatic Model Instead of Ideology

Not every system needs the same level of protection. Data sovereignty is not an “everything in-house” strategy. It is a risk-based operating model.

Crown jewels under direct control. Business-critical data, IP, and highly sensitive data require maximum technical enforcement: key ownership, strong isolation, restrictive access models, and verifiable access chains. For this category, “we trust the provider” is not a control. It is an exposure.
Regulated data and workflows: external is possible, but only under conditions. Outsourcing is often viable, but not by default. Preconditions include demonstrable controls, transparent sub-processors (e.g. third-party service providers) and supply chains, tested incident processes, tested exit options, and clear data flows including backups, logs, and metadata.
Non-critical workloads: outsource pragmatically. For many processes, cloud is economical and sensible. Minimum standards still apply: identity and access management, logging, patch management, clear contracts, and clear accountabilities.

Please note: the goal is not “cloud-free,” and in many cases that is simply not possible. The goal is controlled.

The Most Common Mistake: The Governance Gap

The main problem is rarely a lack of technology. It is a lack of governance. Typical symptoms include no data classification and no clear ownership, no systematic view of sub-processors, no tested exit scenarios, no technical enforcement of contractual logic, and no reporting that genuinely enables boards to steer.

Conclusion

Data sovereignty is a board responsibility, not an IT project.

The decision to move data from Virginia to Frankfurt may reduce certain risks. It does not create sovereignty. Sovereignty requires that control is technically enforced, organisationally anchored, and strategically led. That combination does not emerge from a provider contract. It requires a deliberate architecture decision and active board oversight.

Three things boards should do after reading this:

Ask management for a data classification that distinguishes crown jewels from commodity. If that classification does not exist, it is the first governance gap to close.
Demand evidence of technical control, not contractual assurance. The question is not what the provider has agreed to. The question is what the company can enforce independently.
Put provider independence on the risk agenda. The ability to change providers without operational collapse is a measure of strategic agility. If that ability has never been tested, it should be assumed not to exist.

Technology and tasks around technology can be delegated. Accountability cannot. A board that treats data sovereignty as a technology question has already made a governance decision. In my opinion, the wrong one. When something goes wrong, and in this domain it is a matter of when, not if, the question will not be directed at the IT department or the outsourcer. It will be directed at the board.