A developers guide to GDPR

Subscribe to my newsletter and never miss my upcoming articles

Have you ever tried to comply with a set of rules you don't know? Well, GDPR can be a lot like that.

Over the last two years, companies have been implementing GDPR and trying to understand how it impacts their digital and physical businesses.

Data and privacy are important, but what does GDPR entail for these businesses?

What is GDPR?

To preface this: I'm currently a law student, but I am not a lawyer. Take everything I say as friendly advice and as my personal experience, not as legal counsel.

This article is not intended for legal use and is intended to help the reader to introduce themselves to GDPR before consulting a legal professional for a consultation.

Now that I got that out of the way, what is GDPR?

GDPR stands for General Data Protection Regulation. It's the core of Europe's digital privacy legislation. It is a set of regulations that the European Commission spent multiple years creating to help regulate personal data and platforms that process large amounts of personal data.

The goal of GDPR is to give EU citizens more control over their personal data.

Why was GDPR actually created?

Good question. GDPR was believed to be a necessity by the European Commission because our laws and regulations were behind the times with how the internet was quickly expanding. We share our personal data on the internet every day, why should that not be regulated?

Because of GDPR, personal data in the EU is legally protected and collected only under strict conditions. Compliance is expected and mandatory, or else the offending organization will receive penalties, that way misuse and exploitation are less common.

Should I worry about GDPR?

Regardless of what you're doing or who you are, the answer is "Yes." It is something you should worry about, although it might not affect you.

Every business has regulations they have to follow, and GDPR is just another regulation. If you run an online business, it likely affects you. If you're region-locked (for example, an eCommerce store in a specific town in the USA) you're probably fine, but anytime you come into contact with an EU user you're subject to these guidelines.

Any startup, side venture, etc that is "open to the public" on the internet is instantly a target for GDPR because there's a chance you'll have EU users. That said, there are guidelines for whether you have to comply with specific terms of GDPR that vary on the size of your platform/software/project.

Some services geolocate ban EU users, try to support GDPR just for EU users, etc but it's usually regarded as a best practice to support GDPR globally and save yourself the work.

How do I implement GDPR then?

Tough question, this will depend on your use-case and what your business is.

Instead of trying to explain every possible situation, I'm going to explain the regulations and requirements around GDPR.

Data Processor vs Data Controller

The first area of GDPR to focus on is whether you are considered a Data Processor or a Data Controller. This will affect how the regulations impact you and what liability you actually have.

First off, what are these two types of entities?

A Data Controller is an entity that receives and controls access to data. The controller actually manages where the data is stored and how it's used.

A Data Processor is an entity that processes personal data on behalf of the controller. The data is handed to the Processor by the Controller to carry out specific duties.

A business is always regarded as one, or both, of these under GDPR.

Let's take a real-life example:

Let's say you track product clicks on your eCommerce store and attach that data to each user, then you forward that (not anonymous) data to your marketing company that creates email campaigns. You are the controller and that marketing company is the processor. If you created the email campaigns internally, you would be acting as the controller and the processor.

What are the expectations of Data Controllers?

Data Controllers have a few expectations, but the primary one is "controlling" their data intake. This means they're responsible for justifying their legal authority in collecting personal data.

To establish legal precedent, they're required to use one of the six bases for data collection featured in GDPR.

Controllers also manage their contracts with Data Processors and are required to notify Supervisory Authorities (SAs) when they have data breaches or are not compliant with regulations. If a Data Protection Officer (DPO) is required, it is the Controllers responsibility to appoint a compliant DPO.

Their last responsibility is to have a public Privacy Policy that outlines the following:

  • What data they collect
  • How they store the information
  • How they use the information
  • Whom they share the data with
  • Whether they share the data with third parties
  • When and how they delete the data

It's important to regulate who, externally, has access to personal data when sharing data with Data Processors and external sources. Make sure to note why and where the information is shared.

What are the expectations of Data Processors?

Data Processors have fewer expectations than Controllers, but they have one primary expectation: To fulfill their guidelines as provided by Controllers. They are also responsible for notifying Controllers about data breaches and relaying user requests to their Controller.

Data Processors must follow all security guidelines, including but not limited to encryption, protecting data from destruction or loss, and appointing a DPO to oversee data processing when required.

Under GDPR, documents like a Privacy Policy and Terms of Service are required documents. These allow you to outline your legal guidelines, compliance information, and how you handle personal data.

Legal Policies are something you should consult a Lawyer about while keeping GDPR in mind. These documents are the foundation for legal compliance.

Appointing a DPO

A Data Protection Officer, or DPO, is an independent member of your organization (whether you're a Processor or Controller) that is responsible for educating the company and its employees about compliance, training staff involved in data processing, and conducting regular security audits.

DPOs also serve as the point of contact between the company and any Supervisory Authorities (SAs) that oversee activities related to data.

A DPO is a necessity if you're going to grow past your first few hundred users and if you'll be processing a lot of data. Usually, these roles are for established businesses, but even some projects with teams of 3+ members should appoint an "acting" DPO.

The guidelines around DPO appointments are very vague and conflicting in GDPR, but a few things are pretty clear:

  • Your DPO cannot have any conflict of interest with their ability to monitor data, this generally would include being a legal representative of the business or working with the data directly (legal counsel, pr rep, data engineer, executives, etc).
  • Your DPO should have "expert knowledge of data protection law and practices"
  • Your DPO should be easily accessible (within 24 hours) in case of emergency
  • Your DPO should be able to operate freely, with the ability to audit any/all departments that work with data and be able to report issues to the proper SAs

A proper DPO understands infrastructure, data, organizational structure, and can be relied on to oversee operations and train departments around data processing and security.

Appointing a DPO is required when either a company:

  1. Is a Public Body (publicly traded or owned)
  2. Processes a large amount of data that requires monitoring
  3. Holds special categories of data (criminal history, social security, race, political opinions, sexual or gender identity, etc)

It can be hard to know when you need a DPO and when you don't, so it's best to ask a professional versed in GDPR to help you make the decision.

Conflicting Regulations and Policies

In some cases, outside regulation or policies can impact your ability to comply with GDPR.

GDPR has a few clauses to work around this, like allowing you to store data you require for operation for the minimum time required.

An example of this would be when FinTech or MedTech requires storing personal data for 5+ years prior to being able to delete it. Those regulations would supersede GDPR, but you'd be required to delete that data at the soonest possible time.

Another example would be if you build around a service and they take on a role of Controlling the data you receive (If you run, say, a Discord chatbot), you'd then be more of a Data Processor and they would take on a lot of the liability for the data you process as the Data Controller.

These are edge cases and you should always consult a lawyer before deciding how to handle these situations.

Take a Break

Get up, stretch, maybe take a drink of water. We still have more important stuff to cover.

User Onboarding

An often-overlooked part of GDPR is how you handle onboarding new users.

Onboarding users is the flow of signing up a user, setting up their account, and "onboarding" them to your product/service.

This is less legal, finally, but a good onboarding is important for GDPR. We have the traditional "accept our privacy policy" "accept our terms of service" but an onboarding goes beyond just checkboxes.

A GDPR-compliant user onboarding only requests the minimum needed data for a platform to operate, this means you're asking for their name, their email, etc, not their race, gender, so on. Some platforms require this "special data," but it should be avoided unless you have legal grounds to defend your reasoning.

We may think this data is harmless to collect, but it's all information about identity and that is personal information we rarely need (and it just infringes on their right to privacy).

Data Storage

One of the most important parts of GDPR is data storage. This is a clause that applies to all EU personal data, making it the only real blanket clause in GDPR.

All data that is stored must be deleted once there is no defendable reason to store it and all data must have “appropriate technical and organizational measures” of personal data security. GDPR repeatedly highlights encryption and pseudonymization as methods of achieving this.

So, while this doesn't explicitly state you need to encrypt your data, you will be liable if personal data is not secured.

Right to be Forgotten

This is one of the sections that concern engineers the most, a users "Right to be Forgotten."

Right to be Forgotten is a tricky clause because in some cases if a user requests to be forgotten, you have to delete or anonymize their data in your systems. For established platforms, this was a major shift in how they handled data and required a lot of refactoring to make possible.

Right to be Forgotten does not always apply, for example, if you require their information to operate (remember the FinTech/MedTech example) you do not have to purge their required information but instead just the information you don't need for operation.

Other kinds of required information could include IPs you've banned for service abuse, legal records you have to maintain (such as payment records), and more.

It's especially important to pay attention to these requests when they are a child, as you're not allowed to store data on people under the age of 16 per GDPR.

If you have shared data with a Data Processor or other entity, you are required to notify them about the Right to be Forgotten so they can properly erase the personal data they store.

Data Releases

A much scarier section of GDPR is Data Releases. These are collections of all of your personal data on a platform or service.

These releases are something every organization that meets certain requirements has to provide within 30 days of it being requested. These requirements are as follows:

  • 250+ employees
  • Being at a "large scale"

These data releases are intended for "large businesses," which explains 250+ employees but "large scale" is still vague.

In previous drafts of GDPR, "large scale" was defined as 5000+ data records, so if you ever expect to reach that scale it's best to plan around data releases early on. Implementing them later is much more difficult.


The most important thing I've discussed today, non-compliance.

Failing to comply with GDPR has penalties in the forms of fines. This fine could be up to 10,000,000 euros (or 2% of annual turnover) for mishandling data or 20,000,000 euros (or 4% of annual turnover) for infringements on the rights of data subjects, unauthorised international transfer of personal data, and failure to put procedures in place for or ignoring subject access requests for their data.

Reasons for penalties can include failure to report data breaches, failure to build data protection systems, and failing to appoint a DPO.

Penalties vary based on severity and if an organization has been seen to take proper actions previously to protect personal data and privacy.

Closing Notes

I'd like to stress that GDPR is not simple and I have only covered the basics. There's so much more to it and you should consult a proper legal counsel before making decisions based on the contents of this article. This article has potential errors

As a previous DPO, I have a good amount of experience with GDPR and can be reached at my email for consultations on GDPR or referrals to a lawyer experienced in GDPR.

I want to thank you for reading and invite you to share this article with people who you think need it. Have a great day ✌

No Comments Yet