Practical Steps to Implementing Privacy Engineering
• read
A central remit of privacy-by-design is to dive deeper into the tools, methodologies, and techniques that ensure that your company can integrate privacy into its design processes and workflows. It is a rapidly growing field that is often called privacy engineering. The challenge becomes defining privacy engineering precisely and then making sure that that function is properly supported within the organization.
The emergence of privacy engineering as a discipline signal that privacy-by-design has moved rather quickly from the conceptual to the nonabstract environment that is product engineering.
To discuss the challenges attendant to implementing privacy engineering and dig into some practicable advice, WireWheel Co-Founder and Chief Scientist, Amol Deshpande moderated a panel at the Fall Spokes Privacy Technology Conference held this past December 7-8.
Deshpande was joined by the former Director of Engineering Facebook (now Meta) Yi Huang; Anna Togia, the Technical Product Manager Privacy, Security & Compliance at dating app Hinge; and Uber’s Head of Privacy Engineering and Assurance Nishant Bhajaria to discuss Practical Steps to Implementing Privacy Engineering.
Privacy engineering is a multifaceted challenge
We heard yesterday [during the Spokes Privacy Technology Conference] that there are new frameworks coming down the pipeline and the privacy landscape is moving at a very rapid and aggressive pace.
It’s really understanding, what are our terms, how are we defining privacy engineering, and who really has a stake, that’s going to help us solve this problem.
—Anna Togia, Hinge
“A core problem is noise in the privacy space,” says Yi Huang. And companies really need to be laser-focused on the most important problems.
“At any given time, there are multiple privacy regulations that companies have to deal with – each with different timelines and guidance. So, we ask ourselves: Instead of just simply being compliant with each one as they come, how can we respond to the regulations more effectively? What technology can we put into the products we are building…But practically, it’s very difficult because you have to juggle multiple balls.”
For a small company like Hinge, a central challenge is “how do we define privacy engineering in an organization that doesn’t have the resources to field a privacy engineering team per se,” says Togia. “What then does privacy engineering look like for us? Are we looking at technical know-how, process management, or a combination of both? And if that’s the case, then where should privacy engineering sit?”
Bhajaria is concerned that what has served so well in the past, may not be well-suited to the challenges of privacy engineering:
“There was a scene in the movie Titanic,” relates Bhajaria. “They were looking back and saying, ‘how did this captain not see the iceberg coming. It was out there in the open.’ The response: ‘Everything he knew was wrong. ’ I hope that Titanic analogy is limited when it comes to privacy because that didn’t end particularly well. But there is a larger point here.
“The things that have made us very successful as a tech industry may not automatically transfer on the privacy security side” he opines. “Having siloed teams, bespoke processes, independent tech stacks, allowing complete autonomy to engineers. Those are wonderful things. They led to the creation of great services.”
But with privacy, security, and data protection in general, you need to understand end-to-end how the data flows…across multiple automated systems without any clear visibility. We are literally sailing into the night and running towards an iceberg at times, not knowing that the iceberg is there.
The biggest challenge for all of us is going to be, how do we use the best of our tech impulses and how do we repurpose our instincts, our data, our processes, and our tooling, to ensure that we don’t double down on the things that will not work for privacy and security purposes.
—Nishant Bhajaria, Uber
Building on the theme of “talent profile,” Togia says Hinge is focused on “who should you hire into these roles when you’re thinking about the privacy engineering space.” As “a small fish in a big privacy ecosystem pond, it’s really been a concern. Who are the right people to solve some of these major privacy concerns?”
She notes that while it is really important to be an expert at your core role, the “technical know-how,” the engineer needs an understanding of the impact that privacy is going to have. “Those are the people that you want to go for because those are the people that can also educate the rest of the team…And then you start to really cultivate privacy by design.”
Bhajaria points to the problems of scale and the complexity of growing data. “My advice from a framework perspective would be to try and identify what you have at a very early stage” when you can “harness actual privacy controls. And this too is “very important when it comes to staffing,” who will ultimately create the needed synergies necessary to privacy-by-design.
It’s critical to start with internal teams. Even if you ended up buying third-party tools, even if you hire consultants on the outside, it’s important that your engineers are able to invite those external interventions into their system. And they cannot do that unless they have end-to-end visibility.
So, I would strongly recommend training internal engineers…it is critical that you have the synergy between third-party tools, outside vendors, regulators, and internal engineers because that’s where the culture shift truly happens.
—Nishant Bhajaria, Uber
Integrating the privacy review process into engineering
“Integrating the privacy review process into the engineering release process is necessary, but not sufficient,” says Huang. Rather “we have multiple integration points involving privacy in the development process:
The heavy lifting really happens in the beginning. The earlier you involve the privacy discussions, the better. The first major discussion about privacy is in the product design phase. Before engineering actually puts in any code. We discuss how the specific product is being built, what data the product is using, and what are the privacy implications.
—Yi Huang, Facebook
“At the implementation stage…we focus on whether we’re doing what we said we were going to do… and put checkpoints in place. After it’s finished – before the release process – we have the privacy engineering review process [followed by checks] in the release cycle.”
“When it comes to policy reviews,” Bhajaria notes that the legal team is often put “in an impossible situation of “letting something go…or being seen as a blocker. And that creates unnecessary friction.
We too “intervene at the inception stage before the PRD [product requirements document] becomes and ERD [engineering requirements document].”
Much of it can be automated:
If you find out there are teams collecting a lot of data, but only need that data for a couple of days, you can write a deletion service that will query some of their databases on the third or fourth day…without that data making it to the warehouse…You can fix the problem right off the bat…investing in automation, but in a very targeted fashion.
—Nishant Bhajaria, Uber
Typically, “you start with the first principles. And then, and then struggle to produce implementation details,” continues Bhajaria. “Let’s flip the pyramid a little bit. Let’s get the implementation details and use those learnings to inform the piracy principles and their evangelism across the company to unblock the piracy review process rather than having [it at] the tail end of the process.”
Justifying all this effort
“Figuring out trends over time really justifies the value of privacy,” opines Togia.
Cataloging things like frequency and severity of privacy and incidents is a great place to start. How you quantify those privacy incidents and whether they’re plausible or identifiable,. Looking at the types of privacy failures your system currently has and how much you have fixed over time.
These are baseline metrics that you can then take to decision-makers and leaders in your organization.
—Anna Togia, Hinge
“If we are using data in the right way and know how we are collecting and capturing it, and how it flows throughout its life cycle,” says Togia, it is really a benefit to anyone using data. “I think that you can often justify privacy as more than just what it is at face value, and really leverage it.”
“I want to get away from us, arguing from a defensive, punitive position where if you don’t do this, bad things will happen,” asserts Bhajaria.
Think of it this way. If you have a lot of data in your warehouse (more data than you need) you are probably protecting it, right?” But “you are protecting data that you probably shouldn’t have. It’s not adding value to the business, but it’s a security risk. It’s a business risk. It’s an unnecessary expenditure.”
Importantly, Bhajaria also notes the failure to comprehend the cost of bad data that works its way through the organization that is then converted into decisions.
My advice to people would be, don’t just position it as a privacy expense…Make sure that this is seen as a sustained strategic partnership between you and the data science team, the marketing team, the security team, and the platform team.
I cannot say this enough: don’t make it just about privacy.
—Nishant Bhajaria, Uber
Some concluding thoughts
Yi Huang, formerly of Facebook
I put privacy tools into four different buckets:
- Introspection: understanding how your systems work.
- Detection: the ability to identify when violations happen
- Enforcement: the ability to block issues from arising in the first place, and
- Verification: the ability to prove that you are compliant (e.g., ROPAs and PIAs)
“I think the, one of the reasons why it’s really hard for us to respond to privacy regulations is because we really don’t understand how data really flows [in many cases] through systems.”
Nishant Bhajaria, Uber
“I’m sure there’s an engineer somewhere out there right now, assuring their manager or attorney everything has been deleted, or there is no known risk. And the attorney is going to wake up tomorrow morning and realize that that wasn’t true. Not because the engineer was dissembling, but because they didn’t know somebody else was doing something.”
Anna Togia, Hinge
“The important thing to think about, especially anyone that’s maybe on a smaller team, is that that doesn’t make privacy any less vital.
“It is a matter of ubiquity. This needs to be a pervasive concern and we need to be asking ourselves how do we organizationally affect that.”
