Companies under the remit of the Directive 95/46/EC adopted privacy practices consistent with its requirements (or more precisely, requirements of Member State-specific laws such as UK’s Data Protection Act 98 enacted subsequently). With the advent of General Data Protection Regulation (GDPR), however, such companies are now required to not only revisit some of their existing practices but also deliberate over a handful of new ones.

Furthermore, many new companies now fall under the remit of GDPR (by virtue of its enhanced scope and territorial reach) and hence must embrace similar practices from ground zero.

As it is set to address the preceding Directive’s shortcomings in today’s globalized and advanced digital economy, unsurprisingly, GDPR includes many new and revised provisions, notably in mandatory appointment of Data Protection Officer (DPO), international data transfers, breach notification and penalties, among others.

This whitepaper summarizes key requirements of one of the revised provisions under GDPR – the breach notification, and highlights a technical safeguard that can realistically help impacted companies cope up with such seemingly arduous requirements as well as ameliorate their overall cybersecurity posture.


General Data Protection Regulation (GDPR) contains a number of new provisions aimed at strengthening the rights of data subjects; one noteworthy change is the mandatory breach notification. GDPR imposes strict obligations on data controllers and processors with regard to notification to both supervisory authority and impacted data subject(s) in the event of a personal data breach, under Articles 33 and 34 [1].

As per Article 33, data controller must notify the supervisory authority of a personal data breach within a certain time period, unless the breach is unlikely to result in a risk for the rights and freedoms of data subjects. While this sounds reasonable, Article 34 goes on a step further and mandates data controllers to also timely notify the impacted data subjects if the level of risk posed by the breach is high. This incontestably sounds daunting until one glances across to point 3 under the same section, which fittingly provides an escape route to the controllers, at least partially. According to Article 33(3) [a], notifying subjects is not required if the controller has implemented sufficient safeguards to render the data unintelligible to any unauthorized person; GDPR explicitly names encryption as one such safeguard.

Encryption has always been regarded as a strong measure to protect the confidentiality of data deemed critical by various regulations such as PCI DSS, HIPAA, etc. The only difference is the nature of data each regulation intends to protect: PCI DSS protects cardholder data and HIPAA protects PHI, while GDPR intends to protect PII.

The importance and emphasis given to encryption in various laws, regulations and standards around the world and across industries [exhibit i] make it evident for companies to adopt it across all states the datai goes through. Even if there is no legal or regulatory obligation, though hard to imagine in today’s breach-prone era, it is still in the interest of the companies to protect data from getting into wrong hands.

Data states

The keyword here is state. Throughout its lifecycle, i.e. from point of collection to point of disposal, data broadly falls under one of three states, namely, in transit, at rest and in use [exhibit ii]; all three, conceivably, deserve equal protection. There is no point in investing much time and resources to protect stored data if transmission channels are unprotected, and vice versa. The following paragraphs summarize the changing states of data, highlighting some of the encryption best practices for each.

At rest

While there is no commonly agreed definition of “Data at Rest” (DAR), it largely refers to inactive data that is stored in digital form in databases, spreadsheets, or any other persistent storage media such as disks, tapes etc. Data that is stored in computer’s random access memory (RAM) or is being processed by the CPU is usually excluded from this definition and is instead termed as “Data In Use” (DIU) [8].

The need to protect DAR is growing with every passing day as it is a prime target for unauthorized individuals, especially since data is stored in high volumes at various places and often forgotten about. Going by the frequency and nature of recent data breaches, it is only a matter of time before such data will eventually fall into wrong hands. Seemingly the only way to protect data from unauthorized disclosure is to encrypt it in storage.

The first, and arguably the most arduous task, is to locate where your sensitive data resides. Considering that such data may be stored in structured (e.g. database) or unstructured format (e.g. spreadsheets, files and folders), it is essential to also look outside the organizational perimeter (e.g. offsite backups, mobile devices and cloud).

Secondly, keeping track of the changing value of data over time is vital. Once it is known what data is to be encrypted, the appropriate type and mechanism of encryption is selected – it is crucial to strike an optimum balance between security and operational overhead, and avoid risks of over or under protection. Common encryption approaches include Transparent Data Encryption (TDE), Column-Level Encryption and Full Disk Encryption (FDE).

TDE encrypts entire database and hence no applications are required to be altered in order for encryption to run correctly; data is encrypted when stored and automatically decrypted when called into system’s memory, thus providing transparency. In contrast to this, column-level encryption is more granular as it allows for individual columns within a database to be encrypted. While it increases flexibility by allowing the use of separate encryption keys to encrypt different columns, it affects database performance and lowers the speed of indexing and/or searching.

Now, the fact that encrypted database running on a potentially vulnerable operating system is far from secure brings yet another category of encryption into forefront–file-system encryption, which encrypts the operating system underlying the database. Depending upon what it encrypts, it may be called file encryption (encrypting specific files), folder encryption (encrypting chosen directories) or disk encryption (most commonly, the full-disk encryption which encrypts entire disk, not just specific files or folders). Since FDE encrypts entire disk, a file no longer remains encrypted when extracted out of the disk (e.g. emailed). It is for this reason that disk encryption works well in conjunction with file encryption, which ensures a file remains encrypted throughout.

In addition to knowing what data is to be encrypted, it is equally central to know when to use which type of encryption.

In transit

“Data in Transit” (DIT), as apparent by its name, refers to data that is being transmitted, over public or untrusted networks (e.g. internet, DMZ) or private networks (e.g. enterprise LAN, VPN). It is important to secure data as it moves across such transmission channels, since it can be easily tapped (e.g. sniffed) by unauthorized individuals or inadvertently sent to wrong recipient. Encryption of transmission channels is a key measure to protect confidentiality of data; common transmission channels include web access, email, file transfer, remote access and wireless access. Generally accepted best practices for encrypting each of these channels are summarized below.

Where the data is accessible via web interface, web traffic must be transmitted over secure channels using only strong security protocols such as Transport Layer Security (TLS)iii, which ensures that the connection between the client (e.g. web browser) and the server can be trusted.

Email by itself is not considered secure unless cryptographically strong email encryption tool such as Pretty Good Privacy (PGP) or Secure/Multipurpose Internet Mail Extensions (S/MIME) is used. Alternatively, prior to sending the email, user should encrypt data using file encryption and attach the encrypted file to email for transmission.

File transfers can be secured using FTP over SSL/TLS (FTPS), SSH File Transfer Protocol (SFTP) or Hypertext Transfer Protocol over SSL/TLS (HTTPS), each automatically and transparently encrypting data and preventing it from being sniffed in transit. FTPS and SFTP may often be mistaken to be the same but they are amply distinct; nonetheless, both facilitate encrypted communication using a combination of symmetric and asymmetric algorithms.

A user connecting to corporate network via remote access can potentially do everything that a user with direct access can. It is for this reason that a user’s need for remote access must be monitored closely and such access configured using secure means, such as Remote Desktop Protocol (RDP) and tunnelling remote sessions through Internet Protocol Security (IPSec).

Where data is accessible over wireless networks, it is a good idea to employ cryptographically strong wireless encryption standards such as Wi-Fi Protected Access II (WPA2) to connect to the network. In contrast to its predecessor WPA, WPA2 mandates the use of Advanced Encryption Standard (AES). WPA and the earlier known Wired Equivalent Privacy (WEP) were deemed vulnerable and hence no longer advisablei

Perhaps the most recent application of securing data-in-transit comes from WhatsApp, which implemented end-to-end encryption of all user communication (including images, audio, video and others) via its IM service [12]. Messages are encrypted as they leave sender’s device and are only decrypted by recipient’s device; in between, they are supposedly unintelligible to anyone including cybercrime perpetrators, law enforcement agencies and even WhatsApp.

Now, whether this is good for internet security [privacy] or bad for national security is potentially perilous to comment on, especially in the postSnowden era [13]. Nonetheless, many technology companies have also started bolstering their encryption methodologies, making it apparent that the want and need for privacy continue to grow.

In use

Traditionally, “Data in Use” (DIU) has referred to active data stored in a nonpersistent digital state such as in computer RAM, CPU caches etc. It is equally vital to protect DIU, as compromised DIU may expose DAR and DIT, e.g. someone with access to RAM can parse it to locate the encryption key for DAR and thus decrypt the encrypted DAR. Full Disk Encryption (FDE) is largely considered a mode of encrypting DAR, but the fact that it encrypts the entire disk, including the swap space (space on a hard disk used as the virtual memory extension of the RAM) and temporary files, also makes it a mode of encrypting DIU.

While the earlier definition of DIU still holds its grounds, in today’s cloud-enabled world, DIU largely comprises data that is being held or processed by cloud-based Software-as-a-Service (SaaS) applications. Since there may be risks around data disclosure especially with third-party Cloud Service Provider (CSP) providing a multi-tenant shared computing and/ or storage environment, protecting DIU becomes evident [14]. Encryption, again, is a key measure; however in case of cloud, encryption has not been without its challenges. Historically, processing had to be carried out on decrypted data, so even if encrypted data were provided to the CSP, it had to be decrypted prior to any and every processing operation. This led to security vulnerabilities as well as somewhat defeated the efficacy of encryption.

Out came the concept of “Homomorphic Encryption”, which made it possible to perform operations on encrypted data. In 2013, IBM inventors received a patent for this breakthrough encryption technique [15], which, in simple form, can be represented as Dk(f(Ek(a), Ek(b))) = f(a, b); where a, b is plain text data, Ek/Dk is the encryption/ decryption algorithm with key k, and f is the operation performed on a, b [16]. What this equation translates into is that the result of performing an operation on encrypted data, when decrypted, is same as the result of performing the same operation on original (unencrypted) data. The utility of homomorphic encryption lies in the fact that customers can leverage the CSP’s data capabilities while retaining the custody of that secret key. Rightly then, successful and practical implementation of fully homomorphic encryption promises unparalleled efficiencies and security of cloud data processing.

Honey Encryption is another breakthrough technology designed to produce encrypted text, which, when decrypted with any of a number of incorrect keys, yields plausible-looking but fake plaintexts called honey messages.

Examples of Breach

[Data at Rest] In 2012, TD Bank, one of the largest regional banks in US, misplaced two unencrypted backup tapes containing personal information of over quarter of a million customers. [9]

[Data in Transit] In Heartland’s data breach of 2009, fraudsters gained access to the corporate network and installed a sniffer that allowed them to captured payment card data as it moved within the network [11]

[Data in Use] The Target Corporation’s data breach of 2013 that exposed payment card data of 70 million customers was a result of memory-parsing malware, which infected the retailer’s POS terminals and captured payment card details stored in computer’s memory [18]

Key to success

Just as adopting appropriate encryption type, technology and key length are important, so is protecting the keyv . Imagine a company that selects most advanced encryption algorithm with largest possible key size, but fails to protect key(s) from unauthorized access – the consequences are evident.

As companies go about managing their encryption routines, be it to enhance their data governance states or to comply with the GDPRs, the PCI DSSs, the HIPAAs or the SOXs in today’s world, they are likely to be inundated with a number of encryption keys that they must manage. It isn’t straightforward to manage the keys, for, they themselves have a lifecycle starting from generation to destruction, and strict controls must be implemented at every stage. Mastering the art of key management is indeed a key to success.


In addition to encryption, which is explicitly stated under Article 34 of GDPR as a safeguard to render personal data unintelligible to unauthorized individuals, “pseudonymisation” is another measure that GDPR refers to in various articles and recitals. Pseudonymisation (not to be confused with anonymisation) involves replacing PII or other direct identifiers with artificial information so that the data can still be associated with a particular individual without the individual being identified. It renders data, neither anonymous nor directly identifying, reasonably reducing the risk of harm to data subjects. Data controllers that utilize this measure may also be able to avoid breach notification to data subjects.


Cyber breaches have created myriads of headlines in the recent times, fuelling numerous discussions, debates, forums, articles and surveys on the web. What’s interesting to note is that, a common talking point to most of these breaches has been encryption, or the lack of it. In fact, in recent times encryption has been in news as much as actual breaches. Be it famous cases such as FBI vs Apple ruckus, the stance on encryption by prime ministers of two of the most powerful nations on the planet, or new scenario-based encryption guidance issued by Information Commissioner’s Office in the UK [19] – one thing is certain; today encryption is being discussed at the highest levels from corporate boardrooms to national security agencies as a key safeguard in assuring confidentiality

Cyber security isn’t only about protecting confidentiality of data, which is only onethird of the approach; the remaining twothird comprises integrity and availability. Even the smallest of business today, captures and/or processes sensitive data, such as customer information, financial information, or trade secrets, which, if exposed, will surely cause concern, litigation notwithstanding. Encryption, again, is a go-to defense mechanism in shielding such data from falling prey to unauthorized set of eyes. Even when other defense measures such as firewalls or authentication credentials are compromised, encryption stands tall to foil the malevolent plans of cyber criminals.

Corporations employ encryption to protect their trade secrets and customer/ employee information, while governments use encryption to protect classified information, such as national secrets. Even individuals are greatly benefitted by the use of encryption, for it has a profound impact on their daily lives. It empowers them to protect their most sensitive and important information that is ubiquitously broadcast by many gen-next devices including smartphones, smartwatches, fitness bands and other wearables.

While its importance is indisputably renowned, encryption, as indicated by many studies, hasn’t really kept up with the changing times; for example, results of a survey conducted by Sophos [20] show that while servers, PCs and laptops are more or less encrypted in an enterprise, gen-next devices such as smartphones, tablets and wearables still need to catch up. Unfortunately, in a modern enterprise, the fact that such devices proliferate, store large volumes of personal data and are innately mobile, makes them attractive targets for hackers, and can lead to quite painful ramifications, particularly with the scale of fines the GDPR entails.

Encrypting sensitive data and effectively managing the encryption keys can help mitigate, up to a certain extent, the risks of unauthorized access and/or disclosure. However, it is important to note that additional controls in the areas of physical and logical access, network security, logging, auditing, etc. must be implemented in conjunction with encryption for effective and holistic mitigation of some of these risks. After all, encryption is often only the last line of defense from a cyberattack, though in this case, last is certainly not the least.

While countless benefits offered by encryption cannot be refuted, it is not a perfect solution without side-effects. Though created as a defence against cyber-crime, encryption is also being used to perpetrate crime – Ransomware being a notorious illustration of that. Ransomware is a malware that encrypts files residing on the infected device or network and triggers ransom demands. One who pays the money (usually in digital currency) gets the decryption key and is back to business as usual. One who doesn’t pay loses the data.

Besides, criminals use encryption to mask their doings and avoid being snooped on by the law enforcers – the recent Paris attack is frequently quoted as a pertinent though controversial case of how this technology can be misused.


GDPR is a judiciously drafted regulation. Some of its requirements may seem arduous, but, it does deliver practical opportunities that data controllers and processors must look to leverage. The problem of complying with the stringent breach notification rule under GDPR may be new but the solution is not – strong encryption, supplemented by robust incident management practices, will go a long way.

It is worth reiterating that encryption is a useful tool not only for complying with some requirements of GDPR (or a multitude of other regulations), but also for enhancing general cybersecurity posture. It helps companies exhibit their commitment towards protecting what’s often termed as currency of the digital world – information.

About the authors

Prakhar Agrawal is a Senior Manager with the Consulting practice of EXL Service UK Ltd. With over 12 years’ experience in the field of IS/IT risk advisory, data protection and regulatory compliance, Prakhar has led several projects for top tier clients globally, across diverse industry sectors. In his current assignment, Prakhar is assisting a UK-based leading general insurer in managing multiple work streams on their GDPR implementation program and providing subject matter expertise. He is a Certified EU-GDPR Practitioner, Certified Information Privacy Technologist (CIPT), holds CISM & CISA licenses from ISACA and is a Prince2 practitioner. Shweta Agrawal is a Manager with the Consulting practice of EXL Service UK Ltd. With over 10 years of experience in helping companies enhance their technology risk and compliance profiles, Shweta has carried out multiple projects across North America, Europe, Asia and Africa, focusing on BFSI and telecom sectors. She is a certified ISMS Auditor, has cleared ISACA’s CISM, CRISC and CISA exams and is currently pursuing IAPP’s CIPT credential.


  1. Final text of GDPR | | Brussels, 6 Apr 2016
  2. PCI DSS v3.1 | https://www. QRGv3_1.pdf Cybersecurity and GDPR, the Importance of Encryption | 13
  3. HIPAA | CFR-2007-title45-vol1/pdf/CFR-2007-title45- vol1.pdf
  4. GLBA | PLAW-106publ102/pdf/PLAW-106publ102.pdf
  5. PIPEDA |
  6. DPA |
  7. ISO 27002: 2013 |
  8. | May 2016
  9. TD Bank | | Mar 2012
  10. “PCI DSS Quick Reference Guide” (Understanding the Payment Card Industry Data Security Standard version 2.0) | Oct 2010
  11. “Heartland Payment Systems: Lessons Learned from a Data Breach” (Julia S. Cheney)| Jan 2010
  13. Snowden
  14. “SecaaS Implementation Guidance - Category 8 // Encryption” | Sep 2012
  15. “Made in IBM Labs: Advancing Privacy and Security in the Cloud” (Patented cryptography invention enables unlimited analysis of encrypted data) | ARMONK, N.Y. 23 Dec 2013
  16. “Secure Cloud Computing through Homomorphic Encryption” (Maha TEBAA, Said EL HAJII) | International Journal of Advancements in Computing Technology (IJACT) Volume5, Number16 | Dec 2013
  17. “Honey Encryption: Security Beyond the Brute-Force Bound” (Ari Juels, Thomas Ristenpart) | Jan 2014
  18. Target Corporation | | Dec 2013
  19. “ICO releases new encryption guidance” (Peter Brown, Senior Technology Officer) | Mar 2016
  20. “The State of Encryption Today” (Results of an independent survey of 1700 IT managers) | A Sophos Whitepaper | Dec 2015

i. This article may use the terms “data” and “information” interchangeably
ii. Nature and business of the organization, geography and regulatory implications would dictate what data is considered “sensitive”
iii. SSL 3.0 was considered safe until October 2014, when the POODLE vulnerability came to light
iv. PCI DSS v2.0 prohibited the use of WEP as a security control under its Requirement 4 [10]
v. For the sake of simplicity, this article has not made a distinction between different types of keys such as symmetric/asymmetric, public/private etc.


  1. AES Advanced Encryption Standard
  2. CPU Central Processing Unit
  3. CSP Cloud Service Provider
  4. DAR Data at rest
  5. DIT Data in transit
  6. DIU Data in use
  7. DMZ Demilitarized Zone
  8. DPA Data Protection Act of 98 (UK)
  9. DPO Data Protection Officer
  10. FDE Full Disk Encryption
  11. FTP File Transfer Protocol
  12. FTPS FTP over SSL/TLS
  13. GDPR General Data Protection Regulation
  14. GLBA Gramm-Leach-Bliley Act
  15. HIPAA Health Insurance Portability and Preventability Act
  16. HTTPS Hypertext Transfer Protocol over SSL
  17. IM Instant Messaging
  18. IPSec Internet Protocol Security
  19. ISO International Standards Organization
  20. LAN Local Area Network
  21. PCI DSS Payment Card Industry Data Security Standard
  22. PGP Pretty Good Privacy
  23. PHI Protected Health Information
  24. PII Personally Identifiable Information
  25. PIPEDA Personal Information Protection and Electronic Documents Act
  26. RAM Random Access Memory RDP Remote Desktop Protocol
  27. S/MIME Secure/Multipurpose Internet Mail Extensions
  28. SaaS Software as a Service
  29. SFTP SSH File Transfer Protocol
  30. SOX Sarbanes Oxley Act
  31. SSL Secure Socket Layer
  32. TDE Transparent Data Encryption
  33. TLS Transport Layer Security
  34. VPN Virtual Private Network
  35. WEP Wired Equivalent Privacy W
  36. PA Wi-Fi Protected Access
  37. WPA2 Wi-Fi Protected Access II

Contact US