 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 Callie who's going to be moderating. Hi, everyone. 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'm Suchi. I'm a data privacy and cyber security attorney. I've been practicing for a while and I've 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'm 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 a CISO of Lyft for a year and a half prior to that, you know, nine years at Salesforce 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 and it was really kind of this tremendous learning experience and I'm really glad to have, you know, all these other folks on 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. All right, 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 in 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 all of our standard pipelines, combined with analysts and operators who were 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 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 in a 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 lot 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 we're 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 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 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 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 with 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 risk. But sometimes infosec, 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, like looking at the types of slides, their finance business partner, their HR business partner, their operations business partner was providing, and putting infosec and 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 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 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, 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 this recent Facebook $5 billion fine and the structures of the corporate privacy governance need to put into 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 the 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 at 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 a hundred 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, like we want to do the right thing with your data and 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 in their privacy group, it's a little more challenging because they want that data for revenue, to drive revenue, to build better advertising profiles, etc. I mean, this sounds 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, like 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 the 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. 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. Like 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 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 counsel or in-house counsel 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 a company not still and 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. Right, it's because you can't do this legally. Neat 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've built is a liability machine, which has never, which has 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 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, you know, what's personal data under GDPR or under other privacy statutes. So while we do not necessarily have like 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, and this wasn't one of the questions that we went over. So 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, 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 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 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 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 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 Stacey is like, you're 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 structure I think is good for the product org too, 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 you're, 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 your 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 counsel and to 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. 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 council 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 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, spinning 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 that 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 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're 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 counsel still 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 they're 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's not doing something way off on on the edge of the reservation. I can comment on that actually um so a privacy professional I've been in several different functions I've kind of rolled up like at one point I was in a privacy org that rolled up under IT um rolled up under an ads function of a company and then since then I'm 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 you know a lot of people who've been in privacy for a long time like really kind of just fell into it like everyone I know who kind of fell into it 10 or so years ago like it was that boring risk and 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 um 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 independent fashion um 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 um corporate comms who's been doing security corporate comms for years and 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 so one of the things that I've I've actually been pondering just this week is the idea that security might eventually report to privacy um if we look at the regulations that we're seeing in the world today they're all privacy regulations uh 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 um I wouldn't be shocked one day if we see CISOs reporting to chief privacy officers I think that that is a future that might come and that might be perfectly fine.