gdpr voor developers

There’s already a massive amount of information around concerning the GDPR, especially for CEOs, CIOs, and marketing managers, but what about GDPR for developers? Virtually nothing. We’re hoping to change that with this blog. What do you need to know about GDPR as a developer, and what practical tips can we give you?

What is relevant for developers?

GDPR is all about protecting personal data, so it’s important to know what GDPR defines as personal data. Basically, it’s all data that can be used to identify a person or data on an identified person. This involves both data explicitly provided by the user and data collected about the user via third parties or based on the user’s activities (browsing behaviour, products bought, etc.).

Going through the full GDPR legal text reveals the aspects relevant to developers. These involve a number of basic principles and users’ associated rights. Obviously, we can’t describe everything in detail here, but we can give you an idea of the most important elements.

The following basic principles in the GDPR are relevant for developers:

  • Minimisation of data (you may not collect more personal data than necessary)
  • Integrity of data (personal data must be kept accurate and complete)
  • Confidentiality of data (personal data must be treated confidentially)

This results in a number of user rights (GDPR legislation describes users as “data subjects”) that you, as a developer, also have to take into account:

  • active consent obligation – a user must actively give consent for his or her data to be retained and used
  • the right to be informed – a user is entitled to an understandable and brief privacy statement instead of extended general terms and conditions
  • the right to access data – a user must be able to view all the data collected about him or her
  • the right to change data – a user must be able to change his or her data personally, or request that it is changed
  • the right to data portability – a user must be able to export his or her data, or request that it is exported
  • the right to erasure – a user must be able to change his or her data personally, or request that it is changed

What does that mean for developers?

As a developer, you must provide a number of features so that users can exercise the rights listed above. The GDPR does not require fully automated processes or features, but automation does obviously simplify things.

Active consent

Users must now give active consent that their personal data is retained and used for things that are not related to a contract. To illustrate this with an example: you do not need consent to collect data so that you can send a shipment or invoice. However, consent must be given for each activity involving use of this data for marketing or customer profiling. This can be done via checkboxes, selection menu, profile page, etc. The choices must not be checked by default beforehand. Users must actively indicate what they want, and must also be able to change their choice at any time. Incidentally, active consent must be provided by all users, including those already in your database.

View/change data

You must provide a process or feature where users can view and/or change the data stored about them. Users must be able to change, or have changed, all data on them, including data that you have collected from other sources. A good rule of thumb: it must be possible to change all fields in your table of users via the user interface. It is technically possible to make changes manually, but that’s obviously more expensive than using a form or web interface.

Export data

You must allow users to export all data about them as data subjects. What that exactly means will probably vary from user to user. Normally, it will concern at least the data which is deleted with the “forget me” feature, but there may be additional data (you wouldn’t normally delete orders placed by a user, for example, but this must be included in the export). The structure of the export is not strictly defined, but it must be in a readable format, so something like JSON, XML, CSV or Excel. If exporting data takes a long time, it’s recommended that the user is informed and notified by e-mail when the data is ready.

Retention of data

If you have collected data for a specific purpose (e.g. registrations for an event), you must anonymise or delete it as soon as you no longer need it. That means you need a scheduled job/cron to regularly anonymise or delete the data. The GDPR legislation does not specify any exact timing.

Deletion of data

You must have a method to delete all personal data about a user collected on the basis of active consent or legitimate interest. Data necessary for contract-related reasons or a legal obligation may be retained, but a clear life cycle of the data must also be defined in this case (e.g. up to a few months after the end of the contract). Sooner or later, personal data must always be deleted. This erasure is an obligation, so no excuses such as “our data model doesn’t allow it” are allowed.

What about backups? Ideally, you should keep a separate table with deleted users, so you can delete those users every time you restore a backup. This means that the table must be in a separate database, and associated with a separate backup and recovery process.

Simply deleting the data from your own database is not enough; if you work with other parties such as CRM and ERP systems, Salesforce, Hubspot, or even cloud providers, they too must delete the data, so an API call will be required. You also have to make sure that this data cannot be found online anywhere via a Google search or otherwise.

Technical measures

All this implies a number of technical measures, where the dividing line between the developer and the system administrator becomes fuzzy. The GDPR doesn’t deal specifically with technical measures, so a risk analysis will determine your best course of action. The list below is therefore not an obligation, simply evidence of good management.

  • Encrypt data in transit
  • Encrypt data at rest
  • Encrypt backups
  • Pseudonymization
  • Authentication before changing data
  • Data register of processing activity
  • Registration of access to personal data (both read and write actions must be logged)
  • Registration of all APIs
  • Integrity checks, such as mandatory fields, calculation rules, dropdown lists, etc.

Note: The GDPR covers many more aspects than those mentioned here; doing all this doesn’t necessarily mean you are GDPR compliant, so make sure you check the details of the rest of the legislation.



Related posts
PHP Benelux 2018

PHP Benelux 2019: 7 things that we will remember

For two days PHP Benelux 2019 was the place to be for anyone who works with PHP. A quick overview of the most important takeaways.

Read more

visies meet the hackers

Meet the hackers: three perspectives on security

Better safe than sorry was the message behind ‘Meet the hackers’, our workshop on ethical hacking. In the cosy setting of the Mariaburg barn, […]

Read more

devops mythes

6 DevOps myths we want to debunk

DevOps is a hot topic. There’s lots of information about it, but unfortunately not all of it is meaningful or correct. Our hands-on experience […]

Read more