Data is an incredibly versatile asset for developers. With it, you can build customized user experiences, power effective business, marketing, and sales systems, and help teams better understand how their users and prospects engage with your brand. However, with great power comes great responsibility; strict regulations like GDPR and the California Consumer Privacy Act (CCPA) now govern the collection, storage, and use of personal data. And there is a growing patchwork of new laws and regulations coming out of legislatures everywhere, from Massachusetts to India. For developers, improving privacy requires new tools and skillsets.
While (most) developers aren’t lawyers or data architects, a baseline understanding of privacy compliance concepts allows you to create meaningful products in a compliance-regulated world. That doesn’t mean that every front end developer needs a deep understanding of privacy compliance. And is an excellent asset for developers who are working on projects and participating in discussions where customer data is collected and processed within the organization.
The better developers understand the fundamental legal, operational, and architectural requirements, the better you’ll be able to work effectively with other key stakeholders, including sales, marketing operations, legal, and data privacy officers.
Privacy compliance includes many elements. The General Data Protection Regulation (GDPR) alone is over 88 pages long. However, for developers, we break privacy into three key areas:
One of your first tasks is to evaluate data entry points or data sources. If data is only coming in from one place (e.g., website clicks or social media engagement), then the data should be in the same format and easier to locate.
However, companies acquire data through a variety of channels, including emails, web forms, social, virtual, and in-person events. Other sources include mobile apps, phone calls, paper forms, or even video. Marketing departments may also purchase and import lists. Each of these data sources may have different data collection requirements and policies for both information input by the user and other details collected programmatically by the application. And this varies with the data subject’s location.
Permission is the result of evaluating consent to determine if, at that moment, you may use personal information for the intended purpose. For example, you purchased a widget from acme.com and authorized them to contact you about this product. Two different groups now want to contact you. Marketing has a new product offering they want to promote, but your consent only covers your previous purchase. So, in this case, marketing does not have permission to contact you. Customer Support has a service bulletin for your product. Because a clause in purchase agreement granted consent, customer support has permission to use your personal information to contact you.
Rights entitle digital citizens or “contacts” to specific actions with their data back by force of law. For example: the right to access, view, add incomplete or modify incorrect data, or request removal of their data. Let’s dive a little deeper with rights using a specific example: The Right to Be Forgotten
The Right to Be Forgotten (RTBF). As one of the most important and wide-reaching elements of GDPR, it is an excellent compliance use case. RTBF covers the complete erasure of a user’s data and any backups of that data that may exist. But what does it mean?
In simple terms, RTBF requires companies to completely erase a users’ data from all systems upon request from the user or legal authority. Deleting contact information may seem straightforward if user data enters the system through one entry point and is stored in one central database. But if the data exists across multiple systems, it gets complicated quickly.
For example, if social media data is stored on a marketing platform and copied into a sales platform and duplicated into backups on a separate server, that’s already three different copies of the same information that requires removal. Once the data is replicated or protected via backup systems, tracking down every copy could prove time-consuming and inefficient if not properly planned.
Additionally, if access permissions enable anyone within an organization to download user data into spreadsheets, that creates a severe breach of the RTBF unless you can delete every local file. Of course, a developer can’t keep track of locally stored data, which is part of why admin permissions controlling data access are so critical. Developers must limit data access permissions and retain robust documentation regarding storage practices and policies to comply with RTBF requests.
Each time a person submits information using an online form, you must store details about the activity to demonstrate compliance. The same is true if an employee uploads a file or if data enters through an integration. You must maintain a complete history for each activity along with any previously stored activities.
For auditing purposes, both internal and external, the developer is never allowed to modify the activity history for any reason. It is a permanent, immutable record of a user’s data flowing into your company’s applications and processes, and is used to calculate permissions after applying applicable laws and policies.
The activity history also includes details on any rights requests, their frequency, and information changes.
Managing these three critical areas of privacy compliance may seem daunting, if not an impossible task if you’re building something from scratch. 4Comply is an API service that allows developers to add privacy compliance capabilities to any application or process quickly.