A Swiss practitioner’s guide to separating real controls from sovereignty washing, without losing the value of public cloud.

Introduction: the word “sovereign” has become too easy to use

In my previous article, Sovereignty Reloaded: A Swiss and European Perspective, I argued that sovereignty is not a switch to flip but a ladder of controls, spanning jurisdictional, operational, technical and supply-chain measures, that need to be matched to the workload, the risk scenario and the organisation’s strategy. I also promised that cloud sovereignty deserved its own follow-up. This is that follow-up.

The timing matters, because in the months since, the market has become crowded with sovereign claims. Every major cloud provider now has a sovereignty story, and while some of those stories reflect genuine architectural progress, others are mainly a change in vocabulary. A standard region becomes a sovereign region; a policy template becomes a sovereign landing zone; a data residency commitment becomes a sovereignty claim; and a local support model is presented as if it had somehow solved jurisdiction, encryption, operations and exit all at once. The provider announcements themselves show both the progress and the marketing risk: compare AWS European Sovereign Cloud, Microsoft Sovereign Cloud, Google sovereign controls and Oracle EU Sovereign Cloud.

That is not good enough.

Cloud sovereignty is too important to be reduced to branding. For Swiss and European organisations, especially in regulated sectors, the question is no longer whether a provider calls something sovereign, but what actually changed underneath the label: in the architecture, the operating model, the keys, the legal structure and the exit path. That framing also aligns with Switzerland’s pragmatic public-sector approach to hybrid multi-cloud and the Swiss banking sector’s risk-based cloud guidance, both of which treat cloud as governable rather than forbidden (see the Federal Administration’s Cloud Strategy Bund and the SBA Cloud Guidelines 2025).

This distinction is practical, not academic. One workload may need nothing more than data residency and good contractual controls; another may require customer-held keys, local operations and auditable break-glass; a third may need a Swiss or European provider, a disconnected platform, or a tested exit route out of the public cloud altogether. The right answer is rarely the same twice.

Nor is this an argument against public cloud, which remains legitimate, valuable and often necessary. The mistake is not using hyperscalers; the mistake is using them without knowing which dependencies you have accepted, which controls you actually hold, and which claims are only a sovereign label pasted onto yesterday’s architecture.

So this article deliberately stays on cloud sovereignty. AI sovereignty, the data questions around models, and sovereign AI infrastructure are closely related, but they deserve their own treatment and will get it. Here the task is narrower: how to separate real cloud controls from sovereignty washing, without losing the value of public cloud along the way.

The sovereignty ladder, briefly restated

In the previous article, I leaned on the sovereignty ladder to avoid the most common mistake in this debate: treating sovereignty as a yes-or-no property. It is nothing of the sort. Sovereignty is layered, and each rung adds more control while also adding more cost, complexity and operational responsibility.

The first rung is data sovereignty, the level most often discussed and most often oversold. It asks where data is stored and processed (and that should mean not only the primary content but the metadata, logs, telemetry and backups around it), as well as who holds the encryption keys, who can access plaintext, and whether data can be moved or copied outside the claimed jurisdiction. A Swiss or EU region helps, but location alone is never the full answer. The legal reason is straightforward: statutes such as 18 U.S.C. § 2713 look to a provider’s “possession, custody, or control” rather than only where the data is stored, and the EDPB’s transfer guidance similarly emphasises technical supplementary measures when foreign access risks remain (18 U.S.C. § 2713; EDPB Recommendations 01/2020).

The second rung is operational sovereignty, which asks who actually runs the environment: who can administer the platform, support an incident, or approve and execute break-glass access, and whether non-local operators are technically blocked or merely governed by policy. This is where many claims start to weaken. A local data centre is not especially sovereign if global administrators can still intervene without strong controls, logging and customer visibility.

The third rung is software and technical sovereignty, which is about control over the stack itself: whether the workload can be moved, whether the architecture can be inspected, whether open standards are used, whether the platform can run disconnected if required, and whether there is a credible exit path rather than a lock-in to proprietary services the organisation cannot realistically replace. This rung matters because sovereignty without reversibility quickly becomes dependence with better branding. The EU Data Act is a useful policy signal here because its cloud-switching provisions are explicitly designed to reduce contractual, technical and commercial barriers to switching between data-processing services (Regulation (EU) 2023/2854; European Commission explainer).

The fourth rung, supply-chain and corporate sovereignty, is the hardest of all. It asks who owns the provider, who controls the roadmap, which jurisdictions apply, and which hardware, software and subcontractors the service ultimately depends on. A provider may be European-operated yet rely on US software; a Swiss provider may be locally owned yet depend on foreign chips. A sovereign claim can be entirely valid for one part of the stack and quietly weak for another. The European Commission’s Cloud Sovereignty Framework formalises this kind of assessment through sovereignty objectives and SEAL levels, making clear that ownership, supply-chain resilience and operational control are separate dimensions rather than a single label (Cloud Sovereignty Framework; Commission explanation).

The important point is that the rungs accumulate. A provider cannot be strong on operational sovereignty while ignoring data control, and it cannot claim full sovereignty if the customer has no exit path or if ownership creates unresolved jurisdictional exposure.

Not every workload needs every rung. Paying for maximum sovereignty everywhere is wasteful; ignoring it for sensitive workloads is reckless.

The discipline lies in deciding which rung each workload actually requires, why, and under which risk scenario. And most sovereignty washing begins precisely here, when rung one is presented as if it were rung four.

How sovereignty washing actually happens

Sovereignty washing starts with a simple move: take an existing capability, rename it sovereign, and hope the buyer does not ask what changed underneath.

The most common version is data residency dressed up as full sovereignty. “Your data stays in Switzerland” or “your data stays in the EU” is genuinely useful, and for many workloads it is even sufficient, but it is still only the first rung. It says little about who holds the keys, who can access support data, where metadata is processed, which administrators can intervene, which subcontractors are involved, or which parent company remains subject to foreign law. Microsoft’s completed EU Data Boundary is a real example of improved residency and support-data localisation, but even that kind of boundary does not, by itself, answer the key-custody, control-plane and corporate-jurisdiction questions (Microsoft EU Data Boundary completion).

A second version is local support without local control. A provider may offer a Swiss or European support desk, but the question that matters is not who answers the phone; it is who can access the platform, approve privileged operations, execute break-glass actions, change configurations or inspect logs. Local support is valuable, but it is not operational sovereignty unless non-local access is technically blocked, tightly governed, fully logged and visible to the customer. That is why controls such as Microsoft’s Data Guardian, Google Access Transparency/Approval patterns and AWS’s EU-resident operations model matter only to the extent that they are enforceable, logged and scoped to the actual services in use (Microsoft Data Guardian announcement; Google Sovereign Controls by Partners; AWS European Sovereign Cloud operations).

Encryption is another area where weak claims sound strong. “Encrypted by default” means very little if the provider controls the master keys and can technically decrypt the data; real control begins only when the customer holds the keys, or when the provider is technically unable to reach plaintext at all. That distinction matters most for sensitive SaaS, regulated data, professional secrecy, health data and confidential public-sector workloads. This distinction is also reflected in Swiss public-sector debate: privatim’s 24 November 2025 resolution says international SaaS for sensitive or legally confidential public-sector data is generally only acceptable where the responsible body encrypts the data itself and the provider has no access to the key (privatim resolution; publication page).

Then there is the comfortable phrase “sovereign-ready”, which usually means that templates, policies, landing zones and contractual clauses are available. These can be helpful and can accelerate good architecture, but they do not in themselves create a separate control plane, local-only operations, customer-held keys, disconnected operation or legal independence. A well-configured standard cloud can easily be better than a badly configured sovereign one; it just should not be sold as something it is not. Microsoft’s Sovereign Landing Zone is a useful example: it applies sovereign controls to Azure landing-zone architecture, but it is still a control pattern for public cloud rather than proof of a separate sovereign partition (Microsoft SLZ documentation).

A European region, equally, is not the same as European sovereignty. Region location answers exactly one question, where the service is hosted, and leaves the others untouched: who owns the provider, who controls the software, who can be compelled by which jurisdiction, and whether the customer can exit without a major redesign. The same holds in Switzerland, where a Swiss region is valuable but Swiss data residency alone does not settle the wider question.

Some providers also point to their commitments to challenge government requests. That is useful, and responsible providers should certainly do it, but contractual resistance is not the same as technical inability. A promise to fight access is always weaker than an architecture in which the provider cannot read the data in the first place. The EDPB’s supplementary-measures guidance after Schrems II is a good reminder that contractual clauses may need to be complemented by technical measures such as strong encryption with keys retained outside the importer’s control (EDPB Recommendations 01/2020).

The same caution applies to “data boundary” initiatives. They represent real progress, reducing unnecessary transfers and improving transparency, but they generally sit near the lower rungs of the ladder unless they are combined with local operations, separate control planes, customer-held keys, auditable access controls and credible exit options.

This is why the distinction between promises and barriers matters so much. Contracts are promises; technical controls are barriers. When jurisdictions collide, only the barriers hold.

Sovereignty washing does not always mean bad faith. Sometimes it is imprecise marketing, sometimes a real control described too broadly, sometimes a useful feature inflated into a strategic claim. The buyer’s task is not to reject every claim but to decompose it, to ask what actually changed in the architecture, the operating model, the key model, the legal structure and the exit path. If the answer is “not much”, then the sovereign label is doing more work than the technology.

What actual sovereign cloud controls look like

A serious sovereign cloud claim should be visible in controls, not adjectives.

The first place to look is key management. If the provider controls the master keys, the customer does not have full cryptographic control. Customer-managed keys are better, External Key Management can be stronger still, and Hold Your Own Key models can be stronger again, provided the implementation genuinely keeps key material outside the provider’s control and that losing the key would render the data unreadable to the provider. For the most sensitive cases, and especially where SaaS is involved and the provider should never see plaintext, client-side encryption may be the only adequate answer. Examples of the stronger patterns include AWS KMS External Key Store, Google Cloud External Key Manager/Key Access Justifications and IBM Cloud Hyper Protect Crypto Services with Keep Your Own Key (AWS XKS; Google Key Access Justifications; IBM Hyper Protect Crypto Services).

Confidential computing can also help, particularly where data needs protection during processing rather than only at rest or in transit. It is not a universal answer; it carries scope limits, performance implications and operational complexity. But where it is implemented properly, it reduces the trust that has to be placed in the underlying infrastructure operator. AWS’s Nitro security design, for example, explicitly describes a no-operator-access model for EC2 Nitro hosts, though this is still a control with defined scope rather than a universal sovereignty guarantee (AWS Nitro security design).

Operational controls matter just as much. Local-only operations should mean far more than a local service desk; they should mean defined technical restrictions on who can access production systems, who can approve privileged activity and who can execute break-glass procedures. Break-glass access itself should be rare, justified, time-bound, logged and visible to the customer, with access logs that are immutable or tamper-evident, so that customers can review who accessed what, when, from where and under whose approval. Provider implementations vary: AWS frames its European Sovereign Cloud around EU-resident operations, while Microsoft frames Data Guardian around European access approval and logging for remote access to European systems (AWS European Sovereign Cloud; Microsoft Sovereign Cloud).

Architecture matters too. A dedicated sovereign region, partition, realm or private deployment is stronger than a standard region with policy overlays, provided the separation is real, the control plane is understood and the data flows are documented. That coverage has to extend to metadata, telemetry, logs, backups and support artefacts, not only to customer content; a sovereign claim that ignores metadata is incomplete by definition. AWS describes its European Sovereign Cloud as physically and logically separate from other AWS Regions, and Oracle describes its EU Sovereign Cloud as EU-operated regions separated from commercial OCI regions; those are stronger architectural claims than ordinary residency-only regions, but still need scope review (AWS announcement; Oracle EU Sovereign Cloud).

For higher-risk workloads, disconnected or air-gapped operation may be relevant. This does not mean every workload should run in isolation; it means some workloads need the ability to operate without depending on a global control plane, a foreign support path or a remote update channel. That ability has a cost (it can reduce feature velocity and complicate patching), but for certain workloads the trade-off is clearly justified. This is the design space addressed by products such as Google Distributed Cloud air-gapped and Microsoft Azure Local disconnected operations (Google Distributed Cloud air-gapped; Microsoft Azure Local disconnected operations).

Software and exit controls are routinely underestimated. Open standards, Kubernetes portability, standard APIs, documented data formats and tested migration paths all matter, because a workload is not truly under control if leaving the platform is theoretically possible but practically impossible. Exit plans should not sit in a drawer; they should be tested, costed and kept up to date. The EU Data Act turns parts of this into a legal expectation by requiring providers of data-processing services to remove obstacles to switching and improve interoperability (Regulation (EU) 2023/2854).

Corporate and supply-chain controls remain the hardest of all. Local ownership, partner-operated legal structures, acquisition protections and transparent subcontractor chains can reduce risk, but they rarely remove it completely, because hardware, firmware, chips, software updates and specialised services still flow through global supply chains. The honest question is not whether all dependency has vanished, but whether the dependencies that remain are known, governed and acceptable.

Evidence is the difference between a claim and a control. Buyers should ask for architecture diagrams, key-management designs, operational access models, data-flow diagrams, subcontractor lists, ownership structures, certification scopes and exit-test results.

Certifications can help. SecNumCloud, BSI C5, the ISO standards, Gaia-X labels, EUCS or SEAL levels all provide useful assurance, but they have scope. They assess defined controls, services and operating models, and they do not automatically prove that every workload is sovereign, that every subcontractor is risk-free, or that every jurisdictional conflict has disappeared. For example, SecNumCloud is a French ANSSI qualification, BSI C5 specifies German cloud-security criteria, EUCS remains part of the EU cybersecurity-certification framework, Gaia-X focuses on trust and interoperability, and the Commission’s SEAL model evaluates sovereignty levels for specific procurement contexts (SecNumCloud; BSI C5; ENISA EUCS; Gaia-X Trust Framework; EU Cloud Sovereignty Framework).

A real sovereign cloud control should survive one simple question: if a foreign authority, a remote administrator, a parent company or a failing provider created pressure, what would technically prevent unwanted access, disruption or lock-in? If the answer is only “the contract”, the control is not strong enough for the higher rungs.

Hyperscaler sovereign offerings: better than before, but still not absolute

The hyperscalers have understood the market signal. Sovereignty is no longer a niche public-sector requirement; it has become a board-level risk topic across Europe and Switzerland, and the large cloud providers have responded accordingly.

That response should not be dismissed, because some of the new controls are real. The strongest hyperscaler offerings now reach well beyond simple data residency, into separate regions, dedicated partitions, local operations, external key management, customer-controlled encryption, confidential computing, partner-operated models and disconnected deployments. This is genuine progress.

But progress is not the same as absolution.

AWS is probably the clearest example of a genuine architectural step forward. The AWS European Sovereign Cloud is not simply an ordinary EU region with a new label; it is designed as a separate European cloud environment, with distinct operational structures, EU-based operations and stronger separation from the standard AWS global cloud. For European customers that want AWS capabilities with stronger data and operational controls, this is materially better than the old answer of “choose an EU region and configure it carefully”. The limit is equally clear: AWS remains ultimately Amazon-owned. That does not make the offering useless, but it does mean corporate and jurisdictional exposure has not disappeared. The architecture reduces risk; it does not create legal immunity. AWS announced general availability on 15 January 2026, describes the cloud as entirely located in the EU and physically/logically separate, and also says operations are performed by EU residents with a transition towards EU-citizen-only operation (AWS press release; AWS technical launch blog).

Microsoft’s approach is broader and more layered. Its Sovereign Public Cloud, EU Data Boundary, Data Guardian, External Key Management and regulated-environment tooling all improve the standard Microsoft posture for European customers, and they matter especially for organisations already deeply invested in Azure and Microsoft 365. But the standard Sovereign Public Cloud model is still, in essence, a set of controls layered onto existing public cloud regions, not the same thing as a fully separate sovereign partition. Microsoft’s stronger sovereignty story sits elsewhere: in Azure Local, Microsoft 365 Local, Foundry Local, disconnected operations, and national partner clouds such as Bleu in France and Delos in Germany. These models climb further up the ladder because they change the operating model more fundamentally, bringing workloads closer to customer or local-partner control, even though they still rely on Microsoft technology, roadmaps and software supply. Microsoft’s own materials separate these layers: completion of the EU Data Boundary in February 2025, the June 2025 Sovereign Cloud controls, and the February 2026 disconnected/local extensions (EU Data Boundary; Sovereign Cloud announcement; Azure Local and Microsoft 365 Local disconnected operations).

Google Cloud follows a similar pattern of strong controls with important scope boundaries. Assured Workloads, data-boundary capabilities, Access Transparency, External Key Management, client-side encryption and confidential computing can create meaningful protection for selected services, while Google Distributed Cloud and partner-operated models such as S3NS go further by changing the deployment and operating model. The key distinction, once again, is scope: product-specific controls are valuable, but they are not the same as end-to-end sovereignty across every service, every support path and every dependency. Google documents Assured Workloads/data-boundary controls, partner-managed sovereign controls, and Google Distributed Cloud air-gapped as distinct models with different scopes (Assured Workloads overview; Sovereign Controls by Partners; Distributed Cloud air-gapped).

Oracle deserves mention because its EU Sovereign Cloud is a comparatively strong separate-realm story, offering EU-only regions, EU operations and a distinct sovereign environment while preserving much of the standard OCI service model. For customers already aligned with Oracle, that can be attractive, though the same residual issue remains: Oracle is still a US-headquartered company, and the sovereign realm reduces exposure rather than eliminating it. Oracle states that its EU Sovereign Cloud is operated by EU-incorporated legal entities and delivered from EU sovereign regions, separated from Oracle’s commercial cloud regions (Oracle EU Sovereign Cloud; Oracle Europe cloud regions).

IBM sits somewhat differently in this discussion. Its relevance is less about a single European sovereign public cloud narrative and more about hybrid cloud, regulated workloads, cryptographic control, mainframe integration and strong key-custody patterns. For some banks, insurers and public-sector environments, that hybrid, encryption-led posture may matter more than another branded sovereign region. IBM’s Hyper Protect Crypto Services documentation is a useful example of this posture, because it emphasises customer-controlled HSM administration and master-key custody, including Keep Your Own Key models (IBM Hyper Protect Crypto Services).

The important point is not to rank providers as good or bad, but to classify the claim. A standard region with residency controls is one thing; a public cloud with local access approval and external keys is another; a separate sovereign partition or realm is stronger again; a partner-operated national cloud is different in kind; and a disconnected, customer-controlled deployment sits in a category of its own. These are not interchangeable.

No US-owned hyperscaler offering can fully remove residual US-jurisdiction exposure. The stronger models can reduce that risk to a practical floor (particularly when combined with customer-held keys, encryption applied before data reaches the provider, local-only operations and real technical separation), but they cannot make the exposure vanish. That does not make hyperscaler sovereign offerings irrelevant; it makes them risk-reduction tools. For many workloads that will be enough, and for some it will not. The practitioner’s job is to know which is which. This is the key legal baseline behind the article: U.S. law can reach data within a covered provider’s possession, custody or control even when the data is stored outside the United States, so the practical question becomes whether the design removes plaintext access, operator reach and unilateral control (18 U.S.C. § 2713).

Swiss and European sovereign alternatives: real options, different trade-offs

The sovereignty debate tends to fixate on the hyperscalers, but that is only half the market. Switzerland and Europe have credible sovereign cloud alternatives: some mature, some specialised, some stronger on ownership and jurisdiction than on service breadth. The important thing is to understand what each is good for, rather than to treat them as smaller versions of AWS, Azure or Google Cloud.

In Switzerland, Swisscom is the obvious starting point. Its strength is not that it can replicate the full hyperscaler catalogue, which it cannot, but that it combines Swiss infrastructure, Swiss operations, regulatory familiarity, enterprise integration and majority ownership by the Swiss Confederation. For banks, insurers, healthcare organisations, public-sector bodies and critical infrastructure, that combination matters. Swisscom is best understood as a control-rich Swiss operator and hybrid-cloud anchor, not as a feature-for-feature substitute for public cloud. Swisscom’s own sovereignty positioning and the CNCF architecture material describe a Swiss-operated, open-source-based Kubernetes service on Swiss infrastructure, which is why it is best understood as a sovereign anchor rather than a hyperscaler clone (Swisscom digital sovereignty; CNCF architecture: Swisscom Kubernetes Service; CNCF Swisscom case study).

Exoscale plays a different role. It is a Swiss-based European provider with a more cloud-native profile (compute, storage, Kubernetes, databases and developer-oriented infrastructure across Swiss and European zones), and for many workloads built around standard infrastructure patterns and portability, it is a credible alternative to hyperscaler dependency. The trade-off is service breadth: if an organisation needs the full long tail of proprietary analytics, AI, serverless and global edge services, the gap is still real. Exoscale publishes its European cloud-zone footprint and compliance stack, including ISO certifications, SOC 2, BSI C5 and CSA STAR, but its catalogue remains focused compared with hyperscalers (Exoscale platform; Exoscale cloud zones).

Infomaniak is one of the strongest Swiss examples of sovereignty treated as a corporate and architectural posture rather than a slogan. Its Swiss hosting model, open-source orientation, owned infrastructure and foundation-based governance give its sovereignty claim real substance, which matters in a market where acquisition risk has itself become part of the discussion. A provider that is sovereign today can become less so tomorrow if its ownership changes, and Infomaniak has addressed that risk more explicitly than most. Infomaniak’s 2026 transfer of majority voting rights to the Infomaniak Foundation is a concrete governance change, not just a hosting claim, and its own sovereign-cloud material explicitly contrasts Swiss-controlled infrastructure with mere European hosting by a foreign-owned company (Infomaniak Foundation announcement; Infomaniak sovereign cloud; Infomaniak explanation of sovereign cloud).

PHOENIQS and Phoenix Systems sit in a more specialised category, most relevant where Swiss-controlled infrastructure, AI, high-performance compute or isolated enterprise platforms matter more than a broad general-purpose catalogue. They should not be judged by whether they can replace a hyperscaler globally, but by whether they provide strong control for the selected workloads where Swiss jurisdiction, confidentiality and technical isolation are decisive. PHOENIQS positions its IaaS and AI/cloud clusters as built and operated in Switzerland for Swiss sovereign infrastructure, which makes it relevant for selected sensitive workloads but does not make it a broad hyperscaler substitute (PHOENIQS Cloud; PHOENIQS overview).

CSCS and Alps are different again. They are not commercial sovereign cloud platforms for ordinary enterprise workloads but strategic Swiss compute assets, and their importance lies in national capability, research, high-performance computing and the foundations of sovereign AI. They belong in the sovereignty conversation, yet they should not be confused with enterprise cloud options for banks, hospitals or corporates. CSCS describes itself as Switzerland’s national supercomputing centre, and ETH/EPFL/CSCS’s Apertus release shows why Alps matters for national AI capability rather than ordinary enterprise cloud replacement (CSCS; Apertus announcement).

Across Europe the picture is broader still. OVHcloud, IONOS, Scaleway, Deutsche Telekom and T-Systems, StackIT and Aruba each represent a different version of the European sovereign cloud answer: some stronger in public-sector and regulated workloads, some in core infrastructure, some built on open-source stacks, some offering certified environments, and some embedded in national industrial strategies. OVHcloud’s SecNumCloud-qualified Bare Metal Pod and IONOS’s German public-sector/C5 positioning illustrate how these offerings often compete on assurance scope and jurisdictional anchoring rather than hyperscaler-like breadth (OVHcloud Bare Metal Pod SecNumCloud; OVHcloud SecNumCloud environment; IONOS sovereign public-sector cloud; BSI C5 catalogue).

Then there are the partner-operated models (S3NS and Bleu in France, Delos in Germany), which are interesting precisely because they try to combine local operation and local legal structures with hyperscaler technology. They can climb further up the operational and jurisdictional rungs than standard public cloud regions, while still carrying a dependency on the underlying US software stack. That does not make them weak; it makes them hybrid sovereignty models, and they should be assessed as such. S3NS is a clear example: it combines Thales’ local security and operating model with Google Cloud technology, and Thales announced SecNumCloud qualification for the PREMI3NS offering while also deepening the Google Cloud partnership (S3NS; Thales/S3NS announcement).

Policy-led initiatives are frequently misunderstood. Gaia-X is not “the European cloud”; its practical value lies in standards, trust frameworks, transparency, interoperability and data-space governance. EuroStack and related European initiatives point in a more strategic direction: reducing structural dependency and strengthening Europe’s technology base. The Swiss Government Cloud matters as well, but it is public-sector infrastructure, not a commercial sovereign cloud option for the private sector. Gaia-X’s architecture describes a trust framework for interoperable, trusted relationships rather than a single cloud platform, while the Federal Administration’s Cloud Strategy Bund and Public Clouds Bund show Switzerland’s own public-sector hybrid approach (Gaia-X architecture; Gaia-X 2026 value scenarios; Cloud Strategy Bund; Public Clouds Bund).

The message is simple. Swiss and European providers are real options (especially for core infrastructure, regulated workloads, sensitive data, local operations and exit strategies), and they can be the right answer whenever control matters more than scale. But there is no free lunch. The gaps remain in global footprint, managed-service breadth, marketplace depth, AI-platform maturity, developer ecosystem and release velocity. A sovereign provider tends to give you stronger control but fewer services; a hyperscaler gives you speed and scale but more residual jurisdictional exposure.

That is why the decision cannot be ideological. The right question is not whether Swiss or European providers are “better” than hyperscalers, but which platform gives the right level of control for a given workload, at a cost and capability trade-off the organisation is prepared to own.

Why public cloud matters in everyday business

A sovereignty-conscious cloud strategy should not begin from the assumption that public cloud is bad. That framing is too simple, and in many cases it leads straight to poor architecture.

Public cloud remains valuable because it solves real business and technology problems. It gives organisations elastic capacity, global reach, mature security services, modern development platforms, managed databases, analytics, automation, observability and resilience patterns that are genuinely difficult to reproduce in smaller sovereign environments. For many organisations these are not luxuries; they are simply how digital services now get built and run. Swiss practice reflects this: the Federal Administration uses a hybrid multi-cloud model, and the Swiss Bankers Association calls cloud technology a critical success factor while providing guidance for safe use in financial services (Cloud Strategy Bund; SBA cloud computing page; SBA Cloud Guidelines 2025).

This is especially true for workloads that need speed. A development team testing a new product, a customer platform with unpredictable demand, a data team experimenting with analytics or a business unit launching a new digital service may all gain far more from public cloud than they lose in residual sovereignty exposure, provided the data classification is appropriate and the controls are well designed.

Public cloud also matters for resilience, because a purely local architecture can create its own concentration risk. Keeping systems in national or regional data centres may reduce jurisdictional exposure, but it increases dependency on a small number of facilities, networks, suppliers and operational teams. Under some threat models, including major outages, physical disruption or geopolitical instability, geographic distribution matters more than strict locality.

The Ukraine example is relevant here, though it should not be overused. It showed that when physical infrastructure is under threat, public cloud can provide a continuity that on-premise systems cannot. That does not mean every Swiss or European workload should move to a hyperscaler; it means resilience and sovereignty sometimes pull in opposite directions, and a serious strategy has to hold both in view. In Ukraine, AWS reported more than 10 petabytes moved from Ukrainian servers to the cloud by July 2022, Microsoft says it helped evacuate critical data and services to European datacentres, and PrivatBank publicly described its emergency cloud migration of thousands of servers, hundreds of applications and petabytes of customer data (AWS Ukraine case study; Microsoft European digital commitments; PrivatBank AWS case study; PrivatBank migration announcement).

There is also a security argument. Hyperscalers operate at a scale that funds enormous investment in threat intelligence, patching, identity systems, logging, detection, encryption services, compliance tooling and security automation. None of that makes every public cloud deployment secure (misconfiguration remains a major risk), but it does mean smaller sovereign platforms should not be assumed safer simply because they are local. This is also why the SBA guidance treats cloud adoption as a governed outsourcing and risk-management exercise rather than a blanket prohibition (SBA Cloud Guidelines 2025).

The same applies to innovation velocity. Hyperscalers release capabilities quickly and at scale, some of it genuinely useful and some of it unnecessary noise, so the task is to choose deliberately. A regulated bank may not need the newest experimental service for a critical workload, yet its digital channels, analytics teams and developers may still benefit from a platform that offers breadth, automation and rapid provisioning.

Cost is another uncomfortable point. Sovereignty carries a premium: separate environments, local operations, customer-held keys, dedicated infrastructure, additional assurance, duplicated platforms and exit capability all cost money. That cost is often justified for sensitive workloads, but applying the highest sovereignty model everywhere turns a valid risk principle into an expensive constraint that slows delivery without materially reducing risk. The Commission’s Cloud Sovereignty Framework implicitly recognises that higher sovereignty levels come with stronger evidence, operating-model and supply-chain requirements; buyers should therefore treat sovereignty as a scoped premium, not a universal default (EU Cloud Sovereignty Framework).

This is why refusing public cloud is itself a risk decision. It can reduce jurisdictional exposure while increasing delivery risk, resilience risk and skills risk, opening security-tooling gaps, and adding opportunity cost and operational complexity. The better position is not “public cloud everywhere”; that was always too crude. But “public cloud nowhere” is every bit as crude.

For many everyday workloads, public cloud remains the right answer; for some it is acceptable with additional controls; for others it is simply the wrong platform. The distinction depends on data sensitivity, operational dependency, legal exposure, business criticality, reversibility and the consequences of provider failure or foreign compulsion. A mature organisation does not ask whether public cloud is sovereign in the abstract; it asks whether a specific public cloud design is sovereign enough for a specific workload, under a specific risk scenario, with the residual risk accepted by the right accountable owner.

The workload placement model: governed hybrid cloud

The practical answer is governed hybrid cloud. This is not just a vendor compromise: it is the model used by the Swiss Federal Administration and reflected in Swiss banking guidance (Cloud Strategy Bund; SBA Cloud Guidelines 2025).

Not hybrid cloud as an accidental estate, where every team picks its own platform and governance turns up afterwards; not multi-cloud as a political compromise; and not sovereign cloud as a symbolic gesture. Governed hybrid cloud means workloads are placed deliberately, on the basis of data sensitivity, operational risk, jurisdictional exposure, resilience needs, business value and exit requirements.

The starting point is classification. What data does the workload process: personal data, sensitive personal data, banking secrecy, health data, legal privilege, public-sector confidentiality, intellectual property, critical-infrastructure telemetry? What metadata does it create, and where do its logs, backups, support files and monitoring data go? A great many weak sovereignty decisions trace back to the same error: the main database is classified carefully, and the operational data surrounding it is ignored.

The second question is access. Who can see plaintext, who holds the keys, and can the provider decrypt the data? Can support engineers reach the environment, and can administrators outside Switzerland or Europe intervene? Is that access technically blocked or only contractually restricted? For low-risk workloads, contractual and policy controls may be enough; for higher-risk ones, the answer has to be cryptographic, operational and auditable.

The third question is dependency. Can the workload continue if a region fails, a provider service is suspended, a legal conflict emerges or a vendor relationship deteriorates? Can the organisation move it without a major redesign, and is there a tested exit path rather than just a clause in the contract? Sovereignty without exit capability is fragile.

This leads to a simple placement model.

Public websites, marketing platforms, collaboration on non-sensitive content, developer sandboxes, proofs-of-concept and many customer-facing digital services can usually run on standard public cloud, provided identity, logging, encryption, backup and data classification are properly governed. Here the business value of speed, elasticity and service breadth typically outweighs the residual risk.

Regulated but non-critical workloads can often fit public cloud with additional controls: customer-managed keys, strong identity governance, restricted administration, clear data boundaries, contractual safeguards, monitoring and tested recovery. This is where many banks, insurers and enterprises will operate most of the time.

Sensitive workloads demand a higher bar. Health data, banking secrecy, legal data, confidential public-sector data and critical operational systems may call for external key management, client-side encryption, local-only operations, sovereign hyperscaler offerings, Swiss or European providers, private cloud, or some combination of these. The decision turns on whether the provider can be technically prevented from reaching plaintext, and whether operational control matches the risk. The privatim resolution is a useful Swiss reference point for the strict end of this spectrum, because it emphasises encryption by the responsible public body and no provider access to the key for sensitive data in international SaaS (privatim resolution).

Highly confidential or classified workloads sit at the top end. Military systems, state secrets, some law-enforcement workloads, critical national-infrastructure control systems and the most sensitive research environments may require private, disconnected, air-gapped or nationally controlled platforms. In these cases, losing some public cloud convenience is not inefficiency; it is the price of control.

AI workloads should be classified with the same care, though I will not absorb them into this article. The same placement logic applies: some AI experimentation can run happily on public cloud, while sensitive training data, regulated inference, model governance and strategic AI infrastructure may demand far stronger sovereign controls. That is a subject for the next article.

The governance layer is what makes the model work. Architecture teams can propose patterns, security teams can define controls, and risk and legal teams can assess exposure, but the residual risk must be owned by the business and approved at the right level. A platform decision that creates strategic dependency should never be buried inside a technical design document. The goal is not to create friction for every workload, but to make each decision explicit.

For each workload, the questions are the same: which sovereignty rung is required, which controls prove it, and which dependencies remain? What would happen if the provider, region or jurisdiction became unavailable, how would the organisation exit, and who accepts the residual risk? That is governed hybrid cloud: public cloud where it is the right risk decision, sovereign platforms where control matters more, and clear accountability everywhere.

What to ask vendors before accepting a sovereign claim

The easiest way to test a sovereign cloud claim is to ask what changed, not what changed in the brochure, but what changed in the architecture, the access model, the key model, the legal structure, the operational process and the exit path.

Start with the rung. Which rung of the ladder does the offer actually reach: data residency only, or operational controls as well? Does it improve technical reversibility? Does it change ownership, jurisdiction or supply-chain exposure? If the provider cannot answer in those terms, the claim is not mature enough to rely on.

Then ask about data scope. Do customer content, metadata, logs, telemetry, backups, billing data, support files and diagnostic data all fall within the commitment? Many sovereignty claims sound strong until the surrounding data is examined. For some workloads, metadata can be almost as sensitive as the content itself.

Key control comes next. Who holds the master keys, and can the provider decrypt the data? Is External Key Management available, and is Hold Your Own Key truly external or still dependent on provider-controlled infrastructure? What happens when the customer revokes the key? If the provider can still reach plaintext after all of that, the claim should be treated accordingly.

Operational access needs the same level of detail. Which administrators can reach production systems, and are non-local administrators technically blocked or merely restricted by policy? How does break-glass work, who approves it, and how long does access last? Are the logs immutable, and can the customer inspect them? A serious provider can describe the access path precisely, without retreating into generic security language.

Architecture is the next test. Is the control plane separate, and are identity, billing, monitoring, support and update systems separate with it? Is this a dedicated region, partition, realm or private deployment, or simply a standard region with policy controls layered on top? There is nothing wrong with policy controls for the right workload; they just should not be sold as structural separation.

Legal and corporate structure deserve the same scrutiny. Which entity signs the contract, who owns it, and which jurisdiction applies? Which subcontractors are involved, and what happens if the provider is acquired: are there acquisition protections, local-partner structures or step-in rights? Sovereignty, after all, can change after procurement if ownership changes.

Certifications should be examined by scope, not by logo. Which service is certified, in which region, under which operating model, and which controls were actually audited? Does the certification cover the sovereign variant or only the standard platform? A certificate that sits outside the workload’s actual scope is useful context, not assurance. SecNumCloud, BSI C5, EUCS, Gaia-X labels and SEAL scores are all useful only when the certified service, geography and operating model match the workload being assessed (SecNumCloud; BSI C5; ENISA EUCS; Gaia-X Trust Framework; Commission SEAL framework).

Finally, ask about exit. Can the workload be moved, in which data formats, and which proprietary services create lock-in along the way? Has an exit test ever been run, how long would migration take, what would it cost, and which business processes would be affected? A contractual right to exit is not the same as an executable exit plan. The EU Data Act makes switching and interoperability a regulatory theme, but it still leaves each organisation with the architectural work of making exit executable for its own workloads (Regulation (EU) 2023/2854).

The best vendor conversations are usually uncomfortable, and that is a good sign. Sovereignty is not proven by a confident adjective; it is proven by evidence. Ask for the diagrams, the key design, the access model, the subcontractor list, the ownership structure, the certification scope and the exit test.

If the answer is clear, specific and auditable, the claim may be real. If it is vague, contractual only, or limited to “your data stays here”, then the sovereign label is not enough.

Conclusion: sovereignty as a discipline

Cloud sovereignty is not achieved by buying the right label. It is achieved by making explicit control decisions, workload by workload, by knowing where data sits, who can access it, who holds the keys, who operates the platform, who owns the provider, which jurisdictions apply, and how the organisation can leave if the risk changes. That is less convenient than a simple vendor claim, but it is also more honest.

The market will keep using the word sovereign, and some offerings genuinely deserve serious attention. Hyperscaler sovereign clouds have improved; Swiss and European providers are becoming more credible; and partner-operated models, external key management, confidential computing, disconnected platforms and open-source-based stacks all give architects more options than they had a few years ago. But none of this removes the need for judgement. The current landscape supports exactly that conclusion: major providers have shipped stronger controls, European and Swiss providers have matured, and regulators have moved toward evidence-based frameworks rather than slogans (AWS European Sovereign Cloud; Microsoft Sovereign Cloud; Infomaniak Foundation; EU Cloud Sovereignty Framework).

A Swiss bank, a hospital, a public authority, a manufacturer and a digital start-up will not share the same sovereignty requirements, and the right answer varies even within a single organisation. Some workloads belong on standard public cloud; some need stronger controls on hyperscaler platforms; some should run on Swiss or European sovereign providers; and some require private, disconnected or highly controlled environments.

The objective is not to avoid dependency at any cost (that is unrealistic in a global technology supply chain), but to know where dependency exists, decide where it is acceptable, reduce it where it is not, and retain the ability to move when the situation changes.

That is why “are we sovereign?” is never quite the right question. The better one is this: which sovereignty rung does this workload require, under which risk scenario, and can the provider prove it? If the answer is clear, evidenced and governed, the organisation is in control of the decision. If it is a label, a slide or a vague assurance, it is not sovereignty at all. It is branding.

Cloud sovereignty is not a product. It is not a region, a certification logo or a legal clause standing on its own. It is a discipline: architectural, operational, legal and commercial. And like every serious discipline, it needs to be practised before the crisis arrives.