The GDPR requires that companies implement proportionate and cost effective controls to protect the personal data of EU citizens. Enforcement measures introduced in the legislation for non-compliance can include having to produce mandatory data breach notifications and the imposition of large fines.

   GDPR mandates that companies should examine every opportunity to implement encryption as a control, and must demonstrate that, where it has not been implemented, it is for a good reason of cost-efficiency or proportionality.

   This article focuses on designing an encryption strategy to assist with compliance where the need has been identified by your Data Protection Officer.

   Analogous to buying a new bicycle, the amount of money spent on the security measures should not exceed the utility of purchasing those same security measures. That is, the amount you are prepared to spend must closely track the value (including fine avoidance) of the assets you are protecting.

   It has been argued that security breaches are a matter of when, not if they are going to occur. If this is the case, the encryption you implement will offer post-breach protection that customers will not need to be notified, and any fines imposed will be lessened because of it.

Types of Information to Protect

   Encryption helps in cases of data loss. If the loss is likely to result in discrimination, identity theft or fraud, financial loss, damage to reputation, or other significant economic or social disadvantages for data subjects, businesses will have to notify the breach to the affected data subject. Notification is not required if businesses have implemented appropriate technical and organizational security measures in respect of the data before the breach. Encryption also gives peace of mind to organisations in cases where the extent, vector or timing of data disclosure was not known.

   The GDPR legislation covers the collection, stewardship and use of personal data. Personal data includes any data that reveals a vulnerability that would cause damage or distress to individuals. Items likely to cause distress depends on the collection context, data includes personally identifiable information and can also include highly sensitive information like sexual orientation and preferences (often gathered on dating sites), trade union membership, medical diagnoses, Credit or Debit Card numbers and criminal record information.

   Evaluate which sector(s) your organisation operates in to identify local information collection that could distress if inappropriately disclosed.

Encryption Overheads

“Encryption should be considered alongside a range of other technical and organisational security measures.” (ICO website)

   Although data encryption is an extremely good way of protecting sensitive data whilst at rest and in transit, it is not always necessary or appropriate to encrypt all data fields. For use it needs to be decrypted in the device memory in order to be legible to business users. Other exceptions might be those that contain numerical data frequently accessed for computation e.g. cash amounts or drug dosages.

   Encryption always comes with overheads that need to be considered. These include the cost of products; key management; key rotation; loss of utility by having to encrypt and decrypt; loss of performance due to increased processing time; user training and Disaster Recovery processes and procedures.

   An assessment of whether encryption is applicable and feasible in data processing should be made, and the rationale captured within a Data Protection Impact Assessment (DPIA). 

Device and Network Level Protections

“The two main purposes for which data controllers may wish to consider using encryption are data storage and data transfer. These two activities can also be referred to as data at rest and data in transit.” (ICO website encryption guidance)

Protection mechanisms available include:

  • Enabling full disk encryption on any devices where the operating system allows it. Where it provided as part of the operating system ensure that it is provisioned and configured correctly.
  • Using whole device encryption like BitLocker for devices like laptops, USB sticks or phones that may be compromised by theft. Where possible, remote data wiping of company mobile phones may be an option.
  • Database and website connections and traffic should be protected using encryption protocols. Always use HTTPS or sFTP to transfer sensitive information via webservers. Enable secure protocols like SSL or TLS to protect the data in transit.
  • Secure all Wi-Fi access and connection points.
  • When passing spreadsheets or reports use file level or container level encryption for of data. Where the file or container is password or key protected, ensure you have a secure mechanism for passing the key between parties.
  • When data is passed to an external environment where it is stored in unencrypted form, encrypt it before sending. Create a process whereby the key is securely shared to only those parties who need access.
  • Encrypt web and system logs where they reveal personal data details.
  • At database level consider using whole database encryption protections. Use simple backup encryption, or enable Transparent Data Encryption (TDE) on your database to protect the data when it is at rest and during machine migrations.

   Where possible, leverage the built in encryption capabilities of products, and use well known secure protocols to ensure performance, and to reduce complexity and cost.

Encrypted Systems Design

   Internally developed business systems and database tables often hold many millions of rows of information, and are the source of many of the largest data breaches. However, the necessity for field level encryption is variable and needs to be considered in the wider context of the data, your business, and the conditions within which it is used.

    The following is a (non-exhaustive) list of the techniques and situations to look for when using encryption in database or application design.

  • The data should be organised into 3rd Normal Form (3NF) to ensure that data minimisation occurs. This reduces the surface area that needs to be protected.
  • Use generated surrogate keys not personal data identifiers e.g. Social Security Numbers to organise the data. Surrogate key values are an excellent way to protect personal data via pseudonymisation.
  • Utilise data masking techniques to protect personal identification numbers, or utilise hashing to protect the field values.
  • A good design means that there will only be certain fields and certain tables that require encryption.
  • Encryption can place a large overhead on database lookup routines, due to the need to decrypt, look up, and then re-encrypt the data. Consider whether you can bypass or design out the need for encryption round trips. Lookups should point to reference data that will not be of value if compromised.
  • Utilise deterministic encryption for lookup in preference to randomised encryption if feasible. The keys can be matched without the need to decrypt.
  • Use symmetric rather than asymmetric key encryption for large loads. It is less secure, but considerably faster and less processing intensive.
  • System and debug logs should not contain personal data.
  • Consider using data anonymization techniques like K-anonymity if the spread of your datasets allows (see here).

When designing privacy aware systems use the privacy by design and default principles (see here) in database and application design.

Other Measures

   The GDPR also requires that organisations take measures to ensure resilience of the systems and services and being able to restore the availability and access to the data in the event of a breach. These strategies should form part of a comprehensive Disaster Recovery and Business Continuity (DR/BC) plan, alongside ongoing frequent testing of the effectiveness of security measures.

   Security is only partly determined by the action of machines, and to focus your attention and budget on technical controls neglects the necessity of providing business user training and process re-engineering to increase the awareness of how to handle information, and to mitigate data loss due to human factors.

   If all else fails, consider using cyber insurance to mitigate the effects of an attack. Although it admits to a lack of confidence in your systems, insurance against risks can be a valid business response. If nothing else, the quoted cost of insurance should give you a baseline measure of what you should be spending on protection. 


   The GDPR introduces an obligation on organisations to implement suitable information security measures, including consideration of protection via encryption and data pseudonymisation.

   In addition to technical protective measures data controllers should take other supporting measures to show their ability to carry out their tasks in a privacy aware manner. Transparency as to what is done with people’s data, information protection clauses in contracts with external vendors and Data Protection Impact Assessments (DPIAs) should become the norm for high risk processing activities.

   Beyond encryption, pseudonymisation and compliance, the GDPR offers a way for organisations to use protection to foster greater levels of security, privacy respect and trust for customers.