Health records, legal files, financial detail and anything about 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, a written agreement with everyone who touches the data, and the ability 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 one.
What counts as sensitive
Two different things get called sensitive, and mixing them up is the usual first mistake.
Special-category data is a defined set under the GDPR: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic and biometric data, health, sex life and sexual orientation. Processing it is prohibited unless a specific exception applies — a much higher bar than ordinary personal data.
Data that is sensitive in the everyday sense — salary, financial position, commercially confidential material — is regulated as ordinary personal data, or not at all if nobody is identifiable. It deserves care; it does not attract the same rules.
Criminal offence data sits in its own category with its own restrictions.
In practice: 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 you. For special-category data you need a lawful basis and a separate condition that permits the category. Explicit consent is one; there are others covering employment, health care and legal claims.
This is where many small suppliers discover they cannot lawfully do the work as arranged — and it is far cheaper to discover before starting.
The chain has to be on paper
You are almost certainly a processor here: the client decides what happens to the data, and you act on instruction. That means a processing agreement with your client, and processing agreements with your own vendors, who become sub-processors. If a transfer service cannot produce a DPA, it cannot be part of that chain. What a DPA has to contain.
Jurisdiction stops being academic
For special-category data, "which government can compel this provider" has a real answer with real consequences, and it follows the company rather than the disk. The CLOUD Act piece explains why an EU data centre does not settle it. Many client DPAs in regulated sectors rule out sub-processors in particular jurisdictions outright — read yours before choosing tools, not after.
Retention becomes a hard requirement
Holding special-category data longer than necessary is not untidiness. It breaches the storage limitation principle, with a lot of people 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 your process from scratch. Write it down in advance: who decides, who is contacted, what gets recorded.
Collecting sensitive files is half the job
Most advice is about sending. In regulated work the riskier half is often receiving — a client emailing you a scan of their medical file because nobody gave them a better option. Give them one:
A request link means the client uploads without an account, the files land in one place instead of a mailbox, and each upload is checked for viruses as it arrives.
Sending it: the practical setup
- Send links, never attachments. Attachments cannot be revoked and live in mailboxes for good.
- Expire everything. Short by default. A link should stop working once its job is done.
- Password-protect, and send the password another way. In the same email, it is decoration. The mechanics.
- Limit downloads where it fits — a single-use link for a single document tells you when something went wrong.
- Send less. Redact, crop, cull. The most reliable protection for data is not having sent it.
- Keep a record of what went where and when. When a client asks — and in this work they eventually do — memory is not an answer.
Encryption at rest is part of the picture too. Here is how per-file keys work, which is worth being able to explain to a client's compliance team:
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 established, and where is data stored?
- Where are backups held, by whom, and how long do deleted files persist in them?
- Can we set retention, and 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. If you work in health care, Yungle for healthcare is honest about what stays your responsibility.
Disclosure: I run Yungle — files on a server in Germany and nightly backups in a second Hetzner data centre in Finland, both with Hetzner, a German company; sub-processors named in the privacy policy, and a published DPA. Put the five questions above to me exactly as you would to anyone else; that is what they are for.