The Data Diva E158 - Pádraig O'Leary and Debbie Reynolds

Debbie Reynolds, "The Data Diva" talks to Pádraig O'Leary, Co-founder and CEO of Trust Works. We discuss Data Privacy issues in the enterprise, and the challenges organizations face in Data Privacy and protection, including the need for a more proactive approach to tackling these challenges. We delve into the difficulties of dealing with right-to-be-forgotten requests, including the lack of accurate data mapping and the need for flexibility in finding the right solutions. Additionally, we touch on the challenges of dealing with unstructured data and the need for a risk-based approach to Data Privacy, as well as the importance of considering the limitations of automation in Data Privacy and protection.

We discuss how Trust Works differentiates itself in the crowded privacy space. Padraig explains that the company emphasizes collaboration and automation and that its approach to privacy tool design drives certain choices in how the solution is designed. We also discuss the challenge of AI creep, where companies may unknowingly adopt AI-powered tools without considering the risks associated with them.

We suggest that companies must build a second data map specifically for AI-powered tools and that privacy professionals must be involved in this process. Additionally, they propose the idea of a kill switch functionality to turn off AI capabilities if necessary.

Finally, we discuss the challenges of building diverse and skilled privacy teams. Padraig emphasizes that privacy professionals need to have a unique set of skills that bring together legal, technical, operational, and ethical considerations. Debbie agrees and highlights the benefits of having a well-rounded team of people who understand data and the different angles data challenges take. They both believe that more people from diverse backgrounds and industries must be brought into privacy to build diversity in the field and his wish for the future.

Transcript

30:21

SUMMARY KEYWORDS

data, privacy, tools, companies, unstructured data, ai, organization, challenges, people, deletion, forgotten, request, systems, team, mapping, automation, debbie, enterprise, product, pressure

SPEAKERS

Debbie Reynolds, Padraig O'Leary

Debbie Reynolds  00:00

Personal views and opinions expressed by our podcast guests are their own and are not legal advice or official statements by their organizations. Hello, this is Debbie Reynolds. They call me "The Data Diva". This is "The Data Diva" Talks Privacy podcast, where we discuss Data Privacy issues with industry leaders around the world with information that businesses need to know now. I have a special guest on the show all the way from Spain. Padraig O'Leary, Ph.D., is the Co-Founder and CEO of Trustworks. Trustworks promotes the legal and ethical use of data in the enterprise. Welcome.

Padraig O'Leary  00:48

Thank you, Debbie. It's a pleasure to be here and speaking with you today.

Debbie Reynolds  00:53

Yeah, I'm a bit jealous. Spain is one of my favorite places to visit. So, Chicago's not bad either, but I love Spain. So, thank you for doing a session with me. You and I have been connected on LinkedIn for quite some time. You always have really great insights. And so I've worked with a lot of enterprises before. I'm very well-versed in what happens within the enterprise around data. So I'm very interested in your thoughts about that. So, I want to talk a little bit about your trajectory. How did you get to where you are as the Co-Founder and CEO of Trustworks?

Padraig O'Leary  01:34

Great. Thank you, Debbie. So yeah, first, I'm not a native of Spain. So I'm from Ireland, but I've been living in Valencia for about seven years now. But yes, it is a lovely place to live. So yeah, I think my journey into privacy is probably slightly atypical. My background is in computer science. And I actually followed the academic path, research, and teaching for about 12 years. So, I was an assistant professor for software engineering at the University of Adelaide. And then I held some teaching positions in Ireland, and I was a research fellow at Lero, the Irish Software Research Center. So definitely, I suppose my perspectives on privacy definitely come from the more system level and the engineering side of privacy.

Debbie Reynolds  02:29

That's great. I'm a data geek, I tell people. You know, that's why I'm "The Data Diva"? Not the Privacy Diva, right? So.

Padraig O'Leary  02:37

For us, yes.

Debbie Reynolds  02:39

What is it that organizations get wrong about data in the enterprise? What are the challenges that you have to overcome?

Padraig O'Leary  02:53

Yeah, so I think the challenges around data and privacy, they're probably the same challenges that organizations have had for the last 5, 10, or 20 years, and particularly when it comes to data protection, those core fundamentals around data mapping, tracking, how data is processed, or personal data is processed within the organizations, different types of assessments that you might have to do as a privacy team. So, these challenges are ever present. I think particularly, when we think about data mapping, in some ways, I feel that the challenges around data mapping are bigger or even greater now than they ever were before. I think companies have traditionally treated these areas of data protection or privacy very much as project-based exercises, where, they talked about data mapping exercises, or building a record of their processing activities, let's say, like incident response procedures. But I think what we're starting to see is this evolution towards companies being a bit more proactive in how they tackle these challenges, integrating them into, let's say, privacy programs, which will be designed for kind of more long-term sustainability. So definitely, I think the challenges haven't changed. Debbie, maybe some of the technologies have, but I think for the most part, technology still has a lot of work to do to keep pace with the environment in which businesses are working in terms of cloud and the adoption of AI technologies.

Debbie Reynolds  04:38

I agree with that. I think, and I love that you said that. Data protection or data mapping and things like that tend to have been project-based. I mostly think of it as event-based. So it's like something happened in a company that said, okay, we've got to scramble and try to figure out where this data is because they need to do something with it. So, because of the rise of regulation, because these regulations are requiring more transparency with companies, with how they deal with data, they have to try to find a way to build this type of data hygiene into their business practice, right? So it's not just like, okay, well, something bad happens when now we need to map data, it's like, well, you need to always know where your data is anyway. And also, I think, probably one of the most difficult things that companies deal with, and I want your opinion on this, in my view, is around data deletion, or complying with things like a right to be forgotten, because companies have traditionally just gathered data and never had to answer for what was happening with the data at the end of life. So it's like, let's gather all the data. But then let's keep everything, and I believe anything; what are your thoughts?

Padraig O'Leary  06:01

So I think right to be forgotten; I think this is a particularly difficult technical challenge for most organizations; I think there are a variety of reasons. First, I think in just in so many organizations, the a lack of an accurate data map in the first place. So even not being sure of where the starting point is, for many organizations is probably the biggest challenge. Because if they don't know where the personal data is residing, then how can we even think about strategies around the erasure of that data? We do quite a few Right to be Forgotten projects, or we helped a number of companies with their Right to be Forgotten capability. I think one of the lessons we've learned is this kind of like, let's say, trying to build this big switch solution, where you initiate a Right to be Forgotten process. And then this kind of erases the data across the different systems. But generally, these projects start, or they get clogged down with technical complexity with personnel changes, with different, I suppose changing priorities within the different teams that have been involved. What, I think I've seen work best is when companies take a more flexible approach to Right to be Forgotten project, which means that first, you identify data repositories which are affected, so which are the data repositories for this same data subject that are going to be affected by this right to be forgotten request, and then working with the different stakeholders within the organization, the data repository owner, then for each individual data repository, defining the strategy that is the best fit for that data repository. And that strategy is going to depend on a myriad of issues around, I suppose, the data architecture, the motivation of the team, the cost-benefit, and the ROI for building any type of automation around this. And so often, what we find is that organizations around this almost automation roadmap around Right to be Forgotten requests were, first what they're running is they're trying to orchestrate a request like this, get an overview of the request, and identify where the blockers are. Then they can start to see and isolate individual points within the process, where investment in automation are investment in data engineering resources, to get the ROI from that investment to start to pay off. So yeah, Right to be Forgotten requests, I suppose a favorite technical challenge of privacy engineers. But I think the most important thing here is that there's no magic bullet; you need flexibility. And automation. And engineering is not necessarily always the right solution. Sometimes the right solution is, let's say a JIRA ticket to the right person or communicating with a particular stakeholder and then tracking the manual completion of a task around that Right to be Forgotten request. And then of course, sometimes it is automation and hardcore engineering from the very start.

Debbie Reynolds  09:16

Yeah, I agree with that. When I talk with companies, I advise them who are creating these tools; I have to remind them I'm like some of these requests can't be done with automation. Yeah, some of the things you're asking me for, right? So you have to consider that when people are bringing on tools, hey, this isn't going to be like a silver bullet for everything that you need. It depends on their data system. I want to know your thoughts on the challenges between structured and unstructured data. So, for people who don't understand data, they say, hey, we have this data problem. And they think you're going to come in with a magic wand and plug something in, and all of a sudden, their data problems are going to be over. But we all know, when you're entering enterprise, and you're doing things like data mapping, and you're trying to figure out what their strategy is, you have to have a different strategy for structured and unstructured data. So, can you tell me a little bit about those challenges?

Padraig O'Leary  10:17

Yeah. So I think in terms of the right to be forgotten, or, or even just in terms of anonymizing data, I think within structured data, in some ways, it's a nice challenge. Because sure you have some considerations around maintaining the data integrity. So when you go in, it's not just the simple case of deleting a particular role. But you have to consider the overall data architecture and the context in which you're deleting unstructured data for unstructured data. Yeah, it's a whole other ballgame. I mean, the challenges with unstructured data are many. I think it was actually earlier this week, I was reading a really interesting paper, and it was around anonymization of unstructured data. I think the point was that true anonymization of unstructured data could be the argument that it was almost impossible because for unstructured data, in order to guarantee that that anonymized data could not be linked to the source data, due to the context of the words around it, or the data around us, then that unstructured data will become unusable in any use case that you would want to do something with that unstructured data after the return on the personal data had been anonymized, or you had somehow managed to go through a right to be forgotten request. So I think for unstructured data, much harder problem, there's no silver bullet, and like a risk-based approach and risk-based approach, sometimes tooling around PII identification can help. But in nearly most cases, you would still need some type of manual intervention before you could say any exercises is anywhere near complete.

Debbie Reynolds  12:04

Yeah, unstructured data is tough. And then I think people also don't understand deletion either, right? Because let's say your hard drive you delete a file; the data isn't really deleted; it basically deletes the pointers to that data so that the system can find it. But smart people can find that data.

Padraig O'Leary  12:26

Yeah, so that's very true, Debbie. So, if this concept of like physical deletion versus logical deletion. So logical deletion is where you turn a flag, and then you, let's say, would hide that record, or physical deletion is where you go in. And you're insofar as you can imagine that you're actually erasing the data within the physical memory in that location. I think a good instance of this is what you sometimes see; let's say I think HubSpot has a good example of it where HubSpot has an arranger in place for a customer record or a personal record, a CRM record. And then they have these compliant arrays or endpoints. And the difference here is that one is using logical deletion, where it is just hiding the record. And sometimes, it's hiding the record. But then, in some cases, there might be some logic after 90 days where the record is destroyed. And then the second endpoint is physical deletion, where they're describing that they would then go in and they would immediately physically erase that data non-recoverable way, from their systems.

Debbie Reynolds  13:36

A little bit about the complexity of people's environment, especially when the data is duplicated in multiple places. So let's say someone says, okay, well, Patrick, go to this repository, you'll find all Johnson's data. But then, as you investigate, you find out that Johnson's data is sprinkled in other places. So, how do you work with companies on that challenge of being able to track down possibly duplicate information? I don't know what your experience is; I had to do a data mapping for, it's embarrassing to say how long I've been doing it, okay, for a very long, long time. Okay. But what I find is, when you talk with companies, you ask them about their data systems, where you actually touch the data and look at it, obviously, probably not the way that they think it is. So there's a gap between people's knowledge or the knowledge and the organization about how their data is actually put together and what actually happened. So, a lot of times, you find a lot of duplicative information. Things aren't as neat and clean as you would think it would be. But tell me, how do you work through those challenges for companies?

Padraig O'Leary  14:52

So generally, Debbie, we wouldn't work on the level of the actual, let's say, on the data infrastructure at some level, or we would very rarely do that. I think there was a reason for that, which is at that level, I think it needs to be the internal team who would implement or execute on those, let's say processes, because really, they are the people who have, you know, the knowledge of the system, how it's designed. And in order to ensure that you know, the reliable execution of a particular request, then it will relay the internal, let's say, be data infrastructure team or data engineering team who would execute that request for what we would generally work on, I think we're like a level higher than that. So we would work on the, I suppose, the collaboration layer. So we tend when we work with organizations, we're building, let's say, the flow of execution, or the process or the operation across the organization. And then, we're orchestrating the execution of that request across lots of different data repositories. And for some of those data repositories, if there is an internal data repository with multiple backups, then that orchestration would be using an API. So, we might work with the engineering team on the side of the client to define, let's say, an API that they would design and build to ensure the execution of that data repository. Then, we would track the completion of that work in terms of the overall process, for could be a right-to-be-forgotten request.

Debbie Reynolds  16:35

Why don't you tell me about how Trustworks differentiates yourself? We know that the market now, as a result of all these privacy regulations over the years, has gotten a lot more crowded; I think it's a lot more difficult for people to differentiate one product from another. But tell me, what is it about Trustworks that makes your product unique?

Padraig O'Leary  16:58

I think this perspective around, let's say, that there's a lot more solution providers out there; I think this is just a sign that as a community or as a discipline, privacy is maturing; I think this journey for the past five years. And there's a lot of different needs out there in terms of privacy solutions, as well as different types of privacy teams, a lot of different types of organizations. The idea that there could be one privacy program solution that is a like one fit for all, it's a fallacy because the only way that you can provide from multiple use cases or multiple different types of contexts is that you add a lot of like configuration, and so within the tool, right, so it can be customized to every possible use case. But the cost of that customization is effort and complexity on behalf of the user. In our case, I think our objective is to bridge the gap between privacy and other teams within the organization. We emphasize collaboration and this collaboration framework that we baked into the product. And I think because of the users and the community of privacy professionals that have worked with us, we have been very opinionated in how we think a privacy tool should work. And I think that opinionated solution drives certain choices in how we've designed a solution, where we're emphasizing time to value simplicity, responsible data discovery, and automation when it makes sense. And at the right time for the privacy team. Yeah, I think we still have like one of the main drivers; in some ways, I would have always thought that five years on from, let's say, GDPR, one of the main drivers for businesses to adopt a privacy tool would be customer pressure, or like subject pressure, individual pressure. In actual fact, and maybe it's slightly disappointing, but I still feel that probably the main drivers for companies to build the privacy program is still driven by pressure from business partners. So, this kind of b2b pressure to have a strong data protection program to be good custodians of the controller's data. And yeah, and so definitely space for Debbie.

Debbie Reynolds  19:20

I agree with that. I tell people a lot that this is happening in the US as well around the adoption of different tools and techniques to be able to protect data. A lot of companies don't want to do this; the impetus a lot of times is business associate pressure, right? So I see that a lot. Where else, say they're a company that wants to sign a contract with this big company supplier, but they need to be able to show a level of maturity in their data handling. So that's a pressure point for them to give a tool. Maybe they've seen a competitor in there. Bass, maybe they've had a bad experience in some way. And that, in some way, can be a pressure for people to get a tool and then sell. So I've seen a barrier for companies; let's say they want to sell their product with a certain jurisdiction. And they can't because they can't really show that data maturity. To me, those are like big pressure points. I've not yet seen someone say, oh, my God, like GDPR came out. Now we need to, yeah, why a tool, you know, saw, I think a lot of it has been much like a wait and see type of thing or like, let's not jump in and do this. But I think the complexity of the regulation and the complexity of the business process, especially as we see these bigger players being able to push down a lot of requirements for the smaller third-party companies, it really is becoming more of an issue. So, to me, that's where I see people want to really get out there and want to be able to adopt these tools. I agree. I want your thoughts about AI adoption. So companies now are very excited about AI, even though AI isn't new. But I think just the news reports about it. And with all the investment that we're seeing in AI, especially around Generative AI, there are a lot of companies who aren't even super data mature, they want to ride this excitement wave. And they want to find a way they can implement AI, or they may have existing tools that are implementing AI parts to it. But how does that make your work more complex? We are working with companies.

Padraig O'Leary  21:52

I see one of the biggest challenges at the moment for organizations is AI creep. And I think, over the last few years, how companies are adopting tools has changed. I think the best example of that, or the classic example of that, is Slack, right? Which was like product-led growth, where they pushed bottom-up adoption within an organization rather than top-down; I think this bottom-up adoption can be very dangerous when we come to the realm of AI. Because we can be quite far into our AI journey without ever having considered as an organization, the risks associated with this. And then the second element is this. When I talk about AI creep, it's, let's say, products that have been used in organizations for years. And then suddenly, they're releasing this kind of AI-powered functionality. We had a recent example of this where we were doing a data mapping exercise with an organization the scale up. And there was a number, well, a small number of the systems that were used in HR had AI-powered functionality within them. So you would never have considered them AI systems. But they did have AI-supported functionality within them. And so depending on the context of use, so hiring employee evaluations, suddenly this organization using AI for performance reviews of that, and there was no decision, there was no assessment that we're going to go down this route, it was just, it was creepy. It was by nature and the tools that they were using that privacy professionals and privacy teams there were going to have to build a second data map. And it's hard enough to build the first one. The second data map is the AI power data map. So, it's not necessarily an AI system. It's the list of those systems that have AI capability baked into them. And as we know, if you're using Cloud, then you know that more and more of the tools that we use every day have this functionality baked into them. So I think that's the challenge. On the other hand, I do think, like a lot of the conversation around MLMs and AI is within the privacy community, that I think we're very negative, and we're very focused on the risk which, which is understandable, right, because the risks are great. But there's also a big opportunity for us as a community as well in how these tools can improve our work and make us more efficient, like they're making other departments within the enterprise more efficient. And so I also think there's a second conversation which should be happening around the future role of these types of technologies within our everyday work right as privacy professionals.

Debbie Reynolds  24:41

I've not heard anyone describe what's happening that way in terms of feature creep, and you're absolutely right a thousand percent. What I've seen a lot of companies say like they're afraid of AI, and they put out these bulletins saying, we don't want anyone to use AI, so you're forbidden from using these AI systems. And they're thinking about people putting data into these public LLM systems and things like that. But they're not thinking about the fact that the tools they already use are being embedded with AI capability. So now let's say, for instance, in the past, you have done, quote, unquote, automated decision-making. Now, you have tools that allow you to do that. And I think you're right; I think companies will have to have, like, a second data map because they have really anticipated that within their own organization and the tools they use every day, there's now these new embedded capabilities that are probably creating automated decision-making capabilities that maybe they didn't anticipate that they thought they didn't have before. But now they do.

Padraig O'Leary  25:51

Yeah, and sometimes these don't come wrapped in a this is an HR recruitment tool. Sometimes, it can be more of a generic tool that is being used in HR. Right, it could be used in lots of different departments, but HR using this tool, and this has AI functionality baked in. So I think that's the danger. And so that's this second data map, maybe you call it this is your like aI data map within the organization is going to be just as important as your traditional data map that you're building. Yeah, I mean, I think one thing that I would like to see or expect to see is within this tooling, particularly like enterprise focus, tooling, is like a kill switch for these type of capabilities. So I think like, companies are very quick to kind of push them into the product, because they're great for marketing. And they are amazing in demos, we've explored them because we just see the potential value that they can deliver. But I think there needs to be an easy way to turn these off. So, like this kill switch functionality, which allows you to not just tell someone that they shouldn't be using it, but baked into these products, there needs to be some way for on an organization, that count level that they can switch this type of functionality of.

Debbie Reynolds  27:12

I agree with that wholeheartedly. Instead of it being a thing that makes it hard, it's baked in in such a way that makes it harder for people to not use it. Like you say, don't touch the stove, because it's hot, you know, something like that. Just turn the stove off, right?

Padraig O'Leary  27:27

Yeah, yeah, yeah.

Debbie Reynolds  27:30

So if it were the world, according to you, Padraig, and we did everything that you said, what would be your wish for privacy anywhere in the world, whether that be regulation, technology, or human behavior?

Padraig O'Leary  27:46

Yeah, I think for privacy professionals, I think we, as a community, we still have a long way to go. I think until privacy professionals have privacy, professional teams have, let's say, the level of training and the diversity and background that they need in order to meet the challenges of privacy. I think privacy as a whole is a unique space because you're bringing together legal, technical, and operational skill requirements. But then you also have ethical considerations, which means diversity in background is almost as important as diversity in skill sets. So I think we're only at the start of the journey in terms of preparing privacy teams to be, let's say, having the breadth of skills and diversity that they need in order to function to meet the needs for most organizations. That's our big challenge going forward. I would still say it's on the personnel level. And yeah, my wish for privacy would be that, yeah, more people into privacy, more people from diverse backgrounds, diverse industries, get to build that diversity into privacy, I think.

Debbie Reynolds  29:04

I agree because when you work in these areas, you could definitely see the gaps. You can see where companies can definitely benefit from having a more well-rounded team of people who understand data and the different angles that data challenges take. So I agree with that completely. Thank you so much for being on the show. I'm really happy with all the work that you're doing with Trustworks, and keep commenting on LinkedIn. I love your commentary and the wise words you leave for us; I think it's amazing.

Padraig O'Leary  29:42

Thank you, Debbie. And maybe just to finish, I'm very happy to announce that we are launching at IAPP Brussels. So, anyone who is attending IAPP Brussels, please come and check us out, and we'd love to have a conversation.

Debbie Reynolds  29:57

Perfect. Perfect, exciting. Very exciting times for Trustworks. Thank you so much for being on the show, and we'll talk soon.

Padraig O'Leary  30:06

Okay, thank you very much, Debbie. 

Debbie Reynolds  30:08

You're welcome.