Encryption at rest for GDPR


Our series of GDPR blog posts highlights the different ways the regulation impacts your data transfer and file sharing processes and systems. This article looks at encryption at rest for GDPR. Find out the requirements, common fails and what you need to do to comply.





This article looks at one small part of processing under GDPR – data at rest during a file transfer, and how it is protected. Article 32 of the GDPR specifically mentions data processing must have “a level of security appropriate to the risk”. That risk will change depending upon where in a network data is resting in its transfer process. It’s fairly safe to assume though that any data that’s potentially internet-facing (and therefore at greater risk) will need to be encrypted.

So how do we achieve this?  Protocols used in secure file transfer (SSH and SSL) address the transfer itself, but not before or after the transfer takes place. Three distinct methods to manage encryption at rest for GDPR spring to mind, although of course there may be others!


Option one – Application level encryption

This method relies upon the File Transfer application itself to perform the encryption. The list of acceptable encryption functions changes periodically, but it will generally use symmetric key encryption; either the AES (128, 192 or 256 bit) or TDEA (3DES; 56, 112 or 168 bits) algorithms.

Symmetric algorithms use a key to first encrypt the data for storage and then decrypt it again afterwards when it’s needed. The key is held inside the File Transfer software, ensuring the data is only ever accessed through the application. As a rule of thumb, the longer the length of the key, the more secure the encryption (just like with a password).


Option two – Filesystem level encryption

Using this method, the entire filesystem is encrypted, often using an Operating system level function.  The most commonly used example is BitLocker from Microsoft.

Bitlocker uses AES128 or AES256 algorithms for encrypting the data stored on the file transfer server. The wide availability of Bitlocker though, means it’s more frequently targeted by hackers than an application specific encryption method and therefore is more exposed to attack.


Option three – File level encryption

File level encryption has been popular for a number of years. It’s frequently used as a method to transfer financial files across the internet. The most common example of this is PGP (Pretty Good Privacy).  PGP uses both symmetric AND asymmetric algorithms to ensure encryption (files have a digital signature produced using RSA or DSA algorithms).  The great thing about this approach is that it can be combined with either of the other methods to create a very secure file.

Unfortunately, there are many commonly used file transfer applications that don’t use these methods to store their data. Instead they focus on the security of the actual transfer.  An example of this is Microsoft IIS FTP, which has recently been improved to allow FTPS (but not SFTP) transfers.  Without protecting the filesystem, an IIS FTP site will without doubt fail a GDPR audit. Similarly, many open source ftp platforms or older versions of established FTP applications are at risk in the same way.

Finally, it’s worth remembering that encryption of data at rest is never 100% guaranteed to protect your data; whatever method you choose to use, you should always be aware that any lock is only as good as the protection of its keys.


This is the first in a series of our GDPR blog posts. Each one will highlight a different aspect of data transfer that’s impacted by GDPR. Our technical experts will look at common practices that could result in a breach, and make recommendations to avoid them. Look out for our next post on encryption in transit.