Every large cloud proposal now arrives with a sovereignty chapter. It lists data-center locations, certifications and a reassuring paragraph about European entities. Boards read it, feel reassured, and sign. Then, months later, a legal team discovers that the control plane is operated from another jurisdiction, that key material was never truly outside the provider's reach, and that the exit clause has never been tested by anyone.
Our view is straightforward: sovereignty is not a property of a data center. It is a property of contracts, architectures and rehearsed procedures, and it only shows itself under pressure. The questions below are the ones we put to management before any cloud decision reaches the board. They are drawn, with the author's permission, from the book Sovereign Cloud (Rheinwerk Computing), written within our team, and from his continuing work with public bodies and enterprises in the German-speaking world.
The six questions
- Which jurisdiction governs the operator, the control plane and the support path in a dispute? Normal operations are not the test. Ask where the people who can touch your environment sit, which law binds them, and what happens when two legal systems disagree.
- Who can compel administrative access, and who can refuse it? The answer is rarely in the press release. It sits in the terms of service, the sub-processor list and the ownership structure of the operating entity.
- Is key management demonstrably outside the provider's sphere? Demonstrably means auditable: an external HSM, a documented key ceremony, a log a third party can inspect. A slide that says "customer-managed keys" is a claim, not evidence.
- Has the exit been rehearsed, or only documented? An exit plan that has never been executed, even partially, is an assumption with a budget line. Rehearse the migration of one workload and time it.
- Does this contract increase depth of control, or only breadth of features? Feature catalogs grow every quarter. Control depth (who can stop what, and how fast) rarely does. Buy the second, not the first.
- Who decides in an emergency, and how fast? If the answer involves three committees and a vendor escalation path, the dependency is already yours. Unclear accountability is the most expensive dependency of all.
What this means for the board
None of these questions requires technical depth to ask. They require the discipline to insist on documented, testable answers and the willingness to delay a signature until they arrive. Expect that not every proposal will survive all six, and that the ones that do are not always the most expensive.
Three practical moves follow:
- Make the six questions a standing item in any cloud-related board paper, answered in writing by management, with the evidence attached.
- Separate the sovereignty decision from the vendor decision. Decide first which controls you require. Only then compare who can provide them.
- Fund the rehearsal. A tested exit for one critical workload costs a fraction of a program budget and turns the exit clause from a hope into an option.
How Cloud Tower Group supports this
We work with boards and executive teams as an independent counterpart on cloud and AI decisions. That includes reviewing sovereignty claims against contracts and architecture, preparing the board paper, and, where a decision requires people the organization does not yet have, finding the architects and interim leaders who can carry it. We hold no cloud vendor mandates and sell no cloud software. Our one product relationship, ClearView by SBSI, is disclosed in every relevant proposal.
The full argument, including deployment models, regulatory context and conversations with the leadership of Microsoft, AWS, SAP, Delos, StackIT, Red Hat and IBM, is in the book: Sovereign Cloud. The guide for systems architects and CTOs (Rheinwerk Computing, 2026, in German).