In just over a month, the EU’s General Data Protection Regulation (GDPR) becomes fully enforceable and will dramatically impact data privacy standards. Unfortunately, some companies, especially in the US, aren’t even sure what data is protected. With thousands of possible data points that can be collected, what data is included and excluded? Traditionally, companies built data privacy only around explicit user data like name, address, phone number, and credit card numbers. The GDPR defines a much wider scope. Applications that aren’t compliant could be headed for steep fines. Are you ready?
What Data Is Protected?
In short, the data covered by the GDPR encompasses any information related to a natural person (a ‘data subject’) that can be used to directly or indirectly identify that person. It can be anything from a name, a photo, an email address, social network identities or posts, bank details, medical information, or a computer IP address. If you can connect it back to a person, it’s covered.
Obviously this creates challenges—the first reason to collect data is to understand a unique person’s preferences and behaviors. In modern applications it is common practice to create a marketing profile based on viewing, interaction and purchase history. It is less common to ensure that all that collected data can be completely disconnected from their real-life identity. In fact, the over-zealous collection and overuse of personal data are what prompted privacy concerns with consumers worldwide. After May 25, companies need to be able to ensure user data privacy and be able to respond to a variety of user data requests. (Get more information about these requirements in the Developer’s Guide to the GDPR below.)
A Reason to Collect Data
Another important concept in the GDPR relates to WHY data is collected. It’s not uncommon to hear a product manager say “Just collect all the data you can and we’ll figure out a way to use it later.” Under the GDPR, that’s no longer allowed—any data collected needs to be for a specific purpose. You can still collect the data that you want, but it has to be for a defined purpose, the user needs to be informed, and they need to explicitly agree to it. This isn’t so different from CAN-SPAM regulations, but it covers a wider scope of data that has not been protected in the past.
Data Privacy By Design
The overarching theme of the GDPR is straightforward: Data privacy must be designed into the business processes for products and services. From beginning to end, it needs to be incorporated into the requirements and scope of all business processes in an application. If you are not sure how to start, this report by the European Union Agency for Network and Information Security provides an effective introduction to developing privacy-friendly systems and services. Any developer should be familiar with these concepts, and be able to identify business processes that ignore data privacy concerns.
Conceptually, these regulations should be a relief to developers—it’s easier to build functionality into an application from the start than it is to add it right before launch. (That would never happen, right? #sarcasm) In reality, it will take effort to ingrain data privacy throughout the product development pipeline. If no one else is doing it in your firm, find a way to bring attention to privacy concerns and make sure they are addressed.
Learn More: Developer’s Guide to the GDPR
Before anyone gets too upset, remember that the GDPR does not restrict the types of applications and experiences developers can build. It does place the need for data privacy ahead of the business needs of the company. You can still build your app, you just need to make sure you build privacy controls into it from the start. To learn more about the GDPR and how it will impact developer’s responsibilities, download our paper Developer’s Guide to the GDPR. It covers the essential information developers need to understand to stay compliant and avoid steep fines possible under the regulation.