Professional secrecy and the cloud: lawyers, tax advisors, doctors

A lawyer, a tax advisor and a doctor share a problem that most companies do not have. Their clients’ secrets are protected by criminal law, not only by data protection law. In Germany that is section 203 of the Criminal Code, with professional rules on top: section 43e of the Federal Lawyers’ Act, section 62a of the Tax Advisory Act, the medical professional codes. Comparable duties exist in Austria, Switzerland and the Netherlands. The question every one of these professions has asked since the first cloud drive is the same: may I put this in a system run by someone else?

This article walks through that question for an end-to-end encrypted product. It is written for the person in the practice who has to decide, and for the chamber or data protection officer they will ask. It is not legal advice. Where we describe a legal position we say whose it is, and the decision stays with you and your professional body.

What the law actually asks

Section 203 punishes the disclosure of a secret entrusted in a professional capacity. Since the 2017 reform it also says, in plain terms, that a professional may involve other people and organisations in their work and may disclose secrets to them, as far as that is necessary for using their services. The reform was written with IT service providers in mind. It attaches two conditions: the professional must obligate the helper to secrecy, and the helper is themselves punishable if they disclose what they learn.

The professional rules add the familiar diligence duties: choose the provider carefully, agree the obligation to secrecy in writing, instruct them, and, if the provider sits outside the EU, make sure the secrecy protection there is comparable. Data protection law runs in parallel. Client files routinely contain special categories under Article 9 of the GDPR, health data above all, and Article 32 asks for security that reflects the state of the art, encryption named explicitly.

So the test for any cloud product has three parts. Does the provider learn secrets at all? If yes, is that necessary, and is the provider bound? And does the arrangement satisfy the GDPR on top? End-to-end encryption changes the answer to the first part, and that changes the weight of everything after it.

What changes when the provider cannot read

In Sapherbox every document is encrypted on your device with a key your device holds. The server receives ciphertext and keys that are sealed to your identity and to the identities you have shared with. It cannot open either. That is a design, not a policy: there is no admin mode, no support tool and no court order that turns our access to the storage into access to the content. Password reset works without a provider-held key for the same reason.

That gives you a simple test for any product that claims to be suitable for professional secrecy holders. Ask what happens when a user forgets their password. If an administrator can reset it and the user gets their files back without entering a recovery code or a key that your organisation holds, then a key that opens those files exists outside the user’s control, and in practice it sits with the provider. Whatever the marketing says:

That is a disclosure in the sense of section 203.

The responsibility for it is yours, not the provider’s: section 203 is addressed to the professional who puts the file into such a system. A product that passes the test will make the reset slightly less convenient: the user needs their recovery code, or your administrator needs a customer-managed escrow key that was generated and kept on your side. That inconvenience is the evidence.

For the section 203 test this matters because disclosure means giving someone the possibility to take notice of a secret. The explanatory memorandum to the 2017 reform and the prevailing view in the commentaries take the position that where data is encrypted in a way that leaves the service provider no possibility of taking notice, the content is not disclosed to that provider in the sense of the statute. On that reading, the documents themselves never enter the “necessary disclosure” question at all, and the provider is a helper who moves and stores sealed envelopes.

We state this carefully for two reasons. First, it is a legal reading, and your chamber may hold a stricter one. Second, it covers the documents and their names, which Sapherbox encrypts, but not everything.

What the provider still sees

Honesty requires the next step too. A server that cannot read documents still operates a system, and operating it leaves traces. We publish the full list in What our servers can and cannot see. For a professional secrecy holder the relevant items are these:

Who uses the system. Accounts have e-mail addresses. If you invite a client as a guest so that they can upload or read their own file, the client’s address is visible to the server. For a lawyer, the existence of a mandate can itself be a secret. For a doctor, the fact that a person is a patient is health data under Article 9.
Who shares with whom. The server knows that folder X is shared with guest Y, not what is in it or what it is called.
Shapes and times. Sizes, upload times, the number of files in a folder, which device type connected.

None of this is content. All of it can, in a specific case, reveal a secret. That is why the paperwork does not disappear with encryption. It shrinks. The obligation to secrecy, the written agreement and the careful choice of provider still cover the metadata, and in our case they are satisfied by the data processing agreement, which names us as processor, lists what we process, and binds our people. What you no longer have to argue is that handing over the file itself was necessary. The file is never handed over in readable form.

Three practical reductions follow. Use a neutral address for sensitive guests where the relationship itself is confidential. Keep client names out of folder names only if you want to; folder names are encrypted anyway, and we built that for exactly this reason. And treat the audit log as what it is: evidence of access events, written by the server, with the file identities masked.

Where the files live

Sapherbox tenants run on servers in Germany, and the default storage bucket sits in Frankfurt. A practice that wants its own storage can bring its own bucket, including a bucket at a German provider under its own contract, and the tenant stores ciphertext there without ever seeing a key. Both options keep the data in the EU, which answers the “comparable protection” clause of the professional rules without an adequacy argument.

Hosting location is often treated as the whole answer to the secrecy question. It is not. A server in Frankfurt that can read your files is a disclosure in Frankfurt. The location answers the question of which law applies to the helper; the encryption answers the question of what the helper can learn. You want both.

The client side of the practice

Most secrecy breaches in practice do not happen in a data centre. They happen on the way in and out: a scan e-mailed unencrypted, a USB stick, a shared link that lived too long. The features that matter day to day are therefore the ones at the edges.

Receiving documents from clients. An upload link lets a client put files into a folder of yours without an account. The browser encrypts to the folder’s key before upload, so the file is sealed from the first byte and the client’s device never sees anyone else’s content.
Giving a client their own documents. A guest account with Viewer or Uploader rights on one folder, nothing else. When the matter ends, removing the guest removes their key, and the access report shows an empty row.
Working with an external colleague. Counsel, an expert, a second physician: a share to a named person, limited to a folder, visible in the access reports your supervisor or chamber auditor may ask to see.
Documents that must not survive the matter. Folder expiry and scheduled deletion put a closing date on a matter folder; the deletion article explains what happens to backups and how long a trace remains.
Incoming files you do not trust. Content disarm removes active content from Office and PDF files on your device before they are encrypted. A practice receives attachments from strangers all day; this is the control for that.
Finding the file you must not have. Classification runs on your device before upload and can flag patterns you define, such as a social security number or a diagnosis code, so that a document lands in the right folder with the right label.

What Sapherbox does not do is the practice’s own job on its own devices. Section 203 does not stop at the cloud boundary. A laptop without disk encryption, a shared login, a synchronised folder on a family computer: these are disclosures too, and no server design prevents them. Our desktop sync client keeps files encrypted on disk until they are opened, but the device, its lock screen and its users are yours.

AI in the practice

Summarising a file, translating a contract, drafting a letter from a judgment: the pull toward AI tools in professional practice is strong, and sending a client file to a hosted model is a disclosure in the plainest sense, to a provider who may use it for training. Sapherbox offers AI that runs on your device, in the browser, with no network call. For the secrecy analysis that is the same category as the spell checker. It is also, deliberately, limited to what a device can run. For anything larger the question returns, and the answer is the same as for any other provider: necessary, bound, documented.

A checklist for the chamber

If you take this article to your professional body or data protection officer, these are the points they will want to see, and where each is documented.

Content and names are encrypted on the device; the provider holds no key. Security overview and the threat model.
No provider recovery key; reset uses a code or an escrow key you hold. Password reset article.
What the provider sees, in a list. What our servers can and cannot see.
Processor contract with obligation to secrecy, sub-processor list, EU hosting. Data processing agreement, provided on request; the sub-processor list names the hosting provider and the storage provider, and names on-device AI as not being one.
Access evidence. Tamper-evident audit log and the access reports, exportable as CSV.
Deletion and retention timeline. Deletion and recovery.
Backups cannot be read or deleted by a compromised server. Encrypted to an offline key, written to a locked bucket.

What this does not settle

Two things remain open, and we would rather say so than let a reviewer find out.

The legal reading that encrypted data is not disclosed to the provider is the prevailing one, not a settled court position for every profession in every country. A chamber may require the full helper treatment regardless. Our data processing agreement therefore contains the clause a chamber expects: we act as a cooperating person under section 203(3), we and our sub-processors are obligated to secrecy and instructed about the criminal liability, and disclosure is limited to the necessary. You can give it to them either way.

And metadata is not nothing. If your practice’s secret is the identity of its clients rather than the content of their files, think about guest addresses and invitation e-mails before you invite the first client, and ask us about the options. We would rather have that conversation before the first mandate than after.

Questions?

If you are a lawyer, tax advisor, auditor or physician and want to put this article in front of your chamber, write to hello@sapherbox.com. We will send the data processing agreement, the security overview and answers to the questions your profession asks.