The Swiss buyer's guide to data sovereignty

Data sovereignty has become a line in almost every Swiss tender, and almost every provider claims it. The word covers several different things: where the data is stored, whose law governs the provider, who can be compelled to hand it over, and whether you can take it elsewhere. A provider can be strong on one and weak on the others.

This guide separates those questions, for organisations in Switzerland choosing where their software runs. It covers the Swiss and European data protection rules, the US CLOUD Act, the difference between residency and sovereignty, the role of open source in keeping an exit open, and a list of questions to put to any provider, including us. If you need the term itself first, start with what data sovereignty is and how it differs from residency and localisation. It is general information, not legal advice; your data protection officer or counsel makes the call for your organisation.

What data sovereignty means in practice

Four questions sit behind the word.

1. Location. In which country are the machines, the backups and the logs?
2. Jurisdiction. Under whose law does the provider operate, and which authorities can order it to disclose data?
3. Control. Who holds the keys, who can log in, and who decides when something changes?
4. Portability. Can you move the data and the software to another provider or to your own servers, in a reasonable time, without the provider’s goodwill?

Residency answers the first question. Sovereignty needs all four.

The Swiss Federal Act on Data Protection (nLPD)

The revised Federal Act on Data Protection (SR 235.1), known as the nLPD in French, the revDSG in German and the revised FADP in English, has applied since 1 September 2023. It governs personal data of natural persons processed by private organisations and federal bodies. Cantonal bodies follow their cantonal data protection law, which often goes further on outsourcing and location.

Duties that shape a hosting decision

• Data security (art. 8). Controllers and processors must ensure security appropriate to the risk, through technical and organisational measures. The Data Protection Ordinance (SR 235.11) lists what that covers: confidentiality, availability, integrity and traceability.
• Processors (art. 9). You may hand processing to a processor by contract, provided it only processes the data as you would yourself and guarantees data security. Using a sub-processor needs your prior authorisation.
• Privacy by design and by default (art. 7). Systems should collect and keep only what is needed.
• Records of processing (art. 12). Most organisations keep a record of their processing activities, with an exemption for companies under 250 employees whose processing carries low risk.
• Impact assessments (art. 22). Processing likely to create a high risk requires a data protection impact assessment.
• Breach notification (art. 24). A breach likely to create a high risk must be reported to the Federal Data Protection and Information Commissioner (FDPIC) as soon as possible. Processors must tell the controller without delay.

Disclosure abroad (art. 16 and 17)

Under art. 16, personal data may go abroad when the Federal Council has found that the destination offers adequate protection. Its list, in Annex 1 of the Data Protection Ordinance, includes the EU and EEA states and the United Kingdom, among others. Elsewhere, disclosure needs safeguards such as standard contractual clauses recognised by the FDPIC, or one of the narrow exceptions in art. 17.

For the United States, the Federal Council recognised the Swiss-US Data Privacy Framework from 15 September 2024. Data may flow to US companies certified under it, listed on the Data Privacy Framework site run by the US Department of Commerce, without further safeguards. Transfers to US recipients that are not certified still need contractual clauses and an assessment of the risk in the destination country.

Who is liable

Unlike the GDPR, the nLPD mainly fines people, not the company. Its criminal provisions (art. 60 to 66) set fines of up to CHF 250,000 for the responsible individual who wilfully breaches certain duties, including the duty to inform, the rules on disclosure abroad, and the minimum data security requirements. The company pays only in a narrow case: under art. 64, when the fine would not exceed CHF 50,000 and finding the responsible person would take disproportionate effort. That places the question on the desks of the people who choose and sign with a provider.

Read how Pilae meets its processor obligations on nLPD compliance.

The GDPR, for Swiss organisations

The EU General Data Protection Regulation reaches beyond the EU. Under art. 3, it applies to an organisation outside the EU that offers goods or services to people in the EU or monitors their behaviour there. A Swiss university recruiting EU students, a federation with EU members or a firm with EU clients may fall under both regimes.

The parts that matter most for hosting are:

• Art. 28, which sets what a processor contract must contain.
• Art. 32, the security obligation, in terms close to art. 8 of the nLPD.
• Chapter V, the transfer rules. The European Commission has recognised Switzerland as adequate since its 2000 decision and confirmed it in 2024, so data flows from the EU to Switzerland without extra safeguards.
• Fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher, imposed on the organisation.

The EU-US Data Privacy Framework has survived a first challenge in the EU General Court, but its future depends on US executive commitments and on further litigation. Many European buyers treat it as a legal basis today and not as a guarantee for the life of a contract.

See GDPR compliance and our data processing agreement, which covers both regimes in one document.

The US CLOUD Act

The Clarifying Lawful Overseas Use of Data Act of 2018 (18 U.S.C. § 2713) allows US authorities, with a warrant or other legal process, to require providers of electronic communication and remote computing services under US jurisdiction to disclose data in their possession, custody or control, whether the data is stored in the United States or abroad. It sits alongside other US instruments, notably section 702 of the Foreign Intelligence Surveillance Act, which lets US intelligence agencies compel US communication providers to help target people outside the United States who are not US persons.

Three points are often misunderstood.

1. Control matters, not location. A US provider’s datacentre in Zurich does not take the data outside the Act. What counts is whether the provider, or a parent that controls it, is subject to US jurisdiction.
2. Challenges are narrow. The Act lets a provider move to quash an order that would breach the law of a country with an executive agreement with the United States, and courts can weigh comity more broadly. Switzerland has no such agreement. A challenge is a legal process, not a guarantee.
3. Every country has lawful access. Swiss prosecutors can order a Swiss provider to produce data, and foreign authorities can request it through international legal assistance, handled by the Swiss authorities under Swiss procedure and open to appeal. The difference is that you know which law applies and which courts decide.

A Swiss or European operator on European infrastructure removes the direct CLOUD Act route. It does not remove every US link: many providers use US services for email delivery, content delivery or error monitoring. A good provider names each one and explains what data it sees.

We set out Pilae’s position, including the US services in our data path and what they do not hold, on jurisdiction.

Residency versus sovereignty

Residency is a promise about where data sits. Sovereignty is a promise about who can reach it and whether you can leave.

Watch for residency claims that cover the primary database but not the backups, the logs, the search index or the support tooling. Ask where each copy lives.

For some organisations, residency alone meets the rules. For others, such as holders of professional secrecy under art. 321 of the Swiss Criminal Code, banks bound by art. 47 of the Banking Act, or public bodies under cantonal rules, jurisdiction and control weigh as much as location. Sector rules add their own layer, such as the outsourcing rules in FINMA’s circulars: see FINMA outsourcing and NIS2 and DORA.

Open source and the right to leave

A contract that promises your data back is only as good as your ability to use that data somewhere else. If the software exists only as the provider’s service, you get an export file and a rebuild project.

Open-source and source-available software changes the exit. The same application can run on another provider’s machines or on your own, so what moves is the deployment, not a conversion. Three details matter:

• The licence. Open-source licences such as AGPL-3.0 or Apache-2.0 let anyone run the software. Source-available licences, such as the Sustainable Use Licence, allow internal use but restrict offering the software to others as a service. Read the licence of each app and check that your provider’s use is permitted.
• The data format. Data in PostgreSQL, plain files and standard formats such as CSV, ICS and vCard moves easily. Proprietary exports do not.
• The operating knowledge. Configuration, backups and runbooks should be yours too, so another team can take over.

An exit plan written before signature, and tested once, turns a contractual promise into something you can rely on. See exit plans.

Questions to ask any provider

Put these to every shortlisted provider, and ask for the answer in the contract rather than in a sales deck.

Location

1. In which country is each machine, each backup copy and each log store? Is each location named in the contract?
2. Can data move to another country without our written agreement?
3. Can we run the same service on our own premises, or air-gapped?

Jurisdiction

4. Where is the provider incorporated, and is any parent company or controlling shareholder subject to US or other foreign jurisdiction?
5. Which sub-processors are used, what does each one do, where is it based, and which data does it see?
6. How are we notified before a sub-processor changes, and can we object?
7. Which law governs the contract, and which courts decide disputes?

Control

8. Who can log in to our systems, from where, and is every session recorded?
9. Who holds the encryption keys for data at rest and for backups?
10. How is a change approved and applied, and can we see the history?
11. How soon are we told of a breach, and what does the notice contain?

Security and continuity

12. How often are backups taken, where are they stored, and how often is a restore tested? Can we see the results?
13. What recovery point and recovery time are written into the contract?
14. Which security framework are the controls built to, and which certifications does the provider itself hold, as opposed to its datacentre operators?

Exit

15. Is the software open source or source-available, under which licence, and can we run it without the provider?
16. In what formats is our data returned at the end of the contract, and how quickly?
17. Is deletion confirmed in writing, including backups?
18. Has an exit ever been rehearsed?

A provider that answers these clearly, in writing, is one you can defend to an auditor.

How Pilae answers these questions

Pilae SA is a Swiss company in Lausanne with no US parent or subsidiary, and our contracts are governed by Swiss law, with the courts of Lausanne as the place of jurisdiction. We operate open-source and source-available apps on your premises, on dedicated machines in any of 12 Pilae Cloud regions, in a hybrid of both, or air-gapped. Six of the regions are in Switzerland and the EU, with Zurich the default for Swiss data; the other six, from London to Sydney, serve teams that need them. A workload placed in a US region is stored in the US and subject to US law on data held there. Your contract names the location of every machine and backup, and our data processing agreement gives you notice before any sub-processor change, with a right to object.

Every change is planned, approved by you, applied in your window and recorded by the Pilae Agent. Backups are daily, encrypted and stored offsite in the country you choose, with a restore test every month recorded in the console. At the end of a contract, your data is returned in open formats and then deleted, with written confirmation.

For the details, see data residency, jurisdiction and security. To go through your own requirements with an engineer, contact us.