File sharing and GDPR: the parts that actually apply

Sending a spreadsheet of customer records to an agency is a transfer of personal data, and the rules apply whether or not anyone thought about it at the time. Most people's exposure to GDPR is a training module and a cookie banner, neither of which helps at the moment you are about to attach a file.

This is a practical read of the parts that touch file sharing. It is not legal advice, and where the stakes are high your DPO or a lawyer is the right call.

When it applies

Whenever the file contains information about identifiable living people. That is broader than most assume: names and emails obviously, but also a spreadsheet of order numbers tied to addresses, a folder of CVs, a video with recognisable faces, or a screenshot of a support conversation.

Some categories are treated as special and carry stricter conditions: health, biometrics, ethnicity, religion, political opinions, sex life, trade union membership. Criminal offence data has its own rules. If a transfer touches those, slow down.

The principle that does the most work

Data minimisation. Send the least data, to the fewest people, for the shortest time.

It is the most useful idea here because it improves every other position at once. A smaller export is a smaller breach if it leaks, a smaller obligation if you have to report it, and a shorter conversation with a regulator. It is also usually easier.

In practice: export the three columns needed rather than the whole table, filter to the relevant date range, and remove the "notes" field that someone has been using as a diary. Most spreadsheets sent between organisations contain far more than the recipient asked for.

Six practical habits

1. Check the file before it goes. Hidden columns, extra sheets, tracked changes and comments are all part of the file. So is EXIF location data in photographs.
2. Pseudonymise where you can. If the recipient only needs to analyse patterns, replace names with reference numbers and keep the mapping yourself. The dataset becomes far less sensitive without becoming less useful.
3. Encrypt end to end. Encryption is explicitly named in the regulation as an appropriate measure, and it also matters after the fact: if data is unintelligible to anyone who obtains it, the obligation to notify affected individuals is treated differently. Encryption is not just prevention, it is mitigation.
4. Set a real expiry. Storage limitation is a principle in its own right — personal data should not be kept longer than necessary. A link that deletes on a schedule is that principle implemented rather than promised.
5. Send to one person at a time. A single message to eight recipients discloses eight email addresses to each of them. That is itself a small personal data disclosure, and it is entirely avoidable.
6. Keep a record of what you sent. Accountability means being able to demonstrate what happened. A history of transfers, recipients and download counts is exactly the evidence you would need.

Processors, and why the location matters

A service that stores files on your behalf is acting as a processor. Two things follow.

First, there should be a written arrangement covering that processing — usually a data processing agreement, which for most services is part of the terms.

Second, if data leaves the UK or EEA, a transfer mechanism is needed. This is where knowing where a provider stores data stops being trivia.

Worth noting: with genuine end-to-end encryption the provider holds ciphertext and no key, which materially changes the risk picture — though it does not by itself remove the processing relationship. Do not treat encryption as a substitute for knowing who your processors are.

If something goes wrong

The timeline is short. A personal data breach generally has to be reported to the supervisory authority within 72 hours of becoming aware of it, where it is likely to pose a risk to people. If the risk is high, the individuals affected have to be told too.

So, in order:

1. Revoke the link immediately. If the bytes are deleted, exposure stops at that moment.
2. Establish whether it was accessed. Download counts turn speculation into fact, and "sent to a wrong address and never opened" is a materially different incident from one that was downloaded.
3. Tell whoever owns this internally, straight away. The clock is running.
4. Write down what happened — what data, how many people, when you found out, what you did. You need the record regardless of whether it is reportable.

This is precisely why revocation and download counts are worth having before you need them. They are the difference between a contained incident and an unanswerable question.

Questions to ask any provider

• Where is the data stored, and does it leave the UK/EEA?
• Is there a data processing agreement?
• What exactly is retained after a transfer expires, and for how long?
• Can staff at the provider read file contents?
• Can we delete on demand, and what does deletion mean?

Our answers are in the privacy policy, written to describe what the system actually does rather than what would be convenient to claim.

Related: sending sensitive documents, end-to-end encryption explained, and how long a link should last.