Building Governance at the Speed of Product

Jad: Welcome to the show. I'm Jad Boutros, founder and CEO of TerraTrue. In this series, we sit down with leading experts across privacy, security, and AI to unpack hard-earned lessons and explore how they're navigating this ever-changing landscape.

‍

Today, we're joined by Aaron Mendelsohn. Aaron is a privacy and cybersecurity executive and currently Director and Senior Privacy Officer at the LEGO Group, where he leads data protection across their digital platforms, retail, and global marketing. Aaron is also a law professor and the author of "Operationalizing Data Protection and Privacy." Aaron, thank you so much for joining us.

‍

Aaron: Thanks for having me, Jad.

‍

Jad: Thank you. I want to start with a bit of an origin story. I can count on maybe one or two hands the number of people I know who've studied electrical or computer engineering and then made the leap to law. So I'd love to know a little bit from you what drove this pivot — and was privacy already on your radar back then, or was it just a happy accident?

‍

Aaron: It's a little bit of both. It was really decades ago, which is hard to believe. I went to Ohio State in Columbus, Ohio, and I'm originally from Cleveland, so my Buckeye pride and my Cleveland pride are strong.

‍

I didn't quite know what I wanted to study. I went into school undecided. It was the beginning of the internet, the dawn of Google in the late '90s when I was an undergraduate student, and a lot of my friends and I were just like, "We should do something with computers." I had friends that were in business and information sciences, others doing straight computer science and computer engineering. And I decided — you know what, I've always been good at math and physics and enjoyed the engineering aspect. I'm going to do electrical and computer engineering.

‍

I didn't really know what I wanted to do with my career at the time. I just figured this was a hard undergraduate degree that could serve me well and then be a platform to go pursue other endeavors.

‍

While I was an undergraduate student at Ohio State, I had a couple of internships with a company called Eaton Corporation, a large diversified manufacturing company in Cleveland. I was part of their corporate IT internship program for two summers, and after leaving the second summer I was offered a job to come back as part of what they called their IT and Leadership Development Program.

‍

At the time, these types of programs were not necessarily that abundant. Our program at Eaton was modeled after programs at companies like GE and, I think, Procter & Gamble, where they brought in a cohort of undergraduate and master's students and had them do different rotations through parts of the IT organization. There were finance programs like this, HR programs, but I entered the IT program, where a lot of the students came from similar backgrounds — electrical and computer engineering — and some from other degrees as well.

‍

We did four six-month rotations through different parts of the organization. I've never been a strong developer; I was always more on other parts of the engineering discipline. But very quickly I found an interest in information security and internal controls, and that was where I wanted to begin my career after the program.

‍

At the time our information security group was only about two people. They had recruited the head of IT audit to come and lead a nascent information security team. He brought one hand-chosen person with him. Then someone joined to help do disaster recovery and business continuity. And then I was the junior member — the guy almost fresh out of school who came in and was asked to do everything.

‍

So I started my career as an IT security specialist doing a little bit of everything. I did incident response, email security, pen testing. I then helped write our first plan to deal with SB 1386 in California, the first US law around how you respond to a data breach. And that got me thinking — this was early on — and I said, all right, there's this interesting area between the law and technology. Maybe I should explore that.

‍

In the back of my mind I always thought I could go to law school. My father was a prosecutor, I had an aunt who was a judge, my grandfather was a lawyer. So I came from a pretty deeply rooted legal family. But I didn't know what that would mean for my career — this idea of technology and the law. At the time, a lot of people were like, "Well, you could go be a patent lawyer," and I didn't really want to be a patent lawyer. I tried to understand what that could be, looked at the patent bar, and that wasn't where I wanted to develop my career.

‍

But I said, there's going to be this developing area around data protection and privacy. We had the EU Data Protection Directive. The US–EU Safe Harbor was in existence. I already mentioned California SB 1386. The company itself was a HIPAA covered entity for its self-insured health insurance plan. So there were all these areas mixing together and nobody was really quite managing it at that time. I identified a need and said, let me develop my career around this.

‍

Fortunately I had a CISO at the time who was very supportive. He said, "You know, if I was a little bit younger, maybe I'd go to law school." I made the business case: send me to law school at night and I will develop core subject matter expertise around data protection, privacy, and cyber law. And I did that. I went to night school for four and a half years and became a lawyer.

‍

As I finished my law degree and passed the Ohio bar, I made the business case to stand up a formal privacy program at Eaton and make me the head of that program. I worked with colleagues in Europe and in the US. I was a young twenty-something going into the C-suite talking to a general counsel or chief HR officer, a head of ethics and compliance, or a CIO, trying to make the business case that we need to formalize privacy. Fortunately they saw it, they recognized it, they put a lot of trust and faith in me.

‍

I was able to start building that team, and really the framework for what I think springboarded me to the rest of my career, because it showed me how you build a program from the ground up. How do you engage across functions? Privacy is very much a cross-collaboration team effort. Privacy teams are small — they're still not that big unless you go to some of the bigger companies — and we're having to figure out how to create impact and influence across other organizations within the larger business.

‍

Jad: That's a wonderful story, and we're so glad you made this pivot. Aaron, your technical-meets-legal background clearly influenced your book, "Operationalizing Data Protection and Privacy," which you published almost a year ago. Can you tell us what made you feel compelled to write it, and what the journey was like writing a book while leading privacy at scale?

Aaron: I try to challenge myself to do things outside of my day-to-day work activities — I've always done this. When I was younger, and now I'm dating myself a little bit more, I used to write concert reviews and take concert photographs. That was just a hobby, something I did outside of work to entertain myself.

‍

When I joined the LEGO Group, a lot of it was focused on supporting the organization and some of our initiatives. Then at the beginning of 2018, I started teaching a law school class around this idea of how you engage privacy in a corporate setting. The class was at Cleveland State University — that's my alma mater — and it was called Privacy Law and Management. As far as I understand, this was the first class of this type designed to really engage students and teach them how privacy functions within an organization.

‍

I wasn't teaching the theory of privacy law. We weren't studying treatises or law review articles about what privacy means. What we were teaching is: if you enter an organization as a junior privacy team member, what do you need to know that might help you get your start on that team?

‍

So very carefully, we brought in guest speakers to teach about what it means to do a privacy contract. What does it mean to do privacy communications? What does cyber insurance look like? We brought experts in from the Cleveland privacy community to teach the students what privacy means within an organization.

‍

Data centers are all the rage today, but I even took the students on a data center tour, because I said there is a physical nature to what we do. Now everything's in the cloud and we just see data centers being stood up in neighborhoods. But I think it's a very interesting thing to walk through a data center and understand the physical nature of how information is actually stored and managed at scale. I really wanted students to understand those aspects.

‍

I'd say we went an inch deep and a mile long across what organizational privacy looks like. And I missed that when I came to the LEGO Group. Obviously I had to give it up — I transitioned that teaching to another colleague at the university. But I always enjoy sharing the knowledge I have. It's why I like to do these types of podcasts, and I appreciate you inviting me. It's also about how you communicate across our profession as to what it means to be a privacy lawyer, privacy officer, privacy professional.

‍

I was thinking, how do I share what I'd developed in the syllabus from teaching those five years with a broader audience? And I said, all right, let's do a LinkedIn newsletter or something of that nature.

‍

At the end of '23, I floated that idea on LinkedIn and outlined a curriculum or syllabus I could follow. I challenged myself: could I write an article a week for others entering the profession? It was really geared toward new professionals — what it means to be in the privacy profession. Again, an inch deep and a mile long across twenty-some different topics, every week for half a year.

‍

And I did that, just to keep myself accountable. Could I write one article a week, somewhere between 1,200 and 1,500 words? I had an audience of over a thousand people sign up for that newsletter, and it just grew organically week after week. I got a lot of excellent feedback from people within the profession who reached out and said, "This is really helpful, I'm sharing it with other colleagues." That was really meaningful to hear, because I wasn't doing it for any reason other than sharing my knowledge and engaging with other colleagues in the profession.

‍

But toward the end you start to see — all right, now I have all this content. It's structured. It fits the way I think, and others find it helpful. Maybe I should turn this into a book. A couple of people suggested that. And with the self-publishing tools out there, it's pretty easy — maybe not easy, but the tools are available to make it easier to put things out there for the public to consume or read or buy.

‍

Fortunately I also had a cousin who is a business book editor. I reached out and said, "Hey Dusty, would you help me turn my content into a book?" He thought about it and said, all right, let's see if we can do that.

‍

So he took what I had — twenty-some subjects, structured — and we said, well, that's not enough for a book. Let's see if we can come up with some new topics. We brainstormed back and forth; it was very collaborative. We came up with, I think, another fifteen topics we could add. Then we played around with transitioning this from bulleted blog posts into more structured chapters. That's where his expertise really helped me transform what I had — sort of bulleted thoughts — into more of a structured business book.

‍

For the next almost year we worked on it, went back and forth, collaborated, worked on a chapter a week, rewrote chapters. And my book's right there — plugging myself here — but yeah, we released it a year ago on Amazon's self-publishing platform. It's found an okay audience and it's opened some other doors.

‍

My goal wasn't— you're not doing this to make money. You're doing this to challenge yourself, and to share the information with those who find it helpful. So we'll see what comes of it after this. Maybe I'll do a second edition at some point, or turn it into something more around digital governance and digital compliance. We'll see.

‍

Jad: Absolutely — that's a great story, and we'd love to pick your brain on some of these topics. But first, you brought up that privacy is generally a small team that needs to work with the rest of the business. So I want to ask you a couple of questions, starting with alignment with product and engineering.

‍

One central theme of yours is bridging execution with strategy. Can you share some big lessons you've learned for how to build trust with product and engineering so that the privacy team feels more like an enabler than a speed bump?

‍

Aaron: I think it starts with building trust in the relationship. If you're privacy and you come in all gung-ho and you're like, "I'm going to tell you what to do and you're going to follow my rules, and that's it" — that's never going to work.

‍

You're a compliance function when it comes to it. You're helping to make sure the company doesn't get in trouble, that whatever you do is defensible from a decision-making standpoint, and ultimately we're helping manage risk. That's always how I've viewed our role within an organization.

‍

But engineers have to develop products, ship products, maintain products, and they want to make sure they're doing it in a compliant manner — but that's not necessarily top of mind, even if they say it is. You may have chief digital officers or CIOs who always say compliance is absolute zero, but I think there's always a compromise in their head even when they say that.

‍

So how do you find a way to build that trust, build that relationship? I think it starts with asking questions like: What are the challenges you're facing? What are your big pain points? How can I help make what you're struggling with easier? Is it documentation? Is it doing compliance by design? Is it supporting queries as you're doing ideation?

‍

You really have to understand where their pain points sit. You don't want to reinvent their processes. You don't want to add burden to their workload. You want to figure out how to make what they're doing easier and quicker while still getting the information you need to feel that you're putting the organization in a defensible position and managing risk.

‍

So it starts with having that conversation, building the relationship. When I join an organization, I try to ensure that I have coffee chats with the people I deem — either by looking at org charts or talking to other leaders — as the people I need to know. It may be the director of development, or the VP over your e-comm store, or the team managing your marketing efforts. Go and meet them. Don't even have an agenda except to introduce yourself. Build that relationship. Talk a little bit about where you come from and how you think about these issues, and ask them what they're facing. Then start to build that relationship over time.

‍

You don't want to transform those processes overnight. You want to slowly understand the pain points to get to a point where you can say, "All right, I think I have some ideas as to how we can make your life easier." Maybe you're solving a specific problem like documentation, or risk assessments, or compliance by design, or AI governance — whatever it may be.

If you can start to build those key advocates through those relationships, then the rest will sort of fall into place. I've been fortunate enough in my career that that's seemed to work more often than not. It doesn't always work. Sometimes you have people who, for whatever reason, don't want to play ball, or they see you as a bottleneck, or maybe they had a bad experience with a privacy team in a previous role, so they think of you as the naysayer, the person who's going to come and say no. But very rarely do I want to say no. It's more about how do we get you what you need in a way that meets our compliance obligations.

‍

That's how I've always approached those situations with product teams and developers. Oftentimes they see you for who you are, they want you to be engaged, and then they'll come to you when they have a question six months later and say, "Hey, you helped us with this. Now we're doing this new thing — how do we deal with it?"

‍

Jad: That's great, Aaron. I feel like implicit in your thoughts there is the idea that product and engineering know what they don't know. Meaning they have a sense of what it is about privacy that bugs them, that's hindering them, that's preventing them from building stronger relationships with their end users. And so you're bringing them early in the process to think about what privacy should look like.

‍

So you've found that product and engineering typically are aware of most things and just need help with how to think about it — as opposed to not knowing the space or not knowing the requirements?

‍

Aaron: Yeah. We're almost ten years on from GDPR, and you've got an entire generation now of engineers who have been developing with GDPR as a requirement. A decade ago we had to create that awareness. That awareness exists today. So now it's more, how do we help enable them to get to the place they need to be?

‍

The other challenge I'm seeing today is almost what I call death by a thousand paper cuts. Oftentimes now, digital compliance is broader than just privacy, and it's coming from other angles. You have AI governance, you have online safety, content moderation. I think cyber plays a part of that. And sometimes we're not talking, the different governance functions within an organization.

‍

That's the other pain point we try to solve for our developers, our engineers, the product teams: to consolidate those requirements as much as we can into a single workflow, single touchpoints, so that the teams aren't hearing compliance from five to eight different people — they're hearing it from maybe one, maybe two.

‍

We're not going to be perfect. We're not going to get it down to one, at least at this point. That may be the future state. But we're trying to figure out how to make their lives easier, so there's maybe a single set of requirements they have to adhere to. Privacy being one of them, AI governance now being the new kid, cyber having been there for a long time, online safety if you're managing platforms that have that component, content moderation, and all those other digital GRC issues we're having to manage.

‍

Jad: That's perfect, Aaron, and it's a great segue into asking you more about AI in general and AI governance. Let me start with AI being this operational force multiplier. It's making it possible for different teams in an organization to do things they couldn't do a year or two ago.

What's your sense of how privacy teams can leverage those AI capabilities to scale? As you said, they're small teams — how do they get their voice heard better and continue to innovate and meet the demands of the business?

‍

Aaron: I've been thinking a lot about this lately and I don't have the answers necessarily. But I think there's a lot of potential for us to compress the teams but still expand our impact using some of these AI tools. Every organization is on their own AI journey — some are leaning really hard into it, some are leaning out a little bit.

‍

One of the things I've been playing around with in the last two or three months is this idea of rules as code. I don't know if you've played around with how you develop the rules that you have as a privacy team. And I don't think it's just privacy that can do this — because we're lawyers, I'm a lawyer, and half the law is deterministic rules, maybe even more. How can you codify those rules into code, or some way that can be machine-readable, that can then be managed and consumed across the organization?

‍

I don't have the answer to this yet and we haven't really put it into any real use case, but I think there's a lot of potential if you can say: How do we create a taxonomy and a corpus of rules that can then be consumed by my product teams, by my marketing teams, by the teams engaging with children or other high-risk or vulnerable populations, to say, "Here's what you should be doing"?

‍

Those rules can come straight out of the text of the law. They could also be organizational policies. But I think there's a lot of potential to enable others within the organization to know what's expected of them, if you can find a good way to get your rules into a form that can be machine-readable by agents or other AI-enabled tooling — that can compare what it is that you're doing and what it is that you expect versus your build documentation or your code base. Or maybe it's just being in a chatbot that's helping with ideation, so if I'm thinking of this, what are the organizational policies or rules for doing this? You can't say that you're giving them legal advice, but maybe you're giving them at least quick feedback through that.

‍

I know there are market solutions out there that are starting to play with this a little bit too. But I think there's a lot of potential, and every organization's rules are going to be a little bit different. You could maybe even do that within your own personal organization to play with it.

That's one thing I'm getting really excited about — trying to figure out what that means to our organization, what that can mean to other organizations. As far as I know, there's not a whole lot happening yet in that space. But I would expect that as AI becomes more mature across our profession, that's one area that could produce a lot of impact and value, because you manage those rules once but they could be consumed in a dozen, two dozen different ways if you set it up correctly.

‍

Jad: And then privacy and AI governance can function more at the speed of development and other activities in the business.

‍

You brought up AI governance. Today, when you look at this still-nascent field, a lot of the leaders in AI governance come from privacy — in fact the large majority have transitioned from a privacy role into AI governance.

‍

It's clear that AI is bringing in a ton of new risks, very significant ones — exploitation, hacking into organizations in autonomous ways. But it's also bringing this need for AI governance because there are a lot of new risks an organization is dealing with. From your perspective, what are some ways that's shaping privacy teams, and what are some of the topics organizations are struggling with today?

‍

Aaron: I don't know all the answers here. I think there are a couple of different approaches I've seen, and this is just from evaluating what I see out in the market and talking to other peers.

One solution is privacy taking ownership over AI governance. It's kind of like what you're saying — it's the natural extension of privacy being at the leading edge of digital risk and digital compliance a decade, decade and a half ago, saying, "All right, there's this issue emerging, we have to manage the legal obligations. How do we do that?" We did that with privacy.

‍

I think a lot of big organizations have reasonably mature privacy programs at this point, and you're seeing the consequences of that with teams getting smaller. The build time a decade ago was: we have to build the team, mature the team, the team reaches a mature state. Now what? And so some of those teams have taken on AI governance, and they're like, "Well, we did it with privacy. This is just another digital risk area, so let's approach it similarly." The risk shifts — it's now AI. So what are the requirements? What do we have to do? We embed those into our workflows, our processes. We communicate it across the organization. We manage it. We do our best. That seems to be a lot of organizations. I think that's one model that seems to be viable, and the natural evolution of the privacy profession maturing beyond privacy.

The other model you're seeing is privacy being narrowly boxed in — it's just personal data — and AI governance being stood up independent of the privacy team, running with the AI risk and the AI governance.

‍

I don't think either is wrong. I think it's really about what the organization needs and how the organization is structured. But then they have to be closely communicating, because AI risk could be a privacy risk — and oftentimes it is, because it's very hard to evaluate or use data, or even engage with an individual, without getting some of their data. When AI is engaging with a person, then you're getting personal data if it's identifiable back to them, which generally it is, because there's probably some unique identifier to know who that individual is as they engage with the LLM. So what does that mean, and how do we manage that risk, and what do we need to know from that standpoint?

‍

It's still evolving. I'm not an AI governance professional at this point — I support it. I didn't pursue the AIGP certification that's been out there for a couple of years now. But I'm trying to understand it. Not so much the governance side, which I think is a natural component of it — we have to manage it. The law is going to evolve. The public is getting wary of all the different AI use cases. So as an organization you have to ensure that you clearly communicate how you engage with AI, how you protect your employees and your customers, and where it's in use within different workflows or processes.

‍

Jad: I really appreciate your insights on how that landscape is evolving and how it shifts the mindset, focus, and resources into tackling newer problems.

You also mentioned building programs from scratch, literally. So as a way to leave our listeners with a final thought: if a privacy leader joins an organization that isn't mature, what are the first few things you'd recommend that leader focuses on and enacts within their first few months?

‍

Aaron: I think there are two things. One, it's the relationships — the internal networking, the coffee conversations. If your organization allows and supports that slow ramp-up to try to understand who people are and what they do, I think that's really critical. You have to build that trust and those relationships to make an impact down the line.

‍

The second thing is to really learn the organization. Don't assume you know everything, because maybe you're joining a company you love and have been pursuing, or you're already a customer. Understand what that company does. How do they operate? What data do they have? Where is that data going?

‍

Try to build your own model of what that company does from a digital risk or privacy standpoint. The more you can do that — and you can model it however you think is valuable, in your own mind, or using a spreadsheet, or maybe you're using AI tooling to do it, I don't know — some way to inventory what you need to know about that company. Some of that can be financial, but you also need to know where they're operating, where the data is stored, where the data is going, where you're collecting that information.

‍

Some of that you can get at a very high level to build a high-level inventory. You don't need to go do a full RoPA of everything going on at this point. At some point you probably will, if that data isn't accurate or up to date. But you can build that high-level approximation of what the company is doing so that you can start to see: all right, we know there's children's data over here, we know there are higher-risk marketing activities over here. You can start to build that risk matrix in your head — and if you can get it onto paper or into some documentation, even better.

‍

That will help inform where you start to spend your time. What's really a priority? If you have good documentation, then maybe you don't spend time there. But if you don't, then maybe that's something you have to do.

‍

So: build those relationships, and at the same time start to build your own model, mental map, or inventory of what's going on in the organization and what that organization looks like. Then that should come together, so as you start to build your strategy for where you want to focus your time over the next six to eighteen months to mature the organization, you'll have a better idea. Your roadmap will be well informed, your strategy will be well informed, and you can accelerate through that second six months, or the next year and a half, two years — whatever that may be.

‍

Jad: Aaron, that's great advice. If our listeners want to follow your work and reach out to you, how do you recommend they do that?

‍

Aaron: I'd say connect with me on LinkedIn. Feel free to send me a direct message. I'm always happy to chat and share my thoughts. If you want to have a quick coffee conversation or just introduce yourself, feel free. I always try to pay it forward and talk to people entering the profession, or we can spar over a topic or brainstorm. So feel free to reach out.

‍

Jad: That's great. We'll add a link to your LinkedIn in our comments. But I really want to say thank you — it was absolutely terrific to get your insights and to speak with you. I look forward to you continuing on your journey and writing a next book on how things are changing.

‍

Aaron: Thanks, Jad. This was great.

‍

Jad: Thank you, Aaron.

‍