Sending sensitive client data safely
Health records, legal files, financial detail and anything revealing someone's private life carry obligations that ordinary client work does not. Three things change in practice: you need a lawful basis strong enough for the category, you need a written agreement with everyone who touches the data, and you need to be able to say precisely where it went and for how long. Getting the file there safely is the easy part.
Not legal advice. For health data, children's data, or anything at scale, get advice from someone qualified — this is a map of the terrain, not a substitute for it.
What counts as sensitive
Two different things get called sensitive, and mixing them up is the usual starting error.
Special-category data is a defined set under the GDPR: racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic and biometric data, health, sex life and sexual orientation. Processing it is prohibited unless a specific exception applies — which is a much higher bar than ordinary personal data.
Data that is merely sensitive in the ordinary sense — salary, financial position, commercially confidential material — is regulated as normal personal data, or not at all if no person is identifiable. It still deserves care; it does not attract the same rules.
Criminal offence data sits in its own category with its own restrictions.
The practical consequence: a photographer shooting a hospital ward is handling health data. A designer working on a bank's brand guidelines is not handling special-category anything, however confidential the work feels.
What actually changes
You need more than a contract
For ordinary client work, contract or legitimate interests usually covers it. For special-category data you need both a lawful basis and a separate condition permitting the category. Explicit consent is one; there are others covering employment, health and legal claims.
This is the point at which many small suppliers discover they cannot lawfully do the work as arranged, and it is much cheaper to discover before starting.
The chain has to be written down
You are almost certainly a processor here — the client decides what happens to the data, you act on instruction. That means a processing agreement with your client, and processing agreements with your own vendors, who become sub-processors.
Every link needs to exist on paper. If your transfer service cannot produce a DPA, it cannot be in that chain. What a DPA needs to contain.
Jurisdiction stops being academic
For special-category data, "which government can compel this provider to produce it" is a question with a real answer and real consequences. That follows the company's incorporation, not the location of the disk. The CLOUD Act piece covers why an EU data centre does not settle it.
Many client DPAs in regulated sectors prohibit sub-processors in particular jurisdictions outright. Read yours before choosing tools rather than after.
Retention becomes a hard requirement
Holding special-category data longer than necessary is not untidiness, it is a breach of the storage limitation principle with a large number of data subjects attached. Decide the period, write it down, and make sure something actually deletes it. Choosing a retention period.
Breach notification has a clock
Where notification is required, the supervisory authority must be told within 72 hours of becoming aware. That is not long enough to work out what your process is. Write it down in advance: who decides, who is contacted, what gets recorded.
The practical setup
Send links, never attachments. Attachments cannot be revoked and live in mailboxes forever.
Expire everything. Short by default. The link should stop working once its job is done.
Password-protect, and send the password by a different channel. In the same email, it is decoration. The mechanics.
Limit downloads where it fits — a one-time link for a single document tells you if something went wrong.
Minimise what you send. Redact, crop, cull. The most reliable protection for a piece of data is not having sent it.
Keep a record of what went where and when. When a client asks — and in this kind of work they eventually do — reconstructing it from memory is not an answer.
Choosing a service for this
Ask, in writing, and expect answers within a day:
- Can we have a DPA, and who are your sub-processors?
- Where is the company incorporated, and where is data stored?
- Where are backups held, and how long do deleted files persist in them?
- Can we set retention, and can we revoke a link after sending?
- What is your breach notification process and timeline?
Question three catches a common gap: primary storage in the EU with backups elsewhere, or deleted data lingering in backups for months.
The European services page is the right starting list if jurisdiction is a hard requirement, and the secure services page covers the technical controls in more detail.
Disclosure: I run Yungle — EU-incorporated, files in Germany, backups in the EU, DPA published. Put the five questions above to me exactly as you would to anyone else; that is what they are for.