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 25^th, 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.

Introducing 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.

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:

• The GDPR applies everywhere: yes, even if you’re not based in the European Union.
• It grants eight data rights: EU residents get clear rights around how their data is captured and used.
• It specifies six lawful ways to use data: all personal data capture and use must fit into one of those lawful bases.
• Data protection must be designed-in: your technology and processes must put protecting personally identifiable data first.
• Record keeping is essential: should you later need to justify something you’ve done.
• Non-compliance will be costly: the maximum penalty for a breach is 4% of global turnover or €20 million.

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.

The GDPR applies globally

How can an EU law apply to companies in the US, India or Kenya? The GDPR applies to organisations that are:

• Based in the European Union.

• Or that sell products/services to European Union residents or monitor the behaviour of EU residents.

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:

• Success for your company probably involves an EU presence at some point, so don’t store-up trouble for when that day comes.
• International law will most likely allow for cross-border penalties.
• People are likely to get used to GDPR-style protections and expect them of you.

Okay, so the GDPR most likely applies to your developer relations programme one way or another. What do you need to do?

Eight data protection rights

First-up, you’ll need to consider the data protection rights of EU residents. They are the:

• right to be informed: you must tell individuals how and why you’re collecting and processing their data
• right of access: you must let people know how you’re using their data and allow them to check you’re doing it legally
• right to rectification: if you’ve made a mistake in someone’s data, you must correct it
• right to erasure: also known as the right to be forgotten, in some circumstances an individual can request that you delete data about them
• right to restrict processing: you can still store the data but an individual can ask you stop using it
• right to data portability: people must be able to get hold of the data you hold on them and then use it elsewhere
• right to object: if you’re using someone’s data for marketing or research purposes, they can ask you to stop
• rights relating to automatic decision making: this covers automated profiling, machine learning and so on.

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.

Lawful bases

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:

• Informed consent: the individual explicitly opts-in to the precise way you say that you’ll use their data.
• Contractual obligation: you need to use the data in order to deliver a service the person has asked for, or that they’ve told you they’re considering, and you’re using only the data needed to fulfil that contract.
• Legitimate interest: perhaps the vaguest of the lawful bases, this allows you to use data if the legitimate interests of your company require it and you can show that this balances with the rights of the individual.
• Legal obligation: unlikely to apply to a dev rel programme, but this allows you to use data where the law requires you to.
• Vital interests: you need to use the data to save someone’s life.
• Public task: this applies most to public authorities and allows for the use of personal data if it’s in the public interest.

There’s more detail and commentary about the six lawful bases on the UK’s Information Commissioner’s Office’s website.

Data protection by design and default

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.

How the GDPR affects developer relations

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:

• Data you have now.
• Data you plan to collect and use.
• Data you must delete.

Data you have now

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:

• Hold a data amnesty: ask everyone in your company to come forward with any data they hold on people covered by your developer relations programme.
• Map existing data flows: create a flow diagram of all the ways that personal data comes into your dev rel programme, is stored and used.
• Know your data stores: your data amnesty and mapping exercise should reveal where personal data is stored. Make sure you have a canonical list of those stores and the data they hold.
• Know your data uses: similarly, you’ll now have a strong idea of where data is being used and you should list where, how and why that data is being used.
• Attempt to justify your existing data flows and uses: work through each data flow and:
  • decide if your data collection is justified by one of the six lawful bases
  • make sure your data collection respects the eight data rights.
• Stop, review and destroy: if you find you have data that was collected in a way that doesn’t comply with the GDPR, destroy it. Similarly, if you’re using data in a non-compliant way, stop doing so.
• List your data update and deletion steps: how do you make sure data is accurate and when do you choose to delete it?

Example: auditing your meet-up group

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:

• Where data is collected: event management system and personal interactions.
• What data is collected:
  • Through the event management system: name, email address, company, job title
  • Through personal interactions: phone numbers.
• Where that data is stored:
  • It stays in the event management system indefinitely.
  • The sales team occasionally skim the meet-up data and add it to their CRM.
  • The dev rel team will combine data from the event system with data gathered through personal interactions to a spreadsheet you keep of community members.
• How that is used:
  • Each month, the dev rel team uses the events system to send an email that announces the upcoming meet-up.
  • If someone from a key-target account attends the meet-up, the sales team will contact them to organise a meeting.
  • The marketing team use the event management system to email the attendees once a year to announce your company’s annual user conference.
• Justifications:
  • When joining the meet-up group, the wording is very vague about why the data is collected and how it is used.
  • At no point have attendees opt-ed in to have their data shared with the sales team and you’re not clear it can be justified under one of the other lawful bases.
  • You might be able to justify allowing your marketing team to announce the user conference, through the “legitimate interests” lawful basis but you’re not sure and seek legal advice.
• Stop, review and destroy:
  • You tell the sales team they must stop skimming and using the meet-up data and that they must destroy all data they gathered in that way.
  • You tell the marketing team to pause their communication until your legal review is complete.
  • You contact the meet-up attendees to ask them to opt-in to having their personal data stored as part of your developer community spreadsheet.
• Update and deletion:
  • Your meet-up attendees can amend or delete the data held on them in the event management system and you’ve confirmed with the supplier that the system does not hold onto copies, other than back-ups and they have a system for ensuring data that is deleted deliberately is not restored from back-up.
  • There’s no way for attendees to amend or delete the data you’ve copied to your spreadsheet.

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.

Data you plan to collect and use

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:

• precisely what data you will collect
• how and where you’ll store that data, particularly if that includes using a third-party service
• all the ways in which you might use that data.

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:

• under which lawful basis/bases you’re collecting and using the data
• how this is balanced with the individual’s data rights
• how you’ll give people access to amend or delete the data you hold on them
• when you’ll delete the data because you no longer need it.

Example: scanning badges at a conference

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:

• People come to your booth and they want some of your swag or to enter a prize draw.
• To get the swag or enter the prize draw, you scan their badge.
• Scanning a badge gives you no personal information but, instead, gives you a UUID that the conference organiser will exchange for the individual’s data.
• At the end of day, you hand your scans to the organiser and get a list of personal information in return.
• You do two things:
  • You save all the personal info into a spreadsheet, so you can pick a line at random to choose your prize draw winner.
  • And you send the personal info to your marketing department, who’ll subscribe each person to your developer newsletter and enter them as “dev rel prospects” in your CRM.

Straight away, there are two complications here:

• You’re scanning the badge for two different reasons.
• Your use of the data doesn’t necessarily match the expectations of the person you scanned.

Justifying collecting the data

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.

How you use the data

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.

Data you must delete

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.

Get your dev rel GDPR plan in order now

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.

Good luck.