Data sovereignty in Switzerland explained: revFADP, FINMA outsourcing, the US CLOUD Act, and why key sovereignty with customer-held keys decides who reads data.
Data sovereignty in Switzerland means that data held by a Swiss organisation stays under Swiss law and under that organisation's control, so no foreign provider or authority can read it without going through the organisation itself. Storing data in a Swiss data centre is not enough: if the cloud provider holds the encryption keys and is subject to foreign law, it can be ordered to hand the data over. In practice, sovereignty comes down to one question: who holds the keys?
The question became concrete in November 2025. privatim, the conference of Swiss data protection officers, stated that the US CLOUD Act can oblige US providers to hand over customer data, including data stored in Swiss data centres, and that public bodies may in most cases outsource sensitive personal data to international cloud providers only if they encrypt it themselves and the provider has no access to the key. Two days later the Federal Council adopted a report on Switzerland's digital sovereignty.
This guide covers the definitions, the Swiss legal frame (revised FADP, cross-border rules, FINMA outsourcing, banking secrecy), what the CLOUD Act actually says, and why customer-held keys are the control that makes sovereignty real, with an architecture comparison and a checklist. It is not legal advice: use it to brief your counsel and architects.
The three terms are often used interchangeably. They aren't, and procurement decisions go wrong when they are mixed up.
| Term | Question it answers | What it guarantees | What it does not guarantee |
|---|---|---|---|
| Data residency | Where is the data physically stored and processed? | Data sits in a named country or region (e.g. Swiss data centres) | That only Swiss law applies to it, or that the operator cannot read it |
| Data sovereignty | Whose laws govern the data, and who can be forced to disclose it? | Data is subject to the jurisdiction you chose, and access follows that jurisdiction's procedures | Anything, if a provider under another jurisdiction can technically decrypt the data |
| Key sovereignty | Who generates, holds and uses the encryption keys? | Without your keys, stored data is ciphertext, whoever holds it and whatever order they receive | Protection of data while you have chosen to let a service decrypt it in use |
Residency is a property of the infrastructure, sovereignty a legal goal, and key sovereignty the technical control that makes the goal provable: if a provider never has your keys, an order served on it can only produce encrypted data. For a broader introduction, see what data sovereignty means for enterprise SaaS.
Switzerland has no single "sovereignty law". The obligations come from data protection law, sector supervision and professional secrecy.
The Federal Act on Data Protection of 25 September 2020 (FADP, SR 235.1), often called the revFADP or nDSG, came into force on 1 September 2023. Three provisions matter most for cloud and key decisions:
Wilful breaches of the cross-border rules, the processor rules or the minimum data security requirements can lead to fines of up to CHF 250,000 on the responsible individuals (Art. 61).
Under Art. 16 FADP, personal data may be disclosed abroad if the Federal Council has decided that the destination state guarantees an adequate level of protection. Otherwise, disclosure needs other safeguards: a treaty, contractual clauses notified to the FDPIC, FDPIC-approved standard clauses, or approved binding corporate rules. Art. 17 lists narrow exceptions, such as explicit consent.
On 14 August 2024 the Federal Council added the USA to the adequacy list to the extent of the Swiss-US Data Privacy Framework, with effect from 15 September 2024. It covers transfers to certified US companies only.
The adequacy decision makes certain transfers lawful under Swiss data protection law. It does not change what US law can require of a US provider, and it says nothing about who holds your keys.
For banks, insurers and other supervised institutions, FINMA Circular 2018/3 "Outsourcing" (in force since 1 April 2018, last amended 4 November 2020) applies when a provider performs a function significant to the business. Three requirements bear on key custody:
Keys you control serve both sides: the provider cannot read the data, and you can still decrypt it from Switzerland if the relationship ends. FINMA's 2026 quantum guidance adds crypto-agility to outsourcing expectations; see Switzerland's PQC regulation and FINMA 05/2026.
Art. 47 of the Banking Act (SR 952.0) makes it a criminal offence, punishable by a custodial sentence of up to three years or a monetary penalty, to wilfully disclose a secret entrusted to someone as an officer, employee, agent or liquidator of a bank, or that they learned in that capacity. Whether client data may be processed by a foreign cloud provider is a question for your legal and compliance teams. Architecturally, client-identifying data the provider cannot decrypt is far easier to defend than data it can.
The Confederation uses hyperscale cloud too; it decides tier by tier, by data sensitivity, how much control it needs.
The Clarifying Lawful Overseas Use of Data (CLOUD) Act was enacted in March 2018. Its second part added this sentence to the US Stored Communications Act (18 U.S.C. § 2713):
"A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States."
The operative words are "possession, custody, or control" and "regardless of whether … located within or outside of the United States." For a provider subject to US jurisdiction, the data centre's location does not decide the matter. A Swiss region of a US hyperscaler improves residency, not, on its own, sovereignty.
The US Department of Justice's 2019 white paper adds:
This is the gap encryption closes. A US provider can be compelled to produce what it possesses or controls. If it holds only ciphertext and no access to the key, ciphertext is what it can produce. A request for readable data then has to go to the organisation holding the keys, through the legal channels that apply to it, which for a Swiss company means Swiss procedures.
The DOJ's CLOUD Act page lists executive agreements with the United Kingdom and Australia; it lists no agreement with Switzerland.
Every major cloud encrypts data at rest by default. The issue is not whether data is encrypted, but whose keys are used and who can use them.
If the provider holds or can use the key, encryption protects against stolen disks, not against the provider or an order served on it. Contract clauses describe how the provider intends to behave; they do not remove its technical ability.
If you hold the key outside the provider's control, three things change:
Plan for the trade-off: strong key separation removes features that need the provider to see plaintext. Microsoft's documentation says content protected with Double Key Encryption (DKE) can't be processed by SharePoint and OneDrive search, eDiscovery or co-authoring, and isn't accessible to Copilot, and positions DKE for the small share of most sensitive data. Sovereignty is therefore a classification decision: strongest key separation where needed, lighter models elsewhere.
For a deeper look at the pattern, see our Hold Your Own Key (HYOK) guide.
The table below compares the common models by the question that matters for sovereignty: who can be compelled to disclose readable data?
| Pattern | Where the key lives | Can the provider decrypt on its own? | Who can be compelled to disclose readable data | Typical examples | Trade-off |
|---|---|---|---|---|---|
| Provider-managed keys | Provider's KMS | Yes | The provider, without involving you | Default encryption at rest | No sovereignty; simplest |
| BYOK (Bring Your Own Key) | Generated by you, imported into the provider's KMS | Yes, while the key is in its KMS | The provider, technically | Imported keys in cloud KMS | Lifecycle control, but the provider holds the key |
| HYOK / external key management | Your external key manager; the provider calls it for each operation | No, not without a live call to your key service | Mainly you; the provider can act only while you grant access, and you see every request | AWS KMS External Key Store (XKS) | You own key service availability; services may briefly cache data keys |
| Client-side encryption | Your environment; data is encrypted before upload | No | Only you; the provider stores ciphertext | Microsoft Purview DKE | Search, co-authoring and AI features stop working on that data |
| MPC-split keys | Shares on separate nodes; the full key never exists in one place | No | No single party, including the key service operator, alone | MPC key management behind HYOK or client-side | Needs a share custody design |
MPC is not an alternative to HYOK or client-side encryption; it is how you hold the key behind them. It answers the auditor's next question, "who can be compelled to hand over your key?": with multi-party computation, no single host, operator or administrator holds a complete key.
Each step produces something you can show your board, your DPO or FINMA's auditors.
DuoKey SA is a Swiss company based in Lausanne. DuoKey KMS splits keys using multi-party computation (MPC), so no cloud provider, operator or compromised host holds a complete key. Integrations include:
For your own applications, see the DuoKey KMS client. DuoKey is ISO/IEC 27001:2022 certified. For the broader programme, see the sovereign cloud use case, or contact DuoKey about deployment options.
Q: What is data sovereignty in Switzerland?
It means data held by a Swiss organisation is governed by Swiss law and stays under that organisation's control, so foreign providers or authorities cannot access it without going through the organisation. The relevant rules include the revised FADP, FINMA outsourcing requirements and professional secrecy such as Art. 47 of the Banking Act. Technically, it depends on who holds the encryption keys, not only on where data is stored.
Q: Does the US CLOUD Act apply to data stored in Switzerland?
It can. The CLOUD Act requires providers subject to US jurisdiction to disclose data in their "possession, custody, or control, regardless of whether" it is located inside or outside the United States. A US provider's Swiss data centre is not out of reach by location alone. The Act creates no new authority to compel decryption, so data the provider cannot decrypt can only be produced as ciphertext.
Q: What is key sovereignty?
Key sovereignty means your organisation generates, holds and controls the encryption keys that protect its data, outside the control of the cloud or SaaS provider that stores the data. Without the keys, the provider can store and move the data but cannot read it. It is the technical control that makes data sovereignty enforceable.
Q: Is data residency enough for sovereignty?
No. Residency fixes where data is stored, but a provider subject to foreign law can be ordered to disclose data it controls wherever it sits. Residency still helps, but it needs key sovereignty to keep the data unreadable to the provider.
Q: Does the revFADP require encryption?
Not by name. Art. 8 requires data security appropriate to the risk through suitable technical and organisational measures, and Art. 7 requires measures appropriate to the state of the art. For sensitive data in a foreign-operated cloud, encryption with keys you control is the measure most likely to meet that standard; confirm with your DPO.
Q: Does the Swiss-US Data Privacy Framework solve the CLOUD Act issue?
No. Since 15 September 2024, transfers to certified US companies under the framework are recognised as adequate under Swiss data protection law. That does not change US disclosure obligations or who holds your keys.
Q: What is the difference between BYOK and HYOK?
With BYOK you import your key into the provider's key management service, which then holds and uses it. With HYOK the key stays in your own external key manager and the provider must call it for every operation, so you can see and refuse each request.
Q: What do FINMA outsourcing rules say about the cloud?
FINMA Circular 2018/3 requires agreed security requirements for outsourced IT, audit rights for the institution, its audit firm and FINMA, and, for outsourcing abroad, that information needed for restructuring or resolution stays accessible in Switzerland at all times.
Swiss law, FINMA supervision and the Confederation's cloud strategy point the same way: use the cloud, but stay in control of sensitive data. Location alone cannot provide that control; the keys decide who can read the data.
Written by
DuoKey Team
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
