GDPR-compliant file transfer: what it takes

If the file contains personal data about anyone, you are responsible for it, and three things make a transfer compliant in practice: a data processing agreement with whoever stores it, knowing which country's courts can compel access, and a retention period you actually chose. Encryption matters but is rarely the gap — the gap is usually that nobody wrote anything down.

This is a practical guide, not legal advice. If you are handling health data, children's data or anything at scale, get advice from someone qualified.

The part 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 conflating them causes both over-engineering and genuine mistakes.

What it does require, in the shape it actually bites for file transfer:

You need a lawful basis for processing the data at all. For most client work this is contract or legitimate interests, and it is rarely the hard part.

You are the controller; your transfer service is a processor. That relationship must be governed by a written agreement — a data processing agreement. This is not optional, and it is the single most commonly missing piece.

You must not keep it longer than necessary. Storage limitation is a principle in its own right, and "we kept everything forever because storage is cheap" is a straightforward failure of it.

You must be able to say where the data is and who else touches it. That means knowing your processor's sub-processors.

You must protect it appropriately — encryption in transit and at rest, access controls, and the ability to revoke access.

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 customer photographs to edit, they are the controller and you are their processor — and your transfer service is a sub-processor.

That chain matters because obligations flow down it. Your client's compliance requirements become your requirements, which become requirements on whoever you use.

What a DPA actually needs to contain

Not "we are GDPR compliant" on a marketing page. An actual 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
• Security measures
• Rules on engaging sub-processors, and a list of the current ones
• Assistance 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 transfer limits are. Ours is at /legal/dpa if you want to see what one looks like in practice.

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 derogations.

Where this gets subtle: 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 not a marketing point, it is the substance of why the EU-US arrangements have been litigated repeatedly. The longer explanation.

Practical consequence: "we have an EU data centre" answers a different question from "which government can compel you". Ask both.

Retention: the requirement people invert

Storage limitation means you delete personal data when you no longer need it. Most people treat retention as a service limitation to work around rather than an obligation to implement.

The failure looks like this: a photographer with eight years of client shoots on a drive, including photographs of identifiable people, with no policy and no deletion. That is a large volume of personal data held with no lawful basis, and if the drive is lost it is a breach with a lot of data subjects in it.

Decide a period, write it down, and apply it. How long to keep client files covers choosing one you can defend.

A checklist that survives an actual question

Six things. If you can answer all six, you are ahead of most small businesses.

1. What personal data do we send, and on whose behalf?
2. Who is our processor, and do we have a DPA with them?
3. Where is it stored, and who are the sub-processors?
4. Which jurisdiction can compel access?
5. How long do we keep it, and what deletes it?
6. What do we do if there is a breach? (72 hours to notify the supervisory authority where 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:

1. Can we have a DPA, and who are your sub-processors?
2. Where is the company incorporated, and where is the data stored?
3. Can we control retention, in both directions?
4. Can we revoke a link after sending?
5. Where are backups held?

The last one catches a common gap — primary storage in the EU with backups somewhere else.

The European services page covers who is actually EU-incorporated, whether WeTransfer qualifies and whether Dropbox does go into two specific cases, and the business page covers the organisational side.

Full disclosure: I run Yungle, an EU company with files on one server in Germany, backups in the EU and a DPA you can read before committing to anything. Put the five questions above to me the same way you would put them to anyone else.