The three questions

Where does the data reside?

Data residency is the simplest part: the region where data is stored and processed. Today you can keep data in Switzerland with the hyperscalers — AWS has a Zurich region, Microsoft Azure has Switzerland North and Switzerland West, Google Cloud has a Zurich region — and with Swiss providers such as Infomaniak, Exoscale or Swisscom. EU regions are an option when Swiss residency is not required.

Residency has to cover everything, not just the main database: backups, logs, monitoring data, search indexes, and copies made for support. Each managed service has its own rules about where its data goes; check them one by one.

Who holds the keys?

Encryption at rest is standard. What matters is who controls the keys:

  • Provider-managed keys protect against stolen disks, not against access through the provider.
  • Customer-managed keys in the provider's key management service give you control over use and rotation, and an audit trail.
  • Keys held outside the provider, in your own hardware security module or an external key manager, give the strongest separation, at the cost of more operational responsibility.

Choose the level per dataset, according to its sensitivity — not one answer for everything.

Which jurisdiction applies?

This is the question data residency alone does not answer. A provider headquartered in the United States remains subject to US law, including the CLOUD Act, which can require it to produce data under its control even when that data is stored abroad. Providers headquartered in Switzerland or the EU are subject to their own legal frameworks. The contract also matters: governing law, place of jurisdiction, and how the provider handles requests from authorities.

None of this makes global providers unusable. It means the risk has to be assessed and documented, and the most sensitive data may belong with a provider whose jurisdiction matches your obligations — or on your own infrastructure.

Choosing between Swiss, EU and global providers

Criterion Global hyperscaler, Swiss region Swiss or EU provider
Breadth of managed services Very wide Narrower, focused on core infrastructure
Jurisdiction of the provider Usually US parent company Swiss or EU
Ecosystem and skills on the market Very large Smaller
Fit for highly sensitive data Needs careful key management and risk assessment Often simpler to justify

Many companies end up with a mixed model: core business data and sensitive workloads with a Swiss provider or in a Swiss region under customer-held keys, and less sensitive workloads wherever the services are best. What matters is that the rule is explicit and written down for each application.

Sovereignty rules, written per application

For each application in scope, document:

  1. Data classes it handles and their sensitivity.
  2. Region for primary data, backups and logs.
  3. Key management level.
  4. Provider and sub-processors, with their jurisdiction and the contractual safeguards in place.
  5. Administrative access: who can access production, how, and how it is logged.
  6. Exit plan: how data and workloads would be moved if the provider had to be changed.

This document answers most audit and questionnaire questions directly, and it is the input to every later decision. It also maps naturally onto the obligations described in our checklist on nLPD and GDPR.

Portability is part of sovereignty

Sovereignty is also the ability to leave. Workloads packaged in containers, infrastructure described as code, and data in open formats keep switching costs under control. Proprietary managed services are not forbidden — they are often the most efficient choice — but each one should be a conscious decision, with a note on what an exit would cost.

Where to start

Start with an inventory: applications, data classes, current hosting, suppliers. Then write the sovereignty rules for one application and migrate it end to end, controls included. The first one sets the template for the rest. Our sovereign cloud and cybersecurity service follows exactly this sequence.