Swiss professional secrecy under Art. 321 of the Criminal Code covers specific professions, among them lawyers, doctors, pharmacists, notaries and statutory auditors under the Code of Obligations, together with their auxiliary persons. A fiduciary not acting as a statutory auditor generally does not fall under it, but is bound by contractual confidentiality and data protection law. Cloud outsourcing is possible in principle if the provider is engaged as an auxiliary person and confidentiality is secured contractually, technically and organisationally. Eight points need checking: legal basis, storage location, encryption and key control, access and support, logging, sub-processors, termination and return, incident handling and notification duties. Commonly overlooked is the firm’s own website, where contact forms and uploads route personal data into a CMS database with a publicly reachable login.
The question almost always arrives in the same form: “are we even allowed to put this in the cloud?”
It is posed too coarsely, which is why it gets coarse answers. Usually either “no, absolutely not” or “sure, everyone does”. Both are wrong, and the second is more expensive.
Who is actually covered
Art. 321 of the Swiss Criminal Code makes breaching professional secrecy an offence. The provision lists the professions exhaustively. Among them are lawyers, defence counsel, notaries, doctors, dentists, pharmacists, midwives, psychologists and statutory auditors under the Code of Obligations. Their auxiliary persons are expressly included.
What follows from that is regularly confused:
A lawyer is subject to professional secrecy, and additionally to bar rules and supervision.
A fiduciary is not automatically subject to it. They fall under it insofar as they act as a statutory auditor. Doing bookkeeping and tax returns, they are as a rule not covered by Art. 321 SCC, but bound by contract, by data protection law, and depending on the activity by further specific legislation.
The difference concerns criminal liability, not care. Anyone protecting client data badly has a problem even without Art. 321 SCC: contractually, in supervision, and at the latest when trust goes.
And as with everything here: this describes a framework so that the technical discussion starts in the right place. It is not legal advice.
The auxiliary-person rule is the key
The decisive point for the cloud is that the law anticipates auxiliary persons. A holder of professional secrecy may use auxiliary persons, who are then themselves bound by the secrecy.
A cloud provider or an IT service provider can be engaged as such an auxiliary person. That is the route by which outsourcing becomes permissible at all. But it is not automatic; it is a construction that has to be carried:
- contractually, with an express confidentiality obligation,
- technically, so that access to content is not incidentally possible,
- organisationally, with documented roles and logs.
Whoever has only the first has a piece of paper. Whoever has only the second has a configuration. All three are needed.
Eight points to settle before outsourcing
- Legal basis and role. Is the provider engaged as an auxiliary person, with an express confidentiality clause? Is there a data processing agreement?
- Storage location. Where do data and backups sit? What exactly does a “Switzerland” promise cover, and what not? The seven points on data residency belong answered here.
- Encryption and key control. Encrypted in transit and at rest is the minimum. The more interesting question is who holds the keys and whether the provider can decrypt without you.
- Access and support. Who can see content in operations? Does it require an approval? Is every access logged, and do you see that log?
- Logging. Who accessed what and when, in your own system. Without that trail you cannot say what happened in an incident, and that is precisely what you will be asked.
- Sub-processors. Which further services are attached? A mail sender, a search service, a chat tool. Each is another place content passes through.
- Termination. How do you get out again, in what format, within what period, and when is the data actually deleted at the provider?
- Incident. Who decides what during an incident, in what order is who informed, and does a notification duty apply? The revised Swiss data protection act requires notifying the Federal Data Protection Commissioner where a breach of data security entails a high risk.
These eight points are not a form for the provider, they are a basis for your own decision. Whoever has them in writing can show them to a client. Whoever does not has had a conversation.
The part almost everyone forgets
In practice the practice-management software is examined carefully. Servers, encryption, access concept, all documented.
And next to it stands a website with a contact form.
Personal data arrives through that form: names, matters, sometimes amounts, sometimes documents. In a typical WordPress installation those submissions land in the database on a rented server, often in a plugin whose version is visible from outside, behind a login page open on the internet.
That is rarely deliberate. It happens because the website counts as marketing rather than as data processing. The attacker does not make that distinction.
Three questions worth asking here:
- What arrives through the site, and where is it stored? If form submissions sit in a CMS database, that database is part of your data processing, with everything that entails.
- Who could log in? If the login name is publicly retrievable, which happens with WordPress more often than people think, an attacker is only missing the password.
- Does the site need a database at all? For a law or fiduciary firm’s website the answer is almost always no. A statically served site with a form that delivers straight into a secured mailbox has no database, no login and no plugin that can go stale.
That is the point where a legal question becomes an architectural one. And it is the cheapest place to start, because usually the least depends on it.
What I recommend
Classify first, then check. Establish whether Art. 321 SCC applies at all, or whether this is about contractual confidentiality and data protection law. That changes the requirements considerably.
Answer the eight points in writing, once, properly, together with the provider. After that it is a document you update rather than a discussion you repeat.
And put the website in the same field of view as the specialist application. It is the only part of the system that everyone on the internet can reach.
Frequently asked questions
Does a Swiss fiduciary fall under professional secrecy in Art. 321 SCC?
Not automatically. Art. 321 of the Swiss Criminal Code lists specific professions, among them lawyers, doctors, pharmacists, notaries and statutory auditors under the Code of Obligations, together with their auxiliary persons. A fiduciary not acting as a statutory auditor generally does not fall under it, but is still bound to confidentiality by contract and by data protection law. The difference concerns criminal liability, not the duty of care. This is not legal advice.
May a Swiss lawyer store client data in the cloud?
In principle yes, if the provider is engaged as an auxiliary person and confidentiality is secured contractually, technically and organisationally. What matters is access restriction, encryption, logging, regulated sub-processors, and the question of who in support can actually see content. Bar association rules and supervisory practice may add requirements.
What has to be checked before outsourcing under professional secrecy?
Eight points: the legal basis and engagement as an auxiliary person, where the data is stored, encryption and key control, the access and support concept, logging, sub-processors, termination and data return, and the incident case including notification duties. All of it belongs in writing, not in a conversation.
Why is the firm’s own website part of this?
Because personal data often arrives through it unnoticed: contact forms, file uploads, appointment bookings, call-back requests. That data frequently lands in a CMS database on a rented server whose login is publicly reachable. Protecting client data carefully in the practice software while collecting it unprotected through the contact form leaves the chain open at its weakest link.