Privacy by Design Checklist for Developers

What does GDPR have to do with me?

Today’s most effective, transformative, and enduring innovations in tech are often fueled by the interplay between data and platforms. As this commingling scales with user growth, engineers can find new ways to delight customers. This has been the story of digital growth over the last decade. Privacy engineering can operate similarly and give your business an edge over the competition. TL;DR - Already know this? Skip below for tips on building GDPR compliance into your architecture!

If you're a developer or an architect, you can already experiment with our Vault solution by signing up here, don't wait - it's free.

What every developer needs to know about GDPR

GDPR is composed of seven main principles that developers should take into account when building out enterprise data protection architecture. They’re complicated to operationalize, given that the regulations offer higher-order principles on compliance rather than specific technological frameworks and measurable outcomes.

We’d like to offer a technical and practical translation of GDPR to help developers fully implement these principles and future-proof their enterprise’s compliance. First, let’s try paraphrasing the seven principles:

1. Lawfulness, fairness, and transparency: Data must be obtained and processed lawfully and fairly. Individuals to whom it pertains should know how both occur when they wish, as well as how their data will be used. It’s the responsibility of the enterprise to communicate this information clearly.
2. Purpose limitation: Data can only be collected and utilized for specific purposes. It’s on enterprises to track how data is used and ensure that it isn’t used beyond the permitted scope.
3. Data minimization: Enterprises should only collect the necessary minimum amount of data they need, and its use must be agreed upon by users before it’s collected. This means that its use must be determined and articulated in advance.
4. Accuracy: The data enterprises keep should be consistently accurate–and available for rectification or deletion by users where it is not.
5. Storage limitation: Data should only be kept for as long as necessary, and the individuals to whom it pertains must be made aware of what and when that means.
6. Integrity and confidentiality: Data must be kept secure, meaning that it should only be accessible on a need-to-access basis by both users and machines. It’s the enterprise’s responsibility to implement the right security measures to reduce data exposure.
7. Accountability: Enterprises are responsible for demonstrating compliance with all of the above by using appropriate measurements, processes, and record keeping.

Don’t Silo Yourself

The first step to building GDPR-compliant data protection architecture is to collaborate with the right experts in your enterprise. This often means the legal and privacy departments; you will want their green light before moving forward with your design. Specifically, you’ll want to tap into their expertise to determine: What can you collect from your end users. How and for what reason can you process and share user data. What kind of policies and technical measurements should be applied to the data.

In tandem with this, consult your company’s privacy policy. Typically published on the company website, these policies describe what data is collected and how it’s used and processed. Your backend system should comply with these policies. Moreover, as the checklist below demonstrates, your enterprise is likely filled with other teams that can provide valuable insights to guide your process.

The Developer’s Privacy by Design Principles and Checklist

Use this practical checklist to help you architect and engineer privacy into your backend system:

1. Customers' data protection

You’re responsible for helping keep the enterprise in control of sensitive information. This means taking its security into account and reducing its potential exposure. With this in mind, the following security mechanisms should always be in place:

Access controls / Encryption / Pseudonymization / De-identification

We recommend consulting the company security team on these and potentially repurposing any tooling they have built. For example, consider using encryption keys to sneakily restrict developer access and see who complains. That way, you can remove access from folks who believe or claim that they need that data but don't really use it.

2. Restrictions on the collection and processing of personal data

At its core, GDPR is about transparency, consent, and responsibility around data. There are several ways to build this into your architecture and the user experience:
‍
Transparency: Be sure to comprehensively inform users about data collection. This includes the fact that it is being collected, the amount of time it will be stored, whether or not it will be shared, and its intended use.
‍
Consent: Users must explicitly approve before their data can be collected. Using the language received from your lawyer, offer different consent preferences (opt-in, opt-out, approval, denial, etc.). Be sure to set each in proper conjunction with the appropriate user and the data collected/used/shared. Doing it in the right context can help the users.
‍
Minimization: Minimization is a tough pill for many data scientists to swallow, often leading to clashes with legal teams. Developers can help keep the peace by avoiding collecting information for the sake of it and limiting data collection to what’s absolutely necessary.

→ Tip, having your company think of this as “Data Right-Sizing” may be worthwhile since the word “Minimization” causes data scientists to think that even useful data will be minimized.

Retention: Delete data when it’s no longer needed for the reason it was collected. For example, some companies delete inactive user accounts, including all of their associated information, after 2 years. In the name of compliance, it’s better to have a deletion date in place than an unofficial eternal claim on data.
‍
Individual rights: GDPR empowers users to proactively seek out and manage who has access to their data. At the very minimum, it’s your responsibility to help support these two rights.

Data Subject Access Request (DSAR): This is the user’s right to know and access everything that the enterprise has collected on them. Implement this by enabling users to download this information in a readable format (in a zip file).

→ Maintaining a data inventory/catalog is the best way to know where to find the data so that it can be fetched asynchronously upon user requests too.

Right to Be Forgotten (RTBF): This refers to the users’ right to delete information collected on them. Developers are responsible for ensuring that their systems can indeed delete this information. Just be sure to verify the legitimacy of the request.

→ GDPR requires you to validate the authenticity of the request.

→ Hot tip! To be on the safe side and in line with GDPR’s position on user verification, start with soft deletion to help against forged requests that can introduce a denial of service (DoS) to your users.

→ Moreover, consider fully anonymizing your data sets instead of full deletion. By deleting all relevant PII you can retain the anonymized data and delight your data scientists.

Before implementing all of these, we recommend that product management and legal teams collaborate to finalize the definition of “deletion” and the different kinds of implementation methodologies. Engineers often use terms that make intuitive sense but may not have the same meaning from the legal side.

3. Auditing

Auditing is key to having full control over customer data! It’s also necessary for demonstrably proving GDPR compliance. Accomplish this with the following:

1. Keep full auditing logs of who is accessing what: In other words, keep records of when what, and who has accessed a certain piece of data - or at least the most sensitive data like PII (personally identifying information) and PCI (payment card info). This in and of itself can generate fascinating information for usage analytics and forensics.‍

2. Ensure traceability: Specify why you require data when generating a database read access. This can be used as metadata for enforcement (privacy access policies) and to prove the data hasn’t been processed for unauthorized purposes (user’s consent).‍

3. Be on top of your breach assessments: In the case of a breach, you should know exactly what was exposed and which data subjects are to be notified according to GDPR regulations. Audit logs are the only way to do this, as they track what data was accessed and can show the likelihood of whether or not it was part of a data breach.

Final Thoughts

GDPR is an excellent starting point for privacy engineering, given that GDPR is more restrictive than other major privacy regulations, such as CCPA. Enterprises with an eye on the future tend to start with complying with GDPR first and then address any other gaps to fully comply with its other counterparts. We still have much more on our minds about the practical side of privacy architecture. Stay tuned for more guidance to come!