7 Key Building Blocks for your Privacy Program

What is the level of maturity of your privacy program? Do you feel like you are just spinning your wheels?

It would be nice if every organization had a mature privacy program in place. In order to comply with the various privacy regs, you could simply follow the steps in your carefully designed privacy by design model. You may have to update the program from time to time to comply with the various regulations, but your process itself is well designed.

Unfortunately, this mature privacy program model described above doesn’t exist in many organizations. So, how do you achieve this mythical level of maturity?  

The first step to creating a positive program is to start taking positive steps today. Everyone’s heard these words before, “I’m starting my diet tomorrow.” The speaker of the quote is usually eating something delicious and probably have positive intentions of starting a diet.  Unfortunately, most of us will eat the next delicious, unhealthy thing and plan to start the diet next day. Why are folks not following through with their good intentions of starting a diet? Because, simply put, dieting is really darn tough!

The same goes for privacy. Most organizations have positive intentions of building a strong privacy program yet fail to take significant action. Why is this the case?  I think the answer is two-fold:

a. Like dieting, putting a strong privacy program in place is far from easy, and

b. Most organizations do not even really know where to begin to put such a program in place.

It is impossible to capture all steps necessary to create a privacy program in a blog post, particularly since each organization is going to have its own nuance.  Here are some key building blocks for a good privacy program:

1. "Shift Privacy Left" in the Software Development Life Cycle (SDLC)

I think it is imperative that privacy is considered early in the SDLC process. Ideally, you would want to have some sort of intake form for any engineering project that asks, "Is any Personal Data processed, stored, or otherwise used, in your application?" If the answer to this question is yes, a review should be performed by a privacy pro to ensure adequate privacy controls are in place. You will also need to do a fair amount of outreach and education to the engineering team to ensure that this approach is actually embraced.

In addition to the outreach and education mentioned above, an assurance function related to privacy should be implemented. This can serve as a “belt and suspenders” approach to ensure that each new development that contains personal data goes through a privacy review.  Your assurance team could potentially use a privacy code searching tool such as Privado to catch all areas of the code where personal data is being touched by the application.  

From time to time, even the more secure organization is going to experience some sort of breach.  It is imperative to have an investigative function to investigate breaches with a privacy lens. This is particularly important when the breach might impact regulations from the FTC, GDPR, CCPA, etc.  You need a proper investigation to know how regulations were impacted by the potential breach.

2. Have a good Data Map

‍In order to ensure that you have a good privacy design, it is imperative that you know where all your data (in particular personal data) resides. You will need to know all structured and unstructured data stores where data may possibly reside. Ideally, you would only want to keep personal data in structured data stores. It becomes extremely challenging to respond to Data Subject Access Requests (DSARs) when personal data is kept in unstructured places such as Sharepoint, Slack, and the like. DSARs are referenced when an individual makes a request to obtain a copy of their personal data or request that their personal data be deleted at an organization.

3. Have a strong Data Taxonomy‍

It is important that you classify personal data into low, medium, high, and critical areas of risk. For example, battery percentage on a cell phone is probably something that you would classify as a low risk. An individual's Social Security Number would clearly be critical, meaning you need the strongest safeguards in place.  

4. Incorporate data tagging for data ingested

‍Instead of having to constantly create data maps and matching them to the corresponding taxonomy instead ensure that all data that is ingested is tagged with both what field it is related to in the taxonomy and the appropriate level of risk.

5. Create a data retention schedule that matches the appropriate risk level assigned in the Data Taxonomy

‍For example, low risk data can be stored for a much longer time than those designated as critical. Appropriate Time to Live's (TTL's) should be set to correspond to match the schedule so deletion becomes an automatic process.

6. Create a Knowledge Base for Privacy Related Questions‍

By the time your team has completed enough privacy reviews, you will start to see the same patterns and questions. If you can create a resource that individuals can access prior to submitting a review, it may save your team time from having to answer the same questions.

7. Evaluate Privacy Enhancing Technologies‍

There are several privacy tools and applications out in the marketplace. Your team may also develop their own privacy tools internally. The tools in the marketplace can help solve some of the issues described in this post.  

Each privacy program is different. It is imperative that each program consider the appropriate regulations in their jurisdiction when creating their program. Also, each program will be nuanced by their industry. The steps listed above should serve as useful building blocks for your privacy program.

‍