You are the controller. The liability is yours.
A patient file, a client's divorce papers, a company's unfiled tax return. Under the GDPR, the professional who collects that data is the data controller. Your cloud provider is a processor acting on your written instructions. That distinction decides who is liable when something goes wrong, and the answer is almost always you. A "GDPR-compliant" badge on the vendor's marketing page does not move the obligation off your desk. If a foreign authority can reach your processor, your client's data is exposed and the regulator's letter arrives at your address, not theirs.
This is the part most provider pages skip. Clinics, law firms and accounting practices handle the most sensitive data the regulation recognises, under confidentiality duties that predate the GDPR and sit on top of it. Here is what a defensible setup actually requires, and which parts no vendor can do for you.
Special-category data raises the bar
Health records fall under Article 9: special-category data, processable only on narrow grounds, one being that the handler is bound by professional secrecy. A GP, a psychologist, a pharmacist already meets that condition by law. But Article 9 lifts the standard for everything downstream. Your technical and organisational measures have to match the heightened risk, and a Data Protection Impact Assessment is effectively expected before special-category data goes into a new system.
Law firms and accountants are not always touching Article 9 data, but legal professional privilege and the accountant's duty of confidence are their own statutory regimes. A breach of your cloud provider is simultaneously a GDPR incident and a breach of professional secrecy. Two regimes, one disclosure event, both pointing back at you.
Why "EU region" on a US provider does not clear it
The instinct is to take Microsoft 365 or Google Workspace, tick the data-residency box, point at a Frankfurt datacentre, and call it sovereign. It is not, and a Microsoft executive said so under oath. On 10 June 2025, before a French Senate committee, Microsoft France's director of public and legal affairs, Anton Carniaux, was asked whether he could guarantee that French citizens' data in Microsoft's cloud would never be handed to US authorities without French approval. His answer: "Non, je ne peux pas le garantir." No, I cannot guarantee that.
The mechanism is the US CLOUD Act, which compels US-incorporated companies to produce data regardless of where the servers physically sit. A datacentre in Germany run by a company answerable to a US court is reachable by that court. Residency is a map pin. Jurisdiction is who can compel disclosure. They are not the same thing, and only the second one protects your client. We go through the full chain in how Beebeeb handles the jurisdiction problem.
Where Schrems II leaves you in 2026
If your processor is US-owned, your transfers ride on the EU-US Data Privacy Framework. As of mid-2026 the DPF is valid law: the EU General Court dismissed the Latombe challenge on 3 September 2025. But it is not settled. Latombe has appealed to the Court of Justice (Case C-703/25 P), accepted and pending with no hearing date, and a third consecutive invalidation of a transatlantic transfer mechanism is a live possibility, not a tail risk. Worse for the framework's plumbing: the US body meant to police its safeguards, the Privacy and Civil Liberties Oversight Board, was stripped to a single member in early 2025 and lost its quorum. The EDPB and the Commission have both flagged that it can no longer perform the reviews the framework assumes.
For a practice, that nets out to a legal basis you cannot audit, watched by an oversight body that cannot meet, that an appeal could strike down. If your client confidentiality rests on it, your Transfer Impact Assessment is carrying a heavy load. The cleanest TIA is the one you never have to write, because there is no third-country transfer at all.
What a defensible setup actually looks like
Strip the marketing away and a compliant arrangement for a regulated professional reduces to a handful of things you can verify:
- A processor incorporated in the EEA, not merely hosting there. The entity that can be subpoenaed should be subject to EU law. Beebeeb is operated by Initlabs B.V., a Dutch company (KvK 95157565), with data stored in Falkenstein, Germany. No US parent, no US court with standing.
- A signed Article 28 Data Processing Agreement. The GDPR requires the controller-processor relationship in writing, covering subject matter, duration, sub-processor rules, breach notification, deletion. It is not optional paperwork; it is the document a regulator asks for first.
- A published sub-processor list with a right to object. Every downstream party that touches data has to be disclosed, and you must be able to push back when it changes.
- Client-side encryption, so the processor only ever holds ciphertext. This is the strongest measure on the list because it removes the trust question. If the provider never has the keys, a CLOUD Act order yields encrypted blobs, not readable case files.
That last point is the one that flips the problem. With ordinary "encrypted at rest" storage, the provider holds the keys and can be compelled to decrypt. With end-to-end encryption the way Beebeeb implements it, your files are sealed with AES-256-GCM on your own device before they leave it, under keys derived from your passphrase with Argon2id. The server stores what it cannot open. A subpoena can still reach account metadata (who you are, when you logged in) but not the contents of a patient's history.
The obligations the provider cannot do for you
Picking the right processor is necessary, not sufficient. Two duties stay with you personally, and no architecture removes them.
Erasure (Article 17). When a client invokes the right to be forgotten, you have to delete their data and confirm it is gone, including from old versions and backups, within your retention limits. Map where each client's files live before the request arrives, not after.
Portability (Article 20). A client can demand their data in a structured, machine-readable format. A system you cannot cleanly export from becomes your compliance problem, not the vendor's.
One tradeoff deserves an honest mention. Genuine zero-knowledge means the provider cannot reset your password, because it never held your keys. Recovery runs through a BIP39 phrase you control. That is a strength for confidentiality and a duty for you: lose both the passphrase and the phrase and the data is gone, for everyone, us included. For a practice, recovery-phrase custody belongs in your continuity plan next to the client files themselves.
Six questions before you sign
- Who legally owns the processor, and which courts can compel it? Not where the servers are.
- Will they sign an Article 28 DPA specific to your use, not a generic template?
- Is the sub-processor list published, with a right to object to changes?
- Who holds the encryption keys, them or only you?
- Can you fulfil erasure and portability requests inside the system, without manual heroics?
- Is the claim checkable (open-source clients, a named city) or is it "trust us"?
Beebeeb is built to answer those the boring, verifiable way: EEA incorporation, an Article 28 DPA, data in a named city, open-source clients, and zero-knowledge encryption on every tier including the free one. An independent security audit is planned and the findings will be published. We would rather write "planned" than imply "audited." If you want to test the setup against your own intake workflow before any client data moves, the 14-day free trial is zero-knowledge by default, with paid plans from €1.99/month for 100 GB.
None of this makes compliance a checkbox. But for a clinic, a firm or a practice, the cheapest route to a defensible answer is to delete the hard question entirely: keep the data where no foreign court can reach it, held by a provider that could not read it even if it wanted to.