Privacy by Design: How to build your product with privacy in mind.

You are building an awesome tech product and you are finally ready to launch. Suddenly, you hear someone at your team ask: what about privacy? Ah! Privacy! That little thing preventing you from giving consumers what they want, right? Well, If you relate to this, then this post is for you. 

Here, I will discuss the most important things to consider to build privacy complying products from design. I am confident that this post will give you great tools to tackle privacy revisions like a champ! 

Quick word -- This is NOT legal advice. Remember you must consult with your own privacy counsel before launching. You can use this primer to bring yourself up to speed on your way to pass a privacy revision with flying colors.

Let's get started!

Personal Information.

Step one is to figure out whether you are dealing with personal information (PI). It's simple, if you don’t deal with PI, you PROBABLY won’t need to care about privacy compliance. 

Although the definition of PI varies according to different Laws, in general, PI is defined as any piece of information that identifies (or is susceptible to identify) an individual. The concept is broad and it generally applies to anonymized, dissociated or even encrypted data. 

As you may have figured out, chances are that in the vast majority of cases, you will need some sort of privacy compliance work before launching.  Once you determine you are dealing with PI, list all the PI you are collecting, using, transferring or processing. Try to be extensive and precise.

Data subject and collection point.

Step two is figure out your data subject. A data subject is the individual to whom the PI is related and in most cases they have some sort of “ownership” or “control” over their PI as well as specific rights to protect their PI. 

Generally, our data subject’s location will determine the applicable laws and regulations that we should review with counsel so, put special care in figuring out who our data subject is and where they are located. You will need to identify if you are collecting PI directly from the data subject or from a third party, such as another user of your platform, an external service or a public registry. This could influence how to deal with privacy notices and consent.

Purpose, necessity and proportionality.

The rule is, you can only collect, use, share or process PI if you have a specific purpose. Naturally, step three is defining one or several purposes. Being thorough while defining your purpose is the cornerstone to success in the privacy world. First of all because processing PI just because could potentially violate applicable Laws or even your company’s privacy policy, and; Second because a clear and defined purpose will help your legal and compliance teams to justify any product function you are building.

It is also important to justify that all collected PI is necessary and proprtionate. To do this you may want to ask yourself if the PI in question actually achieves the purpose you have in mind and ask if there are any other less intrusive PI that would let your widget achieve the same purpose. If there is, then you may want to contemplate collecting that other less intrusive piece of PI instead.  

Information (a.k.a privacy notice).

You must inform the data subject about your processes around collection, use, transfer and storage of PI. This includes how you plan to collect, store and use PI as well as with whom you plan to share such PI, for how long you will be retaining such PI in your system, among others.

Oftentimes, people think that publishing a general privacy notice in the company's landing page is enough. However, that is not always the case, in the majority of situations a dedicated privacy notice is advised (and sometimes required by Law) right before collection takes place. 

Ask your legal team how a particular local Law or regulation handles timing or format of privacy notices and make sure that your widget meets those standards. Sometimes, standards can be precise, specially in cases when you are not collecting PI directly from the data subject, it is always advisable to be alert of such standards and be proactive while building the product. 

Finally, make sure that the contents of the privacy notice are adequate, complete and spelled in a way that is easily understandable for your particular data subject. Privacy notices should be clear and concise so, avoid legalese as much as possible and provide your data subject with tools that will help them understand your notice easily.

Consent.

Generally, you can only collect, use, share and store PI if you have consent of your data subject. Depending on applicable regulations or your company’s privacy policy you may have to contemplate  built-in mechanisms to help your data subject navigate consent either implicitly (opt-out) or expressly (opt-in). 

You can also consult with your legal team if the applicable regulation allows a consent exception. Generally, consent is not necessary if the PI is used to provide a service requested by your data subject or when there are other legitimate interests involved. A thorough consent model analysis is highly recommended before launching. 

Storage and Infosec.

Determining where you store the PI can trigger some additional regulations you may need to take into consideration. If you plan to store information in onsite servers, make sure to contact your IT department to make sure your widget complies with all cybersecurity requirements that may be in place. If you're storing information with a third party via a cloud service, you may want to aditionally ask your legal or compliance team about specific regulations. Some jurisdictions have special cloud computing rules that would require you to select  providers that offer privacy compliant services. Finally, make sure that your servers have the adequate configurations to make sure your product compliant with your company’s cybersecurity policy.

Transfer and sharing.

PI transfers require special attention. You should identify the recipients of such transfers and the tools, processes and technologies used to share information, and double check with your IT team that such tools or technologies are aligned with any cybersecurity policy that may be in place. Lastly, you will need to double check with your legal team if the recipients are bound to any agreement that is well suited to ensure the confidentiality and adequate protection of any transferred PI.

Word to the wise. All this is still applicable even if you shared encrypted or anonymized PI. Remember anonymized or encrypted information can still be considered PI if it is susceptible to identify an individual.

Deletion and retention.

Don't forget about data deletion and retention procedures for PI that you no longer need. Unfortunately, many product managers forget about data retention and deletion policies and this tends to block product launch and ramp up frustration. Generally, you must block access to PI when the purpose that justified its collection has been achieved. However, even when the purpose for which you collected data has ended, you will need to consult with your legal team if there are some applicable regulations that would require your company to retain PI (e.g for tax compliance purposes). Don’t forget to double check with your IT team to ensure that any process or tools you are using for data storage or deletion are adequate to avoid data breaches. 

Following this simple primer, will put you in the right mindset to build tech products with privacy at its core which will help you pass a privacy compliance revision with flying colors.