Data Sovereignty Has Two Dimensions
If data sovereignty is narrowed down to procurement, to the choice of provider and location, the debate misses the point. A national cloud on Swiss soil sounds like sovereignty, but it only answers one of two questions. Choosing the right location alone does not yet make an organisation sovereign. Sovereignty also requires controlling who can technically read its most critical data. Both belong together, and both are a leadership question, not an IT question.
Why this question belongs with executive management and the board
Technology and the tasks around technology can be delegated. Accountability cannot, because the board’s duty of ultimate oversight is, under Art. 716a para. 1 no. 1 OR, one of its non-transferable duties. Whoever holds that duty cannot hand its careful exercise to a service provider. An outsourcing contract shifts execution, not accountability. In regulated environments, concentration on a small number of providers has long been recognised as a risk in its own right, not as a technical detail.
Across more than a hundred transformation projects, I have seen this pattern repeatedly: delegating the task is silently mistaken for delegating the accountability. That holds until the first serious incident. Then the question is not directed at the service provider. It is directed at executive management and the board.
Data sovereignty has two dimensions
The first dimension is location, and with it, jurisdiction. It answers which law has reach over the data and over the operator. An operator subject to a foreign legal order can be compelled to hand over data there, regardless of where the data physically resides. And under the cover of national security, the law can occasionally be bent, as history has well documented. A national cloud with a Swiss operator under Swiss law addresses exactly this dimension. That is real, and for regulatorily sensitive data it is often decisive.
The second dimension is technical control, and it is decided by the cryptographic keys. If the organisation holds the keys itself, the operator of the systems has no direct access to the unencrypted data. If it has handed the keys over, the operator has direct access to the data. Location changes nothing about that.
The common mistake is to take one dimension for the whole. A national cloud whose operator holds the keys is legally protected, but the data is still not secure. Conversely, holding your own keys does not shift the jurisdiction the operator is subject to. For the truly critical data, both are therefore needed:
“The data sits in Switzerland” is as little a security concept as “we trust the provider.” Both are risk positions, not control.
What executive management and the board must specifically demand
Four decisions separate a body that has sovereignty from one that only talks about it.
- Know your own data. Without classification there is no control. As long as it has not been decided which data are crown jewels, which are regulatorily sensitive, and which are non-critical, the sovereignty discussion has no real object. This categorisation is not an IT task. It is a leadership decision about what needs protecting in the first place.
- Choose the location deliberately. On-premises, national cloud, and global hyperscaler are not an either-or. They form a spectrum of control, capability, and cost. Your own perimeter is the only configuration in which location and access lie fully in your own hands. That is not an argument for “everything on-premises.” It is an argument for treating the crown jewels differently from the rest. For regulatorily sensitive data, a national cloud can be the right middle ground; for non-critical processes, the hyperscaler can be the economical choice. What matters is that this allocation is made deliberately, not out of convenience.
- Clarify key sovereignty. A single question separates control from illusion: do we hold the keys to our most critical data ourselves, or have we handed them to the operator? Whoever does not know the answer has never asked the question. And whoever asks it demands proof, not assurance. In my view, access that is contractually prohibited is not the same as access that is technically excluded. Where processing is outsourced, technology can exclude the operator, but even then the rule holds: verify, do not take the vendor’s security promises on faith.
Plan the potential exit at project start
An exit strategy that only takes shape once a change is needed is not a strategy. The ability to switch is decided at build time, not at exit: in the architecture, in open data formats, in whether data and cryptographic keys can be retrieved fully and in usable form at any time. Whoever does not make this a condition of the project buys the dependency in from the start. Vendor lock-in is therefore not a procurement detail. It is a question of strategic agility, and it belongs in the project mandate, not in later damage control. A switch that was never planned and never tested should be assumed impossible. This applies particularly to proprietary, closed solutions, whose complexity increases dependency and raises the cost of exit.
Above these decisions sits an obligation owed to the board: reporting that genuinely lets it steer. The board does not need technical detail. It needs the certainty that control over location and access is enforced, not merely assured.
What matters in the end
The goal is not “no cloud.” For many processes, outsourced processing is economical and right. The goal is control over location and access wherever the loss would not be tolerable. Drawing that line is a leadership task, not a project for the IT department.
A board that treats data sovereignty as a technical topic has, by doing so, already made a decision. In my view, the wrong one. When something goes wrong, the answer should be a decision the body made deliberately. Not one it never realised it had delegated to a location or a contract.