Traditional email is insecure: data travels over the internet unencrypted and can be intercepted. So, what does the GDPR say about sending personal data over email? Is it acceptable if certain technical measures are taken?

This article starts with quoting what the Europen General Data Protection Regulation (GDPR) says about securing personal data. We then talk about the difference between ordinary personal data and sensitive personal data and how it affects the security requirements. Then on to the technical measures: the Data Protection Authorities give concrete hands-on tips and we will go through four of these that can be implemented to adequately secure the communication of personal data.

After reading this article you should know what you can and what you cannot send over email and what countermeasure is most suitable for your case.

Too long to read? Jump straight to the conclusion. You'll miss out on some important background information, though.

What does the GDPR say?

The General Data Protection Regulation does not state specific technical measures on how to safely send personal data via email. One of the goals when writing the GDPR was to make it more or less timeless: updates to the regulation and the law should not be necessary each time a new threat emerges or when new countermeasures are developed.

So, what does the GDPR say exactly? Section 2 of the GDPR talks about the Security of personal data. Most important is Article 32: Security of the processing, paragraph 1 of it states:

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
(a) the pseudonymisation and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
[..]

The GDPR leaves the technical measures up to the processor of the personal data. They depend on a number of factors, as discussed next.

Factors to consider

Type of personal data

Ordinary basic personal data, such as name and address require less protection than sensitive personal data, which includes things such as medical data, religion, grades at school, and basically anything else that could potentially seriously harm someone if exposed. To quote one of the relevant parts of the GDPR:

Personal data which are, by their nature, particularly sensitive in relation to fundamental rights and freedoms merit specific protection as the context of their processing could create significant risks to the fundamental rights and freedoms.

Simply put: the more sensitive the personal data, the more protection is required.

Type of persons involved

Not only the type of data is relevant but the GDPR also talks about something called vulnerable data subjects which warrant additional protection. These are persons where there is a power imbalance between the data subject and the data controller. The most common categories you may encounter are children and employees.

Amount of personal data

The amount of personal data you will send is also relevant. There's a difference between sending an email to one person with just data for that one person and sending bulk data with personal data of hundreds or thousands of persons. Again, the latter requires more protection.

If you routinely send or process large amounts of data, in particular large amounts of sensitive data or of vulnerable data subjects then you may even be required to do something called a Data Protection Impact Assessment, also called DPIA. But that would be another story...

Costs and other factors

Finally, it's good to know that the GDPR acknowledges cost and the state of the art as a factor. In other words: you don't have to spend millions of euros on some obscure and unbreakable solution. It should be reasonable.

What do the authorities say?

Each member state of the EU has a Data Protection authority. These are the institutions that could potentially give you that million euro fine in case of a data breach. Fortunately, that is not their only job. They also help by explaining the rules and handing out guidelines.

I checked three data protection authorities for their views on sending personal data over email: the British Information Commissioner's Office (ICO), the German Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) and the Dutch Data Protection Authority.
The UK ICO page on email mainly lists the problems that are related to the email but is less focused on solutions. The German BfDI seems to have no page at all regarding personal data via email.
Fortunately, the Dutch Data Protection Authority is more concrete and gives two examples on how to safely send personal data using email:

• Put the personal data in an encrypted attachment
• Ensure traffic between email servers is encrypted by using modern internet standards.

The options, in order of preference

Let's go through the various options, in order of preference.

Option 1: Don't use email at all, use a portal

The best option would be not to use email at all. Instead, have a customer portal where the user logs in with his/her account details over a secure connection. The portal employs HTTPS which ensures the data won't be intercepted by an intermediary. The customer can safely view, submit and change any personal data. Additionally, one can provide an "inbox" on the portal where the user can read and respond to messages. Such an inbox is often combined with email notification: when there's a new message the user receives an email. The content of the message is not shown in the email, only the fact that there's a new message. Only after logging in to the portal the user can read the message content.

While not explicitly listed by the Dutch DPA as an alternative to email, this method is in use by the Dutch Government for "MijnOverheid" (MyGovernment) for electronic communication with its citizens. Similarly, the UK ICO does mention such secure messaging systems and points out they are in use in the UK, such as NHSmail for sharing patient data.

Advantages:

• High security
• Works for everyone (cross-platform)
• Relatively easy for the user
• Security can be further enhanced with two factor authentication such as SMS or an app

Disadvantages:

• User has to log in to a portal to view or respond
• User has to create (yet) another account

If a portal is available, it should be employed. If your organization does not offer a portal and you have to deal with customers updating their personal data or organizations having to send you bulk personal data then you should seriously consider creating one.

This option does not eliminate all threats. In particular there's the risk of vulnerabilities (such as SQL injection) in the portal. If the portal gets hacked the hacker could extract personal data of potentially a large number of users. If you have a secure customer portal, however, it is the safest option available which any (inexperienced) user can easily use.

Option 2: Use PGP or S/MIME

This is one of the suggestions by the Dutch authorities and the UK ICO. It provides end-to-end encryption and when operated correctly it is really secure. Unfortunately, it is less suitable to ordinary users. First of all, it adds the burden of key management. With both PGP and S/MIME one has to acquire the public key of the recipient and ensure that this key belongs to the user. Last but not least there's the whole issue of requiring PGP or S/MIME at both sides, usually in the email clients. This often requires installation and configuration of additional software.

Because this method is unsuitable for inexperienced users and unsuitable for mass communication I am not going to elaborate further on this. If you are technically savvy then feel free to follow a PGP tutorial online to see how it works in practice.

Advantages:

• Very safe, provided the certificates/public keys are verified

Disadvantages:

• Not suitable for inexperienced users
• Not suitable for mass communication

Option 3: Put the data in an encrypted .ZIP file

Sometimes another organization needs a bulk upload of personal data. Preferably we would use a portal for submitting such data, but what if this option is unavailable? In such a case, when you have for example an excel sheet with personal data of tens or hundreds of persons, you can put the document in a password-protected ZIP file and mail it to the recipient. Be sure to set a complex password of at least 15 characters consisting of random letters and digits and communicate the password over the phone or SMS (NOT over email!!).

On pretty much every OS you can open password protected .ZIP files. Unfortunately, on Windows, in order to create a password protected .ZIP file you will have to install additional (free) software such as 7Zip.

The use of encrypted attachments is suggested both by the Dutch DPA and the UK ICO.

Advantages:

• Quite safe, as long as the password is long and complex and the password is not sent over the internet.
• Works for pretty much everyone: ZIP files can be opened on all Operating Systems out there
• Best used for sending bulk personal data (when a portal is not available)

Disadvantages:

• Requires user interaction for both the sender and the receiver
• Requires the use of a second channel (phone/SMS)
• Not very practical when sending personal data multiple times a day

Option 4: Secure email transport with STARTTLS and DANE

This is another option that the Dutch authorities suggest. They also refer to two factsheets from the Dutch National Cyber Security Center (NCSC): Secure the connections of mail servers and TLS Interception.

As mentioned at the beginning of the article, email is "by default" transmitted via plaintext, that is: unencrypted over the wire. This can be changed, however.

Introducing: STARTTLS

For websites you have HTTPS which ensures secure communication (the famous padlock next to the URL bar). For email there is something called STARTTLS.

STARTTLS is an option that an email server can advertise. It tells the sending email server (or client) that the connection can be upgraded to a secure connection with TLS, the same technology that protects HTTPS sites.

Many email servers nowadays advertise and use STARTTLS. Google (including Gmail) publishes statistics showing that 90% of all incoming and outgoing emails are encrypted in transit using STARTTLS.

Unfortunately, employing just STARTTLS provides insufficient security.

Introducing: DANE

While STARTTLS gives the ability to encrypt email in transit, it does NOT enforce it. There's a risk that a connection is actively intercepted and rewritten to disable STARTTLS. This requires an active attack, which requires more effort and is less stealthy than just eavesdropping. The end result is the same, though: all email content can be intercepted and read.

This is where DANE comes into play. It informs sending email servers that all emails to your email server MUST be sent encrypted. If an encrypted connection cannot be established, the sender must not fallback to unencrypted but must wait and retry later.

Before you deploy DANE, you should ensure that you use a real and proper SSL certificate on the mail server. So, if your SMTP server is mail.example.org then the SSL certificate should also be for mail.example.org and it should be issued by a trusted authority. Fortunately, nowadays initiatives like Let's Encrypt make this rather easy.

Setting up DANE requires adding certain DNS records. If, like most people, you haven't set it up before then it can be a bit challenging. I suggest you follow a DANE tutorial online and monitor the server closely after deployment for any issues.

Residual risk

Once you have STARTTLS and DANE employed then conforming servers will deliver emails to you in encrypted form. Similarly, if configured properly then your email server will send encrypted emails to other mail servers that use STARTTLS (with or without DANE).
Unfortunately, not all SMTP servers employ STARTTLS (as mentioned before, Google statistics show that at least 10% does not), and the percentage domains with DANE is even lower. This begs the question: can I safely send personal data via email, even if I use STARTTLS and DANE on servers I control?

My verdict on STARTTLS+DANE:

Advantages:

• Once configured by the mail administrator, users don't have to take any special steps, it "just works"
• STARTTLS helps both with encrypting incoming and outgoing emails

Disadvantages:

• Most domains have STARTTLS enabled (90%) but some do not. For those domains that do not, any email you send to people on such a domain will still travel unencrypted. In other words: there is no guarantee, it is only partial mitigation of the risk. Sites such as internet.nl offer a Test your email option which will show if a domain has STARTTLS (and DANE) enabled.

Conclusion

Sending personal data over email will always be a challenge due to the insecure nature of email. Additional countermeasures are therefore required:

1. If possible, don't use email but use a portal instead
2. If sending personal data involving tens or hundreds of people and a portal is unavailable, send it as an encrypted .ZIP archive and communicate the password over the phone or SMS.
3. If you are only going to send basic personal data such as a name and address of one person then it is generally acceptable to use email. Still, do ask your mail administrator to implement the latest Internet standards such as STARTTLS and DANE. In the Netherlands, implementing this is mandatory for government and other public institutions since 2016.

I would recommend NOT to send sensitive personal data over ordinary email. If an organization asks you to send a copy of your passport then you could fall back to option 2 with the encrypted .ZIP archive, but such a request is usually a bad sign of security awareness at the receiving organization that should get you seriously worried.

Follow-up

This article outlined the risks of sending email. There are more challenges and risks with regards to email. I will write about this in a next article.