“Data in Switzerland” technically means the stored data sits in a Swiss cloud region, for example AWS eu-central-2 in Zurich. It does not mean no data leaves the country: account metadata, global identity management, worldwide CDN caches, telemetry and support access are usually not covered. The revised Swiss Federal Act on Data Protection does not require domestic storage, but adequate protection when disclosing abroad; data residency is therefore usually a contractual requirement. Against foreign disclosure obligations, location alone does not help, but encryption with customer-controlled keys and data minimisation do. The promise becomes verifiable through seven points: stored data, backups, logs, transmission path, support access, key management, sub-processors.
“Our data is in Switzerland” is one of the most frequently made statements in Swiss tenders and one of the least frequently checked.
It is rarely false. It is usually just smaller than both parties assume.
What a Swiss region actually determines
If you run an application in a Swiss cloud region, for example AWS eu-central-2 in Zurich, then the following sit there:
- the database and its contents,
- the stored files and documents,
- the backups, unless you explicitly copy them elsewhere,
- the compute that processes this data.
That is substantial, and it is exactly what most people mean when they ask. The customer data itself stays in the country.
What goes out anyway
This is where it gets uncomfortable, which is why it rarely appears in proposals.
Account metadata and billing. How many resources you run, what they are called, what they cost. That management layer is organised globally at the large providers.
Identity management. Users, roles and permissions are a global service at AWS. Who signs in and with which rights is not information tied to a region.
CDN caches. A site that should be fast worldwide sits in caches worldwide. Public content is therefore on servers around the globe. For a marketing site that is intended; for a customer portal you have to decide what may enter the cache at all.
Telemetry and operational data. Error reports, performance metrics, security events. Much of it is regional, some is not.
The support case. When you open a ticket and an engineer in Ireland or Virginia looks into it, the question is no longer where the data sits but who may see it. That is contractually manageable, but it is a contract question rather than a location question.
Your own side channels. Mail delivery, the analytics tool, the chat widget on the website, the backup script on the managing director’s laptop. In practice this is where the most common actual outflow happens, not at the cloud provider.
What the law requires, and what it does not
A widespread misunderstanding: the revised Swiss Federal Act on Data Protection does not require storage in Switzerland.
It requires that disclosure abroad happens only to countries with adequate data protection or is covered by appropriate safeguards, and that processing is transparent, proportionate and adequately secured. The Federal Council maintains a country list. For most of Europe the matter is therefore unproblematic.
Swiss data residency is consequently, in most cases, not a statutory duty but a requirement: from a contract, from a tender, from a client’s professional secrecy obligation, or simply from what the customer wants.
That is not an argument against it. A contractual requirement binds just as firmly as a statutory one, and a lost contract hurts just as much. But it is an argument for knowing the reason before paying the premium. And there is a premium: the Zurich AWS region costs around ten percent more than Frankfurt, around twenty on block storage, measured in August 2026.
This too is not legal advice. It is a description of what happens technically, so that the legal assessment starts from the right basis.
The point location does not solve
A US provider can in principle be compelled to hand over data regardless of storage location, if it falls under US jurisdiction. A Swiss region does not change that by itself.
What does change something in practice:
- Encryption with keys you control, which the provider cannot use without your involvement. Handing over blocks of ciphertext is then not the same as handing over content.
- Data minimisation. What is not stored cannot be handed over. The most effective protection is usually collecting less.
- A Swiss provider for the parts where the risk is not acceptable. That costs money and convenience, and for some data sets it is the right call.
Anyone who wants the question answered conclusively needs a legal assessment. What an architect can contribute is an honest account of where which data actually sits.
The seven points worth checking
If somebody promises you “data in Switzerland”, or if you promise it yourself, these are the questions that should be answered in writing:
- Stored data. Which region holds the database and the files?
- Backups. Where do they sit, and for how long? Does anyone replicate them to a second region?
- Log data. Where do access and application logs sit, for how long, and what is in them?
- Transmission. Which networks does the traffic cross, and what sits in worldwide caches?
- Access. Who can reach content in operations and support, from where, and is it logged?
- Keys. Who manages the encryption keys, and can the provider decrypt without you?
- Sub-processors. Which further services are attached, and where do they sit?
If that is not in writing, the promise is a statement of intent. If it is in writing, you have a basis a lawyer can work from.
How we handle it
We build in AWS eu-central-2, so Zurich, and say what that statement covers and what it does not. On every project we go through the seven points once and write the answers down, even when nobody asks.
The reason is simple: the sentence “our data is in Switzerland” will eventually be examined by somebody who wants to know precisely. Usually by a client of your client, in a tender, under time pressure. It is pleasant to already have the document.
Frequently asked questions
Does a Swiss cloud region mean no data leaves Switzerland?
No. A Swiss region determines where the stored data sits, so databases, files and backups. Usually not covered are account metadata and billing data, global identity management, content in worldwide CDN caches, telemetry, and the support case where somebody outside Switzerland looks at a ticket. Anyone promising that no data leaves Switzerland has to have checked each of those points individually.
Does the revised Swiss data protection act require data to be stored in Switzerland?
No. The revised Federal Act on Data Protection does not require domestic storage. It requires that disclosure abroad happens only to countries with adequate protection or is covered by appropriate safeguards, and that processing is transparent and adequately secured. Swiss data residency is therefore usually a contractual or client-side requirement, not a statutory one. This is not legal advice.
Does a Swiss region protect against the US CLOUD Act?
Not through location alone. A US provider can in principle be compelled to hand over data regardless of where it is stored. What helps in practice is encryption with keys the customer controls and the provider cannot use without their involvement, plus data minimisation. Anyone who wants that question answered conclusively needs a legal assessment, not an architect.
How do I tell whether a provider’s data in Switzerland claim holds?
By seven points: the region of the stored data, where backups sit, where log data sits, the path of transmission, access by support and operations, key management, and the sub-processors. If it is not in writing, the promise is a statement of intent.