Data residency describes where data is stored or processed. A Swiss server does not establish the location of backups, support systems, external integrations or every person with access; assess those components separately.
Separate the machine location from the data journey
A country label on a hosting plan answers a narrow question: where the listed configuration is located. Your application can still send information elsewhere. Error reporting, email delivery, payment processing, off-site backups and administrator access are part of the service even when they are absent from the infrastructure diagram. Treat the Swiss destination as one entry in a data map, rather than a conclusion about the complete project.
Begin by naming the information you handle. A public documentation site, a customer portal and a private archive need different controls. Distinguish published content, personal information, authentication secrets and internal operational records. Record why each category exists and what would happen if it were disclosed, altered or lost. This makes later location decisions concrete instead of relying on the general appeal of a jurisdiction.
Build a small processing register
Follow one representative user action from the browser to storage. Note which system receives the request, what it writes and which other services are notified. Repeat the exercise for account creation, password recovery, uploads and support. You will often discover secondary copies in logs, email queues and diagnostic exports. Record these while the architecture is still simple enough to change.
Use a register with a purpose, destination, access owner and retention decision for each component. You do not need an elaborate compliance tool to start. The useful property is that someone can explain every row and update it after a new integration. A diagram without backup locations or administrative access is incomplete for a residency decision.
| Component | What to establish | Useful evidence |
|---|---|---|
| Primary database | Hosting location and permitted access | Service specification and access policy |
| Recovery copy | Destination, retention and deletion | Backup configuration and restore procedure |
| Support export | Content and recipients | Redacted sample and support policy |
| External integration | Information sent and processing terms | Integration configuration and provider documentation |
Understand the responsibility that remains with you
The Swiss Federal Data Protection and Information Commissioner explains that outsourcing processing does not remove the controller's responsibility for data protection. Its guidance covers selecting processors, issuing instructions and checking the handling of personal data. This is a reason to inspect the service relationship as well as the rack location. The exact obligations for your organisation depend on the applicable framework and the information involved.
Where information may be disclosed across borders, use the relevant official guidance and obtain advice for decisions that need a legal assessment. Avoid declaring that a country name automatically makes the application compliant. Ask who the processors and sub-processors are, where processing occurs and what arrangements apply. Keep the answers with the project's operational documentation so the decision can be reviewed later.
Reduce the information that needs a location decision
Collect only what serves a defined purpose. A newsletter does not necessarily need a full postal address, and a troubleshooting report rarely needs an entire customer database. Removing unnecessary fields reduces exposure and simplifies retention. Keep secrets out of diagnostic tools, and consider whether aggregate measurements answer the operational question without reproducing individual records.
Encryption can help protect particular copies, but identify who controls the keys and where decryption occurs. An application that must process readable data cannot be treated as if nobody can ever access it. Likewise, a pseudonymous identifier may still link records over time. Describe the implemented control precisely instead of using an encryption badge as a substitute for the processing map.
A practical scenario: a small customer portal
Imagine a portal hosted on a Swiss VPS, with an independent recovery copy and a third-party email service. The customer database stays on the VPS during normal operation, but password-reset messages and support notifications leave that machine. The team should record the minimum fields in those messages, the destination used for backups and the people allowed to export records.
A sensible review might replace a full record in an error report with a random incident reference, shorten diagnostic retention and restrict backup access. These changes are useful regardless of the selected country. The example is a planning exercise, not a statement that SwissOctet includes these integrations or has verified a particular residency arrangement.
Verify the map before making a public commitment
Before promising a location to your users, compare the register with actual configuration and confirmed service terms. Test whether backup and deletion procedures work as expected. Review exports, monitoring agents and scheduled jobs, because they can introduce copies that nobody remembers during the initial purchase. Assign someone to approve new destinations and update the register when the architecture changes.
SwissOctet presents Swiss configurations in its catalogue. The live operator's processing arrangements, support access and retention rules must be confirmed separately before a real order. Choose the infrastructure with that boundary in view: a clear Swiss location can support your architecture, while a complete and maintained data map supports the claims you make about it.
Your practical checklist.
- Classify the information handled by the project.
- Map primary storage, backups, logs and integrations.
- Identify processors, access owners and retention decisions.
- Review official guidance for applicable cross-border questions.
- Verify actual configuration before promising residency.
The details that matter.
Does a Swiss server mean every copy stays in Switzerland?+
No. Backup destinations, exports, support systems and integrations have their own data paths and must be checked separately.
Does encryption remove the need to map processing?+
No. You still need to know where data and keys exist, who can decrypt it and what processing takes place.
Does this guide certify a SwissOctet deployment?+
No. It provides a planning method. Live processing terms and implemented controls need confirmation for the specific service.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- FDPIC: Data processing in the cloud www.edoeb.admin.ch
- FDPIC: Outsourcing of data processing www.edoeb.admin.ch
- FDPIC: Cross-border transfer of personal data www.edoeb.admin.ch
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.