Does Swiss FADP Force You Off US-Owned Clouds? What Actually Matters in 2026
Switzerland's revised FADP treats foreign government access as a real risk, but it never bans US-owned clouds. Here is what Swiss companies actually have to prove - and why a Zurich region alone is not the proof.
No, the Swiss Federal Act on Data Protection does not force you off US-owned clouds. And no, picking a Zurich region does not settle the question either. AWS, Microsoft and Google all run Swiss regions, and all three remain US companies that a US court can order to produce data in their "possession, custody, or control" (18 U.S.C. § 2713). The gap between those two facts is where most Swiss compliance arguments go wrong.
Key points:
The revised FADP (nFADP), in force since 1 September 2023, contains no ban on US providers and no Swiss-hosting mandate (Fedlex, SR 235.1). It asks for a lawful transfer basis under Art. 16-17 and adequate security under Art. 8, not a vendor passport.
A Swiss region gives you data residency, not data sovereignty. The US CLOUD Act follows the provider's control of the data, not the location of the disk.
US transfers are lawful today through two routes: the Swiss-U.S. Data Privacy Framework (effective 15 September 2024, and only for organisations actually certified) or EU Standard Contractual Clauses with the Swiss adaptations plus a transfer impact assessment.
Infrastructure choice is necessary but not sufficient. The FDPIC, a FINMA outsourcing reviewer and an enterprise security questionnaire all end up asking the same three things: who holds the keys, which humans can reach production, and where are the logs that prove it.
The workable pattern is tiered: your own cloud account or your own Kubernetes cluster for most data, customer-held keys and audit logs, and Swiss-only hosting reserved for data bound by banking secrecy (Art. 47 BankG) or professional secrecy (Art. 321 StGB).
This is engineering-side guidance from someone who sits in a lot of these security reviews, not legal advice. For the law itself, go to the FDPIC and Fedlex.
Does the Swiss FADP actually ban US-owned cloud providers?
No. The nFADP regulates disclosure of personal data abroad under Art. 16-17 and requires either an adequate destination, a recognised safeguard such as the Swiss-adapted EU SCCs, or a legal exception, plus security measures under Art. 8. Nothing in the Act names a provider nationality.
The nFADP replaced the 1992 Act and entered into force on 1 September 2023 (Art. 74, Fedlex SR 235.1). The Federal Data Protection and Information Commissioner (FDPIC, EDÖB in German) supervises it. The articles an engineering team actually touches:
Art. 8: data security appropriate to the risk, through technical and organisational measures.
Art. 9: processing by processors needs a contract, and the processor may only do what you could do yourself.
Art. 12: a record of processing activities.
Art. 16: disclosure abroad only to adequate states or under recognised safeguards.
Art. 17: narrow exceptions such as consent or contract performance.
Art. 22: a data protection impact assessment where processing carries a high risk.
Art. 24: notify the FDPIC "as quickly as possible" of a breach likely to cause a high risk.
The penalties land on people, not companies. Art. 60-61 impose fines of up to CHF 250,000 on "private persons" for wilful breaches, including disclosure abroad in breach of Art. 16-17 and failing minimum security requirements (Fedlex SR 235.1). The company only pays (up to CHF 50,000, Art. 64) when finding the responsible individual would be disproportionate. That is why your CTO, not your legal entity, should care.
Annex 1 of the Data Protection Ordinance lists the states the Federal Council considers adequate. The United States appears only for organisations certified under the Swiss-U.S. Data Privacy Framework, added by an amendment in force since 15 September 2024 (Fedlex SR 235.11, FDPIC).
For most regulated Swiss companies, the FADP is not the binding constraint. Sector law is. Banking secrecy under Art. 47 Banking Act and professional secrecy under Art. 321 Swiss Criminal Code both carry up to three years' custodial sentence. Add FINMA Circular 2018/3 for banks and insurers, and the health-data rules under KVG/EPDG.
If you already built a GDPR programme, most of it carries over. The transfer logic is aligned, but the enforcement model is not.
Dimension
nFADP position
GDPR position
Practical consequence for a Swiss engineering team
Entry into force
The nFADP applies from 1 September 2023.
The GDPR applies from 25 May 2018.
A Swiss team with a GDPR programme only needs to adjust it for the nFADP, not rebuild it.
Who enforces
The FDPIC investigates, and cantonal criminal authorities prosecute fines.
Each EU member state's data protection authority enforces, coordinated by the EDPB.
A Swiss incident goes to one federal commissioner, but fines run through criminal procedure.
Transfer mechanism to the US
Transfers are allowed to Swiss-U.S. DPF certified organisations or under SCCs with Swiss adaptations.
Transfers are allowed to EU-U.S. DPF certified organisations or under SCCs.
The same vendor check works for both, but you must confirm the Swiss-U.S. certification specifically.
Maximum penalty
The nFADP sets fines of up to CHF 250,000 for wilful breaches.
The GDPR sets fines of up to EUR 20 million or 4% of worldwide turnover (Art. 83).
The Swiss ceiling is lower, but it is personal and can appear on a criminal record.
Who is liable
The responsible natural person is fined, and the company only pays up to CHF 50,000 as a fallback.
The controller or processor as an organisation is fined.
Under the nFADP, the person who approved the setup carries the risk directly.
Register of processing threshold
Companies under 250 employees are exempt unless they process large volumes of sensitive data or run high-risk profiling (DPO Art. 24).
Organisations under 250 employees are exempt unless processing is risky, non-occasional or involves special categories (Art. 30).
Most SaaS companies process data continuously, so keep the register anyway.
Breach notification deadline
Notify the FDPIC "as quickly as possible" when a breach is likely to lead to a high risk.
Notify the supervisory authority within 72 hours where feasible (Art. 33).
Design your incident runbook for 72 hours and you satisfy both.
The rest of this article uses one frame. The regulator's question is "can you show who is able to read this data, and under which law", not "is your provider American".
Why does a Swiss data centre region not solve the CLOUD Act problem?
Because the US CLOUD Act attaches to a provider's possession, custody or control of data, not to where the hardware sits. AWS Europe (Zurich), Azure Switzerland North and Google Cloud Zurich are operated by companies a US court can compel, so residency alone does not answer Art. 16.
The CLOUD Act was introduced as H.R.4943 and enacted on 23 March 2018 as Division V of the Consolidated Appropriations Act 2018 (Pub. L. 115-141). It amended the Stored Communications Act so that orders reach data "regardless of whether" it is stored inside or outside the US. That mooted United States v. Microsoft: the Supreme Court vacated the case on 17 April 2018 without ruling on the merits (Supreme Court, No. 17-2).
The debate conflates three different things. I call them the triad, and the rest of this article keeps coming back to it:
Data residency: where the bytes physically sit.
Data sovereignty: whose law can compel disclosure of those bytes.
Access control: who can technically decrypt and read them.
A Zurich region fixes residency. It changes nothing about sovereignty for a US-owned provider, and it does not touch access control at all.
Now size the risk honestly, because the published numbers are small. The hyperscalers publish this data, and it deserves a fair reading:
AWS received 2,310 requests in H1 2026, disclosed content in exactly one, and answered "None" to whether it gave the US government enterprise or government content stored outside the US. Fifteen requests came from Switzerland. National security requests across all of Amazon fall in the 0-249 band (Amazon Information Request Report, H1 2026).
Microsoft received 190 requests for enterprise customer data in H2 2025. It disclosed content in 45, and 96 were rejected, withdrawn, had no data, or were redirected to the customer (Microsoft Law Enforcement Requests Report). Content from three non-US enterprise customers stored abroad went to US law enforcement, one of them in the EU/EFTA.
Google received 1,248 requests for Google Cloud and Workspace enterprise data in H2 2025 and disclosed some information in 27.2% of them (Google Transparency Report).
The residual stays, though. No contract clause removes a provider's duty to comply with a valid order served on an entity its US parent controls. The DOJ CLOUD Act resources page lists executive agreements with the UK and Australia and ongoing EU negotiations. As of October 2026 it lists no agreement with Switzerland, which is a material fact for your transfer impact assessment.
This is not vendor marketing either. The FDPIC told Suva in June 2022 to reconsider moving personal data to Microsoft 365. Meanwhile the Confederation signed its "Public Clouds Bund" contracts with AWS, Microsoft, Alibaba, IBM and Oracle on 27 September 2022 (Federal Chancellery) and extended them to August 2031 (admin.ch, September 2025). In parallel, Parliament approved a CHF 246.9 million commitment credit for the Swiss Government Cloud in December 2024 (FOITT). The federal government itself runs a tiered setup.
Residency is a useful control for latency, cost and sector rules. It is not a sovereignty argument, and presenting it as one is how a transfer impact assessment gets rejected.
What does "we picked a Swiss provider, so we are fine" get wrong?
A Swiss provider fixes jurisdiction and nothing else. The failure modes that produce breaches and failed security reviews look identical on Exoscale, Infomaniak or Swisscom and on AWS. Back to the triad: you solved sovereignty and left access control untouched.
Keys. With provider-managed KMS, the provider can technically produce plaintext. With customer-managed keys, the provider still runs the key service, but you control policy and rotation. With hold-your-own-key or an external key store, plaintext requires your HSM to answer.
Human access. Provider support engineers with break-glass rights, third-party SaaS in the data path (observability, error tracking, CI, AI coding assistants), and your own developers holding permanent production credentials.
Evidence. Without per-environment RBAC and exportable access and deployment logs, you cannot answer the FDPIC, a FINMA reviewer or a customer questionnaire. "We trust our provider" is not an artefact.
The control plane above the infrastructure. A Swiss-hosted Postgres behind a US-operated PaaS control plane with vendor support access reintroduces the exposure you paid to remove. This is the quiet trap for teams on Heroku, Render, Vercel or Platform.sh/Upsun, and almost nobody lists it in their sub-processor register.
The breach data points the same way. Stolen credentials were the top initial access vector in 22% of breaches, and the human element was present in 60% (Verizon DBIR 2025). Misconfiguration ranks among the top three error types. The global average breach now costs USD 4.99 million (IBM Cost of a Data Breach 2026). Compare that with the single content disclosure in AWS's latest report.
My opinion, after a lot of these reviews: Swiss teams over-index on the flag on the data centre and under-invest in provable access control, which is the only part an auditor can actually test. The FDPIC received 484 breach notifications in 2025/26 (FDPIC 33rd Annual Report). Those came from compromised accounts and mistakes, not CLOUD Act warrants.
Which cloud setup fits which kind of Swiss data?
Match the pattern to the data tier: a hyperscaler with customer-held keys for ordinary personal data, Swiss or self-hosted infrastructure for secrecy-bound data, and a transfer impact assessment for anything that leaves the country. Most Swiss companies end up with two or three tiers rather than one sovereign bet.
Tier the data first:
Public and marketing data: no nFADP constraint worth designing around.
Ordinary personal data: customer accounts, CRM, product analytics.
Sensitive personal data under Art. 5 lit. c: health, biometrics, religious or political views, social security measures.
Secrecy-bound data: client data under Art. 47 BankG, patient and client files under Art. 321 StGB, health records under KVG/EPDG.
Then map each tier to a pattern. Every row below stands on its own; the triad tells you which column matters most for your tier.
Pattern
Exposure to foreign government orders
Who holds the encryption keys
Transfer mechanism under Art. 16-17
Managed service and GPU breadth
Typical data tier it fits
Main drawback
US hyperscaler Swiss region (AWS Zurich, Azure Switzerland North/West, Google Cloud Zurich)
The provider remains subject to US orders because its US parent controls the data.
The provider holds the keys by default through its managed KMS.
You need DPF certification of the vendor or SCCs with Swiss adaptations, plus a transfer impact assessment.
It offers the widest managed service catalogue and the deepest GPU supply.
It fits public data and ordinary personal data.
Residency without key control does not address foreign access.
US hyperscaler with customer-managed or external keys
The provider can still receive orders, but cannot produce plaintext without your key service.
You hold the keys in your own HSM or external key store.
You still need DPF certification or SCCs, but the transfer impact assessment becomes far easier to defend.
It keeps nearly the full catalogue, though some managed services do not support external keys.
It fits ordinary and most sensitive personal data.
External key stores add latency, cost and an availability dependency you must operate.
Swiss or EU provider (Exoscale, Infomaniak, Swisscom, Scaleway)
Swiss providers operate under Swiss law only, and EU providers under EU law.
The provider holds keys by default, and customer-held options vary by vendor.
Swiss providers need only an Art. 9 processor agreement, and EU providers benefit from EU adequacy in Annex 1.
The managed catalogue is narrower, and GPU supply is limited and model-dependent.
It fits sensitive and some secrecy-bound data.
You lose managed service breadth and often IAM maturity.
Own Kubernetes on-prem or in a Swiss colo
Exposure is limited to Swiss law and your own staff.
You hold all keys yourself.
No foreign transfer happens unless your tooling sends data abroad.
You get only what you build and operate yourself.
It fits secrecy-bound data.
You carry the full operational burden, including upgrades, backups and on-call.
Sovereign-cloud construct with a local operator
Exposure depends on the legal separation between the local operator and the foreign technology vendor.
The local operator or the customer holds the keys, depending on the contract.
The contract structure determines whether any transfer occurs, so it needs case-by-case review.
Feature parity usually lags the public cloud version.
It fits public-sector and highly regulated data.
It costs more, ships features later, and its legal guarantees need independent review.
Each pattern also needs its contract layer: an Art. 9 processor agreement, a per-vendor check against the DPF participant list, and a maintained sub-processor list with change notification. As of 29 October 2026, 2,918 organisations hold an active Swiss-U.S. certification, including Amazon.com, Microsoft Corporation and Google LLC. Check the Swiss-U.S. box specifically, per vendor, every year.
Keep a dated caveat in your file too. The EU General Court dismissed the Latombe challenge to the EU-U.S. framework on 3 September 2025 (CJEU press release), but an appeal (C-703/25 P) is pending before the Court of Justice. The Swiss framework is built on the same US commitments.
The common failure is lifting everything to a smaller provider and silently losing managed backups, mature IAM, multi-AZ failover and the compliance evidence your enterprise customers demand.Exoscale (Geneva and Zurich zones), Infomaniak and Swisscom are credible answers for the top tier. They are not drop-in replacements for every service on a hyperscaler.
GPUs make tiering unavoidable in 2026. Exoscale offers several NVIDIA GPU families, but teams running serious inference or training usually need hyperscaler capacity for at least part of the pipeline. That is a legitimate engineering reason to keep two tiers.
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster, including Swiss-hosted ones. Start deploying in under 10 minutes.
How do you prove to the FDPIC or an enterprise customer that access is controlled?
You prove it with artefacts: a record of processing, a transfer impact assessment per destination, key custody documentation, a per-environment RBAC matrix, and exportable access and deployment logs with a stated retention. Map each obligation to its artefact and the review becomes a document pull instead of a debate. This is where the access-control leg of the triad becomes visible.
nFADP obligation
What a reviewer asks for
Artefact that satisfies it
Where it comes from in a cloud setup
Who owns it internally
Art. 8 data security
The reviewer asks how access to personal data is restricted and monitored.
A per-environment RBAC matrix, a KMS key policy export and an audit log retention statement satisfy it.
These come from your cloud IAM, your KMS and your deployment platform's audit log.
The CTO or head of platform owns it.
Art. 9 processor agreement
The reviewer asks for the contract with every processor that touches personal data.
A signed data processing agreement per vendor and a dated sub-processor list satisfy it.
These come from vendor contracts, including observability, CI and AI tooling vendors.
Legal or the DPO owns it, with engineering supplying the vendor list.
Art. 12 record of processing
The reviewer asks what personal data you process, why, and where it is stored.
A record of processing activities listing purposes, categories, recipients and destination countries satisfies it.
It comes from your data inventory mapped to cloud accounts and regions.
The DPO owns it, with engineering confirming the locations.
Art. 16-17 disclosure abroad
The reviewer asks on what basis data leaves Switzerland and what risk remains.
A transfer impact assessment per destination plus DPF certification evidence or signed SCCs satisfies it.
It comes from your vendor list, the DPF participant search and your key custody design.
Legal owns it, with engineering documenting who can decrypt.
Art. 22 DPIA
The reviewer asks for a risk assessment of any high-risk processing.
A data protection impact assessment describing risks and mitigating measures satisfies it.
It draws on architecture diagrams, data flows and the controls listed above.
The DPO owns it, with product and engineering contributing.
Art. 24 breach notification
The reviewer asks how you detect, assess and report a breach.
A written incident runbook naming the FDPIC portal and a decision log for past incidents satisfies it.
It comes from alerting, audit logs and your incident management tooling.
The security lead owns it.
The operational controls that move the needle more than any vendor choice:
No standing production access. Short-lived credentials, approval-gated deploys.
Ephemeral preview environments seeded with anonymised or synthetic data, never production copies.
A complete sub-processor list that includes the AI coding assistant reading your repo.
Anonymisation is your cheapest compliance win. The nFADP covers data relating to an identified or identifiable person (Art. 5 lit. a). Irreversibly anonymised data falls outside it, while pseudonymised data stays in scope because someone can re-identify it. Shrinking the regulated surface beats migrating it.
For banks and insurers, FINMA Circular 2018/3 adds a layer. You need an outsourcing inventory, contractual audit and inspection rights for you, your audit firm and FINMA "at any time without restriction", an exit path to insource or switch provider, and, for outsourcing abroad, assurance that the necessary information stays accessible in Switzerland.
A copyable evidence checklist for a questionnaire or a FINMA file:
TEXT
[ ] Record of processing activities (Art. 12), dated, with destination countries
[ ] Transfer impact assessment per foreign destination (Art. 16-17)
[ ] DPF Swiss-U.S. certification screenshot or signed SCCs, per vendor
[ ] Processor agreements + sub-processor list incl. observability, CI, AI tools (Art. 9)
[ ] KMS key policy export showing who can decrypt
[ ] RBAC matrix per environment (dev / staging / prod)
[ ] Audit log export sample + stated retention period
[ ] Infrastructure-as-code history for production changes
[ ] Breach runbook pointing at the FDPIC portal (Art. 24)
[ ] DPIA for high-risk processing (Art. 22)
How does Qovery let Swiss teams keep control without hiring a platform team?
Qovery deploys into your own cloud account or your existing Kubernetes cluster, so the data, encryption keys, cloud contract and audit trail stay with the Swiss entity while developers keep git-push deployments. It answers the access-control half of the question, not the legal half.
Bring-your-own-cloud means the cluster, databases and bill live in your own AWS, GCP, Azure or Scaleway account, or on a Kubernetes cluster you already run, including one on Swiss infrastructure or on-prem (Qovery Kubernetes install). Your committed-spend discounts stay in the Swiss entity's name.
Run it through the triad:
Residency stays wherever you choose: Zurich, Geneva, your colo.
Sovereignty depends on your provider and your transfer mechanism. Qovery does not change it.
Access control is the part Qovery makes provable. Keys stay in your own KMS, per-environment RBAC scopes who can deploy where, and audit logs record every action without a vendor support ticket.
The limit, stated plainly: Qovery does not make a US hyperscaler region Swiss-sovereign, and it does not make anyone "FADP compliant". If you need a fully Swiss data plane, point Qovery at a Kubernetes cluster running on Swiss infrastructure.
Then there is the hiring problem. Michael Page puts a Swiss DevOps engineer at CHF 105,000 to 150,000 a year (Michael Page Switzerland Salary Guide 2026), and those profiles take months to find. A ten-person engineering team cannot staff a platform rotation just to produce an RBAC matrix and an audit log export.
How do I set this up with Qovery from Claude Code or Cursor?
Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy into your own cloud account. The agent acts through scoped Qovery permissions, and the MCP Server stays read-only until you enable writes in both the command and the Qovery Console.
BASH|Install the skills globally for Claude Code, Cursor, Codex, OpenCode, Gemini CLI
curl -fsSL https://skill.qovery.com/install.sh | bash
# Or keep them inside one repository
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project
# Add the MCP Server to Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242
# Enable writes only when you want them (also enable write access in the Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242
The split is simple. The skills (qovery-onboard, qovery-deploy, qovery-preview, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-terraform and more) handle deploying. The MCP Server operates what already exists, and every agent action lands in the same audit log.
Then ask: "Deploy this app into our own Azure subscription in Switzerland North with Qovery, with preview environments on pull requests and no production data in previews." Full walkthroughs are in the AI agent quickstart and the Claude Code integration page.
Frequently asked questions
Does the Swiss FADP prohibit storing personal data with US-owned cloud providers?
No. The nFADP contains no ban on US providers and no Swiss-hosting mandate. It requires a lawful basis for disclosure abroad under Art. 16-17, such as the Swiss-U.S. DPF or SCCs with Swiss adaptations, and appropriate security under Art. 8.
Does hosting in a Swiss cloud region protect data from the US CLOUD Act?
No, not by itself. The CLOUD Act reaches data in a US provider's possession, custody or control regardless of location, so a Zurich region gives you residency, not sovereignty. Customer-held keys through an external key store are what limit what the provider can actually produce.
Is a Swiss company allowed to use AWS, Google Cloud, or Azure under the nFADP?
Yes. Amazon.com, Microsoft Corporation and Google LLC all held active Swiss-U.S. DPF certifications as of October 2026, which makes transfers to them adequate under Annex 1 of the DPO. You still need a processor agreement, a record of processing and appropriate security measures.
What transfer mechanism do Swiss companies need when personal data goes to the United States?
Either the recipient is certified under the Swiss-U.S. Data Privacy Framework, or you sign EU SCCs adapted for Swiss law and document a transfer impact assessment. Check certification per vendor on the official participant list, because the Swiss-U.S. extension is a separate box. Art. 17 exceptions such as consent cover only narrow, occasional cases.
Is customer-managed encryption enough to satisfy Swiss data protection requirements?
No, it is one strong control among several. Keys you hold outside the provider shrink foreign-access risk and simplify your transfer impact assessment. You still need access controls, audit logs, processor agreements and a breach procedure.
When does a Swiss company genuinely need a Swiss-only or sovereign cloud?
When sector law binds harder than the FADP. Client data under banking secrecy (Art. 47 BankG), patient or client files under professional secrecy (Art. 321 StGB) and some health records usually justify Swiss-only infrastructure or customer-held keys with no foreign operator access. Ordinary personal data rarely does.
What evidence does the FDPIC expect if a Swiss company is audited on cloud outsourcing?
The FDPIC expects documents it can review. Expect to show your record of processing, processor agreements, transfer impact assessments, security measures including key custody and access rights, and your breach procedure. The FDPIC's cloud guidance is the right starting point. Swiss law asks you to know exactly who can read your data and to prove it on demand. If you want that control without building a platform team, run your deployments on infrastructure you own and try Qovery free.
Romaric founded Qovery to make Kubernetes accessible to every engineering team. He writes about platform strategy, developer experience, and the future of cloud infrastructure.
Next step
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster, including Swiss-hosted ones. Start deploying in under 10 minutes.
