A Developer’s Guide to GDPR that won’t make you sweat
The General Data Protection Regulation (GDPR) is a set of rules that come into effect on May 25th, 2018. It regulates the use of data and it applies to all organisations that store or process any data relating to individuals inside the EU.
Much of what I’ve read recently about GDPR seems to have been written and designed with the sole aim of inducing panic and nausea in every developer it reaches. But in the time that I’ve been working on GDPR for ft.com I’ve realised that there’s very little in the regulations that could fundamentally change how we write code and I know that most of my colleagues tackle challenges bigger and hairier than GDPR every day, without breaking a sweat.
Why then, are these scare-pieces so pervasive?
Many of the articles I’ve read stress the sheer length of the legislation, the huge potential fines and the myriad challenges involved in building complex compliance tooling in a matter of months.
It’s true that a huge amount of time and effort is being dedicated to making organisations compliant by the May 25th deadline and the challenges being faced are many, complex and varied. But there’s a massive difference between developing new features in a compliant way — a charge we will all soon be taking up — and the task of retroactively applying new legislation to mature systems. Just like with security, accessibility, performance and testing, it is comparatively simple to build with GDPR in mind, and extremely difficult to shoe-horn it into your system later.
What many of these articles miss is the fact that most devs won’t be involved in this (extremely important) shoe-horning exercise and they skip the practical advice explaining how we will need to work in a post-GDPR world.
So this is not, in fact, a GDPR guide. It is a post-GDPR guide. It is an account of the most relevant bits of GDPR that will affect developers and it will hopefully act as the starting point that most devs actually need.
It will cover storing data, subject access requests, contacting users and profiling. If you get to grips with just these few aspects of GDPR you should be in a good position to start incorporating it into your work.
This blog post does not contain legal advice. You should always take your own organisation’s GDPR guidelines into account.
1. Storing Data
TL;DR Protect the data you store and only store what you need.
This one gets to the core of GDPR which is, after all, concerned with data protection.
Personally Identifiable Data (aka Personally Identifiable Information, or PII) refers to anything that could be used to identify a ‘natural’ person and it encompasses a lot of different data points. You must take reasonable steps to protect any PII in your system.
If you’re working on a feature that requires you to store any data related to your users or their actions, you should go through some checks before you start.
First, prevention is easier than the cure; make sure that you really do need to store the data. Could your feature work without it or by using a separate ID that’s not directly tied to a user?
Next, work out how much data you need to store for your use case and only store those values. For instance, you probably don’t need to keep a record of the user’s device-type when they enter profile details and you probably don’t need to know their gender to send a newsletter.
You must inform users if you collect or use any of their personal data and make them aware of any associated privacy policies. The explanations should be concise, transparent and easily accessible.
Then work out how long you need to store the data for. GDPR makes it a liability to store data about users without good reason so consider applying retention policies to data that quickly becomes irrelevant. E.g. auto-delete old reading history if you only use the last month’s activity to power your recommendations.
Depending on the level of sensitivity and risk, you will need to apply a reasonable level of protection to the data you store to comply with GDPR. (Remember PII?) This could involve encryption or limiting access to data via auth or access keys. Again, this is pretty standard stuff in most dev teams but worth noting that it has specific role in dealing with GDPR.
Lastly, make sure that wherever you’re storing the data is integrated with your SAR tooling (we’ll cover this in a minute) so that subject access or erasure requests will pick up on the new data.
Relatedly, there is a case in GDPR for protecting Legitimate Business Interests (LBI).
Data which is integral to your business model may be covered under Legitimate Business Interest (LBI) and partially exempt from these rules. There should be a compelling justification for the processing of data classed as LBI and the decision should be balanced against the user’s interests, rights and freedoms.
Basically, under GDPR, it’s important that your team is able to justify why data is being kept and what it’s being used for. When you no longer have a business case for keeping a piece of data, mark it for deletion. Retention and data management policies on your data stores can help ensure that the data you’re storing about users remains relevant and has the additional benefit of saving on storage costs. Like most of the tools discussed here, many developers will already feel pretty comfortable with these policies so making them a part of your GDPR toolset should be relatively straightforward.
2. Subject Access Requests
TL;DR Make it easy to retrieve, delete or anonymise data when you need to.
By May 25th, your organisation should have a plan for dealing with both Subject Access and Erasure Requests.
Subject Access and Erasure requests are among the list of Individual Rights granted to users under GDPR. Users may request a copy of all (or a subset of) the data an organisation holds about them via a Subject Access Request (SAR). They can also request that their data be deleted via an Erasure Request (aka the right to be forgotten). Organisations must comply promptly and fairly with data and deletion requests from users.
Some good rules to keep in mind when developing in a GDPR-compliant way are to make it easy to retrieve all the data you’re storing about a particular user from the start and make sure your feature is designed to deal cleanly with deletions or anonymised data. It’s much easier to consider how data can be safely deleted early on.
In cases where it is not possible to fully-delete data, the data must instead be completely anonymised to the point where it would not be possible to use it to identify a user even when combined with other data points. This is one to consider if the data you’re working with is tightly coupled with other systems or data points.
Be aware of how deletions may affect any analytics or tracking you’ve implemented and if this could have business implications elsewhere. Your tech choices can have an impact too: blockchains, for instance, are append only and caches will persist data after the source has been deleted unless properly invalidated.
Some personal data, such as billing information and contract records, will be exempt from deletion requests as they’re required for legitimate accounting and legal reasons.
3. Contacting Users
TL;DR Get fair consent before you communicate with users and maintain a preferences management page.
This is the one that Marketing professionals can get very nervous about and it’s the most-cited consequence of GDPR in articles and blogs I’ve read.
Under GDPR, organisations are not allowed to contact users without their permission. This covers all channels including email and text messages. Consent cannot be assumed, it must be actively given, for example, by checking a box or clicking a ‘subscribe’ button and it can’t be bound up with your T’s and C’s.
This is good news for users as it gives them greater control over their inboxes and it’s an incentive for organisations to up their game in terms of what they’re sending. If the content and marketing material you’re sending is valuable then users should be happy to grant you consent.
If you’re working on a feature that will trigger an email or some other message to be sent to users you will need to integrate with your organisation’s consent tooling and check if you already have a consent channel for your use case. It’s likely that this will take the form of some source-of-truth database and an API that you can query before sending messages. Make sure you add a step to check against this database for each user before hitting send. For situations like a newsletter that is only sent to specific users who have asked to receive it, then all users who opted-in have given consent by signing-up.
Depending on what you’re working on and your existing consent architecture you might decide to surface your new feature to users and ask them to opt-in as part of your feature release.
If you want to start sending messages to users for the first time then you will need to ask them for permission and then store and respect their answers. Be aware that it may also be necessary to store the exact wording used when asking users for consent as well as their answers. This will be important if the consent constitutes a legal agreement and might be needed if your organisation faces an audit in the future.
As part of GDPR compliance your service should have some form of preferences management page that is easy-to-navigate to and where users can opt in to or out of the different communication types and channels you use. It should be as easy to unsubscribe as it is to sign up.
Service messages are a special case. They include things like account changes, password update links, billing notifications and important security messages and they are exempt from the normal consent rules under GDPR. Users cannot normally opt-out of these messages.
4. Profiling
TL;DR Users must be able to opt-out of profiling.
If you are using data to provide real value to your users, this one shouldn’t worry you as they’ll hopefully want to keep using those data-enriched features.
To be compliant with GDPR, your organisation should have a clear way for users to opt-out of profiling if they choose. The only important thing for developers going forward is to understand what counts as profiling and to faithfully respect your users’ choices before implementing any form of personalisation.
If you use data about users to personalise the experience you serve, that is profiling. Unlike the channels mentioned in the contacting users section above, you don’t need active consent from users you simply need to provide a ‘right to object’.
Profiling can be demographic (based on information the user has given to you) or behavioural (inferred from the user’s onsite or offsite actions). Profiling includes — but is not limited to — use of a user’s personal details, profile data, browsing activity, likes, on-site actions, geolocation and decisions about what ‘users like them’ engage with. Among other things it plays a role in targeted content, targeted advertising, personalised experiences, recommendations and some offers.
As long as they are being served to all users equally you can still show ads, highlight features and run special offers on your site. Once any active separation of users or algorithmic decision-making has been involved in the decision to show something to a user, then it can’t be served to a user who has opted-out of profiling on your service. Remember to include a check against your source-of-truth to confirm each user’s preference before applying features that rely on profiling to work.
Luckily, there’s a good chance that you already serve a ‘vanilla’ experience when a part of your system goes down, when you can’t complete some client-side processing or the user is logged out. GDPR essentially allow users to opt-in to this pared-back experience.
We got this
This is by no means a comprehensive account of GDPR; it merely lays out the most core concepts and how they will likely affect typical developers once the tricky business of compliance has been settled.
Contrary to all the scare-mongering out there, GDPR is not a terrifying and impossibly difficult blocker to how we work and it doesn’t take much to become informed about the basic principles. And even better, many of the concepts at play aren’t even new to a lot of developers. It’s simply a matter of incorporating some new best-practices into your work. Privacy by design can be embedded into our development processes in the same way we’ve learned to incorporate accessibility, performance and security.
Ultimately, there are many potential benefits to incorporating GDPR into your best-practices: Demonstrating that you respect your users’ data and are taking the right measures to secure it can positively impact your reputation and increase trust in your organisation. Communicating clearly and honestly about how you use data to enhance users’ experiences on your platform can allow you to grow your core audience and tailor experiences to them. Having robust and well-maintained data management policies can increase confidence in your analytics and help to mitigate some cyber-security vulnerabilities.
And I’m pretty sure we can handle it.
