July 16, 2026

GDPR requirements for file transfer: what actually applies

GDPR is often invoked as a monolithic compliance requirement, but which Articles actually govern file transfer? This post maps the real requirements: what encryption means under GDPR, what happens when a file is deleted (and how to prove it), what your processor contract must say, and what a breach notification actually requires. No legal advice here — just a reading of the regulation that applies to the file transfer layer.

Core principles: integrity and confidentiality

Article 5(1)(f) of the GDPR requires that personal data be processed with integrity and confidentiality — meaning data must not be disclosed to unauthorized people and must not be modified without authorization. For file transfer, this is the foundation. The regulation does not mandate specific technologies, but Article 32 names encryption as an example of an appropriate measure — and in practice that means files containing personal data are encrypted in transit (so they cannot be read on the network) and at rest (so they cannot be read if the storage is compromised). It must also be possible to detect if a file has been modified in transit or at rest.

Article 32 expands on this and requires appropriate technical and organizational measures to ensure confidentiality, integrity, availability, and resilience. For file transfer systems specifically, this means: encryption in transit and at rest, the ability to restore data after an incident, access controls so only authorized users can retrieve files, and logging to detect unauthorized access or modification.

Processor contracts and liability

If you use a third-party file transfer platform (a processor), Article 28 requires a data processing agreement (DPA) between your organization (the controller) and the processor. That DPA must specify what personal data the processor will handle, for how long, and what safeguards are in place. If the processor is outside the EU, Chapter V (Articles 44 to 49) governs international transfers: the destination country must be covered by an EU adequacy decision, or appropriate safeguards such as Standard Contractual Clauses (SCCs) must be in place. Without either, the transfer lacks a lawful basis unless one of the narrow Article 49 derogations applies.

Read the fine print of your file transfer provider's DPA. Does it permit you to use the provider for EU personal data? Does it include Standard Contractual Clauses if the processor is outside the EU? If not, review with your data protection officer before signing up.

Records of processing and proof of deletion

Article 30 requires you to maintain records of processing activities — what data you process, why, for how long, and who accesses it. For file transfer, this means: audit logs of every transfer, who initiated it, what file was transferred, and proof of delivery or failure. These records are evidence if a regulator investigates or a data subject asks "what happened to my data?" Keep audit logs for at least as long as your documented retention period requires — and set that period deliberately, because logs about personal data are themselves personal data.

Article 17 is the right to erasure: if a data subject asks for their data to be deleted, you must delete it and be able to prove that it was deleted. For file transfer platforms, this is critical: if you received a file containing a data subject's information, and the retention policy says to delete it after 30 days, the platform must actually delete the file from disk — not move it to archive, not just revoke access, but genuinely delete it in a way that it cannot be recovered. The file transfer platform must provide evidence that deletion occurred: a log entry, a checksum proof, or a certificate. A compliance officer cannot accept "we deleted it" as proof; they need evidence from the system.

Breach notification and timelines

Article 33 requires that you notify the supervisory authority (your national data protection authority) of a personal data breach within 72 hours of becoming aware of it. This notification goes to the authority, not to affected data subjects. It must describe the breach, the likely consequences, and the measures you have taken to mitigate it. If the breach was caused by inadequate file transfer safeguards — a file left unencrypted on an SFTP server, or credentials leaked in an audit log — the notification must mention that.

Article 34 requires notification to affected data subjects if a breach poses high risk to their rights and freedoms. There is no 72-hour deadline for this notification — it can happen after the authority is notified — but it must be prompt. If you cannot identify who was affected, or if the data was already encrypted when breached, you may not need to notify data subjects (review with your DPO).

What to document in your file transfer setup

Before selecting a file transfer platform, document: encryption in transit (TLS 1.3, SSH) and at rest (AES-256), access logs (who, when, what file, success/failure), retention enforcement (files auto-deleted after N days, with audit log proof), and DPA compliance (processor name, jurisdiction, SCCs if needed). Keep evidence of all of these in your records of processing.

For deeper guidance on deletion proof, see Deletion you cannot prove: a GDPR blind spot. For residency issues in cross-border transfers, check Data residency broke on transfer hop. And review our security practices page for details on how we handle GDPR requirements.

Read the full GDPR on EUR-Lex. Review your file transfer setup with your data protection officer or legal counsel before moving regulated data through any platform. xEvolve provides per-transfer audit trails, encryption in transit and at rest on EU infrastructure, tenant isolation, and Entra SSO — supporting your GDPR obligations with traceable, encrypted file transfer.