How much thought do we give to data protection in developer relations?
If you’re working with developers who live in the EU, then you might find you’re not doing enough.
On May 25th, the European Union’s General Data Protection Regulation (GDPR) comes into force. It represents perhaps the biggest ever change in how personal data is regulated.
In this blog post, we’ll look at what the GDPR is, how it might affect your developer relations activities and why it needs to be central to your dev rel strategy in 2018 and beyond. And we’ll also look at why it probably applies to your dev rel programme even if you’re based outside the EU.
Nothing in this article is legal advice and I have no legal training. You should seek professional legal advice regarding the GDPR.
In effect, the General Data Protection Regulation has two parts. On one side, it is a bill of data rights for European Union residents. On the other, it offers a framework that organisations must use to justify their use of personal data.
The good news is that the GDPR builds on existing data protection legislation. Although it changes a lot about how we should think about our use of personal data, it’s an evolution of what we should have been doing anyway.
Perhaps the bad news, though, is that the GDPR introduces significant new penalties for breaches: fines of up to 4% of global turnover or €20 million.
It sounds scary. Feeling a sense of urgency about the GDPR is a healthy reaction. But you probably shouldn’t panic. Instead, it’s a good idea to think now about how to make your developer relations programme GDPR-compliant.
So, let’s look at what’s new in the GDPR.
Summarising the GDPR is tricky. It’s law and, so, the wording matters. Nonetheless, we can pull out the main changes:
There’s more to it — and you should seek legal advice to understand the full impact on your developer relations programme — but those first three points are where the core of the GDPR lies.
How can an EU law apply to companies in the US, India or Kenya? The GDPR applies to organisations that are:
Data doesn’t stop at international boundaries. As such, the GDPR seeks to protect the rights of EU residents and it doesn’t care where your company is based.
Most companies with dev rel programmes fall under one, if not both, of the conditions that require GDPR-compliance.
“So, what?”, you might think. “How will the European Union penalise me when I’m not even there?” There are three answers to that:
Okay, so the GDPR most likely applies to your developer relations programme one way or another. What do you need to do?
First-up, you’ll need to consider the data protection rights of EU residents. They are the:
The likelihood is that your organisation already has a plan for upholding these rights. Each one has its nuances and you should both seek advice and read widely to understand them fully.
The GDPR provides six lawful bases under which you can collect and use personal data. As someone running a developer relations programme, each time you collect or use personal data you’ll need to make sure it’s allowed under at least one of these lawful justifications.
So, here they are:
There’s more detail and commentary about the six lawful bases on the UK’s Information Commissioner’s Office’s website.
Data protection should be built in to everything you do. Your processes and technology should be designed to ensure the privacy of individual data.
One way to plan your compliance with this part of the GDPR is to complete a privacy impact assessment at the state of any new project, an exercise that will leave you knowing where your new project falls down in terms of the GDPR.
Overall, though, this is about making sure that your processes and technology do the right thing as part of their natural flow, rather than data protection being bolted-on afterwards.
That’s a lot to take in. And there’s much more to the GDPR than the fundamentals. However, it should give you an idea of the basics of what your obligations are.
So, how does this affect the typical developer relations programme? We can break it down into three broad areas:
Unless you’re just starting out, your developer relations programme already holds personal information on the people who’ve previously participated in your developer community and, unless you’ve been super-diligent, you might not have good answers to why and where you have that data.
A data audit will help you to find all the data you hold, understand all the ways in which you’re using it and then take the right steps to make sure you comply with the GDPR.
The precise steps in your audit will be unique to your company, but your audit will probably look like this:
Here’s a dev rel friendly example: during your data audit you look at your London meet-up group. Your audit might reveal something like this:
A real data audit would surface much more, but this offers an idea of what you might discover. If your company has a legal team, you should review your findings with them or, otherwise, an external lawyer.
Of course, a data audit is not a one-time thing. Schedule regular audits and you’ll be able to quash problems before they grow.
For any new data you plan to collect –– even if it’s from an existing source, such as new people joining your meet-up –– you need to decide up-front:
Under the GDPR, you must be totally transparent about what data you’re collecting, how you’ll store it and what you plan to do with it.
Of course, you also need to justify all of that, so you also need to consider:
It’s pretty common for dev rel people to run booths at developer conferences. Many companies will ask you to justify the expense of an event sponsorship and lead generation can be a relatively easy, if imperfect, way to keep budget holders happy.
But where does such lead generation fit with the GDPR? Let’s look at a pretty typical scenario:
Straight away, there are two complications here:
Which lawful basis justifies scanning the badge? If you’re scanning badges only for the prize draw, you could argue that it is justified under the “legitimate interest” lawful basis. As with everything under the GDPR, if you take that route, you need to keep records of how you came to select that lawful basis. The UK’s ICO has an excellent checklist to help both decide if “legitimate interest” is the right lawful basis and also to balance that against the rights of the individual.
If you’re scanning the badge only to allow access to swag, then your justification is less clear. You can argue that you need someone’s data to put them in a prize draw but you certainly don’t need their data to give them a t-shirt.
Some developer relations managers have decided that the only way to get around that problem is to rely on informed consent. Rather than scan the badge, they have iPads on their conference booths that people can use to enter their details and give consent to join the developer newsletter, for example.
Importantly, the GDPR is clear that consent must be freely given and that it cannot be a condition for providing service. In other words, you probably can’t demand someone’s data in exchange for swag.
When you gather the data, you must be up-front about how you plan to use it. You can’t bury this beneath a pre-filled checkbox.
In the words of the GDPR itself, the consent and usage information must be “presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language”.
That’s somewhat easy to do if you’re collecting data with a device like an iPad.
What if, instead, you’re scanning badges for the prize draw? In that case, you’re most likely limited to using the data for running the draw. If you use the data for anything else, then you need to get the person’s consent up-front.
Here’s the part of the GDPR that will be the biggest cultural shift for a lot of companies: you’re going to have to delete data once you’re done with it.
Our prize draw example neatly illustrates how companies’ attitude to data deletion must change. As we haven’t gathered explicit consent for anything else, we can use the data collected only in order to run the draw. There’s no keeping it in case it’s useful later on. Once the draw is over, we have to delete that data.
Ideally, as part of data protection by design, your software and processes should delete the data automatically once you no longer have a reason to hold it. However, each time you set out to collect new data, you should also have a plan for how and when you’ll delete it.
Of course, an individual can ask you to delete or amend their data at any time.
There is an alternative, though: pseudonymisation. If data cannot be traced back to an individual, then you can hold onto it. For example, your prize draw data might be useful in the future to show your executives the type of people you spoke to at the event. Job titles and company names, for example, are unlikely to be directly traceable to individuals.
Whatever shape your developer relations programme takes, you should make sure that the data you have today passes the requirements of the GDPR. You must then make sure that any new data you collect and use is justified under the GDPR and balances the rights of the individuals.
This article barely skims the surface of the new regulation and it is not legal advice; you should seek professional legal advice. However, it should give you an idea of what you need to consider and, most importantly, the legal advice you need to seek.
Aja Hammerly shares how Google use friction logs to document where a developer-targeted product is hard to use.