Chapter 2: The Pillars of the GDPR

The Pillars of the GDPR

Understanding the pillars of the GDPR can help us understand and interpret our responsibilities as business owners to ensure GDPR compliance and strong policies within our organization.

Let's take an in-depth look at these core concepts of the GDPR and how we should navigate them.

Pillar 1: Purpose and Proof for Data Handling

Gone are the days when apps and websites can collect any and all information possible from users without the users knowing. The GDPR is doing away with shady data collection practices and leveling the playing field for businesses that respect the privacy and desires of their data subjects.

Under the GDPR, data controllers must have a legal basis for collecting and processing the personal information of their users. Without an adequate reason, data controllers are not permitted to collect or process personal information. It's as simple as that.

In addition to requiring an adequate purpose for personal data handling, the GDPR also requires proof on the part of the data controller to ensure they are acting in accordance to the law.

Data controllers and processors are required to document the data they have collected, the data they have processed, and the reason for doing so so that they can present these records to the proper authorities as proof of their compliance with the GDPR if need be.

This documentation should include the following:

• All types of personal data in your possession
• The reason why it was collected (including proof of the data subject's consent, if applicable)
• The lifecycle of the personal data in your possession (how long will you retain it?)
• Any data processors, third-parties, or other entities with whom you have shared the data
• Your legal basis for collection and/or processing all data in your possession

See Chapter 5 for more information on "legitimate interests" and when you can use that as your legal basis for data processing.

Collect and Keep Data Only as Needed

A misunderstanding that many business owners have is that once they collect personal data from one of their users, that data then belongs to them and they can do with it as they wish. This actually contradicts several sections of the GDPR.

In order to be compliant with the GDPR, you must only collect data with a sufficient legal basis to do so, and you should only retain that information for as long as it is actually needed for the intended and communicated purpose.

So, having a legal basis to collect personal data from one of your users allows you to obtain that data, but once you are finished using that data to complete the task you had a legal basis for, the data should then be deleted or completely anonymized to remove any connection to the data subject.

Retaining personal information for only a limited time reduces the need for ever growing data storage, encourages efficient use of collected data, and significantly reduces the risk to data subjects in the event of a data breach.

By setting a lifespan for the personal data that you collect and process, your users are no longer at risk of their data being compromised after the set amount of time when their data is processed.

Pillar 2: Data Security

The GDPR aims to reduce security risks to data subjects by increasing the responsibilities and expectations of data controllers and processors.

Article 32 of the GDPR states that data controllers must have sufficient security measures in place appropriate to the sort of personal data they handle and in light of the potential risks involved.

Essentially, this declaration puts the full responsibility of data security on the data controller to ensure that the privacy and personal data of their users are adequately protected by modern measures.

Some recommended and expected measures you should take in order to ensure you have adequate security measures in place to protect your data subjects' personal information include:

• Using SSL encryption
• Applying data anonymization/pseudonymisation
• Erasing nonessential data

Encryption should be used at multiple stages in your processes when possible to ensure that the data is secure, even if it is stolen or you are the victim of a breach.

A German chat app recently faced a €20,000 fine after a data breach exposed that the company had been storing user passwords in plain text files. This company did everything right in notifying its users and the proper authorities of the breach, and it would seem that the fine came simply as a result of the lack of encryption.

Had the data been properly encrypted, the passwords that were stolen in the breach would have been uninterpretable and useless as a result of encryption. But since this data was stored as plain text without any encryption, it was left vulnerable and not compliant with the privacy protection requirements set forth in the GDPR, thus the fine.

Modern day encryption is usually in the form of SSL 256-bit keys that turn easily understandable information such as a text document into an unintelligible jumble of characters that must be unencrypted before it can be understood. 256-bit encryption is virtually uncrackable, meaning even if someone were to steal the content of your encrypted database, the content would be unintelligible without the encryption key to decode it.

Pseudonymisation and Anonymization

Pseudonymisation is a process where data is substituted according to a system so that it is not easily identifiable without knowing the pseudonymization system or by cracking the code.

For example, a very basic form a pseudonymization would be a simple cipher where one letter is replaced with another letter or symbol. This might look something like this:

A=1, B=$, C=F, D=!, E=P, etc.

If you took the word "DAD" and applied the cipher it would become "!1!." Or if you took the word "CAB" it would become "F1$."

While this extremely simple version of pseudonymisation is not enough for modern internet security purposes, you can see how even a form as simple as this can make data more difficult to detect and understand. If an unauthorized entity were to take a look at account information in your pseudonymized database, it would be much more secure for the account owner if their name was displayed as "1$P" instead of "ABE."

However, with access to an entire database worth of information, it would be possible to crack a simple pseudonymization cipher and decode the information within.

Some other weaknesses of pseudonymization are the ability to find patterns. Even if the cipher is not cracked, the name "ABE" would appear as "1$P" in every instance which could give away some information and show a pattern. In some cases, a pseudonymized name or unique identifier would still behave as a unique identifier because it is consistent, even though pseudonymized.

But make no mistake, pseudonymization can be a powerful security measure to use in your projects. While not infallible, and not sufficient for securing your database in and of itself, using any form of pseudonymization is far better than doing nothing at all. Advanced pseudonymization techniques can be much more difficult to crack and offer much higher levels of security.

Article 3 of the GDPR refers to pseudonymization where it mentions using methods of data processing that require "additional information" to be interpreted. Pseudonymization is one such method requiring a cipher to interpret the data.

Anonymization is another method of converting sensitive data into a less interpretable form. It uses a slightly different process to camouflage data, offering some advantages and disadvantages compared to pseudonymization.

Anonymization by definition (Recital 26 must alter the data in a way that it is irreversible.

Unlike ciphers and other methods used in pseudonymisation which can be cracked and decoded, anonymization is a permanent and irreversible process. In fact, true anonymization completely erases any personal information from an entry to the point that it is no longer identifiable (or useful) to the data controller securing it.

For this reason, there are some methods that can be used to anonymize data without losing all of its value.

One useful way to implement personal data anonymization is to anonymize all unnecessary information after it has been used.

For example, if a user on your website fills out a survey with some information about himself that you will be using to make insights about your business model, you can anonymize that data after you complete the study.

Instead of having a survey that says John Smith likes your new homepage and Jane Doe dislikes your new homepage, you can anonymize the results by simply saying that 50% of your users prefer your new homepage. This result is free of any identifying information.

The trick to using anonymization for data security is to remove any information that can be used to link to an individual while still retaining useful information for your analytics. This isn't always obvious or easy, and you should think back to how the GDPR defines personal data to determine what can be considered identifying information.

Pillar 3: User Rights

User rights create a balance between the data subjects and data controllers. This balance of power makes the relationship between data subjects and data controllers a give and take rather than the data controller holding all of the cards.

These rights are discussed thoroughly in Chapter 6.

Pillar 4: Transparency

The final pillar of the GDPR is transparency on the part of data controllers and data processors.

Privacy Policies are perhaps the most crucial component of transparency. The GDPR has strong guidelines for what should be disclosed to data subjects, and a strong Privacy Policy is an effective way for data controllers to communicate a vast amount of information to their users.

Transparency is also a good way to build a relationship with your users as well as improve your reputation. Keeping your data subjects informed shows that you want what's best for them and lets them know what you are doing to protect their personal information and privacy.