A provider that prints "GDPR compliant" on its homepage has told you nothing. GDPR is a regulation, not a certification. There is no badge to earn and no registry to check. Compliance lives in the contract, the architecture, and the jurisdiction — and you verify it there before you sign. Here is the due-diligence list we'd want a buyer to hold us to.
1. A real Article 28 DPA, with the annexes filled in
If a provider stores personal data on your behalf, you are the controller and they are the processor. Article 28 says that relationship needs a binding written contract: a Data Processing Agreement. No DPA, no lawful processing. A missing or invalid one is itself a violation, fineable up to €10 million or 2% of global turnover.
Article 28(3) lists the processor obligations a DPA must cover — documented instructions, staff confidentiality, Article 32 security, sub-processor controls, help with data-subject requests and breach notification, deletion or return at the end, and support for audits. Most providers paste these in cleanly. The failure mode is the annexes. A DPA with an empty Annex 1 (what's processed), Annex 2 (the actual security measures) and Annex 3 (the sub-processor list) is a template, not a contract. Ask to see them populated before you commit.
2. The data physically lives in the EEA, and they can name the city
"EU region available" is not the same as "your data only ever sits in the EEA." Ask where the bytes rest, where backups go, and where support staff reach them from. A provider that can name one location is more trustworthy than one waving at a continent. Our answer is Falkenstein, Germany: a single place under German jurisdiction, not a rotating set of "EU regions" with US failover.
This matters because the moment data crosses to a third country, you inherit Chapter V. You need an adequacy decision or Standard Contractual Clauses plus a transfer impact assessment — the Schrems II homework. The EU recognises adequacy for a short list of countries (Switzerland, Canada, Argentina, New Zealand and a handful more), and the US arrangement remains contested in court. Keeping storage inside the EEA isn't a feature. It's how you delete that entire category of work.
3. No third-country transfer hiding in the sub-processor list
You can host in Frankfurt and still leak data to a US parent through a CDN, an analytics SDK or a support tool. Read Annex 3. If an "EU-hosted" provider's sub-processors include a US-incorporated entity with access to plaintext, your data is reachable under the CLOUD Act and FISA 702 no matter where the disk spins. The structural fix is jurisdiction: an EU company with no US parent that can be compelled. We're operated by Initlabs B.V., a Dutch entity (KvK 95157565), for exactly that reason.
How does end-to-end encryption change who's the controller?
This is where the honest answer parts ways with the marketing one. With zero-knowledge storage the provider holds only ciphertext. Your keys are derived on your device and never sent — ours stretch your password with Argon2id, derive a per-file key with HKDF, encrypt file contents with AES-256-GCM, and use X25519 for sharing. The server cannot read your files. That holds on every tier;
The legal consequence is subtle. We remain a processor of the personal data your files contain. We just can't see it. That genuinely shrinks the Annex 2 security-measures picture: a breach of our storage exposes unreadable blobs, not your documents. But it does not erase our processor status, and metadata — file sizes, timestamps, account email — is still personal data we process and protect. Any provider claiming E2E makes GDPR "not apply to them" is wrong, and you should read that as a red flag. The right framing, which we keep on our security page, is that encryption changes the blast radius, not the regulation.
4. Erasure that works, backups included, with the how spelled out
Article 17 erasure is where providers quietly fail. In February 2026 the EDPB published its Coordinated Enforcement report on the right to erasure, drawn from 764 controllers, and backup deletion was among the most common weak spots: no procedure, or a vague "it'll cycle out eventually" with no documented rationale. Half the responding regulators raised it, and several expressly asked the EDPB for guidance on erasure in backups.
The standard they actually apply isn't "the impossible." It's a documented, reasoned, proportionate approach to erasing data from backups too — and honest communication of it. So ask directly: when I delete a file, what happens to it in your backups, and on what timeline? A provider that answers with a retention schedule passes. One that says "deleted means deleted" with no detail probably hasn't thought about backups at all. Zero-knowledge helps in an odd way — a leftover ciphertext backup with the keys destroyed is functionally erased, because no one can decrypt it.
5. Article 20 portability that's real, not a PDF export
Data portability means getting your data out in a structured, commonly used, machine-readable format. For file storage that should mean your actual files, in their original formats, downloadable in bulk — not a vendor-locked container you can only open inside their app. Test it before you depend on it: can one person export everything in an afternoon? With us, the available feature set covers the web app and the bb CLI, so a scripted bulk pull is a one-liner. Open-source product clients matter here too: when the export code is public, "you can leave" is checkable rather than a promise.
6. Your exit is a legal right now, not a favour
The EU Data Act moved cloud exit from goodwill to statute. Its switching provisions have applied since 12 September 2025, and the screw tightens on a date worth writing down: from 12 January 2027, providers may charge no switching fees at all against EU customers. Until then they can bill only the direct cost of the switch. Egress walls and punitive migration fees, the classic lock-in moves, become illegal.
So a 2026-current checklist item is blunt: does the contract already reflect this? A provider still writing lock-in clauses into 2026 agreements is either not paying attention or betting you aren't. Ask what the documented exit process is, how long a full migration takes, and whether there's a fee. The answer should be boring.
The checklist, condensed
| Check | What "pass" looks like |
|---|---|
| Article 28 DPA | Signed, with Annex 1/2/3 actually populated |
| Data residency | A named EEA city, not a vague region |
| Third-country transfer | No US-reachable sub-processor with plaintext access |
| Encryption posture | Client-side keys; provider holds ciphertext |
| Erasure incl. backups | A documented retention and deletion schedule |
| Art. 20 portability | Bulk export in original formats, scriptable |
| Data Act exit | No switching fees; documented migration path |
One caveat in our favour and against it: the shipped clients today are the web app and the bb CLI. Native desktop and mobile clients, and cloud-import from Drive and Dropbox, are coming soon, not live. We'd rather you check that than take our word — If a provider can't survive seven concrete checks, the homepage badge was never going to save you.