Sending Personal Data Securely: What the GDPR Requires

An HR department sends a payslip to an employee. A tax adviser transmits records to the authorities. A medical practice sends a diagnosis to a specialist clinic. Three everyday actions – and three transfers of personal data that determine whether an organisation meets its obligations under the GDPR. The question that matters here is rarely "Is the file encrypted?" but "Can I show that this transfer was appropriate to the risk?" This article sets out what the GDPR requires when sending personal data, how those requirements translate into a defensible decision, and how to recognise a suitable transfer channel.

• Compliance Is a Process, Not a File Format
• Four Questions Before Every Transfer
  • Which Data Are Leaving the House?
  • Who Receives the Data – and in What Role?
  • Where Are the Data Going Geographically?
  • What Level of Protection Does the Risk Demand?
• What Article 32 Actually Requires
• Appropriateness Means Calibrating, Not Maximising
• Transfer Channels Compared
• From the Right Channel to Defensible Proof
• When the Transfer Goes Wrong
• A Decision Aid for Everyday Sending
• Conclusion

#Compliance Is a Process, Not a File Format

A transfer is not GDPR-compliant because a particular tool was used, but because the decision taken can be justified after the fact. The GDPR nowhere mandates a specific technology. It sets out principles and obligations whose fulfilment the controller must ensure and be able to demonstrate.

Three provisions form the frame. Article 5 GDPR names the principles, among them integrity and confidentiality, data minimisation and purpose limitation. Article 32 GDPR requires technical and organisational measures appropriate to the risk. And Article 5(2) GDPR – the accountability principle – requires the controller not only to ensure compliance with these principles but also to be able to demonstrate it.

This answers the first and most frequently asked question: when is a data transfer GDPR-compliant? When it is proportionate, tied to a purpose and carried out with risk-appropriate safeguards – and when that assessment is documented and can be evidenced if challenged. "Compliant" is therefore not a state of the file but a property of the process. Those who internalise this stop looking for the one secure send button and start making the right decision.

#Four Questions Before Every Transfer

The GDPR's requirements can be translated into a short test that can be run before every transfer. Four questions are enough to determine the appropriate level of protection and the right channel.

#Which Data Are Leaving the House?

The nature of the data is the first consideration. Personal data are not all equally sensitive. Article 9 GDPR names special categories – including health data, data on religious or philosophical beliefs, trade union membership, sex life and biometric data used for unique identification. A higher level of protection applies to these, and the requirements for transferring them rise accordingly.

Before the question of how is even raised, the principle of data minimisation is worth applying: do these data, in this scope, need to be transferred to this recipient at all? Often the risk can be lowered simply by having fewer data leave the house – through redaction, pseudonymisation or limiting the transfer to what is actually necessary.

#Who Receives the Data – and in What Role?

The second question concerns the recipient and their data protection role. It matters whether the data go to an independent controller – an authority or a client, for instance – or to a service provider processing the data on your behalf.

In the latter case there is processing on behalf of the controller, and Article 28 GDPR requires a data processing agreement as its basis. This answers a common question: you need such an agreement whenever an external service provider processes personal data on your instructions – and therefore also when you use a provider's portal or cloud service for the transfer itself. The chosen channel is thus not only a technical but also a contractual question.

#Where Are the Data Going Geographically?

If the data leave the European Economic Area, an additional set of rules applies. Articles 44 et seq. GDPR govern transfers to third countries. Such transfers are permissible in particular where the European Commission has issued an adequacy decision for the destination country, or where appropriate safeguards such as standard contractual clauses (SCCs) are in place, supplemented where necessary by additional protective measures.

Transfers to the United States are a distinct checkpoint here, because the legal basis for transatlantic transfers has repeatedly been subject to adjustment. Anyone transferring personal data to US recipients or to services with a US nexus should check the current adequacy basis and the recipient's specific certification rather than rely on an earlier legal position. The server location of any transfer service used belongs in this assessment as well.

#What Level of Protection Does the Risk Demand?

The fourth question brings the first three together. Article 32 GDPR requires a level of protection appropriate to the risk – and the risk follows from the type of data, the recipient and the transfer channel. The more sensitive the data, and the greater the likelihood and severity of potential harm, the stricter the requirements for the technical measures. This balancing exercise is the core of every transfer decision.

#What Article 32 Actually Requires

Article 32 deliberately remains technology-neutral but offers examples of suitable measures. These expressly include the encryption and pseudonymisation of personal data, ensuring the confidentiality, integrity, availability and resilience of systems, and a process for regularly testing the effectiveness of those measures.

This answers a frequent question: must personal data be transmitted in encrypted form? The GDPR does not state an absolute requirement. In practice, however, encryption is the expected state of the art when transferring personal data – and for sensitive data in the special categories it is practically indispensable, because a lower level of protection would regularly be inappropriate to the risk. Supervisory authorities take a correspondingly critical view of sending data worthy of protection without encryption.

A practical note concerns the keys. Encryption protects only as well as the associated key is kept; if the key is sent over the same channel as the data, or inadequately secured, the protection evaporates. Article 32 likewise requires not a one-off but an ongoing assurance of effectiveness – measures must therefore be reviewed regularly and adapted to changing risks.

Technical and organisational measures are not only technical. Organisational measures include access concepts, rules for verifying recipients, training and defined transfer routes. It is precisely the organisational side that decides whether the secure route becomes the default or depends on the individual case. Equally important is the distinction between encryption on the transport path and continuous encryption from sender to recipient; it is explored in End-to-End vs. Transport Encryption and has direct consequences for the choice of channel.

#Appropriateness Means Calibrating, Not Maximising

The risk-based approach of Article 32 has a consequence often overlooked in practice: it does not require the maximum level of protection for every operation, but a level appropriate to the individual case. Blanket maximum security for every message is not only uneconomical but can undermine acceptance in daily work – and thereby ultimately weaken security, because staff find ways around cumbersome routes as soon as those routes feel like an obstacle.

The benchmark is calibration. An internal, low-sensitivity scheduling note demands a different level of protection than the transfer of a complete personnel file or a medical finding. For the former, a transport-encrypted connection may suffice; for the latter it is regularly inadequate. The art of appropriate transfer lies in deliberately tying the level of protection to the type of data and the risk, rather than consistently underestimating it or reflexively overdoing it.

This calibration is at the same time an argument for clearly defined transfer routes. If it is established for typical cases which channel is used – ordinary but transport-secured communication for the uncritical, a continuously encrypted route for the sensitive – there is no need to weigh things up afresh for every message. Case-by-case assessment remains reserved for borderline situations, and routine operation runs securely without overburdening those involved. Such a definition is itself an organisational measure within the meaning of Article 32, and it incidentally strengthens evidential value, because the chosen approach is reasoned and repeatable.

#Transfer Channels Compared

From the four questions and the requirements of Article 32, there follows no universally best choice but one suited to the risk. The following matrix sets common channels against the central requirements.

Two rows deserve particular attention. Email with transport encryption protects the message only on the respective segment between two servers; at the stations and in the mailbox it sits in plain text. Why this regularly does not suffice for confidential content is covered in detail in Why Email Is Not a Secure Way to Transmit Data. This also answers the question of whether TLS-encrypted email is enough: for low-sensitivity messages possibly yes, for data worthy of protection generally no.

The lower approach – a secure link instead of the content itself – inverts the logic. Rather than sending the data through foreign systems, the content stays in a controlled place and the recipient retrieves it through a secured access route. With a zero-knowledge method, even the provider cannot decrypt the content; the background is described in Zero-Knowledge Explained. How files can be transferred this way in concrete terms is shown in Secure File Sharing and One-Time Links.

#From the Right Channel to Defensible Proof

The right channel is half the work; the other half is the proof. The accountability principle in Article 5(2) GDPR requires the controller to be able to demonstrate compliance with the principles. If challenged or audited, having acted securely is not enough – you must be able to show it.

A transfer becomes evidenceable through several interacting elements: documentation of the technical and organisational measures taken, the record of processing activities, existing data processing agreements with the service providers involved, and – depending on the method – logs of retrieval or delivery. It is precisely here that transfer channels which document a controlled retrieval, rather than releasing a message unseen into the open system, show their strength.

In practice it pays not to reconstruct the proof only when something goes wrong, but to let it accrue as a by-product. A transfer route that automatically logs receipt or retrieval supplies this evidence without extra effort. Where the method itself records what was transmitted, when and to whom, accountability turns from a retrospective effort into a side effect of normal operation.

This answers the question of proof: you do not demonstrate compliance through a single encrypted file, but through a coherent chain of justified risk assessment, documented measure and – where possible – technical evidence of the actual transfer. For higher risks, a data protection impact assessment may additionally be required, whose outcome supports the choice of protective measures.

#When the Transfer Goes Wrong

The choice of channel has a consequence that often becomes visible only when something goes wrong. If an inadequately protected transfer falls into the wrong hands, there is regularly a personal data breach. Article 33 GDPR then requires notification of the competent supervisory authority, in principle without undue delay and where feasible within 72 hours of becoming aware. Where a high risk to the affected individuals is likely, Article 34 GDPR adds the obligation to notify those individuals as well.

This is where the real value of a sound transfer decision shows. If the data were continuously encrypted and the key was not also affected, that materially changes the risk assessment of the breach. Appropriate encryption is therefore not only fulfilment of duty in normal operation but also an effective means of limiting the consequences of an incident.

#A Decision Aid for Everyday Sending

The following logic condenses the four questions into a sequence that can be run through in seconds before each transfer:

1. Are these personal data? If not, the following steps do not apply; if so, continue.
2. Are special categories under Article 9 involved, or is the content otherwise highly sensitive? If yes, continuous encryption is the benchmark.
3. Can the volume of data be reduced before sending – through redaction, pseudonymisation or limiting to what is necessary? If yes, reduce first.
4. Is the recipient a processor? If so, is a data processing agreement in place?
5. Are the data leaving the EEA? If so, is there an appropriate basis for the third-country transfer?
6. Does the chosen route meet the required level of protection at rest and in transit – not just on one segment?
7. Is the decision documented and the process evidenceable if questioned?

If any of these questions remains open, the next step is not the transfer but the clarification. Such a sequence shifts responsibility from the spontaneous individual decision towards a repeatable procedure – which is exactly what accountability requires at its core.

#Conclusion

The GDPR prescribes no product and no technology for sending personal data. It requires a justifiable decision appropriate to the risk, and proof of that decision. Anyone who systematically examines the type of data, the recipient's role, the geographical destination and the required level of protection arrives almost inevitably at a suitable route – and can defend it if challenged.

For data worthy of protection, this examination regularly leads away from ordinary email and towards methods with continuous encryption and controlled, evidenceable retrieval. The decisive step is organisational in nature: making the secure route the default rather than leaving it to the memory of individual staff in the particular case. That is how "sending securely" becomes not an intention but a demonstrable standard.