Nandita Narla on Taking a Top-Down Approach when Building Privacy Programs

What is your role, and how does it relate to ensuring data privacy?

I lead a team focusing on three different privacy aspects at DoorDash. One is privacy engineering, which focuses on building tooling and product features that enable privacy. The second is privacy assurance, aligning control frameworks, audits, and investigations response. The third function is privacy operation. So that's just the day-to-day privacy risk management and governance activities. My team works closely with the legal side of privacy, the privacy compliance function, and diverse stakeholders across the organizations, primarily engineering, product, security, and other teams.

Tell us about your approach to building privacy programs.

I have been doing this for ten years at different companies. I approach building a privacy program, whether starting from scratch or enhancing an already existing program, by taking a top-down approach. 

‍

I generally began with understanding the goals or strategies and the organization's current state of privacy. Once that's well understood and aligned with an industry-accepted framework, standard ISO/IEC. That forms the baseline for policies, procedures, and guidelines.

‍

Then I step one level below into the operations and privacy risk management and embedding privacy by design, which I generally like to focus on two different lifecycle areas. One is the SDLC, or the software development lifecycle. And the second is the data lifecycle. So in terms of SDLC and embedding privacy by design into SDLC, it would involve building a dev ops equivalent of privacy, like embedding privacy code reviews and code libraries, making sure that there's low friction for developers when integrating privacy into products. On the data lifecycle side, there would be a focus on managing or building privacy across the data lifecycle. So when we're talking about anonymization, masking, secure deletion, data minimization, adopting privacy enhancing technologies, there's a whole lot of suite that can go into it in terms of tooling, processes, data walls, and clean rooms. 

‍

And the underlying fabric for all of this would be data infrastructure, so making sure that there are services and infra to support all these tools and processes built across these two lifecycle areas. And then one of the most important ones is privacy awareness and training. The human aspect may include building a Champions program to ensure everyone in the organization is aligned and has the same understanding of privacy. And all of this needs to be incorporated into some privacy metrics and reporting so that the value of the privacy function can be demonstrated across the organization. You can get buy-in and resources for enhancing the program long term, as well as identifying gaps and improving areas where there are deficiencies.

How do you measure and prioritize data privacy risks?

For data privacy, risks, measurement, and prioritization, I've seen in the last ten years, I've seen companies do it many different ways, and I've built programs where it then the risk measurement and prioritization were highly dependent on the resources available the data available, what is the risk tolerance of the organization and how much are they willing to invest in setting up this program? I'm at the court. Privacy risk is a function of the likelihood of harm, impact, or severity. And the third part is mitigating control effectiveness. So you need three elements to understand the risk to an up to an individual or a particular function. 

‍

Several things need to be put in place to do this appropriately. For example, how do you understand asset criticality? Do you already know this information? In terms of likelihood and severity, some companies take an individual approach where you define privacy risk and harm to an individual. Some companies tend to take an org approach, like what is the privacy risk to this for me as a company, and then try to incorporate that into the enterprise risk management function. And then you need threat modeling; you need to have a good understanding of what mitigating controls you have and how you are testing. And do you have a privacy assurance function that can adequately describe the effectiveness of these controls to be able to build into the risk model? So it's easier said than done. And there, I've built programs aligned to compliance frameworks that provide GDPR-focused programs where the risk was calculated, primarily driven by DPIA. And then you have built some programs that integrated with security functions. So they used a fair model for assessing privacy risk. And then, one of my companies had a privacy risk assessment methodology used by some government entities. ISO has a privacy risk assessment framework. But most companies tend to use a combination of these to build their own custom privacy risk measurement and scoring model that works for them.

What's one thing that has surprised you in your data privacy work? 

Because I was coming to privacy from a security background, the one thing that surprised me was that there were many gray areas in privacy. A lot of privacy policy and policy enforcement is driven by how a particular company interprets a legal or compliance requirement, which is very different from what I was used to in the security space, where you have very clearly defined parameters. You have rules, and a lot of automation is possible because things are much easier and more definitive. 

What challenges have you faced, and how have you overcome them?

The most common challenge I see the privacy pros, especially privacy engineering, folks face is getting buy-in from leadership or getting resources or headcount to invest in maturity-related tooling or processes. In most cases, there is a higher probability of success in partnering with other teams to implement some of these. Some examples are: say, the security team has some API governance tools and some DLP tools that can be used for privacy and incident management. Similarly, data teams generally have tooling for data discovery or cataloging, which can also be used for privacy data maps. So if you're not getting bandwidth, or if you're not getting the headcount and priority from leadership to be able to implement programs that are on your roadmap, then finding allies and other teams is a good idea.

What has been your experience engaging technical or developer teams?

I didn't even need to convince them that they needed to do the right thing for privacy. They are already aligned in that privacy is essential. I don't know why that is the case. Many of the engineers I had the opportunity to work with and currently work with come from highly regulated industries. So this has been the norm in their previous organizations, or they've come from another big tech, which had noteworthy fines imposed for their like privacy practices, so they're very aware of privacy implications and are generally on board to implement countermeasures or address privacy risks that are surfaced by privacy teams.

What best practices to share or pitfalls to avoid when ensuring data privacy?

I have three best practices. The first one is when you're building a privacy program, don't reinvent the wheel. There are many frameworks, standards, control inventories, and program guidance that can be used as a starting point. So rather than doing something very custom for your organization and having lots of consultants come in and give you the strategy, I think it's easier to adopt something that's industry-accepted. 

‍

The second best practice is around deploying tooling. When you're building or buying tooling, make sure that it is scalable to your organization, as well as it is; some element of flexibility has been baked into it. A lot of the laws that are upcoming and on the horizon have slightly different flavors. Making sure that you're thinking ahead and being proactive and that you're building these tools, or deploying these tools, is a good idea. 

‍

And the third one is around privacy metrics. You have to show the program's value to be able to measure it and demonstrate value to improve it in the long term. So that's an immensely neglected topic. But it's something that privacy pros should start building programs with that end in mind. How are you going to report this? What are the SLAs is what are our target metrics, and try to get 1% better every day?

What are some of the key privacy metrics you track?

In terms of metrics, there are two types; I would think from like strategic metrics where you're looking at, you've maybe done an assessment or a benchmarking exercise against the peer group or some best-in-class organization, and metrics around where you are, whether you're like on the maturity scale with to your target maturity, that's like at the strategic level. But on the tactical and operational side. There are so many metrics around each area that we discussed earlier when we built the privacy program in terms of like desires or individual rights. Are you maintaining your SLA regarding the user experience with those complaints reduced regarding training and awareness? Again, like, have you done? Like, what's your training coverage? Has that led to a decrease in privacy vulnerabilities from developers? Are the marketing and product teams aligned? In terms of operational metrics, such as third parties? Are you doing like a vendor in the due diligence program? What are some common areas? How many are going through an accelerated review? Everything you do in privacy should result in some metrics that should be reported. And then, it should like to roll into the strategic metrics showing that you're moving ahead as a program.

What SLAs do you follow for privacy reviews for new products/features? 

So especially when it comes to the SDLC part of the program and how privacy is embedded? What does that SLA look like if you use a workflow for every feature to embed privacy by design? Is it two weeks or two days? Is there a lot of back and forth? How many hours are like, and what is the time developers take to fill this out? And is that actually valid? Like, was there? How much did it change from the first time they submitted it versus when it was actually completed? Time-related, like those, is the metrics that help justify the program. So you should try to reduce the friction and improve, making it as streamlined as possible. Versus should be seen as something other than a blocker where you're spending multiple iterations weeks on getting privacy, like a check, on being able to go ahead.

What predictions do you have for Data Privacy in 2023?

For privacy in general, there is like no surprise that because of the macroeconomic conditions that we are facing, every company is trying to like cut costs; they've been massively offset across the industry, especially in tech; I think it's highly likely that there won't be any increase in budgets for privacy teams. Best case, they will be able to retain the budget they had last year. So with that in mind, there will likely be an increased focus on privacy teams being required to do more build versus buy evaluations. With limited budgets, there would be a lot of interest in buying tooling versus building it in-house, even for companies that have typically built the rest of their tooling in-house. 

‍

So this is going to be a year where with limited resources, there would be more privacy tools and procurement. The second prediction is around laws and how the legal landscape needs to evolve in the US. But we have various state laws that are on the horizon. There's the California age-appropriate design code. On the global front, India, Indonesia, China, and South America, a lot of countries are rolling out new privacy laws or making substantial changes to their existing ones. So with these additional considerations, privacy teams would have to align their compliance strategy and be proactive on how they comply, like baking that into their roadmaps for this year. And the last prediction is around AI. There's been a lot of focus on AI ethics, explainability, and transparency. And with the EU AI Act coming up, NIST is launching its AI risk management framework this week. So there are a lot of interesting moving parts in this space, and this is going to be an area where privacy teams are going to be asked to lean in more and at least like a plan for what will happen in the future.

What does Data Privacy Day mean to you?

There are some common characteristics among all privacy pros. We want to do the right thing, and we think deeply about privacy. We want to solve complex problems. But there are times when it just feels like you're fighting a losing battle, especially when it comes to your privacy. There's like breaches happening every day. There's so much privacy enforcement happening and like noteworthy fines. So there's like, not you're not making a difference. Data privacy days are an opportunity for all of us to connect and network, learn from each other, and celebrate our collective wins.