Short answer: a file transfer is GDPR compliant for your use only if the service signs a data processing agreement with you, keeps the files with a company and in a country whose law you can live with, and deletes them on a schedule you chose. Encryption matters, but it is rarely the gap. The gap is usually that nobody wrote anything down.
The six-point checklist
Hold any service to these six. Each is explained further down.
- A data processing agreement you can sign. You are the controller; the service is your processor. Without a DPA you cannot lawfully use it for personal data.
- Files stored in the EU, by a company under EU law. Where the servers are and who owns them are two different questions. Ask both.
- Who holds the encryption keys. Encrypted at rest is the minimum; know whether the provider can open the files.
- Deletion you control, with a date. Expiry you set, and the ability to delete or revoke a link after sending.
- Sub-processors listed by name. The companies that touch your data on the processor's behalf, in writing.
- No exposure to US government access. A US-owned provider, or a US-owned sub-processor, can be compelled under US law wherever the data sits.
How four services answer it
From each company's own pages, checked on 13 October 2026. Where a page did not say, the table says so rather than guessing.
| WeTransfer | Dropbox | SwissTransfer | Yungle | |
|---|---|---|---|---|
| Company | Dutch, based in the EU (source) | Dropbox International Unlimited Company (Ireland) for customers outside North America; parent in the US (source) | Infomaniak, Swiss (source) | Dutch business (about) |
| Where files are stored | AWS servers in Ireland for uploads from Europe | "May transfer … and store Customer Data in locations other than Customer's country" | Only in Switzerland, in Infomaniak's own data centres | Hetzner, Germany (security) |
| DPA | On paid business plans | Part of the Business Agreement, for personal data | Not mentioned on the SwissTransfer page | Published, for every account (DPA) |
| US-owned company in the chain | Yes: AWS stores the files | Yes: Dropbox's parent | Not on the pages checked | No: files and backups stay with Hetzner, a German company, in Germany and Finland |
No row is a verdict on its own. A Dutch company storing in Ireland on AWS and a Swiss company storing in Switzerland can both be the right choice; what matters is that you know which you picked, and have the DPA in hand.
This is a practical guide, not legal advice. If you handle health data, children's data or anything at scale, talk to someone qualified.
The rule people get wrong first
The GDPR does not say "files must stay in the EU". It says personal data may leave the EU only where an adequate level of protection is ensured. Those are different rules, and mixing them up causes both over-engineering and real mistakes.
What it does require, in the shape it actually bites for sending files:
- A lawful basis for processing the data at all. For client work this is usually contract or legitimate interests, and it is rarely the hard part.
- A written agreement with your processor. You are the controller; the service storing the bytes is a processor. That relationship needs a data processing agreement. It is not optional, and it is the piece most often missing.
- No longer than necessary. Storage limitation is a principle in its own right. "We kept everything because storage is cheap" is a plain failure of it.
- Knowing where the data is, and who else touches it — your processor's sub-processors included.
- Appropriate protection: encryption in transit and at rest, access control, and the ability to take access back.
Controller and processor, in one paragraph
You decide what happens to the data, so you are the controller. The service that stores the bytes on your instruction is the processor. If a client hands you their customers' photographs to edit, they are the controller, you are their processor, and your transfer service is a sub-processor. Obligations flow down that chain: your client's requirements become yours, and yours become requirements on whatever you use.
What a DPA actually has to contain
Not "we are GDPR compliant" on a marketing page. A real agreement covering:
- the subject matter, duration, nature and purpose of the processing
- the categories of data and of data subjects
- that the processor acts only on documented instructions
- confidentiality obligations on staff
- the security measures
- the rules for engaging sub-processors, and the current list
- help with data subject requests and breach notification
- what happens at the end: deletion or return
- audit rights
If a vendor cannot produce a document like that, you cannot lawfully use them for personal data, whatever their size limits are. Ours is published at /legal/dpa if you want to see what one looks like before you need one.
The transfer question, properly
If personal data goes outside the EU or EEA, you need a legal mechanism: an adequacy decision, standard contractual clauses, or one of the narrow exceptions.
The subtle part is that jurisdiction follows the company, not the server. A US-incorporated provider storing your files in Frankfurt can still be compelled under US law to produce data it controls. That is the substance of why EU–US arrangements have been litigated again and again, and the CLOUD Act piece explains it properly. "We have an EU data centre" answers a different question from "which government can compel you". Ask both.
Retention: the requirement people turn upside down
Most people treat retention as a service limitation to work around. It is an obligation to implement. The failure looks like this: eight years of client shoots on a drive, photographs of identifiable people included, no policy and no deletion. That is a lot of personal data held with no purpose — and if the drive is lost, a breach with a great many people in it.
Pick a period, write it down, apply it. How long to keep client files helps you choose one you can defend.
Where the protection actually comes from
Encryption is necessary, and it is worth knowing what it covers. Here is what happens to a file on Yungle, as an example of the chain you should be able to describe for any service you use:
Notice what the diagram cannot fix: a link that still works in two years, sent to the wrong person, with no expiry. The controls that prevent the realistic leaks are the boring ones — expiry, passwords sent separately, and the ability to revoke.
Six questions that survive a real audit
If you can answer all six, you are ahead of most small businesses.
- What personal data do we send, and on whose behalf?
- Who is our processor, and do we have a DPA with them?
- Where is it stored, and who are the sub-processors?
- Which jurisdiction can compel access?
- How long do we keep it, and what deletes it?
- What do we do if there is a breach? (72 hours to notify the supervisory authority, where notification is required.)
Number six is the one nobody has an answer to until they need it.
Choosing a service against this
Ask five questions in writing. Any serious vendor answers within a day:
- Can we have a DPA, and who are your sub-processors?
- Where is the company established, and where is the data stored?
- Can we control retention, in both directions?
- Can we revoke a link after sending it?
- Where are backups held, and by whom?
The last one catches a common gap: primary storage in the EU, with backups somewhere — or with someone — else.
The European services page covers who is actually EU-based, whether WeTransfer qualifies and whether Dropbox does work through two specific cases, and Yungle for business is the organisational side.
Full disclosure, answered the same way I would want a vendor to answer me: I run Yungle, a Dutch business. Files live on one server in Germany at Hetzner, and nightly backups go to a second Hetzner data centre in Finland, so no US company holds them. Sub-processors are listed in the privacy policy. The DPA is published, and the security page says what we do and do not do. Put the five questions above to me exactly as you would to anyone else.