Developer Guide to GDPR
It’s been over a year since the GDPR came into full effect, thus panic associated with the changes has already subsided; nevertheless, the GDPR compliance still raises a handful of issues, which we’ll subsequently cover below. TL;DR: there’s actually very little in the regulations that can fundamentally change the way you code, and perhaps you’ve tackled bigger challenges on a daily basis, but just like with accessibility, security, performance, usability, and testing — it’s much easier to build with GDPR in mind than later shoe-horn it into your existing system.
_ Disclaimer : Take everything written in this article with a grain of salt. It’s not legal advice, just a set of recommendations to implement to comply with GDPR; you’re greatly encouraged to seek legal professional advice in case you have any compliance questions or concerns._
GDPR , which stands for General Data Protection Regulation , is a regulation in the European Union law on data protection and privacy of all individuals residing in the European Union (EU) and the European Union Economic Area (EEA). However, it also affects and addresses the transfer of personal data outside the EU and EEA. Even if you’re not residing or operating in the EU but have an online business, there’s a high chance you’ll come in contact with a user from the EU, so the law applies and affects your business. However, there are specific terms of GDPR that you need to comply with depending on the size of your business or project or software or whatever else you’re operating.
The process of integrating GDPR policies largely depends on whether you’re considered a Data Processor or a Data Controller. Let’s briefly outline each of those entities.
A Data Controller is an entity that receives and controls access to data, it 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 Data Controller, where the Controller hands data to the Processor to carry out specific tasks.
Depending on what you do with the collected data and how you process it, you’ll be regarded as either a Data Controller, a Data Processor, or both.
For example, if you’re collecting data from your users on your eCommerce website and then transfer that information to a third-party marketing company, then you’re the Controller, and the latter is the Processor. However, if you process the collected information yourself without the help of any third party, then you’re regarded as both the Controller and the Processor.
The Data Controllers are expected to control their input data; they also have to justify their legal authority in collecting it. Controllers are required to notify Supervisory Authorities (SA) of any data bridges, non-compliance with regulations, and appoint a Data Protection Officer (DPO) if required by the law.
- What data is collected
- Why that data is collected
- How the information is stored
- Whom the information is shared with (including disclosure on any third party)
- When and how the data is deleted
Data Processors need to fulfill the guidelines provided to them by Controllers, as well as notify the latter about any breaches or user requests. Data Processors must follow security guidelines including encryption, protection of data from loss and destruction, and appoint a DPO if required by the law.
A Data Protection Officer ( DPO ) needs to be appointed once your company reaches more than one hundred users. A DPO is an independent member of your company, whose sole responsibility will be educating and training your staff in compliance with GDPR, essentials of data collection and processing.
A DPO is absolutely required if:
- Your company is publicly traded or owned.
- Your company processes large volumes of data.
- Your company holds special categories of data, including but not limited to criminal history, social security, race, and gender identity.
Now let’s get down to some of the core principles outlined by GDPR, the requirements, and your approximate plan of action in addressing each.
The core principle and the main requirement of GDPR are protecting the data you store and only storing what you need as long as you need it, as well as deleting it whenever you stop using it.
The Personally Identifiable Data (commonly referred to as PII ) refers to anything that identifies a natural person and encompasses a lot of data points around it.
A few questions to ask yourself at this point will be
- Do you really need to collect that data?
- Will your feature work without direct identification with the user?
- If you need to store data, identify the values you really need and discard anything else.
This clause is especially important, because if you choose to collect race, gender values, then you should have legal grounds to defend your reasoning for requiring that data from your users. All you’ll probably need is your users’ email address and name.
- How long do you need to store the data?
Do not store data without good reason, consider applying retention policies to data that quickly becomes irrelevant.
- Think of a reasonable level of protection to the data you store.
Protect your data with encryption or limit access to data with the auth and access key.
Another core principle of GDPR is making it easy to retrieve, delete, and anonymize data.
Subject Access and Erasure Requests are among the fundamental rights granted to users by GDPR, which directly implicate that they can request a copy of all data your company holds on them via Subject Access Request ( SAR ) and ask to delete that data via an Erasure Request (a fundamental right to be forgotten); your company, in turn, has to promptly handle that request and satisfy it.
Rules to keep in mind while working your way through developing your website:
- Make sure all data is easily retrievable.
- Make sure your feature or software is designed to deal with deletions or anonymized data.
- If it’s not possible to fully-delete the data, make sure it’s anonymized to the point where it would not be possible to use it to identify the user even when used in conjunction with other data points.
It’s especially important to delete all child data, as you’re not allowed to store data of users under the age of 16.
Also, in case you transfer data to a Data Processor, you must inform them about the user’s request to be forgotten, and ensure they properly erase that data.
Some data might be exempt from deletion for legal and accounting reasons, such as billing and contract records.
Another important part of GDPR is Data Releases , which means the release of the collection of data of all personal information you store on your platform within 30 days of it being requested. You’d better start preparing early one, because when your data reaches more than 5,000 records, or you have more than 250 employees, you’ll be subject for the data release request.
Under GDPR, companies are not allowed to contact users without their explicit permission, including all communication channels like email and text messages. You cannot assume the consent, the user has to perform the explicit action by clicking, subscribing, or checking a box.
To be compliant with GDPR, your users must have a clear way to opt-out from profiling.
Fines are probably what you’re most afraid of and they could be plenty — up to 10,000,000 euros or 2% of annual turnover for mishandling data and 20,000,000 euros or 4% of annual turnover for infringements on the rights of data subjects, unauthorized international transfer of data, ignoring the subject requests for retrieving or deleting data, and for failure to put procedures in place. Other reasons for penalties can include data breaches, failures to appoint DPO or build a data protection system.
Summing it all up, what you should really strive to do is to demonstrate respect for your users and their data, take all the necessary steps to store it securely and protect it, communicate clearly and honestly how you collect and use data to enhance users’ experience or tailor your services to their needs, manage data effectively, and mitigate cyber-security vulnerabilities.