Technologies Required for GDPR, Part 3


The GDPR explicitly talks about the use of pseudonymization as a means of protecting personal data. In practice, pseudonymization means separating data elements that can be used to identify a specific person – such as their name or common identification number (e.g., passport number or Social Security number) – from the data being tracked (e.g., the book purchased). It is not a failsafe approach per the data protection requirements of GDPR, however, because pseudonymized data can be re-identified to a specific natural person through various organizational and technological means. Fully anonymized data, on the other hand, is unable to be re-identified to a specific natural person unless new information is supplied to enable the re-identification process.

Various vendors offer means of pseudonymizing or masking data, encrypting identifying data, or even encrypting identifying data inside structured data sources, such as databases. These technological methods can be combined within organizational approaches to greatly reduce the likelihood of personal data being compromised, leaked, or exposed unnecessarily. For example, a common valid use of personal-type data is in software development and testing environments, and also for analytics and reporting purposes. If data is pseudonymized for these purposes, identifying personal data is not disclosed unnecessarily, and is also not left lying around in less protected or unprotected data sources that could be compromised through a targeted attack.

One reason that pseudonymized data is not considered a failsafe approach is that if the lookup source data or encryption keys are compromised through a data breach, personal and potentially personal sensitive data can therefore be exposed too. The GDPR still recommends the use of pseudonymization, but organizations that use products and services to implement this method are not given an automatic exemption to data protection requirements under the Regulation.


Data subjects have the right to request an export of their data in a usable format that can be given to another vendor or service provider to import into its service. Data subjects can request that organizations provide this data to them directly or transfer it to the new vendor. Current data schemas and storage methods need to be examined to ensure an export is feasible, economical, and timely, and products and services to facilitate the portability requirement should be explored for implementation. Enabling customers to perform their own export of personal data through a secure, self-service web interface is a good way of balancing access and economics.


Computing devices need to be protected from loss or theft through mobile device management capabilities, such as remote wipe and kill. A lost device could be the weak link in the data protection chain, leading to a data breach based on information stored on the device or accessible through still active user credentials. Enforcing certain settings in order for a device to connect to the network at all – such as local encryption, password complexity, the presence and currency of security software, and the removal of the local administrator account – will be an essential part of protecting the organization within the GDPR framework.


Perimeter security – erecting defences to keep malicious actors out – was essential when organizations ran data centers and other on-premises infrastructure. In the age of multiple cloud services the “perimeter” is much harder to control, but technologies that monitor perimeter security should still be one element of the security defences maintained by organizations. Security over the data itself is becoming more important (hence the essential requirements around data discovery, classification, and encryption), and perimeter security is less able to dissuade internal malicious actors, such as a disgruntled employee, from doing harm from the inside.

Technologies Required for GDPR, Part 4