GDPR
Does GDPR Require Email Encryption?
The GDPR does not say that every email must be encrypted. It requires “appropriate technical and organisational measures” to protect personal data and names encryption as one of them. When emails carry sensitive or large volumes of personal data, encryption is usually the clearest way to show that security was appropriate, and encrypted data that is lost or intercepted may not need to be reported to the people affected.
This article explains the relevant provisions, how to assess your own email traffic and where TLS falls short. It is general information, not legal advice.
What the GDPR actually says
The General Data Protection Regulation never mentions email specifically. Four provisions shape how it applies to email:
- Article 5(1)(f) requires personal data to be processed with appropriate security, including protection against unauthorised processing and accidental loss.
- Article 32 requires controllers and processors to implement measures appropriate to the risk, taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of the processing. It names “the pseudonymisation and encryption of personal data” as an example.
- Article 33 requires notifying the supervisory authority of a personal data breach.
- Article 34 requires informing the people affected when a breach is likely to result in a high risk to them.
The full text is published on EUR-Lex, the official database of EU law (external link).
A risk-based obligation, not a blanket rule
Article 32 asks what is appropriate for the risk, and the risk in email varies widely:
| Message content | Typical risk | Reasonable protection |
|---|---|---|
| Meeting logistics and general business correspondence | Low | TLS in transit |
| Customer contact details, order history, routine HR correspondence | Medium | Enforced TLS, with encryption for bulk or external sharing |
| Health, financial, identity or legal data, and special category data under Article 9 | High | Message-level encryption applied by policy |
Scroll sideways to see the whole table.
Special categories of personal data, such as health information, deserve particular care, because exposure can seriously affect the people concerned. Volume matters too: a single spreadsheet of customer records sent to the wrong address can expose thousands of people at once.
Document the assessment. Article 5(2) makes controllers responsible for demonstrating compliance, so being able to show why a measure was chosen matters as much as the measure itself.
How encryption changes breach notification
An email containing personal data that reaches the wrong person is a personal data breach, as is a compromised mailbox. Article 33 requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk to people’s rights and freedoms. Article 34 requires telling the individuals when the risk is high, but Article 34(3)(a) removes that duty if the data was rendered unintelligible to anyone not authorised to access it, “such as encryption”.
In practice, a message encrypted with PGP or S/MIME that is misdirected or exposed reveals ciphertext rather than readable personal data, provided the private keys were not compromised too. The breach should still be recorded internally, as Article 33(5) requires, together with the reasoning behind the risk assessment.
Is TLS enough?
TLS is a sensible baseline and, for low-risk mail, may be all that is appropriate. Its limits matter for higher-risk data:
- It protects each connection, not the message, so the content is readable on every server and in every mailbox it reaches.
- It is opportunistic unless enforced, so mail can fall back to unencrypted delivery.
- It does nothing for a message sent to the wrong address.
Message-level encryption with PGP or S/MIME keeps content protected in transit and at rest, readable only by the intended key holders. Our comparison of PGP and S/MIME for enterprise email explains how the two standards differ.
Common email scenarios
Sending payroll or HR files to an external provider
Salary, bank and identity details for many employees are high-risk by volume and content. Encrypt these transfers by policy, and make sure the provider’s contract covers security as a processor.
Replying to a customer who emailed their own data
A customer who chooses to email you their details has not set the standard for your reply. If the reply contains sensitive information, such as account or health details, use encryption or a secure portal rather than a plain reply.
Sharing case files with lawyers, auditors or insurers
Professional advisers often support PGP or S/MIME. Where they do not, a secure portal or an encrypted document keeps the files protected without asking them to install anything.
Controllers, processors and email providers
Article 32 applies to controllers and processors alike. When an email or encryption provider processes personal data on your behalf, Article 28 requires a contract that commits it to appropriate security, and transfers outside the European Economic Area must meet the conditions of Chapter V.
Ask every provider where messages are processed and where keys are stored. Our page on email security compliance and data sovereignty covers regional processing and the regulations CloudPGP helps organizations address.
A practical GDPR email encryption checklist
- Map personal data in email. Identify which teams send which categories of personal data, and to whom.
- Assess risk per flow. Rate each flow by sensitivity, volume and type of recipient.
- Set policy. Enforce TLS as a baseline and require message-level encryption for high-risk flows.
- Automate. Apply encryption by rule, so protection does not depend on individual judgment.
- Plan for recipients without keys. Offer a secure portal or an encrypted document instead of unprotected mail.
- Keep records. Retain audit logs of encryption activity to demonstrate accountability.
Frequently asked questions
Is sending personal data by unencrypted email a GDPR violation?
Not automatically. The question is whether the security was appropriate for the risk. Sending low-risk information over TLS may be appropriate; sending health or financial records without stronger protection is much harder to justify.
Do we have to report a breach if the email was encrypted?
You must still assess and record it. If the content was encrypted and the key was not compromised, the breach may be unlikely to result in a risk, which affects whether the supervisory authority must be notified, and under Article 34(3)(a) the people affected generally need not be told.
Does GDPR apply to organizations outside the EU?
Often, yes. Under Article 3(2), it applies to organizations that offer goods or services to people in the EU or monitor their behaviour there, wherever the organization is based.
Which encryption standard does GDPR require?
None. The GDPR is technology-neutral. PGP, S/MIME and other current, well-implemented methods can all be appropriate; what matters is that the measure fits the risk and the state of the art.
Is encrypted email still personal data?
Yes, for anyone who can decrypt it. Encryption reduces the risk, but it does not take the data outside the GDPR; the organizations that hold the keys must still process it lawfully.
Should internal emails be encrypted too?
Internal mail often stays within one platform, where enforced TLS and access controls may be appropriate. Sensitive HR, health or disciplinary records can still justify encryption, especially when many administrators or connected systems can access mailboxes.
