GDPR for Developers

The General Data Protection Regulation (GDPR) is a European Union privacy law that has worldwide implications. The penalty for non-compliance can be as high as 4% of global turnover or 20 Million euros, depending on the egregiousness of the violation. The law affects every company that either does business in Europe or its customers could access the site while in Europe. There are additional rules governing which companies can be held responsible under GDPR, but most companies are affected by this law.  If you fall into one of those categories, I recommend speaking with a lawyer to fully understand your risks under GDPR.

The law requires that companies put specific things in place to restrict the collection and use of personal data, and seeks to have companies build privacy settings into their products. It’s important to keep in mind that the GDPR’s definition of personal data is more than the traditional name, address, credit card info, username/password, etc. The definition of personal data is now much broader. An IP address counts as personal data if it can be tied back to a specific person. Pretty much anything that has the potential to be tied to a specific person counts as personal data.

Every company and every product is different, so choose the tips that apply to you. This is not legal advice, but here are a few helpful recommendations for working towards GDPR compliance. Please note that this is not a comprehensive list, but it is a great place to get started. Even if GDPR does not apply to you, consider building some of these privacy techniques into whatever you’re developing.

1. Encryption, Encryption, Encryption. Preventing a data breach is essential.

2. Only use fake data sets when you’re testing your new product or functionality. Some governments provide fake test sets to work with. Using fake data sets (or data sets scrubbed so many times that the data could never be reidentified) prevents developers from having access to data they don’t need to have. This protects the developers and data subjects alike, as no one would be able to say they accessed someone’s information without permission. Likewise, it creates a “need to access” or “need to know” mentality around real data. Only those with a real reason to directly access the data will get access.

3. Communicate with your customers and coworkers about how you’re collecting and using their data. Even though people rarely read privacy policies, they’re important. If you want, you can create other ways to explain how you’re working with customers’ data. Talk to the consumer-facing or client-facing members of you’re team so everyone’s on the same page about how data is being used.

4. When you’re building out your product or tool, develop it in a way that you can easily explain the data flow to a non-developer. GDPR requires that companies have an accurate map of personal data flows throughout their tools and their company, as a whole. In other words, be able to “dumb down” how the product works so someone who doesn’t understand system architecture or programming can understand.

5. If it makes sense for what you’re developing, allow users to change the privacy settings. When you initially roll out the tool, the settings should be set to the strictest options. From there, users can choose to loosen them up if they wish.

6. Users should be able to continue using your product, even if they opt-out of some of the ways you’d like to collect their data. For example, you should still be able to use an app even if you don’t want to share your exact location.

7. Cookies, tracking pixels, beacons. Except for ones that are necessary for the website or product to function, create a way for users to “opt-in” (privacy term for “agree”) to the use of cookies, pixels and beacons.

8. Make sure your product/tool allows you to edit or delete data later. GDPR allows people to contact you to fix incorrect information you have in your database, or delete their personal data altogether. There are specific rules about when and how this rule applies (it applies to each company in different ways and to various degrees), but it’s helpful to have this functionality built into your tool.

9. Have a system in place for reacting to a data breach. If the breach is significant and meets certain criteria under GDPR, it will need to be reported within 72 hours of initial discovery to your data protection authority. (The standard is if the breach poses a “risk to the rights and freedoms of natural persons”). You will also need to notify your data subjects about the breach if there’s a high risk. I’d recommend speaking to your legal team about the types of incidents that will meet these standards, as not reporting a data breach could result in massive fines.

Reach out if you have any questions! The tips above are not legal advice, but I hope they are a good starting point for building privacy into whatever you develop…also known as privacy by design (privacy term for incorporating privacy from the very beginning).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s