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.
