Getting Started With GDPR Compliance

DZone 's Guide to

Getting Started With GDPR Compliance

Concerned about the upcoming GDPR regulations? Read on to get a developer's perspective on the regulations and how they affect users.

· Security Zone ·
Free Resource

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.

For more details, visit the EU's official doc, WeCognize, and Intersoft-consulting

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 GDPR in a Nutshell

The key changes connected to the GDPR you need to comply with right now.

There is a total of 99 articles, divided into 11 chapters. The summary of each chapter is given below:

What Should We Do to Make Our System GDPR Compliant?

Principles (Articles 5 - 11)

Consent Checkboxes - Terms and Conditions, Privacy Policy updates - Article 7

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.”

Key Takeaways:

  • Make the consent prominent and separate from “terms and conditions”

  • Give the users an option to withdraw their consent.

  • Avoid making consent a precondition of a service

Age Check - Article 8

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.

“Information must be provided without delay and at the latest within one month of receipt. You will be able to extend the period of compliance by a further two months where requests are complex or numerous.”

Rights of Data Subject/User (Articles 12 - 23)

Export Data - Article 20

There should be another button, "export data." When clicked, the user should receive all the data that you hold about them.

See All My Data - Article 15

This is very similar to the "Export" button, except data should be displayed in the regular UI of the application rather than an XML/JSON format.

Allow Users to Edit Profile - Article 16

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).

Forget Me - Article 17

Make sure you provide a "Forget me" option in your app/website, where the user can click to delete all their data from your system.

When does the right to erasure not apply?

The right to erasure does not apply if processing is necessary for one of the following reasons:

  • to exercise the right of freedom of expression and information.

  • to comply with a legal obligation.

Restrict Processing -Article 18

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.

Notify Third-Party of Erasure - Article 19

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:

  1. 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.
  2. Encrypted Databases: Databases and backups should all be encrypted.
  3. 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.

Logging Data:

  1. Logging Personal Data: If you're logging data to your server, make sure no personal data is logged.
  2. Analytics: If you're using analytics in your system, make sure no personal data is used for analytics purpose.


  1. If you're sending data to third-parties for processing, such as data backup, or for the analytical processing of data, it's your responsibility to make sure those parties are GDPR compliant.

Bookmark the permalink for up to date info on GDPR compliance.

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.

data security, gdpr compliance, gdpr regulation, security, security compliance

Published at DZone with permission of Abdul Qavi . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}