With the passing of GDPR in May 2018, the technical requirements for digital dialogue marketing have increased as well. Those requirements that marketers try to meet are, amongst others, higher standards for the encryption of communication. Now the comissioner for data protection (Landesbeauftragte für Datenschutz und Informationsfreiheit (LDI)) in the German state of North Rhine-Westphalia (NRW) has lately published a statement in which she makes the encryption of email transport a subject. But how far can these requirements be considered realistic for real use cases like for example in marketing and service communication? Can every provider meet these standards? And if they cannot, what is the next step? There are definitely alternatives to the recommended TLS-encryption. In this article we want to tell you what they could look like.
But are you even affected by this? Generally, the requirements apply to every email that contains personal data. That could be transaction mails, which normally contain address and transaction data. Also the correspondence between business and customer, business and partner, or even internal correspondence often transmit personal data. BMW Motorrad e.g. transmits personal data about test drives encrypted via email to authorised dealers (see case study at the end).

“A minimum of the standard transport encryption used by considerable European providers is required”

This is a quotation out of said statement from 25th January 2019. It names a criterion that companies should fulfil when sending emails, according to the LDI. But who are those “Considerable European providers”? This question is not an easy one to answer. The problem lies already within the word “provider”. What exactly does she mean by that? We come to the conclusion that in this case she refers to email service providers. And what do their standard transport encryptions look like? Here, the statement specifies that transport encryption should be performed as the technical guidelines “BSI TR-03108 secure email transport” say. When you look into these guidelines you find the word “DANE”. This is a technique that allows you to connect domain names with TLS/SSL certificates and thereby specify the security certificates that are valid for a domain. Basically, that means that “the standard for provided transport encryption”, the minimum required, is TLS. But even though that kind of encryption could be considered standard because most email providers support it, still not all providers do. If no TLS encryption is possible, the recipient of an email won’t even notice that and therefore won’t notice that his content is transmitted unencrypted. This fact is a potential cause of problems.

Realistic chance of meeting those requirements?

If you yourself or your email service provider do support transport encryption via TLS but the provider of one of your recipients doesn’t, then TLS won’t work. The recipient wouldn’t be able to encode what you sent to him in encrypted code. For that reason the providers of sender and recipient come to an agreement about encryption before anything is sent. So what can you do? Not so much it seems, because your messages will be sent unencrypted if there is no TLS compatibility. This is where the problem contained in the LDI’s statement stands out. To this point, we are far from every provider supporting the necessary methods and actions. But that means, if you don’t want to send your mails unencrypted or stop sending them at all, you need an alternative.

Secure redirection is key

A solution looks like that: In case an encrypted transmission of a certain message isn’t possible, an alternative message is sent which only contains a link. This link directs the recipient to a secured space (secure domain, cloud, etc.) where he can access his content with separately sent login data. Such data like passwords definitely shouldn’t be sent unencrypted though, so you could use Short Message Service to transmit it. So you send the link via email and the password or access code without any background information via SMS. This way your communication is even safer, thanks to separate channels.

Privacy Compliance Mail

Our reatl-time marketing automation technology ELAINE® contains a feature called Privacy Compliance Mail. This works the way explained above and allows you to make it your standard encryption method. Through a called TLS bounce, the recipient is asked whether it supports TLS or not. If he doesn’t, content is never sent unencrypted but instead a PDF document of the content is created which the recipient can access with a separately sent password. The sending of the password as well as the link leading to the document is automated. Thus you can meet the requirements for transport encryption even if the technical circumstances your recipient provides would normally not allow you to do that. This means the Privacy Compliance Mail supports the realisation and goals of LDI NRW.
Encrypted data transmission at BMW Motorrad
In this case study we show you how BMW Motorrad transmits personal data between manufacturer and contract dealer encrypted via Privacy Compliance Mail.