There are many documents related to GDPR regulation, but they’re not always easy to understand. In Part 1 of this series, “Getting started with GDPR Compliance,” we’ll look into basic concepts about the GDPR and how we can get started implementing it.

What Is the GDPR?

The General Data Protection Regulation (GDPR) will replace the Data Protection Directive 95/46/EC (Directive). It applies to all EU and foreign organizations offering goods/services to individuals in the EU and handling personal data of EU residents.

It even applies to companies that are not registered in Europe but have European customers.

Approved by the EU Parliament on 14 April 2016.

Enforcement date: 25 May 2018

Basic Definitions:

Controller: The legal person or agency that determines the purpose of processing personal data.

Processor: The organization that processes that data on behalf of the controller.

3rd party: Any product/service provided by an organization that you're using in your system - through their API, like Google APIs and others.

Data subject: User, i.e. the person who is using your product/service.

Personal data: Basically, it's every piece of data that can be used to uniquely identify a person. Data that the user has explicitly provided, but also data that you have collected about them from either third parties or based on user activities on the site.

Supervisory authority: An independent public authority which is established by the EU Member State.

To Whom Does the GDPR Apply?

The GDPR applies to ‘controllers’ and ‘processors.’

What Is the Penalty if an Organization Isn't GDPR Compliant?

The GDPR establishes a tiered approach to penalties for breach:

Fines for some infringements of up to 4% of annual worldwide turnover or 20 million Euros, whichever sum is higher (e.g. a breach of requirements relating to international transfers or the basic principles for processing, such as conditions for consent).

Other specified infringements will incur a fine of up 2% of annual worldwide turnover or 10 million Euros (again, whichever is higher).

The following 2 chapters contain the significant changes that need to be considered and implemented:

Principles (Article 5 - 11) - This chapter discusses things related to User consent and user’s data processing. “Privacy policy” and “term and conditions” related changes, such as how the user should explicitly give their consent and can withdraw consent at any time, age check, etc.

Rights of the data subject (Article 12 - 23) - The end user has full control over their data. The data should only be accessed with user’s permission and should be erased upon the user’s request. This chapter discusses all the rights of the end user.

Controller and Processor (Articles 24 - 43) - The responsibilities of the controller and processor are discussed, followed by a discussion of the various roles, such as duties and responsibilities, of the DPO - Data Protection Officer.

Cooperation and Consistency (Articles 60 - 76) - This discusses cooperation between supervisory authorities and the responsibilities incumbent upon the board and other entities to ensure the consistent application of the GDPR regulations.

What Should We Do to Make Our System GDPR Compliant?

Principles (Articles 5 - 11)

This seems to be the biggest change that the regulation brings. "I accept the terms and conditions" will no longer be sufficient to claim that the user has given their consent for processing their data. So, for each particular processing activity, there should be a separate checkbox on the registration (or user profile) screen. You should keep these consent checkboxes in separate columns in the database, and let the users withdraw their consent. Make the consent prominent and separate from “terms and conditions.”

You should ask for the user's age, and if the user is a child (below 16), you should ask for parental permission. The crux of "article 20" is you have to have a way to give users their data in whatever way.

This seems like an obvious rule, but it isn't always followed. Users must be able to fix all the data a company has about them, including data that you have collected from other sources (e.g. using a "login with Facebook" you may have fetched their name and address).

In your admin panel, where there's a list of users, there should be a button labeled "restrict processing." The user settings page should also have that button. When clicked (after reading the appropriate information), it should mark the profile as restricted. That means it should no longer be visible to the back office staff, or publicly visible.

If you are providing user data to a third-party, make sure you ask that third-party to delete all the data when a user asks your system to "forget me." Calling the third-party APIs to remove data is not the full story, though. You also have to make sure the information does not appear in search results. Now, that's tricky, as Google doesn't have an API for removal, only a manual process. Most other organizations also don't have regular APIs to remove data from their system.

Other Considerations

Data Encryption:

Secure communication over TLS (HTTPS): All the communication should be over a secure channel, such as TLS, communication between client and server, and server-to-server.

Encrypted Databases: Databases and backups should all be encrypted.

Pseudonymization: When using production data on test/stage a server for testing purposes, make sure you hide actual user data, such that no person is identified.

Make sure you're not using any data of users who haven't agreed to the specific terms and conditions on your system.

Disclaimer: I’ve prepared this document to the best of my knowledge and studies related to GDPR regulation. Professionally, I’m not a lawyer or DPO, I’m a professional software developer, so I may have missed some important legal matters. For a more detailed explanation - check EUGDPR or consult a DPO (Data Protection Officer) who has “expert knowledge of data protection laws and practices.” Responsibilities and appointment of DPOs are discussed here. This document is work-in-progress (Part 2 is underway), so any suggestions are highly welcome.