An interview with Sheila Jambekar, CPO at Plaid

Sep 27, 2021
Share this post
Sharing to FacebookSharing to LinkedInSharing to XSharing to Email

The following interview took place in April 2021 when Sheila was the VP and Deputy General Counsel of Privacy and Product at Twilio. Sheila is now the Chief Privacy Officer at Plaid and an Advisory Board Member at Techtonica.

Key Points:

- Privacy teams have to work arm-in-arm with engineering teams to implement robust privacy protocols that aren’t daunting.

- A privacy mandate must come from the very top of the organization and each employee must feel empowered to do the right thing.

- Companies struggle with recognizing what truly constitutes personal data and how quasi-identifiers interact to make an individual re-identifiable.

Watch the full session:

Patricia: I’m thrilled to have Sheila Jambekar here today. She is the VP and Deputy General Counsel of Privacy and Product at Twilio. A little bit about her background. She joined Twilio back in 2015 and built out the privacy program at Twilio, a US-based but global communications platform as a service, including guiding it through the downfall of Safe Harbor back in 2015 and then up through GDPR, obtaining binding corporate rules and now onwards in a post-Privacy Shield world. By building a team focused on doing privacy right, not just checking the boxes, she has helped build trusted data stewardship into the culture at Twilio. And I’m so excited to have her here. She is very knowledgeable and I’m very excited that she can share her wisdom with us today.

Sheila: Thank you, Patricia. Excited to be here.

How have you dealt with GDPR compliance internally at Twilio?

Patricia: Sheila, how have you dealt with GDPR compliance internally at Twilio?

Sheila: That’s a great question. Twilio was a relatively small company, but growing really fast, when GDPR came along and so we were in the throws of building a privacy program out. In some ways it was a catalyst to hurry it along in terms of getting our privacy program put together and also created a lot of burden, because of all of the sudden we had to move really fast and go from having a very nascent program to having a strong one that met GDPR standards in a relatively short period of time. The way that we approached GDPR compliance internally was really to try to build it right from the get go. I worked really closely, arm-in-arm, with our engineering architects to take these broad GDPR principles and convert it into “ok, what does it actually mean in terms of engineering work?” so that teams can start to think “how do I apply these engineering concepts and then cut tickets in Jira and actually start executing and implementing these controls?” because you can imagine - data minimization, what does it actually mean in terms of engineering that into your products and services? And so that close partnership with our architects was key. Even today, how we operate is thinking about new controls, different controls. We think about “ok, what does that actually mean operationally?” “how does that actually get implemented by the engineers?” and we need to work with folks who have that technical background who can help serve as that bridge. We have a bridge between ourselves and the architects to then bake that into how we operate. That is how we dealt with it and now today that’s part of our engineering standards. To make sure we keep those controls, they stay in place and we try to leverage the tools that our engineers and architecture teams already have in place, so it’s not layering on this new thing on top, but it’s actually infused into how we build from the ground up. It’s a journey and I’m sure we’ve always got room to improve upon these processes, but that’s the concept that we’ve been using.

At the same time that we did the GDPR compliance, we worked on our binding corporate rules, which worked really nicely together, so we were able to layer on that policy piece at the same time as working with the engineers. That has been our approach.

I worked really closely, arm-in-arm, with our engineering architects to take these broad GDPR principles and convert it into “ok, what does it actually mean in terms of engineering work?” so that teams can start to think “how do I apply these engineering concepts and then cut tickets in Jira and actually start executing and implementing these controls?”

Are there any tips that you have to making bridging the gap between the privacy team and the engineering teams a smooth process?

Patricia: That’s fascinating, Sheila. I think that a lot of organizations have trouble bridging that gap between the privacy team and the engineering teams. Are there any tips that you have to making that a smooth process?

Sheila: To me, I think the important thing is that, on the lawyer side or the legal side or the privacy professional side, finding people who are humble and curious. If you can get people who really are interested in trying to understand and capable of understanding how engineering systems and the services work, that’s going to make it much easier. And then you’ve got to find those champions within the engineering or architecture team who are interested in doing the right thing and the importance of privacy. Those can be your best advocates. And also to be interested in, from there standpoint, of how do implement these things. If you have the lawyers who say they don’t need to understand how engineering works or they don’t need to understand the details of how the data flows or why this is hard, just make it happen, then your engineers and your product people are going to push back and be frustrated because you’re speaking different languages. And vice-versa, if you’re trying to work with engineers or product team members who don’t buy into the value of what you’re asking them to do, then that’s not going to work either. I would say there’s a bit of internal marketing as well that goes into building a privacy program and getting everybody on board is really finding those champions but also selling it.. Selling to the organization why it’s important, so that there’s an intrinsic interest beyond the legal team and the privacy team in getting it done. Perhaps first and foremost, because the engineers and the product folks, they are the people who are bringing in the money, right? They are building the thing that brings the company money and the trick as coming in from a privacy or legal or any kind of compliance perspective is how do you not feel like a burden? How do you find ways that you can help them rather than you being just one more thing that potentially stands in the way of them launching the product, and selling it, and making money? Not to say that there aren’t going to be moments like that, right? Inevitably you run into that. Even in those moments, you want to be able to explain to the organization why it’s important to maybe stop and tweak something and change how you do it and not from a “because I said so, because I’m a lawyer.” That’s not going to get you very far. That’s not going to be very compelling.

Are there any regulations coming up that don’t fit in nicely with the GDPR that you are working towards complying with?

Patricia: I love that answer. That’s great. And I think that the fact that you spent so much time focusing on the engineering piece, understanding how the tech works is a really great point. It really makes such a difference and is also one of the reasons why I really enjoy speaking with you.

Are there any regulations coming up that don’t fit in nicely with the GDPR that you are working towards complying with?

Sheila: The upside being that most privacy laws are based at least to some extent on the OECD principles, which are international. But there are always unique ones out there. The ones that we are working towards and thinking about how to tackle are privacy laws that have a data localization requirement. The Schrems II case that came out middle of last year, which was based on GDPR and then created stricter rules around data being moved out of the EU, started to put the GDPR almost into the same realm as some of these laws that make things more difficult, which is keeping the data in specific countries. You’re starting to see that pop up in different pockets around the world where there is a need to keep a need in the country. The other ones that are interesting and create a new angle that GDPR didn’t bring along are the data sale laws that we’re seeing crop up, like the California Consumer Privacy Act, the CCPA, laws like that that are very specific to data sale create some interesting angles that change the landscape. Now instead of having to think “am I a controller or a processor” you’re now thinking “am I a controller and does the thing that I’m doing constitute a data sale” and in some ways these make it more difficult to comply and layers on additional obligation. Those are the ones that I’m keeping an eye on. Some of the smaller ones, like the Illinois Biometric Act, the CCPA, what other laws are going to crop up like that? And then another one that’s coming along, there is some chatter right now in the EU around AI regulation. That is another one that we are keeping a close eye on. It’s kind of adjacent to GDPR in that there’s starting to talk about “do we want to put in new regulations around responsible AI and ML?” And that is an interesting one, because that goes beyond some of the principles of privacy which make sure that people can control their data or being concerned about the classic privacy issues of where the training data being used or how it’s being used. Really moving beyond into things like making sure that the AI can’t be hacked or is it dangerous AI, or unintended consequences. Things for which there really isn’t much history on how to solve those problems from an engineering standpoint. So keeping a close eye on that stuff so we don’t lose sight of how that could impact the business as it grows.

What are some common mistakes that you see companies making with the data that they are handling?

Patricia: And what are some common mistakes that you see companies making with the data that they are handling?

There’s also assumptions that email addresses aren’t personal data, for example, or IP addresses aren’t personal data. Actually they are. They can be. And so not really realizing the full scope of what constitutes personal data is another common mistake I see.

Sheila: Perhaps one of the more common mistakes that you run into is just misunderstanding. For example, companies thinking “okay, so we just removed the names from this database, so it’s all anonymized and it’s totally fine, and we can use it for whatever” and not realizing that that doesn’t actually constitute for example true anonymization under privacy laws. Some of that hubris of “we just removed the last four digits of the credit cards and the names” but they haven’t actually truly anonymized the data and then someone figures out that you can re-identify it and do some horrible thing. Some of the common mistakes are around recognizing what it means to anonymize data, what truly constitutes personal data. It’s not just if it directly identifies me, Sheila Jambekar, it can be a combination of factors of a middle-aged woman in the Bay Area and you start to put those pieces together in a database and you can still find me and figure out that that’s me. And that’s a common misconception that I run into from businesses, is thinking that the only thing you need to do is remove the identifiers. The other one that I run into similarly is the assumption that if you just hash it, you just hash the data then it’s all anonymized and it’s find and you can go off and do whatever you want with it. Well that’s also not true. It may not be directly identifying, but it may still be pseudonymized, and that doesn’t count as fully anonymized and you’re still restricted in what you’re allowed to do with it. And if you can reverse the hash or if I can still reverse-engineer my way back to the data, you still are handling personal data and you have to treat it that way. So I think that some of that nuance can be really tricky frankly. There isn’t a “this is anonymized enough” and it can be frustrating for teams well “what do we have to do?” And you’re balancing between trying to be able to use a dataset in a lawful way that is anonymized against stripping so much information out of the data that it’s no longer useful. So that’s one we struggle with and that I’ve seen a lot of companies struggle with and I’ve seen mistakes being made around. It’s that assumption around what constitutes personal data and what turns personal data into not being personal data anymore. That being one of them. There’s also assumptions that email addresses aren’t personal data, for example, or IP addresses aren’t personal data. Actually they are. They can be. And so not really realizing the full scope of what constitutes personal data is another common mistake I see. And I think just lastly is that you see a lot of carelessness. It’s hard to get all of the tools and controls in place in a way to make sure that it’s easy for people to do their jobs and not accidentally mishandle data. So as companies evolve, and change, and grow, you just run into the silly mistakes. The casual things. “Oh, I put this data into a spreadsheet and emailed it.” Or “oops, I accidentally emailed it to people out side the company. Things that are unintentional and yet, because there is so much data at many of these companies, and people have access to it in order to do their jobs legitimately, every person that has access can become a vector for risk. That’s a lot of people! And privacy or security is not their first job or their full time job. It’s tricky to get everybody aligned and sometimes there just aren’t good tools that enable people to both get their jobs done and also prevent bad things from happening accidentally: “I just need to put it in the spreadsheet so that I can get it out and oh shoot I emailed it to the wrong person, I emailed it to someone external instead of the internal Patricia at the company.” There you go, you’ve got yourself a breach. Unfortunately, that happens and it’s a hard one to find solutions to mitigate against.

Patricia: I guess through mitigating the sharing of information in the first place.

Sheila: Exactly. But then people have work to do and then they get frustrated cause they’re saying “wait a second, I need to get my job done.” So trying to find the tools that enable people to share the data in a safer way, or only share the data they need, in a way that makes it easier without creating so many barriers. That’s where it can be tricky to find the right tools and solutions out there that make both sharing when you need it easy, but at the same time dummy-proofing and avoiding the mistakes, preventing people from making the oopsies, but while still giving them the ability to get their job done.

Patricia: It’s interesting that you’ve also found that companies sometimes think that just removing the name, just removing a few digits of the credit card number are enough for anonymization. You’ve got the GDPR, the CPRA coming up as well, and a bunch of other regulations that list direct identifiers, quasi-identifiers, and everything that you should consider as a minimum for anonymizing a dataset. Do you think they are not reading these regulations? Or is it a misinterpretation?

Sheila: Yeah, I think it’s probably because they’re assuming and not reading closely, is probably one of them. And these still in the grand scheme of things, GDPR is now two years old and if you didn’t do business in Europe in the past, CCPA is now a year old in terms of enforcement, so it’s kind of a new concept for a lot of companies that aren’t steeped in privacy. For privacy people who are like “oh, yeah, of course, I know this” but let’s say that you’re a smaller company and you don’t have a privacy expert in-house, and the last time you really looked at privacy issues or your lawyer looked at privacy issues was years ago, and they went to some seminar but it’s not really their area of expertise and so they don’t know it in depth and they may be applying old concepts that they were used to from back in the day when the only privacy laws out there were data breach laws, where personal data is often defined very narrowly to things like name + credit cards, or names + account ids, or social security numbers, and so there’s just a misconception about what it it because they’re applying old models to that. For those of us who are in the data world or are steeped in privacy, it feels like old news, but I still run into people who aren’t operating in this space a lot who say “what’s the big deal? It’s just an email address” or “it’s just a phone number” or “it’s just a name.” And because we operate in our everyday lives not necessarily ourselves thinking of that as being sensitive sometimes people struggle to understand why it’s a big deal or why it’s considered personal data. I think that’s where it comes from, it’s kind of like a cultural thing. Think about how much privacy changes in just a couple of years since GDPR. It’s been an explosion and there’s a lot of people who are operating in different spaces so they haven’t really caught up and they can get caught off guard because they’ve applied old notions to a new world.

Let’s say that you’re a smaller company and you don’t have a privacy expert in-house, and the last time you really looked at privacy issues or your lawyer looked at privacy issues was years ago, and they went to some seminar but it’s not really their area of expertise and so they don’t know it in depth and they may be applying old concepts that they were used to from back in the day when the only privacy laws out there were data breach laws, where personal data is often defined very narrowly to things like name + credit cards, or names + account ids, or social security numbers, and so there’s just a misconception about what it it because they’re applying old models to that.

Patricia: Hopefully it’s just a matter of time.

Sheila: I think so.

Data Left Behind: AI Scribes’ Promises in Healthcare

Data Left Behind: Healthcare’s Untapped Goldmine

The Future of Health Data: How New Tech is Changing the Game

Why is linguistics essential when dealing with healthcare data?

Why Health Data Strategies Fail Before They Start

Private AI to Redefine Enterprise Data Privacy and Compliance with NVIDIA

EDPB’s Pseudonymization Guideline and the Challenge of Unstructured Data

HHS’ proposed HIPAA Amendment to Strengthen Cybersecurity in Healthcare and how Private AI can Support Compliance

Japan's Health Data Anonymization Act: Enabling Large-Scale Health Research

What the International AI Safety Report 2025 has to say about Privacy Risks from General Purpose AI

Private AI 4.0: Your Data’s Potential, Protected and Unlocked

How Private AI Facilitates GDPR Compliance for AI Models: Insights from the EDPB's Latest Opinion

Navigating the New Frontier of Data Privacy: Protecting Confidential Company Information in the Age of AI

Belgium’s Data Protection Authority on the Interplay of the EU AI Act and the GDPR

Enhancing Compliance with US Privacy Regulations for the Insurance Industry Using Private AI

Navigating Compliance with Quebec’s Act Respecting Health and Social Services Information Through Private AI’s De-identification Technology

Unlocking New Levels of Accuracy in Privacy-Preserving AI with Co-Reference Resolution

Strengthened Data Protection Enforcement on the Horizon in Japan

How Private AI Can Help to Comply with Thailand's PDPA

How Private AI Can Help Financial Institutions Comply with OSFI Guidelines

The American Privacy Rights Act – The Next Generation of Privacy Laws

How Private AI Can Help with Compliance under China’s Personal Information Protection Law (PIPL)

PII Redaction for Reviews Data: Ensuring Privacy Compliance when Using Review APIs

Independent Review Certifies Private AI’s PII Identification Model as Secure and Reliable

To Use or Not to Use AI: A Delicate Balance Between Productivity and Privacy

To Use or Not to Use AI: A Delicate Balance Between Productivity and Privacy

News from NIST: Dioptra, AI Risk Management Framework (AI RMF) Generative AI Profile, and How PII Identification and Redaction can Support Suggested Best Practices

Handling Personal Information by Financial Institutions in Japan – The Strict Requirements of the FSA Guidelines

日本における金融機関の個人情報の取り扱い - 金融庁ガイドラインの要件

Leveraging Private AI to Meet the EDPB’s AI Audit Checklist for GDPR-Compliant AI Systems

Who is Responsible for Protecting PII?

How Private AI can help the Public Sector to Comply with the Strengthening Cyber Security and Building Trust in the Public Sector Act, 2024

A Comparison of the Approaches to Generative AI in Japan and China

Updated OECD AI Principles to keep up with novel and increased risks from general purpose and generative AI

Is Consent Required for Processing Personal Data via LLMs?

The evolving landscape of data privacy legislation in healthcare in Germany

The CIO’s and CISO’s Guide for Proactive Reporting and DLP with Private AI and Elastic

The Evolving Landscape of Health Data Protection Laws in the United States

Comparing Privacy and Safety Concerns Around Llama 2, GPT4, and Gemini

How to Safely Redact PII from Segment Events using Destination Insert Functions and Private AI API

WHO’s AI Ethics and Governance Guidance for Large Multi-Modal Models operating in the Health Sector – Data Protection Considerations

How to Protect Confidential Corporate Information in the ChatGPT Era

Unlocking the Power of Retrieval Augmented Generation with Added Privacy: A Comprehensive Guide

Leveraging ChatGPT and other AI Tools for Legal Services

Leveraging ChatGPT and other AI tools for HR

Leveraging ChatGPT in the Banking Industry

Law 25 and Data Transfers Outside of Quebec

The Colorado and Connecticut Data Privacy Acts

Unlocking Compliance with the Japanese Data Privacy Act (APPI) using Private AI

Tokenization and Its Benefits for Data Protection

Private AI Launches Cloud API to Streamline Data Privacy

Processing of Special Categories of Data in Germany

End-to-end Privacy Management

Privacy Breach Reporting Requirements under Law25

Migrating Your Privacy Workflows from Amazon Comprehend to Private AI

A Comparison of the Approaches to Generative AI in the US and EU

Benefits of AI in Healthcare and Data Sources (Part 1)

Privacy Attacks against Data and AI Models (Part 3)

Risks of Noncompliance and Challenges around Privacy-Preserving Techniques (Part 2)

Enhancing Data Lake Security: A Guide to PII Scanning in S3 buckets

The Costs of a Data Breach in the Healthcare Sector and its Privacy Compliance Implications

Navigating GDPR Compliance in the Life Cycle of LLM-Based Solutions

What’s New in Version 3.8

How to Protect Your Business from Data Leaks: Lessons from Toyota and the Department of Home Affairs

New York's Acceptable Use of AI Policy: A Focus on Privacy Obligations

Safeguarding Personal Data in Sentiment Analysis: A Guide to PII Anonymization

Changes to South Korea’s Personal Information Protection Act to Take Effect on March 15, 2024

Australia’s Plan to Regulate High-Risk AI

How Private AI can help comply with the EU AI Act

Comment la Loi 25 Impacte l'Utilisation de ChatGPT et de l'IA en Général

Endgültiger Entwurf des Gesetzes über Künstliche Intelligenz – Datenschutzpflichten der KI-Modelle mit Allgemeinem Verwendungszweck

How Law25 Impacts the Use of ChatGPT and AI in General

Is Salesforce Law25 Compliant?

Creating De-Identified Embeddings

Exciting Updates in 3.7

EU AI Act Final Draft – Obligations of General-Purpose AI Systems relating to Data Privacy

FTC Privacy Enforcement Actions Against AI Companies

The CCPA, CPRA, and California's Evolving Data Protection Landscape

HIPAA Compliance – Expert Determination Aided by Private AI

Private AI Software As a Service Agreement

EU's Review of Canada's Data Protection Adequacy: Implications for Ongoing Privacy Reform

Acceptable Use Policy

ISO/IEC 42001: A New Standard for Ethical and Responsible AI Management

Reviewing OpenAI's 31st Jan 2024 Privacy and Business Terms Updates

Comparing OpenAI vs. Azure OpenAI Services

Quebec’s Draft Regulation Respecting the Anonymization of Personal Information

Version 3.6 Release: Enhanced Streaming, Auto Model Selection, and More in Our Data Privacy Platform

Brazil's LGPD: Anonymization, Pseudonymization, and Access Requests

LGPD do Brasil: Anonimização, Pseudonimização e Solicitações de Acesso à Informação

Canada’s Principles for Responsible, Trustworthy and Privacy-Protective Generative AI Technologies and How to Comply Using Private AI

Private AI Named One of The Most Innovative RegTech Companies by RegTech100

Data Integrity, Data Security, and the New NIST Cybersecurity Framework

Safeguarding Privacy with Commercial LLMs

Cybersecurity in the Public Sector: Protecting Vital Services

Privacy Impact Assessment (PIA) Requirements under Law25

Elevate Your Experience with Version 3.5

Fine-Tuning LLMs with a Focus on Privacy

GDPR in Germany: Challenges of German Data Privacy (Part 2)

Comply with US Executive Order on Safe, Secure, and Trustworthy Artificial Intelligence using Private AI

How to Comply with EU AI Act using PrivateGPT