Swiss sovereign cloud: what actually separates it from AWS

The confusion is common in Swiss IT teams: believing that hosting data in an AWS datacenter located in Zurich automatically protects it from US law. It does not, and the consequences are concrete. What defines a Swiss sovereign cloud is not the address of the servers: it is the jurisdiction that applies to the data, and the legal obligations that jurisdiction imposes on the operator.

Infrastructures such as Hikube are built around that principle from the start, hosting exclusively in Switzerland, an operator subject to Swiss law alone, and exposure to the US CLOUD Act removed by a wholly Swiss legal and ownership structure. That distinction is not a sales argument. It is a legal reality that any organisation handling sensitive data should understand before choosing a provider.

By the end of this article you will know exactly what digital sovereignty means, why AWS Zurich does not offer it, what nFADP actually requires, and how to evaluate a provider before signing.

What “Swiss sovereign cloud” actually means

A Swiss sovereign cloud is not simply infrastructure located geographically in Switzerland. It is a service whose operator, governance, data and associated processing escape any foreign jurisdiction. The definition rests on a distinction many people miss: the difference between data residency and data sovereignty.

Data residency and sovereignty, two distinct notions

Data residency is where the bytes are physically stored. Sovereignty is which law applies to them and who may lawfully access them. A US provider can have servers in Geneva and remain fully subject to US law. Physical location does not erase the operator’s jurisdiction. Sovereignty requires the provider itself to be organised and to operate under Swiss law alone.

The three cumulative criteria of a sovereign cloud, strictly speaking

Based on market practice and the evaluation guides available, three criteria qualify a sovereign cloud rigorously. The operator’s jurisdiction is the first: the provider must be subject exclusively to Swiss law, with no foreign parent exposed to extraterritorial legislation. Ownership control is the second: the shareholding structure must not open a door to requests from foreign authorities. Technological control is the third: no dependency on proprietary components governed by another jurisdiction’s rules. Each of these has to be verifiable contractually, not merely announced on a marketing page.

Why AWS and Azure hosted in Switzerland do not guarantee sovereignty

This is the point many IT leaders avoid examining, often because the migration to a US hyperscaler has already happened. Yet the demonstration is simple and needs no polemic: a US provider’s Swiss location does not protect data from US law.

The US CLOUD Act, what it allows in practice

Adopted in 2018, the CLOUD Act obliges US companies, AWS, Microsoft and Google among them, to hand data to US federal authorities on a court order, whatever the physical location of that data. The obligation is most often exercised without going through mutual legal assistance treaties and may, in some cases, carry no prior notification to the customer concerned, notably where a confidentiality order accompanies the request. A Swiss company hosted on AWS Zurich is therefore exposed to that mechanism: not because its servers are in the United States, but because its provider is subject to it.

A zone of legal uncertainty with concrete consequences

For a Swiss SME handling HR or financial data, for a bank under FINMA supervision or for a cantonal administration, the implications are direct. Guaranteeing total confidentiality to their own clients contractually becomes difficult. Sector audits raise questions that AWS standard clauses do not answer. Documenting the sovereignty of processing for the Federal Data Protection Commissioner or for FINMA becomes hard to assemble. This is not a theoretical risk: it is a structural fragility in any organisation that outsources sensitive data to an operator subject to US law.

What nFADP and sector regulation actually require

As a general rule, nFADP does not impose hosting exclusively in Switzerland. Data may be transferred abroad, provided the destination state offers an adequate level of protection recognised by the Federal Council, or that appropriate safeguards are in place. But the framework carries precise obligations that many underestimate.

What nFADP effectively requires of cloud hosting

nFADP requires prior information to the individuals concerned in the event of a transfer outside Switzerland, technical and organisational measures proportionate to the sensitivity of the data, notification of breaches to the Commissioner where they present a high risk, keeping a register of processing activities, and applying protection by design.

It also imposes strict contractual framing of subprocessors, outsourcing to a cloud provider does not discharge the controller of its obligations. Hosting in Switzerland considerably simplifies compliance, but it is not systematically mandatory: except for highly sensitive data, where the legal risk of a transfer becomes hard to justify.

Finance, healthcare and the public sector, when a Swiss sovereign cloud becomes a de facto requirement

FINMA requires financial institutions to be able to access their data at any time, to document where their providers sit, and to guarantee continuity of access during a crisis or an exit. Those governance and traceability requirements make hosting under Swiss jurisdiction close to indispensable for limiting audit friction, even if some institutions manage to frame partial hosting abroad contractually.

In healthcare, medical data is sensitive data under nFADP and requires a heightened level of protection. Sector recommendations and cantonal practice lead, in the vast majority of cases, to favouring hosting under Swiss jurisdiction. For public administrations, digital sovereignty is often a political condition as much as a legal one: some cantons and municipalities now impose data residency in Switzerland contractually.

Which organisations gain most from moving to a Swiss sovereign cloud

Many organisations, of all sizes, are actively reassessing their exposure and making concrete decisions in favour of sovereign hosting. The reasons vary by sector but converge on one point: legal control of data has become an operational imperative.

Swiss SMEs handling sensitive customer data

An SME handling its clients’ HR, financial or medical data carries direct liability in the event of a leak or unauthorised access. Hosting on a Swiss sovereign cloud simplifies nFADP audits, strengthens customer trust, and removes complex contractual clauses on cross-border transfers. That is a measurable competitive advantage, not only a regulatory constraint. In sectors where data confidentiality is a selection criterion, being able to guarantee an exclusively Swiss jurisdiction becomes a differentiator.

Financial players, healthcare institutions and public administrations

For these organisations the room for manoeuvre is narrow. FINMA, healthcare regulators and the cantons demand traceability and control of data that hosting under Swiss jurisdiction facilitates structurally, per FINMA circular 2023/1 and the Commissioner’s recommendations. A sovereign cloud also makes it possible to answer public tenders that now impose residency and sovereignty requirements. For a bank or an insurer, every audit is an opportunity to demonstrate that critical data never left Swiss ground.

What a 100% Swiss infrastructure has to deliver in practice

Legal sovereignty is not enough if the infrastructure does not meet a modern organisation’s technical requirements. An enterprise-grade Swiss sovereign cloud has to combine both dimensions without compromise.

Replication across three sites, and high availability

A serious sovereign infrastructure does not rest on a single Swiss datacenter. According to the information the provider publishes, Hikube spreads its infrastructure across three independent datacenters in Gland, Lucerne and Geneva, with volume replication between them, synchronous or asynchronous depending on the mode chosen per volume, and the two do not carry the same RPO, for a published availability objective of 99.99%. In that architecture no data leaves Swiss territory, even during an automatic failover after an incident. High availability and sovereignty are not contradictory objectives; they reinforce each other when the architecture is designed for both from the start.

Enterprise managed services without proprietary lock-in

A sovereign cloud worthy of the name has to offer the same technical capabilities as a hyperscaler. According to the data Hikube publishes, the offering includes:

• CNCF-certified managed Kubernetes, with node group autoscaling; the GitOps tools you deploy on it, Flux or Argo CD, remain yours
• managed databases (PostgreSQL, MariaDB, Redis, MongoDB, ClickHouse), whose operation is handled for you
• S3-compatible object storage (AWS CLI, boto3, rclone)
• GPUs for artificial intelligence (L40S, A100, H100)
• full observability through Grafana and VictoriaMetrics

All of it rests on open standards, kubectl, Helm, S3, which limits proprietary lock-in. The Terraform integration, however, is announced as in preparation: check it before making it a dependency of your chain.

How to evaluate a provider and prepare a migration

Choosing a Swiss sovereign cloud is a structuring decision. It deserves a rigorous evaluation of the provider and a planned migration, not a rushed one.

The contractual and technical points to check before signing

Beyond certifications (ISO 27001, SOC 2, ISAE 3402), several points deserve particular attention. Verify the actual address of the datacenters and their exact scope, not just the words “hosted in Switzerland”. Require explicit contractual clauses on the residency of data and metadata, along with full transparency on subprocessors and administrative access. Ask for proof that the operator is itself subject exclusively to Swiss law, with no parent exposed to extraterritorial legislation. A data processing agreement compliant with nFADP is a non-negotiable minimum. Certifications attest to security; on their own they do not prove sovereignty, a distinction the comparative analyses available on the market underline consistently.

Migrating progressively without stopping everything

A successful migration happens in batches. Start with a full audit of your existing data and flows, then classify your workloads by criticality: low-sensitivity data, sensitive data, critical data. Run a pilot on a non-critical application to validate performance, backups and support before going further. Then migrate in successive waves, validating each batch before moving to the next. The main risk is not technical: it is the lock-in inherited from the existing architecture, notably proprietary AWS services and tied licences. A sovereign provider built on open standards reduces that risk structurally from day one.

Conclusion

Location and sovereignty are two different things. The CLOUD Act changes everything for organisations hosting their data with US operators, even when those operators have servers in Switzerland. Organisations handling sensitive data, financial, medical or administrative, have concrete, verifiable reasons to move to a Swiss sovereign cloud.

Digital sovereignty is not an abstract surcharge. It is a legal and technical guarantee that only infrastructures designed for it can offer: an exclusively Swiss jurisdiction, replication across several sites, managed services built on open standards. Hikube built its infrastructure around those requirements, without trading availability against sovereignty.

Before renewing a contract or extending your current infrastructure, ask your provider a simple question: under which jurisdiction is your data actually protected? If the answer is not clearly “Swiss law only”, you know what is left to evaluate. Get in touch with our team to look at your situation and compare what your current infrastructure really guarantees.