Crypto and Privacy Village - How to Integrate Privacy Legal Security
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Pahi, Suchismita
et al.
You've got a whole pack of privacy lawyers, cybersecurity team members, a CISO, a CTO, a CPO, a General Counsel, privacy engineers, security engineers, and more. Where do you put them? Who reports to who? There is a robust and lively debate going on among CISOs, CPOs, GCs, and others about structuring privacy and security teams efficiently and effectively within an organization. Sit in and listen to that debate here - and maybe take away some recommendations for your own teams. BIO Suchi is a data privacy and cybersecurity lawyer. She was supposed to be a doctor, but went rogue and wound up in law school arguing about the CFAA. After 4 years of working on some of the most incredible incidents as a cybersecurity lawyer and of helping companies of all sizes set up privacy and security practices, she decided to leave the law firm life so that she could do more tech law things. Robin Andruss - Director, Privacy Operations at Twilio has over 15 years experience in privacy, audit, and compliance. Currently, as a Director, Privacy Operations for Twilio, Robin leads a variety of internal strategic privacy initiatives to help Twilio meet it’s internal and external privacy commitments. Prior to Twilio, Robin's privacy career includes privacy roles from Google, Yahoo and TrustArc and developed a strong background in project and process management, financial audit and compliance (Sarbanes Oxley internal/process audits), and consulting from Deloitte. Marina is a well-established change agent in technology and cyber security with over 15 years of experience developing and delivering cyber security and IT strategy and programs. She has extensive experience aligning cyber strategy with business strategy while executing enterprise wide initiatives. Marina has expertise in risk management, data strategy and governance, security controls, information technology implementation and transformation, training, and project management. As Planned Parenthood Federation of America’s (PPFA) and Planned Parenthood Action Fund’s CISO, she works with senior leadership team to provide technical and cyber security expertise to mature the security posture of the Federation. Mike has over twenty years of experience in the security industry. He’s currently enjoying some well earned time off after a year and a half as Lyft’s first CISO where he had overall responsibility for their cybersecurity efforts. Prior to Lyft, he spent nine years at Salesforce in various roles, ultimately building and growing their world class Detection and Response organization. He started his career prototyping intrusion detection systems for battlefield networks. Fred is yet another privacy and cybersecurity lawyer, with a background in cybercrime defense. As GitHub’s Associate Corporate Counsel, he works closely with their security teams on bug bounty policy, incident response, and breach notifications. When not lawyering, Fred enjoys shell script kludges and improbable vehicles.
 Hello everyone. It is my pleasure to welcome onto the stage our next talk or group of panelists. They're going to be talking about structuring privacy and security organizations within a business. I think this topic is super interesting and I'm really excited to have all of these amazing experts here and so it's my pleasure to introduce them and with that I'm going to hand over the phone, not the phone, the mic to Kelly who's going to be moderating. Hi everyone. So Whitney was not kidding in that we have a great panel of experts here which makes my job so much easier because I just get to let them share their expertise with you. This panel is about how we structure internally. Privacy, security and our whole internal program. How do you deal with your CISO, your CPO? How do you pull in the exec board? How do you incorporate legal IT? When should you? When is it just cluttered? And I'm going to turn to our panelists real quick to introduce themselves because between all of them they have so much experience I will be talking way too long if I do this myself. So Fred, go ahead. Sure. Hi, my name is Fred Jennings. I am associate corporate counsel at GitHub and I work very closely with their security team on various things ranging from GDPR compliance to breach notification to, I don't know, a whole laundry list of things sort of in that intersection of security, privacy and law. So I will pass that on. Hi guys. I am Suchi. I am a data privacy and cybersecurity attorney. I have been practicing for a while and I have had a lot of fun working with companies and all of the weird things they do with privacy and security or don't do with privacy and security. So I am excited to hang out on this panel today and chat and share. Hi, my name is Marina Speeru. I just moved over to the non-for-profit sector in a healthcare company but came from the private sector from a big multinational as a CISO and have a lot of experience with risk, security and engaging with privacy and legal across a multinational organization. Hi, I'm Robin Andrus. I'm the director of privacy operations at Twilio, a fast growing tech company in San Francisco. I'm a privacy professional. I'm not an attorney though and I have 10 years of experience in privacy from Google, Yahoo and consulting. So what I do at Twilio is help kind of strategically run and scale the privacy program. So my name is Mike Johnson. Currently unemployed and enjoying it. Previously I was CISO of Lyft for a year and a half. Prior to that, you know, nine years at sales force and so on and so forth. At Lyft, that was the first time where I had not only responsibility for security but also for data privacy and we were growing that and scaling that, having to figure out how we build the team, how we operate it. It was really kind of this tremendous learning experience and I'm really glad to have, you know, all these other folks on the stage that I'm going to learn from and I hope we'll be able to help you all learn something along the way. So. Alright, so to kick off the panel, we thought the best structure would be for me to address a question to someone specifically and then have everyone jump in with your thoughts and response there. So to start off, Mike, you have had quite a range of experience. You have done engineering, you've done products management, you've done security. There's been a lot going on. One or two things. So in all of your experience and all the places you've worked, what have you seen that's been one of the most effective structures for ensuring privacy and security and if you want to throw in an example of bad structures, I won't stop you. So I will say, Kavya, I haven't seen something, you know, as perfect as it could be. What we had at Lyft was effective and the way that we had structured things was we had security teams with specific assignments and we had data privacy teams and it worked out that each team was a combination of engineering and ops. So every team had their own and I should back up. The concept of engineering was software engineering. So writing code, releasing it through kind of all of our standard pipelines, combined with analysts and operators who are able to consult with the rest of the business, give guidance, take feedback, move from there. So what I really took away from that was that combination of engineering, of being able to build where tools don't exist, but also being able to consult with the business to find out what their needs to make sure that both, they weren't going and doing something crazy, but at the same time, we weren't doing something crazy that was going to impact the business. That combination, I would say, was really what was effective of being able to build, but also being able to talk with the business. So one of the things I pick up from that response is that ideally you need a structure that both kind of checks the requirements and is flexible enough to respond to the needs of the individual business. Does that sound accurate? I think that's reasonable. You could also break it down into strategic versus tactical of being able to look ahead at what the business needs not only now but tomorrow, which has that tactical of, oh my god, something has changed. We need to deal with it now, but also trying to get ahead of it so that you're not surprised. And sometimes it takes a while to solve some of these problems. So getting ahead helps the business move faster. Has anyone else on the panel seen structures that they thought were especially effective or especially ineffective in your experience? So something similar to Mike where we always partnered, so privacy and security were partners, and we always identified where were the integration points. So where is, from a data privacy perspective, aligned with data security? And how do we, from the end user, the business, software development, whoever else were engaging within the organization, how do we engage with them cohesively so we're not asking the same questions, so we're not over burdening on them when the end game for both security and privacy is to ensure we're protecting the data and the regulations and the, you know, accordingly. So it's, for me, it's really about that alignment and the integration points and making it as easy as possible on the business so that then they engage with security, they engage with privacy. I actually have one that's an example of the most ineffective structures. And so I primarily worked on incident response. And so what you might expect then is that there's probably a problem other than with the data. And there was a company who shall remain unnamed and involved about 1.2 million folks data that was exposed. And the problem was every department thought the buck stopped at their desk. And so they didn't really understand that, you know, you needed to talk to your peers at a particular level, like the idea of a dashed line across and things like that. So there was no coordination between teams. And it was as if, in that particular instance, IT was doing the security and security was doing the compliance and privacy didn't exist. And so it was, it was definitely one that I don't recommend that structure. But if that happens, I know plenty of reach response attorneys that can probably help you. All right, for the next question, Marina, you mentioned that you've seen some some interesting structures that way. I know that in your background, you've consulted with multiple tech clients. And you also have some experience in risk. In your experience, do you think that risk is best as its own separate thing? Is it best when it's integrated fully or partly into security? And what structure have you seen best that addresses risk issues most effectively? So I think risk first, you have to take a step back. And it's not just about structure. It's about the culture of the organization. One, do they even understand what risk is? Do they understand how it plays a role in decision making? I don't think you can do security or privacy or compliance or anything without your part of risk. So how does it all come together? I've seen structured where you have an enterprise risk management and then infosex cyber rolls up, you have IT risk, you have privacy. But at the end of the day, what do you do with that? So it's really about risk being part of the DNA of the organization, I think is the most effective. So while I'm a CISO, and I may represent and be the subject matter expert around cyber and security risk, I also need to ensure I understand how this would impact financial risk or operational risk or reputational risk, because my job is to help the business make the most risk informed decision. So it's not always just about the structure for me, it's about the culture and the education within leadership of how does information security risk and privacy risk play a role in their decision making? And it's just as important and in my opinion, if not sometimes more important than just the financial risk or the operational risk that they're accustomed to looking at. So how do you have those conversations? I think it's we all play a role in risk. I do think having an enterprise risk program where cyber sits at the table, privacy sits at the table, and we speak the same language is the most effective way. Having consistency in language, consistency on what risk acceptance, what risk threshold, footprint, all those terms are known. So regardless of who they're speaking to, they understand why we're at the table, why that is an important variable to their decisions. So I kind of take a non-structural but really about the cultural of how we engage with leadership and how information security risk, privacy, etc., is just as important as financial and operational and risk. But sometimes in FOSEC, I do believe in privacy, drive that conversation. So making sure that infoSec and privacy are first aligned, making sure again that the wording, it's really important to educate people that my definition of risk is the same definition that you use, and then taking it up the ladder and educating, even all the way to the board where I've had to educate. Here's what risk management is. Here's how we should all be thinking about it. So there's consistency. So when a risk is escalated to that level, they know what to do with it. So playing off that a little bit, when you're looking at risk within a company and when you're trying to create a culture where everyone's aware of common risks and is addressing the problem proactively, how do you pull people in at all levels of the company? How do you make sure that the board executives are understanding risk levels and risk in different areas? How do you make sure that employees are aware of those risks down at even entry level? What have you seen that best works as an approach to kind of create that culture? It's around awareness and training. So with associates, it's just when they say, hey, security, come approve this. It's like, no, it's not necessarily about an approval that you're looking for. It's let me have a conversation with you, understand what you're trying to accomplish within your scope of responsibility and what your business area is doing so that you can now understand what risk you're adding. I can provide you subject matter expertise and how to mitigate that risk. And then we talk through, is that acceptable? Are you the right person who can actually make that decision? And then with executives, we do tabletops, just like I would do an incident response tabletop. When we do that, we talk about the risk and how do we, how is risk incorporated into the board and their nomenclature? So education, I think, varies depending on your audience. But it's really about when someone comes to me, I'm not about approving or denying 99% of the time. I'm about, hey, let's talk about what this risk is. Let me talk about what the business is trying to do because I'm here to enable the business. And since you brought me in late, it's going to feel like I'm saying no, but I'm really saying slow down so I can catch up. And if you bring me in sooner, I can actually be much more of that enabler where we can mitigate the risk together from the very beginning. So education can be anything from your annual training. It could be to tabletops. It could be to cybersecurity awareness month and leveraging the risk within those conversations. But a lot of it is in day-to-day interactions. Having the team talk about it from a risk perspective versus an approval or denial, I think is a huge first step. Fred, I saw you nodding to that. Anything you want to add? Any experiences you've got there? I just want to extremely enthusiastically agree with the notion of looping people in sooner rather than later from a legal perspective as well. I have yet to see a situation where that doesn't make the conversation easier, less painful, and usually leading to a more pleasant solution for literally everyone involved. That was all. Yeah, I'm purely from the legal side. I'm just a privacy lawyer. So coming in as early as possible always makes my conversations with engineers so much better. And it makes me so much less likely to come in and just be evil and shut down the projects they've been working on. I think one more that was successful for me is I used to be responsible for regional presidents and market presidents. And they would always say, why are you at my leadership meetings? And once I started producing, looking at the types of slides, their finance business partner, their HR business partner, their operations business partner was providing, and putting infosecond risk within those types of language and also the visual. Why am I creating a different visual if they're used to absorbing information and talking about, hey, did you see what that, you know, your finance person said? Here's how infosec plays a role in those numbers or not. Here's how information security risk actually impacts your bottom line or not. So putting it into that business language and also learning my audience and understanding how to present information, then they started thinking about, oh, so this is the risk. And here's how I already talk about risk. And here's infosec and privacy at the table. So it takes time. I didn't mean to cut you off. I'm just eager. I didn't want to lose the point. So what I like that you're talking about there, Marina, was risk as a concept. And, you know, there are this, there's going to be responsibility for risk and decision making and that sort of thing. But I'm not a lawyer, but I'm married to one. And we have a lot of conversations about the legal side of the world and then everything else, I guess. And what really she talks about is that law is also all about managing risk. And that's this great common language that we can all speak on the security side, on the privacy side, on the legal side and help carry that message forward to the rest of the business in a common language without necessarily giving competing messages. So playing off a point Marina made earlier about financial risk and how you build that in and how you can kind of use that to make people pay attention to what you're trying to build. Robin, you've got a background in audit and compliance and privacy. Now you're a director of privacy operations. And in the course of that work, you have to structure privacy programs in order to make sure that there's a limit to the financial risk your particular businesses may incur. What have you seen as some of the more effective strategies to avoid financial risk and to make an impact on people that what you're doing is actually impactful in that way? So I don't know if people have been following the recent Facebook agreement with the FTC. So as a former auditor from Deloitte, you know, the financial statement, you do your financial statement audit, Sarbanes-Oxley audits, which Sarbanes-Oxley was the huge law that was passed in 2002 after the Enron crisis. And so I kind of liken like this recent Facebook, five billion dollar fine and the structures of the corporate privacy governance need to put in a place like of the 2002 SOX era, but for privacy. So essentially, like basically they have to have a separate privacy committee that's on the board. They have to have independent compliance directors that have to report to the board. And there is penalty for false compliance, for false like saying that Facebook is compliant, but they're not. So there's this concept of independence, you know, because that the they can't just go through Mark Zuckerberg or some other CEO and kind of say, no, we're gonna, they have to be independent in some way. So I'm just, I'm starting to see privacy become much more of a bigger at the board level discussion where the board is really included. And even Facebook said they're going to build and structure their privacy programs similar to a Sarbanes-Oxley internal control program. So you'll have controls and control ownerships and doing testing. So that's where I think in the end of the day, like it'll be interesting to see what this Facebook agreement does, how other companies start to maybe voluntarily change it. Are they going to build more formalized structures to then limit the financial risks and have controls and test controls and build privacy and security programs around these controls? Now, then also you kind of flip around if you're a publicly traded company, in your SEC reports, you have to disclose kind of, you know, risks to the business. So like security risk, privacy risk. And then Facebook actually was also fined 100 million from the SEC for basically saying like they didn't see foresee risks and then they did have risk. So that's how it kind of all loops in together with the financial risk to the business. So it will be interesting to see how companies take this and build out their programs. I mean, if anything, it gives us more of a reason to go to the board and your executives and say, you know, we need funding to build a privacy program. We need to make it better. Let's, you know, look at the NIST privacy risk model and really build out a great strong privacy program, which is one of the things we're trying to do at my company. So now that we're on a little bit of a Facebook kick, I love getting to do this. So it was also in the news recently that a night circuit decision just went through saying that the state of Illinois can go after or a case against Facebook can proceed in the state of Illinois because of violations of facial recognition laws there. For me, this ties in, I'm a privacy lawyer, so I pay a lot of attention to facial recognition tech. For me, this goes through in the way that this is a long-term integrated piece of how Facebook operates. You know, facial recognition is hugely interactive in all of their photos and tagging people and figuring out your contacts and that sort of thing and in sharing information with ad companies and marketing tech. When your company has something that they've developed that they've spent a lot of time and effort on that is really involved in their product and it ends up having a problem like this or it ends up being a major risk factor for them, what kind of advice would you give hypothetically? Obviously, none of your companies would do this. But hypothetically, if you were working for a company like this, how do you approach a problem that is so integrated into the main product and into the company culture when it's running into major legal risks this way? Sure. I mean, the company I work for now is we're a B2B company, so for us, we want to do the right thing with your data and from privacy and security, not saying that other companies don't, but a company based on advertising revenue, because I used to work for Google and Yahoo and their privacy group, it's a little more challenging because they want that data for revenue, to drive revenue, to build better advertising profiles, et cetera. I mean, this seems a little too idealistic, but they kind of push the boundaries for years. There's been issues around facial recognition since the EU brought this up and the Irish DPC did an investigation of Facebook years ago. They've said, I think they should do the right thing and they're going to have to rearchitect their systems and it's going to cost some time and money, but they've made probably billions of dollars on the fact that they've had this tool, so that they can use the billions of dollars in engineering resources to do it right for users. I have small children and I actually don't put them on Facebook because I freaked out about people scanning their face and won't even let them put them on the website for their preschool they're going to. I was like, no, I don't want my kids. So, yeah. So to the question, like setting aside Facebook for a moment, I think transparency can really help out a lot. So what your company doing might inherently impact the privacy of your users. That there might be a service that you're providing, maybe location services, that does impact the privacy of the users. And if you're transparent with what you're doing with that data, why you're collecting it, what you're doing with it, how you're protecting it internally, and that helps with the public perception. But then there's the, okay, well, this is what we're saying that we're doing. The responsibility then comes, well, how do we know that we're doing that? How can we prove that we're doing it? And frankly, are we actually doing it? And do we have the resources to do it effectively? So it can certainly be done, but I really think that if you're opaque about what you're doing, you're not living up to your promises and to your responsibilities, that's when you should get in trouble by somebody. Someone else? Brad? So I think the Facebook decision recently is a wonderful example of one of the very sort of unique legal compliance challenges where it's a state law. It's something that a lot of companies the size of Facebook and Google, probably like, they're probably thinking about it, but it's not GDPR, it's not a federal level law. It's easy for these state level rules to slip through cracks if you're inside and talking compliance with your legal department. I would echo, I think transparency is key, absolutely. I think one thing that has been helpful in my experience internally is we have very open lines of communication with the teams that are sort of building features and building products and making these services. And there's a well-established culture of, if you're building something, come talk to legal and here's our template to make sure that we're reviewing it. And does that always include state level regulations? Hopefully, maybe, but at least for the well-known established risks. I think having that culture of communication with legal is absolutely key. So I think the transparency thing is great, but as a user, I think you're full of shit. When I see what you're doing and you tell me what you're not doing with your data, a lot of times it's written in some very ambiguous terms and as an attorney who does privacy and cybersecurity, I'm all about ambiguity. I want to let the company do what it needs to do with the data to help provide a service and maybe look at better options for the products they're providing later. So I think transparency is great, but I don't think it's very effective when you're thinking about something like a runaway company where maybe the C-suite or the board isn't really paying attention or the engineers are just really focused on, hey, I want this new product out. Like, you know, a product that's listening to ambient noise and serving up ads to you. Is that really something we need to do? It would maybe drive some revenue, but it's really fucking creepy. And so I think we have to be careful with if you're like creep factor, sensors go off, then it's an obligation to point out whether you're CISO or outside council or in-house council to say, you know what, this could work out legally or maybe here are all the problems legally and here's the risk to your business, both legal and security and bottom line, but also think about the creep factor. And I think that's a big one that should be emphasized from top down, bottom up all around all the time. So the second that becoming resident like creep factor sensor becomes a real job I'm in. I've got the high sensitivity level. I'll go full tin foil hat. I'm all about that. So as soon as you guys hear about that, let me know. Fred, you've also had kind of a range of experience worked with a lot of different areas, different departments. In your experience, where do lawyers come into the process when dealing with security and privacy reporting and what do you think is the best time for them? So kind of to summarize, when have you seen lawyers come into that process and when do you think they should if it's not necessarily what you've seen? So right, I would certainly say usually they come into the process too late. I think the worst examples I've seen was when I was in private practice, we'd often be called in to consult and it was more often than not a relatively early stage, often like security focused startup and probably the worst example of which I will not name company, not still undone, honestly, but my favorite was a sort of PayPal ask finance financial company that had found a really great way to do frictionless transactions in deep and complete unawareness of anti money laundering laws. So we got to be the people to tell them so you've got a neat business idea but it's completely illegal and here's why. It's because you can't do this legally. Need idea though. So I feel like one of the reasons why I'm such an advocate for like talk to legal sooner rather than later is to avoid things like that. You know, this was a great a sort of textbook example of someone who had built something without talking to sort of legal compliance, privacy, people and spent, you know, countless hours and countless dollars on making the system only to find out oh, all we built is a liability machine, which is never fun news to deliver either. You know, I think it's a little different when you are inside of a company. It's easier to have an eye on what's happening more proactively. You know, I think one of the difficulties being outside council was people only come to you when they know something's wrong or when there's no something might be wrong, which 50-50 odd something already is. I think internally the structure that I've seen work best is open lines of communication and oh, open lines of communication and the other thing that I have found to be very effective is good documentation across teams. So for example, our security team, we work with them to basically draft a handbook for what to do when there is a security breach. And because we work closely with them, that includes kind of summary level versions of what's personal data under GDPR or under other privacy statutes. So while we do not necessarily have a lawyer embedded in the security team, we've given them information to be aware of okay, if we see these things when we're going through the logs, they know to talk to us, we get looped in and it's a fairly seamless way to make sure that the people who are most likely to see things that legal would want to know about know to tell us about it. So I think that sort of early awareness has been the biggest structural thing that I've found useful outside of any sort of, you know, I wouldn't say that we have any sort of strict like legal security hierarchy, but it's that open line of communication. As a lawyer, it's very disheartening to hear that we're not in a hierarchical structure where we're on top, but we'll take that. Mike, you've got some thoughts here and I'd love to hear from the other lawyers and non-lawyers about what you've seen work best or work badly. So I was actually asking a question, I wanted to ask a question of the lawyers on the panel, which was one of the challenges that I faced was that, you know, we always think about a lot in ratios, like there's one security person for every 100 developers or something like that and it seemed like we had one lawyer for the entire company. And I totally agree with you on it's more effective to get the lawyers involved early, but how do you scale that? And you started touching on it a little bit with some of the documentation, but and this wasn't one of the questions that we went over. So how, what are some of the effective ways that you've seen to scale the legal side, especially in a fast moving engineering company? I love this question. So I really enjoyed some of the companies I'd worked with that were product tech focus that moved pretty quickly, engaged, they had security engineers, and those security engineers were also cross trained in kind of high level privacy and like sectioned off by team. And so that meant like the person on the ground who was doing the product building at certain stages of development had someone to go to while they were going through the process and and say, Hey, do you think this is a problem? Like, are we pulling a bunch of PII? Do we need to tell our lawyers about this random vendor that we Googled and said they're pretty awesome? Oops, I signed a contract. Like those are the kind of things that the security engineer was able to also flag for the team. And I thought that was, I saw two companies do that in six years. And it looked like it was a newer trend. And I don't know if you guys have seen more of that, but I thought it was cool. So sure. So yeah, we actually have a security engineering group and they're called their security partners. And they work with a security champion who's kind of a security, it's an engineer embedded within their kind of product org. And they try to meet the champion tries to meet on a monthly basis with to have an open line of continuous continuous conversation with their security partner. But I've worked with the security partners to kind of like bring me in on certain things like that. And it's helped a little bit. They're definitely starting to kind of identify things and bring us in more. But another structure that's very effective that you see a lot of tech companies doing is having like a product council structure, where you kind of know like you work in this org, you know that Bob or Stacy is like your kind of go to attorney for anything legal, whether it's contracts or partnerships or, you know, privacy copyright terms. And then that kind of person is a generalist and they are able to bring in the right experts on the team in legal. So that that structure I think is good for the product org to if it's a company that has resources to scale a legal team like that. Yeah, I would agree that that's one of the models I've seen work pretty well. I feel like you're sort of, you know, to answer your question about like how do you scale this? It's kind of that like difficult triangle of thorough scalable and cheap. And you kind of get to pick two. If you want all three, sorry, I've got some bad news. I think the easiest least cheap option is hire more lawyers. That is not always accessible to a company, especially because like your legal department is not your moneymaker in most systems. You know, you are, we are a cost item. But we are a, you know, ideally one that prevents other bigger cost items like federal fines. I've also seen it work for companies that have some resources but not enough to grow a huge legal team to like go sort of the product council role and have a kind of deep list of outside counsel who can be deferred to for subject matter expertise. And so your, you know, one or two product counsel become kind of, you know, generalists who have a knowledge of exactly who to talk to when for what. And then I think the third way I've seen this work that is the cheapest, but sort of the heaviest lift on your counsel is right, like build documentation, get extremely good at triage for the live time that you're like understaffed counsel team has. So I'd say those are the three models I've seen work most reliably. And it's just a question of like, where do you have the resources and how much resources is, you know, for the area that your company is in, how much resources can you sort of afford to allocate to solving this problem? So just to layer on to what you said, I think it's also where training within each organization. So what are the triggers? So if I'm in DevOps and I all of a sudden see change in data set, change in data points, and I understand data to some degree, what's a trigger or threshold that would then go to like a security or privacy champion versus going directly to counsel and then really getting like the right person at the right time, but also the value proposition. Does every change in data, every change in code, every change in product direction require counsel or are there other people who can triage it and keep it on track and then a certain, again, back to risk. When the risk reaches a certain threshold, then yes, we need to reach out to the security team or to legal counsel or to both. And also making sure I think the connections between orgs. So if someone's purchasing something, did sourcing or finance catch it so that it can then be turned back around to the counsel and to the security and privacy. So having those integration points in other business processes that trigger the right group, either before action has been taken or even retroactively because sometimes you have to go back and fix. Sushi, I know that you've worked with some corporate clients. I was wondering, have you seen any challenges when it comes to reporting structures that either you feel are specific with corporate clients or are exacerbated with corporate clients? Are there any experiences there that you think would serve as good kind of cautionary tales for structural creation here? Yeah, I don't know about cautionary tales. It's more the more communication that I've seen among people at particular levels, the better it is. So if we were all working together at the same company, the best relationship would be one where I could pick up a phone and or text and be like, hey, I need to talk about this. Do you have 15 minutes? And then it should be that easy. There's a lot of politicking that I've seen at different companies that I've worked with that can really throw a wrench into that type of a relationship. And that's a part of living in society and it's part of life. But hopefully with some empathy and context, you can work with your peers and get to a point where you have open communication about, I'm really worried about this idea that we have going forward or, hey, outside counsel told me this crazy thing. Can we talk about it so we can strategize and approach, like manage up, go talk to whomever is above us and needs to make a decision. And another thing I'd really emphasize is that a lot of organizations think of escalation as a problem, like, oh man, someone escalated to the person above me. But you know what, that's why an escalation exists. So if I disagreed with Marina on something, then we could respectfully lay out why we think the way we think and where the risks should be ranked and whether we want to build something in or not. And then I could say, hey, you know what, I'm going to go ahead and escalate this. I just wanted you to know. And then we would have that conversation at a different level. And that's entirely appropriate. So I think corporations should be less averse to escalating and more interested in communicating with one another to move together towards whatever the goal is. So I would agree with that. And I think it goes back to, again, you're speaking the same language, so you're talking risk. But I also think it also helps you when it comes to resourcing. So if we continue to go back and forth and work on the same problem, but we're at a stalemate and we don't know how to escalate or we're too scared to escalate, then we're wasting our time and potentially our team's time working the same problem versus, hey, we have differing opinions, we're bringing different expertise to the table. We really need to raise this to the next level to make the business decision. Who is able to actually accept this risk or say, or we need to mitigate the risk to whatever new acceptable level is, then it actually allows you to be more efficient and your resources can be spent more wisely. So I agree. So the one cautionary tale that I would have, I absolutely agree with the concept of escalations and really is kind of core quality community. And I think it's kind of core quality communications. But you have to be careful that the people who are being escalated to know that it's coming. I've seen cases where escalations have been weaponized. It's you either agree with me or I'm going to go escalate this. And it becomes then a very adversarial relationship, even though I agree with you, spending on something that you're not getting anywhere is a waste of resources. So the best way that I've seen to prepare that is to make sure that like the entire leadership understands that escalations is a thing and they have to encourage it, not just at whatever level you're having the disagreement. I just realized I didn't ask part and answer part of your question, which is the reporting structure. So one of the weird ones I saw was compliance was solely under security and privacy reported up to security. And so that was all through the CISO and then there was general counsel and legal over there. And I thought it was really odd and I don't know what you guys think about this, but I thought it was odd to have privacy and security reporting to the same person where I would have preferred to have security reporting up to CISO and privacy reporting up to a director of privacy or something like that. So you have a dashed line across between CISO and director of privacy because I think there's actually, although privacy and security are in tandem, I think there are some different ways of assessing the risk and that I don't think one person should carry the responsibility of making a determination that involves both security and privacy. So I feel attacked because that was exactly the structure that we had. And so you weren't talking about us, so that's fine. But it really comes down to it's going to be one of those it depends questions. And what I would say, any of the discussions that we have about structures and reporting, they can all work if you have the right people. For us, it was that alignment of security with privacy came in very handy. Partially to the earlier discussion about scaling privacy with security champions and those kind of mechanisms, we could have the security team talk to the privacy team and say, hey, there's something going on here. And they were so tightly intertwined that that was more efficient. And I thought that was rather effective. I will, however, say we did have privacy council so within the legal org. And that meant that we did have still that oversight. I would agree with you that if it was just one straight silo, there is that risk of making these decisions that are too, they have impact and you don't have that oversight. But you can, I believe that you can be effective with security and privacy as part of the same organization as long as you have that external oversight, as long as you have somebody else who's kind of keeping an eye on that team and making sure that team is not doing something way off on the edge of the reservation. I can comment on that. Actually, so a privacy professional, I've been in several different functions that have kind of rolled up. Like at one point I was in privacy org that rolled up under IT, rolled up under an ads function of a company and then since then it mostly legal. And the one, and actually it's interesting if you look at Google's consent decree, they were told to build like a separate privacy program that's separate from their security program. So the challenge is there is that privacy might not be, might just be this little thing that security does, but it's not really as important. And I think that's, I think it's just privacy growing up and figuring out where they fit and that they have a voice at the table where a lot of people who've been in privacy for a long time really kind of just fell into it. Like everyone I know who kind of fell into it 10 or so years ago, it was that boring, risking compliance thing someone did in the back office. It's just privacy, but now obviously it's very sexy and everyone wants to do it. But so we'll see how privacy grows up. I mean, I kind of really like being part of a legal department even though I'm not an attorney, as a privacy professional because I feel like at the end of the day we are still mitigating risk and supporting the business, but in independent fashion. At one point actually our CISO and our head of privacy, CPO reported both up to the general council, but recently they just changed that structure where our CISO is reporting to our CFO. And that's actually a newer structure because I was talking to our head of corporate comms who's been doing security corporate comms for years, PR, and he said, you're starting to see actually a lot of companies putting the security function under the CFO, the chief finance officer, because it's around mitigating risk. Maybe they get more budget that way. Who knows? So one of the things that I've actually been pondering just this week is the idea that security might eventually report to privacy. If we look at the regulations that we're seeing in the world today, they're all privacy regulations. We've got breach notification requirements, but that's just a fraction of what security does. All the privacy regulations are very in depth with heavy fines associated with them, and it's the privacy regulations that people are pushing for. So it wouldn't surprise me if we start seeing this other way around. I wouldn't be shocked one day if we see CISO's reporting to chief privacy officers. I think that that is a future that might come and that might be perfectly fine.
 Hello everyone. It is my pleasure to welcome onto the stage our next talk or group of panelists.  They're going to be talking about structuring privacy and security organizations within a business.  I think this topic is super interesting and I'm really excited to have all of these amazing  experts here and so it's my pleasure to introduce them and with that I'm going to hand over the  phone, not the phone, the mic to Kelly who's going to be moderating.  Hi everyone. So Whitney was not kidding in that we have a great panel of experts here which  makes my job so much easier because I just get to let them share their expertise with  you. This panel is about how we structure internally. Privacy, security and our whole internal  program. How do you deal with your CISO, your CPO? How do you pull in the exec board? How do  you incorporate legal IT? When should you? When is it just cluttered? And I'm going to turn to  our panelists real quick to introduce themselves because between all of them they have so much  experience I will be talking way too long if I do this myself. So Fred, go ahead.  Sure. Hi, my name is Fred Jennings. I am associate corporate counsel at GitHub and I work very  closely with their security team on various things ranging from GDPR compliance to breach  notification to, I don't know, a whole laundry list of things sort of in that intersection of  security, privacy and law. So I will pass that on. Hi guys. I am Suchi. I am a data privacy and  cybersecurity attorney. I have been practicing for a while and I have had a lot of fun working  with companies and all of the weird things they do with privacy and security or don't do with  privacy and security. So I am excited to hang out on this panel today and chat and share. Hi, my  name is Marina Speeru. I just moved over to the non-for-profit sector in a healthcare company but  came from the private sector from a big multinational as a CISO and have a lot of experience with  risk, security and engaging with privacy and legal across a multinational organization. Hi, I'm  Robin Andrus. I'm the director of privacy operations at Twilio, a fast growing tech company in  San Francisco. I'm a privacy professional. I'm not an attorney though and I have 10 years of  experience in privacy from Google, Yahoo and consulting. So what I do at Twilio is help kind of  strategically run and scale the privacy program. So my name is Mike Johnson. Currently  unemployed and enjoying it. Previously I was CISO of Lyft for a year and a half. Prior to that,  you know, nine years at sales force and so on and so forth. At Lyft, that was the first time  where I had not only responsibility for security but also for data privacy and we were growing that  and scaling that, having to figure out how we build the team, how we operate it. It was really  kind of this tremendous learning experience and I'm really glad to have, you know, all these other  folks on the stage that I'm going to learn from and I hope we'll be able to help you all learn  something along the way. So. Alright, so to kick off the panel, we thought the best  structure would be for me to address a question to someone specifically and then have everyone jump  in with your thoughts and response there. So to start off, Mike, you have had quite a range of  experience. You have done engineering, you've done products management, you've done security.  There's been a lot going on. One or two things. So in all of your experience and all the places  you've worked, what have you seen that's been one of the most effective structures for ensuring  privacy and security and if you want to throw in an example of bad structures, I won't stop you.  So I will say, Kavya, I haven't seen something, you know, as perfect as it could be. What we had at  Lyft was effective and the way that we had structured things was we had security teams with  specific assignments and we had data privacy teams and it worked out that each team was a  combination of engineering and ops. So every team had their own and I should back up. The  concept of engineering was software engineering. So writing code, releasing it through kind of all  of our standard pipelines, combined with analysts and operators who are able to consult with the  rest of the business, give guidance, take feedback, move from there. So what I really took away from  that was that combination of engineering, of being able to build where tools don't exist, but also  being able to consult with the business to find out what their needs to make sure that both, they  weren't going and doing something crazy, but at the same time, we weren't doing something crazy that  was going to impact the business. That combination, I would say, was really what was effective of  being able to build, but also being able to talk with the business. So one of the things I pick up  from that response is that ideally you need a structure that both kind of checks the requirements  and is flexible enough to respond to the needs of the individual business. Does that sound accurate?  I think that's reasonable. You could also break it down into strategic versus tactical of being able  to look ahead at what the business needs not only now but tomorrow, which has that tactical of, oh my  god, something has changed. We need to deal with it now, but also trying to get ahead of it so that  you're not surprised. And sometimes it takes a while to solve some of these problems. So getting  ahead helps the business move faster. Has anyone else on the panel seen structures that they thought  were especially effective or especially ineffective in your experience? So something similar to Mike  where we always partnered, so privacy and security were partners, and we always identified where  were the integration points. So where is, from a data privacy perspective, aligned with data  security? And how do we, from the end user, the business, software development, whoever else were  engaging within the organization, how do we engage with them cohesively so we're not asking the  same questions, so we're not over burdening on them when the end game for both security and privacy  is to ensure we're protecting the data and the regulations and the, you know, accordingly. So  it's, for me, it's really about that alignment and the integration points and making it as easy  as possible on the business so that then they engage with security, they engage with privacy.  I actually have one that's an example of the most ineffective structures. And so  I primarily worked on incident response. And so what you might expect then is that there's  probably a problem other than with the data. And there was a company who shall remain unnamed  and involved about 1.2 million folks data that was exposed. And the problem was  every department thought the buck stopped at their desk. And so they didn't really understand that,  you know, you needed to talk to your peers at a particular level, like the idea of a  dashed line across and things like that. So there was no coordination between teams.  And it was as if, in that particular instance, IT was doing the security and security was doing  the compliance and privacy didn't exist. And so it was, it was definitely one that I don't recommend  that structure. But if that happens, I know plenty of reach response attorneys that can  probably help you. All right, for the next question, Marina, you mentioned that you've seen some  some interesting structures that way. I know that in your background, you've consulted with  multiple tech clients. And you also have some experience in risk. In your experience, do you  think that risk is best as its own separate thing? Is it best when it's integrated fully or partly  into security? And what structure have you seen best that addresses risk issues most effectively?  So I think risk first, you have to take a step back. And it's not just about structure. It's  about the culture of the organization. One, do they even understand what risk is? Do they understand  how it plays a role in decision making? I don't think you can do security or privacy or compliance  or anything without your part of risk. So how does it all come together? I've seen structured where  you have an enterprise risk management and then infosex cyber rolls up, you have IT risk, you  have privacy. But at the end of the day, what do you do with that? So it's really about risk being  part of the DNA of the organization, I think is the most effective. So while I'm a CISO, and I may  represent and be the subject matter expert around cyber and security risk, I also need to ensure I  understand how this would impact financial risk or operational risk or reputational risk, because  my job is to help the business make the most risk informed decision. So it's not always just about  the structure for me, it's about the culture and the education within leadership of how does information  security risk and privacy risk play a role in their decision making? And it's just as important  and in my opinion, if not sometimes more important than just the financial risk or the operational  risk that they're accustomed to looking at. So how do you have those conversations? I think it's  we all play a role in risk. I do think having an enterprise risk program where cyber sits at the  table, privacy sits at the table, and we speak the same language is the most effective way. Having  consistency in language, consistency on what risk acceptance, what risk threshold, footprint,  all those terms are known. So regardless of who they're speaking to, they understand why we're  at the table, why that is an important variable to their decisions. So I kind of take a non-structural  but really about the cultural of how we engage with leadership and how information security risk,  privacy, etc., is just as important as financial and operational and risk. But sometimes in FOSEC,  I do believe in privacy, drive that conversation. So making sure that infoSec and privacy are first  aligned, making sure again that the wording, it's really important to educate people that my definition  of risk is the same definition that you use, and then taking it up the ladder and educating,  even all the way to the board where I've had to educate. Here's what risk management is. Here's  how we should all be thinking about it. So there's consistency. So when a risk is escalated to that  level, they know what to do with it. So playing off that a little bit, when you're looking at risk  within a company and when you're trying to create a culture where everyone's aware of common risks  and is addressing the problem proactively, how do you pull people in at all levels of the company?  How do you make sure that the board executives are understanding risk levels and risk in different  areas? How do you make sure that employees are aware of those risks down at even entry level?  What have you seen that best works as an approach to kind of create that culture?  It's around awareness and training. So with associates, it's just when they say, hey,  security, come approve this. It's like, no, it's not necessarily about an approval that you're  looking for. It's let me have a conversation with you, understand what you're trying to accomplish  within your scope of responsibility and what your business area is doing so that you can now  understand what risk you're adding. I can provide you subject matter expertise and how to mitigate  that risk. And then we talk through, is that acceptable? Are you the right person who can  actually make that decision? And then with executives, we do tabletops, just like I would do  an incident response tabletop. When we do that, we talk about the risk and how do we,  how is risk incorporated into the board and their nomenclature? So education, I think,  varies depending on your audience. But it's really about when someone comes to me,  I'm not about approving or denying 99% of the time. I'm about, hey, let's talk about what this  risk is. Let me talk about what the business is trying to do because I'm here to enable the  business. And since you brought me in late, it's going to feel like I'm saying no, but I'm really  saying slow down so I can catch up. And if you bring me in sooner, I can actually be much more  of that enabler where we can mitigate the risk together from the very beginning. So education  can be anything from your annual training. It could be to tabletops. It could be to cybersecurity  awareness month and leveraging the risk within those conversations. But a lot of it is in day-to-day  interactions. Having the team talk about it from a risk perspective versus an approval or denial,  I think is a huge first step. Fred, I saw you nodding to that. Anything you want to add? Any  experiences you've got there? I just want to extremely enthusiastically agree with the notion  of looping people in sooner rather than later from a legal perspective as well. I have yet to see a  situation where that doesn't make the conversation easier, less painful, and usually leading to a  more pleasant solution for literally everyone involved. That was all. Yeah, I'm purely from the  legal side. I'm just a privacy lawyer. So coming in as early as possible always makes my conversations  with engineers so much better. And it makes me so much less likely to come in and just be evil and  shut down the projects they've been working on. I think one more that was successful for me is I  used to be responsible for regional presidents and market presidents. And they would always say,  why are you at my leadership meetings? And once I started producing, looking at the types of slides,  their finance business partner, their HR business partner, their operations business partner was  providing, and putting infosecond risk within those types of language and also the visual.  Why am I creating a different visual if they're used to absorbing information and talking about,  hey, did you see what that, you know, your finance person said? Here's how infosec plays a role in  those numbers or not. Here's how information security risk actually impacts your bottom line or  not. So putting it into that business language and also learning my audience and understanding  how to present information, then they started thinking about, oh, so this is the risk. And here's  how I already talk about risk. And here's infosec and privacy at the table. So it takes time.  I didn't mean to cut you off. I'm just eager. I didn't want to lose the point. So what I like  that you're talking about there, Marina, was risk as a concept. And, you know, there are this,  there's going to be responsibility for risk and decision making and that sort of thing. But  I'm not a lawyer, but I'm married to one. And we have a lot of conversations about the legal side  of the world and then everything else, I guess. And what really she talks about is that law is  also all about managing risk. And that's this great common language that we can all speak on the  security side, on the privacy side, on the legal side and help carry that message forward to the  rest of the business in a common language without necessarily giving competing messages.  So playing off a point Marina made earlier about financial risk and how you build that in and how  you can kind of use that to make people pay attention to what you're trying to build. Robin,  you've got a background in audit and compliance and privacy. Now you're a director of privacy  operations. And in the course of that work, you have to structure privacy programs in order  to make sure that there's a limit to the financial risk your particular businesses  may incur. What have you seen as some of the more effective strategies to avoid financial risk  and to make an impact on people that what you're doing is actually impactful in that way?  So I don't know if people have been following the recent Facebook agreement with the FTC.  So as a former auditor from Deloitte, you know, the financial statement, you do your financial  statement audit, Sarbanes-Oxley audits, which Sarbanes-Oxley was the huge law that was passed  in 2002 after the Enron crisis. And so I kind of liken like this recent Facebook,  five billion dollar fine and the structures of the corporate privacy governance need to put in a  place like of the 2002 SOX era, but for privacy. So essentially, like basically they have to have  a separate privacy committee that's on the board. They have to have independent compliance directors  that have to report to the board. And there is penalty for false compliance, for false like  saying that Facebook is compliant, but they're not. So there's this concept of independence,  you know, because that the they can't just go through Mark Zuckerberg or some other CEO and  kind of say, no, we're gonna, they have to be independent in some way. So I'm just, I'm starting  to see privacy become much more of a bigger at the board level discussion where the board is  really included. And even Facebook said they're going to build and structure their privacy programs  similar to a Sarbanes-Oxley internal control program. So you'll have controls and control  ownerships and doing testing. So that's where I think in the end of the day, like it'll be  interesting to see what this Facebook agreement does, how other companies start to maybe voluntarily  change it. Are they going to build more formalized structures to then limit the financial risks and  have controls and test controls and build privacy and security programs around these controls?  Now, then also you kind of flip around if you're a publicly traded company, in your SEC reports,  you have to disclose kind of, you know, risks to the business. So like security risk, privacy risk.  And then Facebook actually was also fined 100 million from the SEC for basically saying like  they didn't see foresee risks and then they did have risk. So that's how it kind of all loops in  together with the financial risk to the business. So it will be interesting to see how companies  take this and build out their programs. I mean, if anything, it gives us more of a reason to go to  the board and your executives and say, you know, we need funding to build a privacy program. We  need to make it better. Let's, you know, look at the NIST privacy risk model and really build out  a great strong privacy program, which is one of the things we're trying to do at my company.  So now that we're on a little bit of a Facebook kick, I love getting to do this. So it was also  in the news recently that a night circuit decision just went through saying that the state of Illinois  can go after or a case against Facebook can proceed in the state of Illinois because of  violations of facial recognition laws there. For me, this ties in, I'm a privacy lawyer,  so I pay a lot of attention to facial recognition tech. For me, this goes through in the way that  this is a long-term integrated piece of how Facebook operates. You know, facial recognition  is hugely interactive in all of their photos and tagging people and figuring out your contacts and  that sort of thing and in sharing information with ad companies and marketing tech. When your  company has something that they've developed that they've spent a lot of time and effort on  that is really involved in their product and it ends up having a problem like this or it ends up  being a major risk factor for them, what kind of advice would you give hypothetically? Obviously,  none of your companies would do this. But hypothetically, if you were working for a company  like this, how do you approach a problem that is so integrated into the main product and into the  company culture when it's running into major legal risks this way? Sure. I mean, the company I work  for now is we're a B2B company, so for us, we want to do the right thing with your data and  from privacy and security, not saying that other companies don't, but a company based on advertising  revenue, because I used to work for Google and Yahoo and their privacy group, it's a little more  challenging because they want that data for revenue, to drive revenue, to build better advertising  profiles, et cetera. I mean, this seems a little too idealistic, but they kind of push the boundaries  for years. There's been issues around facial recognition since the EU brought this up and the  Irish DPC did an investigation of Facebook years ago. They've said, I think they should do the  right thing and they're going to have to rearchitect their systems and it's going to cost  some time and money, but they've made probably billions of dollars on the fact that they've had  this tool, so that they can use the billions of dollars in engineering resources to do it right  for users. I have small children and I actually don't put them on Facebook because I freaked out  about people scanning their face and won't even let them put them on the website for their preschool  they're going to. I was like, no, I don't want my kids. So, yeah.  So to the question, like setting aside Facebook for a moment, I think transparency can really help  out a lot. So what your company doing might inherently impact the privacy of your users.  That there might be a service that you're providing, maybe location services, that  does impact the privacy of the users. And if you're transparent with what you're doing with that  data, why you're collecting it, what you're doing with it, how you're protecting it internally,  and that helps with the public perception. But then there's the, okay, well, this is what we're  saying that we're doing. The responsibility then comes, well, how do we know that we're doing that?  How can we prove that we're doing it? And frankly, are we actually doing it? And do we have the  resources to do it effectively? So it can certainly be done, but I really think that if you're  opaque about what you're doing, you're not living up to your promises and to your responsibilities,  that's when you should get in trouble by somebody.  Someone else?  Brad?  So I think the Facebook decision recently is a wonderful example of one of the very sort of  unique legal compliance challenges where it's a state law. It's something that a lot of  companies the size of Facebook and Google, probably like, they're probably thinking about it,  but it's not GDPR, it's not a federal level law. It's easy for these state level rules to slip  through cracks if you're inside and talking compliance with your legal department. I would  echo, I think transparency is key, absolutely. I think one thing that has been helpful in my  experience internally is we have very open lines of communication with the teams that are sort of  building features and building products and making these services. And there's a well-established  culture of, if you're building something, come talk to legal and here's our template to make  sure that we're reviewing it. And does that always include state level regulations? Hopefully,  maybe, but at least for the well-known established risks. I think having that culture of  communication with legal is absolutely key.  So I think the transparency thing is great, but as a user,  I think you're full of shit. When I see what you're doing and you tell me what you're not doing  with your data, a lot of times it's written in some very ambiguous terms and as an attorney who  does privacy and cybersecurity, I'm all about ambiguity. I want to let the company do what  it needs to do with the data to help provide a service and maybe look at better options for  the products they're providing later. So I think transparency is great, but I don't think it's  very effective when you're thinking about something like a runaway company where maybe the C-suite  or the board isn't really paying attention or the engineers are just really focused on, hey,  I want this new product out. Like, you know, a product that's listening to ambient noise and  serving up ads to you. Is that really something we need to do? It would maybe drive some revenue,  but it's really fucking creepy. And so I think we have to be careful with if you're like creep  factor, sensors go off, then it's an obligation to point out whether you're CISO or outside council  or in-house council to say, you know what, this could work out legally or maybe here are all  the problems legally and here's the risk to your business, both legal and security and bottom line,  but also think about the creep factor. And I think that's a big one that should be emphasized from  top down, bottom up all around all the time. So the second that becoming resident like creep  factor sensor becomes a real job I'm in. I've got the high sensitivity level. I'll go full tin foil  hat. I'm all about that. So as soon as you guys hear about that, let me know. Fred, you've also had  kind of a range of experience worked with a lot of different areas, different departments. In your  experience, where do lawyers come into the process when dealing with security and privacy reporting  and what do you think is the best time for them? So kind of to summarize, when have you seen  lawyers come into that process and when do you think they should if it's not necessarily what  you've seen? So right, I would certainly say usually they come into the process too late.  I think the worst examples I've seen was when I was in private practice, we'd often be called in  to consult and it was more often than not a relatively early stage, often like security  focused startup and probably the worst example of which I will not name company, not still  undone, honestly, but my favorite was a sort of PayPal ask finance financial company that had found  a really great way to do frictionless transactions in deep and complete unawareness of anti  money laundering laws. So we got to be the people to tell them so you've got a neat business idea  but it's completely illegal and here's why. It's because you can't do this legally. Need idea  though. So I feel like one of the reasons why I'm such an advocate for like talk to legal sooner  rather than later is to avoid things like that. You know, this was a great a sort of textbook  example of someone who had built something without talking to sort of legal compliance, privacy,  people and spent, you know, countless hours and countless dollars on making the system only to  find out oh, all we built is a liability machine, which is never fun news to deliver either.  You know, I think it's a little different when you are inside of a company. It's easier to have  an eye on what's happening more proactively. You know, I think one of the difficulties being  outside council was people only come to you when they know something's wrong or when there's  no something might be wrong, which 50-50 odd something already is. I think internally the  structure that I've seen work best is open lines of communication and oh, open lines of communication  and the other thing that I have found to be very effective is good documentation across teams.  So for example, our security team, we work with them to basically draft a handbook for what to do  when there is a security breach. And because we work closely with them, that includes kind of  summary level versions of what's personal data under GDPR or under other privacy  statutes. So while we do not necessarily have a lawyer embedded in the security team,  we've given them information to be aware of okay, if we see these things when we're going through  the logs, they know to talk to us, we get looped in and it's a fairly seamless way to make sure  that the people who are most likely to see things that legal would want to know about know to tell  us about it. So I think that sort of early awareness has been the biggest structural thing that I've  found useful outside of any sort of, you know, I wouldn't say that we have any sort of strict like  legal security hierarchy, but it's that open line of communication. As a lawyer, it's very  disheartening to hear that we're not in a hierarchical structure where we're on top, but  we'll take that. Mike, you've got some thoughts here and I'd love to hear from the other lawyers  and non-lawyers about what you've seen work best or work badly. So I was actually asking a question,  I wanted to ask a question of the lawyers on the panel, which was one of the challenges that I  faced was that, you know, we always think about a lot in ratios, like there's one security person  for every 100 developers or something like that and it seemed like we had one lawyer for the entire  company. And I totally agree with you on it's more effective to get the lawyers involved early,  but how do you scale that? And you started touching on it a little bit with some of the  documentation, but and this wasn't one of the questions that we went over. So  how, what are some of the effective ways that you've seen to scale the legal side,  especially in a fast moving engineering company?  I love this question. So I really enjoyed some of the companies I'd worked with that were  product tech focus that moved pretty quickly, engaged, they had security engineers, and those  security engineers were also cross trained in kind of high level privacy and like sectioned off by  team. And so that meant like the person on the ground who was doing the product building at  certain stages of development had someone to go to while they were going through the process  and and say, Hey, do you think this is a problem? Like, are we pulling a bunch of PII? Do we need  to tell our lawyers about this random vendor that we Googled and said they're pretty awesome?  Oops, I signed a contract. Like those are the kind of things that the security engineer was able to  also flag for the team. And I thought that was, I saw two companies do that in six years. And it  looked like it was a newer trend. And I don't know if you guys have seen more of that, but I thought  it was cool. So sure. So yeah, we actually have a security engineering group and they're called  their security partners. And they work with a security champion who's kind of a security, it's  an engineer embedded within their kind of product org. And they try to meet the champion tries to  meet on a monthly basis with to have an open line of continuous continuous conversation with their  security partner. But I've worked with the security partners to kind of like bring me in on certain  things like that. And it's helped a little bit. They're definitely starting to kind of identify  things and bring us in more. But another structure that's very effective that you see a lot of tech  companies doing is having like a product council structure, where you kind of know like you work  in this org, you know that Bob or Stacy is like your kind of go to attorney for anything legal,  whether it's contracts or partnerships or, you know, privacy copyright terms. And then that kind  of person is a generalist and they are able to bring in the right experts on the team in legal.  So that that structure I think is good for the product org to if it's a company that has  resources to scale a legal team like that. Yeah, I would agree that that's one of the models I've  seen work pretty well. I feel like you're sort of, you know, to answer your question about like how  do you scale this? It's kind of that like difficult triangle of thorough scalable and cheap. And you  kind of get to pick two. If you want all three, sorry, I've got some bad news. I think the easiest  least cheap option is hire more lawyers. That is not always accessible to a company, especially  because like your legal department is not your moneymaker in most systems. You know, you are,  we are a cost item. But we are a, you know, ideally one that prevents other bigger cost items like  federal fines. I've also seen it work for companies that have some resources but not enough to grow a  huge legal team to like go sort of the product council role and have a kind of deep list of  outside counsel who can be deferred to for subject matter expertise. And so your, you know, one or  two product counsel become kind of, you know, generalists who have a knowledge of exactly who  to talk to when for what. And then I think the third way I've seen this work that is the cheapest,  but sort of the heaviest lift on your counsel is right, like build documentation, get extremely  good at triage for the live time that you're like understaffed counsel team has. So I'd say those  are the three models I've seen work most reliably. And it's just a question of like, where do you  have the resources and how much resources is, you know, for the area that your company is in,  how much resources can you sort of afford to allocate to solving this problem?  So just to layer on to what you said, I think it's also where training within each organization. So  what are the triggers? So if I'm in DevOps and I all of a sudden see  change in data set, change in data points, and I understand data to some degree, what's a trigger  or threshold that would then go to like a security or privacy champion versus going directly to  counsel and then really getting like the right person at the right time, but also the value  proposition. Does every change in data, every change in code, every change in product direction  require counsel or are there other people who can triage it and keep it on track and then a  certain, again, back to risk. When the risk reaches a certain threshold, then yes, we need to reach  out to the security team or to legal counsel or to both. And also making sure I think the  connections between orgs. So if someone's purchasing something, did sourcing or finance catch it so  that it can then be turned back around to the counsel and to the security and privacy. So  having those integration points in other business processes that trigger the right group, either  before action has been taken or even retroactively because sometimes you have to go back and fix.  Sushi, I know that you've worked with some corporate clients. I was wondering, have you seen  any challenges when it comes to reporting structures that either you feel are specific with  corporate clients or are exacerbated with corporate clients? Are there any experiences there that  you think would serve as good kind of cautionary tales for structural creation here? Yeah, I don't  know about cautionary tales. It's more the more communication that I've seen among people at  particular levels, the better it is. So if we were all working together at the same company,  the best relationship would be one where I could pick up a phone and or text and be like, hey, I  need to talk about this. Do you have 15 minutes? And then it should be that easy. There's a lot of  politicking that I've seen at different companies that I've worked with that can really throw a wrench  into that type of a relationship. And that's a part of living in society and it's part of life.  But hopefully with some empathy and context, you can work with your peers and get to a point where  you have open communication about, I'm really worried about this idea that we have going forward  or, hey, outside counsel told me this crazy thing. Can we talk about it so we can strategize and  approach, like manage up, go talk to whomever is above us and needs to make a decision. And another  thing I'd really emphasize is that a lot of organizations think of escalation as a problem,  like, oh man, someone escalated to the person above me. But you know what, that's why an escalation  exists. So if I disagreed with Marina on something, then we could respectfully lay out why we think  the way we think and where the risks should be ranked and whether we want to build something in  or not. And then I could say, hey, you know what, I'm going to go ahead and escalate this. I just  wanted you to know. And then we would have that conversation at a different level. And that's  entirely appropriate. So I think corporations should be less averse to escalating and more  interested in communicating with one another to move together towards whatever the goal is. So  I would agree with that. And I think it goes back to, again, you're speaking the same language,  so you're talking risk. But I also think it also helps you when it comes to resourcing. So if we  continue to go back and forth and work on the same problem, but we're at a stalemate and we don't  know how to escalate or we're too scared to escalate, then we're wasting our time and potentially our  team's time working the same problem versus, hey, we have differing opinions, we're bringing  different expertise to the table. We really need to raise this to the next level to make the business  decision. Who is able to actually accept this risk or say, or we need to mitigate the risk to  whatever new acceptable level is, then it actually allows you to be more efficient and your resources  can be spent more wisely. So I agree. So the one cautionary tale that I would have, I absolutely  agree with the concept of escalations and really is kind of core quality community. And I think  it's kind of core quality communications. But you have to be careful that the people who are  being escalated to know that it's coming. I've seen cases where escalations have been weaponized.  It's you either agree with me or I'm going to go escalate this. And it becomes then a very  adversarial relationship, even though I agree with you, spending on something that you're not  getting anywhere is a waste of resources. So the best way that I've seen to prepare that is to  make sure that like the entire leadership understands that escalations is a thing and they have to  encourage it, not just at whatever level you're having the disagreement.  I just realized I didn't ask part and answer part of your question, which is the reporting  structure. So one of the weird ones I saw was compliance was solely under security and privacy  reported up to security. And so that was all through the CISO and then there was general  counsel and legal over there. And I thought it was really odd and I don't know what you guys think  about this, but I thought it was odd to have privacy and security reporting to the same person  where I would have preferred to have security reporting up to CISO and privacy reporting up to  a director of privacy or something like that. So you have a dashed line across between CISO and  director of privacy because I think there's actually, although privacy and security are in  tandem, I think there are some different ways of assessing the risk and that I don't think one  person should carry the responsibility of making a determination that involves both security and  privacy. So I feel attacked because that was exactly the structure that we had. And so you  weren't talking about us, so that's fine. But it really comes down to it's going to be one of  those it depends questions. And what I would say, any of the discussions that we have about  structures and reporting, they can all work if you have the right people. For us, it was  that alignment of security with privacy came in very handy. Partially to the earlier discussion  about scaling privacy with security champions and those kind of mechanisms, we could have the  security team talk to the privacy team and say, hey, there's something going on here. And they  were so tightly intertwined that that was more efficient. And I thought that was rather effective.  I will, however, say we did have privacy council so within the legal org. And that meant that we  did have still that oversight. I would agree with you that if it was just one straight silo,  there is that risk of making these decisions that are too, they have impact and you don't have  that oversight. But you can, I believe that you can be effective with security and privacy as part  of the same organization as long as you have that external oversight, as long as you have somebody  else who's kind of keeping an eye on that team and making sure that team is not doing something  way off on the edge of the reservation. I can comment on that. Actually, so a privacy professional,  I've been in several different functions that have kind of rolled up. Like at one point I was  in privacy org that rolled up under IT, rolled up under an ads function of a company and then  since then it mostly legal. And the one, and actually it's interesting if you look at Google's  consent decree, they were told to build like a separate privacy program that's separate from  their security program. So the challenge is there is that privacy might not be, might just be this  little thing that security does, but it's not really as important. And I think that's, I think  it's just privacy growing up and figuring out where they fit and that they have a voice at the table  where a lot of people who've been in privacy for a long time really kind of just fell into it.  Like everyone I know who kind of fell into it 10 or so years ago, it was that boring,  risking compliance thing someone did in the back office. It's just privacy, but now obviously  it's very sexy and everyone wants to do it. But so we'll see how privacy grows up. I mean,  I kind of really like being part of a legal department even though I'm not an attorney,  as a privacy professional because I feel like at the end of the day we are still mitigating risk  and supporting the business, but in independent fashion. At one point actually our CISO and  our head of privacy, CPO reported both up to the general council, but recently they just changed  that structure where our CISO is reporting to our CFO. And that's actually a newer structure  because I was talking to our head of corporate comms who's been doing security corporate comms  for years, PR, and he said, you're starting to see actually a lot of companies putting the  security function under the CFO, the chief finance officer, because it's around mitigating risk.  Maybe they get more budget that way. Who knows? So one of the things that I've actually been  pondering just this week is the idea that security might eventually report to privacy.  If we look at the regulations that we're seeing in the world today, they're all  privacy regulations. We've got breach notification requirements, but that's just a fraction of  what security does. All the privacy regulations are very in depth with heavy fines associated with  them, and it's the privacy regulations that people are pushing for. So it wouldn't surprise me if we  start seeing this other way around. I wouldn't be shocked one day if we see CISO's reporting to  chief privacy officers. I think that that is a future that might come and that might be perfectly fine.
Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_0_95.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_96_719.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_720_1943.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_1944_3539.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_3540_4223.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_4224_4751.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_4752_5195.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_5196_5375.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_5376_8507.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_8508_8591.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_8592_8699.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_8700_9299.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_9300_13007.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_13008_16931.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_16932_21167.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_21168_23351.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_23352_25127.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_25128_30803.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_30804_30995.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_30996_34319.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_34320_34463.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_34464_36455.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_36456_36515.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_36516_39239.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_39240_46247.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_46248_46307.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_46308_47867.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_47868_49559.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_49560_52319.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_52320_54695.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_54696_54875.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_54876_59939.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_59940_60071.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_60072_60119.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_60120_64139.png Suchismita_Pahi_-_How_to_Integrate_Privacy_Legal_S_NSuII5D76kI_64140_67680.png