A Data, Security and Privacy Engineer Walk into a Conference Room
In our previous post, Ben Herzberg shared some of the challenges privacy, compliance and legal leaders face when implementing enterprise data protection programs. Chief among them was the amount of time and effort required to gather critical information from all of the teams and subject matter experts involved. Today, I’m going to dive deeper into this problem and explore the human element of protecting enterprise data.
To work well, the average data protection program requires healthy collaboration between an enterprise’s data, security and privacy/legal/compliance teams. While there are many other teams and departments that can get involved, we’ve decided to focus on these three given that they are the fundamental key players in the vast majority of cases. This set up already presents our first obstacle — while every cross-functional program requires special attention to goal alignment and execution coordination, the unique perspectives and goals of these three particular teams can often get in the way. It is here that the human element often plays a deciding role in the success or failure of a project.
You may recall Josh, our privacy hero in our last post. Well, allow me to introduce Lucy, our new security hero, and Lynn, our new data hero! After collaborating on a number of projects at ACME Corporation, a new company initiative has tasked these three with a cross-functional mission to build new data infrastructure. The guys and gals upstairs are insisting on creating a single source of truth for the enterprise’s data assets and a platform for developing new services and maximizing operations through machine learning and analytics. The guiding strategy involves gradually migrating to a new and unified data infrastructure for data ingestion, processing and analytics using a combination of modern cloud data lakes and data warehouses with data pipelines leading to and from different apps and services.
Josh, Lucy and Lynn have gotten to discussing one of the main requirements for this new data infrastructure: the need for all consumer data handling and processing to be inline with local privacy requirements. So far, so good! All three leaders are 100% behind the vision, strategy and requirements. However, things begin to fall apart once the tactical discussion begins.
Let's close our eyes and imagine this discussion:
Privacy: … so we need to be able to associate each data object with its data subject location and then make sure that whoever is getting this data is authorized according to the data sovereignty model.
The data teams hear this and freak out over the amount of work that it will take to support this...
Data: While I understand these requirements, adding this kind of attribute to every data element is going to require a lot of changes in our data models and applications. Maybe you can share what kind of specific restrictions and controls are needed and we can focus on only supporting those instead?
Privacy: We can share what we know now, but the goal is to get ahead of new regulations. They’re basically popping out or changing on a monthly basis right now.
The security teams see that this is going nowhere and tried to bring this to a more practical level...
Security: What you are asking for makes sense but might set the project back by 6 months. Maybe we can somehow create more abstract requirements about region-specific handling and then apply them to the relevant data instead of all of it?
Privacy now feels the importance of these controls is not appreciated and is starting to lose patience. All hope seems lost when, miraculously, a new idea emerges...
Privacy: This is not a question of whether we do it or not. We have to have these controls. Wait a minute… What if we just create a separate database for each region so we can apply the right policies for each environment separately?
Data: The whole point of the new infrastructure is to have all of our data in one place so that we can run our analytics on the best data available.
Security: Maybe we can have an anonymized version of the data in its unified view for analytics while keeping the original data separated for the sake of meeting the requirements?
Privacy: Sounds great!
Data: That might have been a good option 12 months ago when we started, but now it is going to both bump up cost and overhead significantly, nevermind that it's going to be extremely difficult to sync up with the data source every time it changes…
Privacy: I don't understand. Why is it such a problem to add that data origin attribute? It's just another column…
And so it goes on and on….
Why is this happening? Why is collaboration across these three teams so hard?
First, it’s crucial to remember that each team occupies completely different spaces with their own respective priorities and perspectives. Privacy officers are primarily focused on privacy regulations, data subjects, privacy controls. Data engineers are focused on creating an infrastructure that will satisfy the data scientists that count on them and maximizing their enterprises’ unit needs along the lines of scale, cost and performance. Meanwhile, security needs to navigate the requirements of everyone else while still ensuring their authority and efficacy over securing the way their organization’s data is handled.
Unfortunately, it is extremely difficult to align these priorities under a single set of policies for data infrastructure and management. No amount of systems or applications will help unless they can address the very important needs of all three.
Now that you’ve gotten a good look into this very critical human problem, we invite you to explore how to overcome it and other obstacles like it in our upcoming virtual expert panel, featuring:
Recent blog posts
- How to Control Access to PII in Snowflake with Satori
- Sensitive Data Isn’t The Crown Jewels
- Creating an Okta SSO application for a Satori-protected Snowflake account
- The Principle of Least Privileged Data Access
- The Do’s and Don’ts of Nailing that Developer Interview
- It’s Time to Set your Data Free (and Decouple it from Data Protection)