"GDPR-compliant" is not something a vendor can grant you
There is no GDPR certificate. No regulator hands out a "compliant" stamp. When a provider prints GDPR-compliant on its homepage, the badge means one thing: the provider believes it has done its part. Compliance is a property of your processing, as the controller — lawful basis, a real Article 28 contract, sub-processors you can actually see, and no unlawful transfer of personal data out of the EU. The badge tells you almost none of that. Here is what has to be true, and where the marketing pages go quiet.
You are the controller. The provider is a processor.
Put customer data into a cloud and you are the controller. The provider is your processor. Under Article 28 you may only use a processor that offers "sufficient guarantees" of appropriate technical and organisational measures, and you need a binding written contract — a Data Processing Agreement — before any personal data flows. The DPA is not boilerplate. It has to pin down the subject matter and duration of processing, the nature and purpose, the types of personal data and categories of data subjects, and the processor's duties on security, deletion, audit, and breach notification.
So the first question is blunt: do you offer a real DPA, and is it signable on my plan? Plenty of "GDPR-compliant" pages stop at the logo and bury the contract behind enterprise sales. If you can't get the DPA, the badge is decoration.
Sub-processor transparency: the part the badge never shows
Almost no provider runs alone on its own hardware. They use sub-processors: a hosting company, a CDN, an email service. Article 28(2) and 28(4) are strict — a processor can't bring in a sub-processor without your authorisation, must tell you about any intended change so you can object, and must bind that sub-processor to the same obligations. Your processor stays fully liable to you for whatever the sub-processor does.
The second test follows: is there a public, current sub-processor list with a notification mechanism for changes? Without it you can't assess third-country transfers and you can't meet your own accountability duty under Article 5(2). You'd be signing a DPA you can't enforce. A badge lists nothing. A serious provider lists everyone.
The transfer problem nobody on a US provider has solved
This is where most "EU region" marketing falls apart. After Schrems II in 2020, sending personal data to the US — or to any provider that US law can compel — requires protection "essentially equivalent" to the EU's. The EU-US Data Privacy Framework currently makes those transfers lawful for certified US companies, and in September 2025 the EU General Court dismissed the Latombe challenge to it. But it isn't settled: the case was appealed to the Court of Justice (C-703/25 P) on 31 October 2025, with no hearing scheduled as of mid-2026. Anyone who watched Safe Harbor and Privacy Shield get struck down knows how this can go.
The deeper issue isn't the framework's paper validity. It's the US CLOUD Act and FISA 702, which let US authorities compel a US company to hand over data regardless of where the servers physically sit. That stopped being theoretical on 10 June 2025, when Microsoft's French legal director told a Senate hearing, under oath, that he could not guarantee data stored in France would be shielded from US authorities — even under a "sovereign" offering. An EU data centre owned by a US parent doesn't remove the legal reach. It just relocates the disks.
Two design choices that actually shrink the problem
Once you see the transfer issue clearly, two structural decisions do more than any badge.
- EU incorporation with no US parent. If the company holding your data is European and has no US entity to serve with a CLOUD Act order, the conflict-of-laws problem mostly evaporates. The data sits under EU law and stays there.
- Client-side (zero-knowledge) encryption. If files are encrypted on your device with keys the provider never holds, then a lawful-access demand — wherever it lands — returns ciphertext. The provider can't decrypt what it can't read. Under GDPR's risk-based logic, encrypted data the controller itself can't access is a much smaller exposure, and a breach of it is far less likely to be reportable.
Neither is magic on its own. Encryption only protects the content that's actually encrypted client-side; filenames, account email, and billing data usually are not, so they still need a lawful basis and a DPA. Put them together, though, and EU jurisdiction plus client-side encryption is the strongest practical posture going — and one a US hyperscaler structurally can't match, however many compliance pages it ships.
Where Beebeeb stands, including what it doesn't do
Honesty first, because the brand runs on it. Beebeeb is operated by Initlabs B.V., a Dutch company (KvK 95157565), with data stored on dedicated servers in Falkenstein, Germany — an EU company on EU soil, no US parent in the chain. Every file is encrypted client-side with AES-256-GCM, keys derived from your passphrase via Argon2id and never sent to the server, on every tier including the free one. That's the full key-derivation and zero-knowledge architecture written out on our security page, not a tagline — and the product clients are open source, so the encryption is something you can read rather than take on faith.
What Beebeeb does not have yet: an independent security audit. One is planned, and the findings will be published — we won't use the word "audited" until that's true. We don't hold documented HIPAA, ISO 27001, or TISAX certificates today. If your procurement process demands those right now, our honest Beebeeb-vs-Tresorit comparison says so plainly. Tresorit is a closed-source Swiss provider (owned by Swiss Post) with a mature, well-documented compliance stack and genuinely zero-knowledge encryption; it now offers a small free tier and 14-day trials on paid plans, and it's a fair pick when a certificate on file is a hard requirement. The trade-off is verifiability. A compliance certificate is an attestation someone else signed; open-source clients let you check the crypto yourself.
A buyer's checklist that ignores the badge
Before you trust any "GDPR-compliant" cloud, get these answers in writing:
- Is there a signable DPA for my actual plan, covering the Article 28 essentials?
- Is there a public, current sub-processor list with change notifications?
- Who legally controls the company, and can any entity in the chain be compelled under US law?
- Is data encrypted client-side, and if so, which fields are not?
- What's the documented breach-notification process and the deletion behaviour?
A logo in the footer answers none of them. If you want to feel the difference before any contract is on the table, Compliance is yours to demonstrate as the controller. Pick the provider that makes that easier to prove, not the one with the most badges.