General Data Protection Regulation, or GDPR, is a new EU law about data protection and privacy. You have probably heard it, but what is all this buzz about? The new regulation applies not only to EU businesses but to all companies that have users in European countries. So, basically, to everyone. Maybe, your team has already adopted a part of regulation to your working process. Still, there some information that you need to know as a developer. Let’s look at a few questions you could ask.

1. Is GDPR only for big companies?

It is a myth. However, some processes must be implemented in an organization that has over 250 employees. Also, specific rules apply to companies that process a significant amount of data. These rules include a record of all types of processing activities and even transfer information to cloud service providers. But all other GDPR requirements do not have any exceptions for smaller organizations. So, you should pay attention, too.

2. What kind of information is protected by GDPR?

All information, that we can call ‘personal data’. Put simply, it can be any piece of information that helps to identify a person or some data about an already identified person. 

3. How can you get personal data?

– A user can provide it to you (like in a registration form);– you can collect this data based on activities on the website;– data from third parties (e.g. using a “login with Facebook”). No matter how you get the data, a user has rights to restrict of its processing, export, fix, or even erasure all information about himself. A user should have full access to the data you have about him. The main rules relevant for developers: minimize data, collect only necessary information, and protect data in all possible (and impossible) ways.

4. How exactly to follow this law?

There some features that must be implemented within the regulation. They do not have to be automated, but in the most cases, it would be more comfortable than a manual process. As a developer, you need to be careful with: Data storage. You should delete personal information as quick as possible. If you are collecting data, as an example, for delivery service, it would be better to anonymize information after completing the task. So, you need to delete names and addresses after a certain moment – e.g. the product is confirmed as delivered. You can have some kind of deadline after which all data must be scratched out. In cases of delivery problems deadline can be changed, but you should never keep data longer than it necessary. Informing third parties about deleting data. If you send some information, for example, to Twitter or any cloud, to delete this personal data you have to call their API. In the cases of public profile pages, you should check if this information does not appear in search results. This assignment could be tricky in some cases because there is no API for removal in Google. To remove this information you can assign a 404 HTTP status to the personal data page. Consents checkboxes. One consent checkbox for all processing of personal data does not work anymore. Ideally, there must be a checkbox or yes/no buttons for every processing activity in a registration form or user’s profile. You can keep all consents in separate columns in the database. Some information that is called “legitimate interest” requires no consent checkboxes. Without this information business activity could not be done. As an example, if you run a delivery business, address information will be a legitimate interest. Still, which data is a legitimate interest in your company better to discuss with the lawyer. If you are using personal data for machine learning, you need to get users’ concert, too. Scientific purpose is the only exception, and it has a special section in the GDPR. Pay attention, user’s agreement will not be counted if you use preselected checkboxes. Also, users should have the ability to change their consent. More details – in the section about user’s rights. Also, the regulation requires clearly given consents. If users simply clicked on terms & conditions, you need to ask them to check all permissions they have given on your website. However, think carefully if that re-request is really necessary – we have enough spam after May, 25 :) Age checks. Users must confirm they are older than 16. If your user is a child, to process personal data you should have a parents’ permission. There are no specific instructions on how to do that. One of the variants is to request an email of the parent. Even in this case, you can’t guarantee the child will not fake parent's email or his age. More importantly, you will comply with the law. Cookies. All user’s activity on a website is personal data. So, if you have a tracking piece of code on a website it is your responsibility to protect this information. With GDPR it is not enough to warn users about the cookies. You must have a legal reason for data processing. Here can be a legitimate interest too, but in this case, it will be hard to prove its necessity. You can ask users to consent cookie tracking with a checkbox, but this causes some technical puzzles. Cookies are sent via 3rd party code when the page is loads. Usually, it happens before a user gives his permission, and that is against the law. It is possible to insert the 3rd party code after getting permission, but you will need some fiddling with JavaScript. This process has a usability question because you need literally everyone’s answer. So, you will need a full popup that asks for consent. More about cookies and GDPR read here.

5. What can help to protect personal data?

The backups, data in transit and data at rest should be encrypted. The process depends on the database. For transiting just google “X encrypted connections”. For data at rest, the assignment could also be done on machine-level, for example, with help of LUKS. Pseudonymisation. It allows changing personal data to some “pseudonym” to encrypt information. Basically, user object method can apply hash+salt/bcrypt/PBKDF2 to part of the data that is used for personal identification. In Orale, for example, this feature is built-in. Register processing activities. You must record them all whatever you are doing with personal data. So, GDPR requires implementing at least a simple register in your infrastructure. There another thing you should have – log access to personal data. According to the regulation, this function is not necessary, but keeping an audit log is a best practice. It will make you sure about data security and the absence of unreasonable processing.

6. What about the most common mistakes?

Anonymous API shouldn't have access to your database. For each API you must request the information about the organization and contact person. This data can be put in your processing register. If you want to use personal information to analyze advertising or for machine learning, if you want to change API for some kind of users, you still must get users’ permission on data processing. Every your move concerning personal data should have a consent. Avoid redundant questions in a registration form and in a profile. You don’t need personal information if you cannot prove its necessity. Within new regulation, you are responsible for data protection even at 3rd parties part. So, if you send information to another service, it would be better to check which kind of data protection they have. Pay attention, a big part of GDRP is not covered by information security standards and even personal data standards, so ISO XXX will not be enough.

7. What do I need to know about user rights?

Within the new regulation, users have a right: To have access to full information. Ideally, users should have the full access to data you keep about them. It can be displayed in a personal profile, for example. Furthermore, you must be ready to give all information about personal data and its processing to unregistered users. You can do it in a manual mode checking by email if you have some data about it. To export data. Similar to the previous point, this is a users’ right to get all the information you keep about them. But in this case, they must be able to export it or transfer to another platform. This function doesn’t have to be automated, but you should give users the opportunity to request their data. The structure of exported information could be different. You can use schema.org definitions for JSON or XML. In the case of simple information, CSV/XLS export will work, too. If it a big amount of information and data exporting takes time, you can send it via email. To restrict data processing. A user must be able to make his personal data invisible for publicity, analytics or marketing programs. It can be done by a “restrict processing” button in the users’ profile. To edit the information. All personal data even collected from other resources (e.g. names or addresses from Facebook) must be editable. It is possible to support this process in manual mode, but much more easily to automatize it. To be forgotten. That means your system must have an ability to delete all personal information about a user. In a simple database it will be an uncomplicated task, but in some cases, record deleting can affect foreign keys. So, you should allow nullable foreign keys. If in your system order data has a reference to the client, you can set the user ID to null when you need to delete his data. Be careful with blockchain-like systems, and try to not put personal data in it. Also, it is possible to use a chameleon hash function. Concerning backups, you should keep a separate database for deleted user ID, and during backup restore, the system will re-forget the forgotten users. Whichever variant you choose, there must be the way to delete personal data, and “I do not have such function in the system” is no explanation.