 For this opportunity to come and talk to you today about data governance and privacy, and so I am Julie Park and I am the manager of a global data privacy program and a data protection officer for the Church of Jesus Christ of Latter-day Saints. I have over 20 years of experience working with data and have worked in the fields of information security and information technology auditing, and over the last 12 years I have been primarily focused on data privacy. My name is Paula Olson, I work with Julie at the Church. I am a technical program manager with more than 30 years experience in data management in the fields of information technology, higher education, health care, and I have spent the last seven years with a primary focus on data privacy engineering. We are, so we appreciate you being here today. We bring our experiences, we represent our organization, collects processes and manages data in more than 200 different countries, and our headquarters of course are based in Salt Lake City. Great. So before we get started, I just have to take care of a quick disclaimer. The opinions expressed in our presentation and on the following slides are our own. They do not represent the views of the Church of Jesus Christ of Latter-day Saints, and we are not providing legal guidance or legal advice. And I may sound like I'm attorney when I talk, but I am not an attorney. So now with that out of the way, let's get started and let's talk about embracing the disruption of data privacy in a governance program. So super excited to present on this topic. When we tried to put a title behind it, we wanted to bring in that word disruption. And when we sat back and we thought about, you know what disruption means to us? We're at a very unique crossroads in the data privacy world, the data governance world, the data security world right now. And I want to kind of lay that foundation for what our environment looks like. So first of all, let's talk about data and technology. We have tons of new technology being developed all around us, and we're collecting data in different ways than we've ever been able to collect it before. And we're using it in a lot of different ways. We expect, and the experts are telling us, that the explosion of data that we're collecting is going to exponentially climb over the next 10 to 15 years. And can you imagine what life is going to be like if that information isn't organized in a way that we can respond to data governance and data privacy laws around the globe? Now let me talk to you a little bit. That's the first factor, just this explosion of data. The second factor is the expansion of all of these data privacy laws that are going global. When I looked at this map seven years ago when I started working with Julie, there were just a few dots on the globe. Now we have nearly a fully colored globe, and regulations are wrapping up, they're turning into laws, and we have to respond to those laws. And so if you're doing business in any of these countries, and you need to govern data, you need to be aware of what those laws are and how it impacts the data that you're collecting that you're using and you're processing. Now the third disrupter, and when all three of these collide, it's going to be quite a whirlwind storm for us. But the third factor here is people. And people beginning to recognize that they have rights and they want to begin to exercise those rights. So in the GDPR we call those data subject access rights, and in other laws they're named something very similar. But as people begin to exercise those rights and request businesses and organizations to inform them of what data they're collecting, how it's being used, collected, processed and stored, it's going to change our world. And in fact, we're already seeing it in our organization. Those requests are doubling every year. And we stepped back and we said if we didn't make a few changes, automate some of our processes, put a few more controls around our data, the price tag for executing those requests moves into the millions of dollars. So think about your bottom line a little bit as you think about having to respond to these requests. So again, massive amounts of data, more and more laws are coming in and people are going to start exercising those rights. So those tectonic plates are going to come crashing against each other and that's that tsunami effect that Julie and I will talk to. So with that being said, that's kind of laying the foundation for our presentation. I'm going to have Julie talk to you a little bit about frameworks and how we organize ourselves from a data privacy perspective and how they marry up quite well with data governance frameworks. Yeah. So before we do that, I just wanted to do a little level setting. How many of you are wearing multiple hats where you are governance, privacy and security? Okay. So there's a few of you that are wearing. How many of you are security professionals? No. One? Okay. How many of you are focused only on privacy? None. Okay. And how many are focusing only specifically on data governance? Okay. So our audience is really all data governance professionals. Okay. Great. Thank you. We just wanted to kind of get that level set. The concept of data privacy has been around for a long time and I think depending on if you go into any privacy training, you'll see that or you'll hear about the Louis Brandez right to privacy and the concept of privacy or autonomy has been around since 1980s, sorry, not 1980s, 1990s. So then these frameworks, you cannot talk about privacy without any of these frameworks coming up. So the first internationally recognized framework was the OECD and that stands for the Organization for Economic Cooperation and Development. The purpose for this was just to recognize that in order for commerce to work for businesses to make money, there had to be a free flow of information. And when it was dealing with information about a person, they wanted to recognize that there are fundamental human rights about how personal data is shared. Well, when the OECD was established in 1980, then Asia Pacific followed suit and then soon after the AICPA or the Association of Public Accountants, they also established different frameworks. It used to be GAPP and now it's called the Privacy Management Framework. They've all aligned with these principles and we're going to go through these principles in just a minute. But again, we can't get to this point in 2021 without everyone has heard about GDPR, right? We all heard about it. We all know that it's almost making, because the only reason why GDPR is we're familiar with it now is before it was a self-regulatory guideline. And that's when it was a directive. In 2016, it was changed to a regulation which made it a law. It put some teeth to it. And now because the general data protection regulation is a law, there's fines associated with it. Now everyone's starting to pay attention. All right, now these principles, these principles are not new to any of you as data governance professionals. These are all common principles that we see about how to manage data. When we're talking about data and we're talking about privacy, a lot of data is about a person. Lots and lots of data are about personally identifiable information. The definition of personal data is very, very broad. And so it's important to understand that personal data is any information that can identify a person directly, my name, Julie, that directly identifies me, or indirectly, red hair, black and polka dot address, my voice. If it can identify me indirectly, that is also personal data. This is important to understand as you're applying these principles within your organization. Now we're not going to spend time going through these principles. I know that there's other trainings that have gone through these principles and did a great job explaining them. So we're going to just focus on what did we find as we've gone through and lessons learned, how are being some disruptors in data governance and sometimes, and I'll let Paula speak to that, what are our disruptors or the ones to embrace? Because we're talking about embracing privacy here, so we'll talk about what, how principles to embrace. Julie, why don't you go ahead and click through that until we have the complete list up there really quickly? And I do that just because we've had some great discussions in our keynote and in the presentation that I attended before. This one talked a lot about these principles and how many times they're misunderstood. They're interpreted in different ways, whether you're the security expert, the privacy expert, or even the governance expert. We spend a lot of time in our organization sitting down, collaborating on these terms in our various specialties, and deciding what these mean in our organization and how we act or react to these terms. So again, they're often misunderstood and sometimes just completely forgotten. But with privacy, being an up and coming specialization and us needing to be more mindful of it, we need to clearly understand what these things mean. So I'm just going to point out a few of them. So for example, lawfulness. Lawfulness means that you have to have a legal basis for processing an individual's data. So you're doing business and you bring that data in and you process that data. You've obtained their consent or you've provided a notice, maybe you have a contract or you have another legitimate interest for collecting that data. As you hold on to that data and use that data, you need to keep it in that context. No secondary use of that data. And we're going to talk a little bit more about secondary use as we move on. Another one that has been a little bit challenging to particularly get our IT teams to embrace is the concept of privacy by design. It's, we pull teeth a little bit to help our developers know and understand that as they are designing and building new technology, that we want to take those privacy considerations into account upfront and develop them right into the technology. How do we obtain that consent? If we are collecting this data, are we going to share that data? Can it be used in other ways? Lots of different factors that we consider as we set up and build new technology. And we want to make sure that we manage that technology through its entire life cycle when it goes into development and then when it's decommissioned, how do you dispose of that data? How do you dispose of any of that data that's been shared or pushed downstream? What do those connections look like? All of that has to be considered and I hope through our presentation, you'll, as we build upon this, you'll understand more as to why that's so important. And then last but not least, I'll just hit on transparency for a few minutes. People have a right to know what we're doing with their data. Although they choose to do business with us and we collect their data, they do have the right and the laws are giving them more rights to say, I want to know what you hold. I want to make sure it's correct. I want to make sure that only certain people can access and see that data. This is what the laws are giving them. And so we want to be very transparent with them about what we collect and what we do with that data. Another big one is access. And access many times means something very different than what we in general think it means. So I'm gonna have Julie talk to you a little bit about access. All right, so access. So I've been giving trainings and talking about privacy over the years. When we'd always get to the principle of access, everyone would start thinking, oh, that means access to a system because we're always in the mind of security. So the principle of access, which in some of the frameworks refer to it as individual participation, the principle of access is that it's a fundamental human right that an individual can access the information that an organization collects and holds about them. And so it's really important to understand we recognize privacy as a separate and unique discipline from data privacy. Sometimes we may use the same words but they don't always mean the same thing, which was the perfect Princess Bright effect that was a wonderful presentation just before this one. And so this is one with access. We also find that the case. So the principle of access or individual participation, again, is there are fundamental rights that individuals have. When an organization collects information, they have the right to say, I would like to access the information you hold about me. We'd like, I'd also like to request that it is either it is erased. So an individual can ask that their personal data be erased. They can object to the further processing of that information. An individual can also request that it is portable, meaning it's provided in a format that they can make, then go and transfer it to another organization. With data portability, that does not mean an organization has to go to great lengths and then go to extensive, expensive costs to provide data portability. There are reasonable checks in place on that principle of data portability. And then the last one is automated decision-making and profiling. And I just wanna say as we are adopting these principles, which they seem so simple and so basic, but when you start getting into the actual application and actually seeing how this works within an organization, it does take a little bit of work cooperating with data governance, with security, and with privacy together to really correctly implement these principles and how it should work within an organization. But again, given the potential impact on individual rights, I also wanna pick out the principle of privacy by design. When you are working with access or individual access, if you can incorporate the principle of privacy by design and make it easier for your interactions with your users, your consumers, it can also increase their trust and make it so much easier. So again, continuing to build upon itself in every principle, we do find that you have to kind of work within each of those principles and privacy by design is a very good example with access. All right, so then. Well, let's go back for a minute. Okay. Let's down that slide for just a second. I just wanna give you a chance to maybe get a fill for the audience or for you to ask some questions here for just a second. In the organization I currently work with, our data governance practice seems to be driven more by our IT and our technology teams than it does by our business side. So there's definitely a weighted influence to how our previous governance program worked to the direction that we're headed today. But as you think about your own governance programs, is there anything on that list that is going to impact you or on anything on that list that's going to impact you or that you need some thoughts on? Great question, you wanna repeat that, Julie? Yeah. Well, repeat it and then I'll try to answer that. Okay, so she just said how do, when you get a subject access request that comes into your organization, how do you make sure it's appropriately handled and triaged through the right organization? So one way to do is have one centralized location where all requests come to and making sure that it's monitored daily. But if you can have a way to automate it as much as possible and there are vendors and tools out there that are available that you can direct people from your privacy notices or in your websites to submit a subject access request through a web form and then that can help automate and simplify and clarify what the request actually is about. And then the way that it's vetted is generally how the privacy office in coordination with legal and IT, together you have to, that is the best way to make sure that you're responding appropriately to those requests. It's a very important to include your legal counsel in evaluating the requests because sometimes individuals may misunderstand what a law actually, how it's actually applied or it also could be you want to coordinate with the information technology team to make sure that you correctly answer the question and provide all the right information. Yeah. Yes. Yes, and that's one thing that's what, and I love that's a great segue because where we, what we want to talk about is our lessons learned and how can we effectively and accurately respond to subject access requests. And again, this goes back to the title embracing privacy into data governance. And I'm gonna transition to Paula because for the first thing, these are the lessons that we've learned for us to quickly and effectively and correctly respond to subject access requests in addition to requests from governmental agencies, there's data protection authorities that ask organizations to attest their compliance to data privacy laws and regulations. Well, if you don't know where your personal data is or where then how can you effectively respond to that? In addition, if it's not classified in a way in a way that's meaningful or aligns with the policies or the laws, it's also makes it very difficult for you to respond. It takes an unusual, an unreasonable amount of time but we are expected as all organizations as we know with having to deal with GDPR, the California Consumer Privacy Protection Act and others that are coming, it is the responsibility of organizations to be able to respond to these questions. And so Paula, I'm gonna have you just kind of go through starting with the data inventory. So I think we'll answer your question in more clarity with the next couple of slides and it's a great question. Thank you for asking it. It's a great transition. So really, one more question. Oh, go ahead. You're giving data on why people ask this data about their personal data. So if individuals contact you, do they get any of the reasons? Yeah, usually. There's various reasons but usually it's some people just say I just wanna know what information you hold about me. Some individuals, especially when we start talking about and I'll talk about this later but in algorithms, predictive modeling, individuals wanna know because if there's an outcome that has a negative consequence for them, let's just say for an employment, if you have an algorithm for hiring an employee and someone gets scoped out because of some factor and your data set was wrong, the individual would want to know what information do you hold about me where one of the data inputs inaccurate or incomplete which resulted in me being disqualified for being considered for a candidate for a job position. Some individuals wanna know, hey, I wanna know what you had so that if it's inaccurate or incomplete, I wanna make sure it's right so I get a fair chance to be considered. And so that would be a reason why individuals want to view and access the information held by organizations. What about rules around the right to be forgotten? In other words, you request to have your data and profile for a two separate effort? Yeah, so that's a good question. The right to be forgotten or the right to erasure, rectification and erasure, it's important to remember that facts cannot be erased. So the right to erasure is not an exact exact because if you owe a bank alone, you cannot ask for the erasure of the fact that you owe the bank money. And so the exercising the right to erasure cannot be the right to erase the fact or history of what's actually happened in the past. The right to erasure is just saying I don't want my information in within an organization from this point forward or for onward processing, but again, the right to erasure does not apply to erasure of facts. Or historical facts, yeah. Just, I'd like to expand on a little bit. Yeah, thanks. The right to erasure is very limited. It basically, it enforces the retention obligations of an organization. So largely the right to erasure in less-care social media company is if you don't have a good lawful reason to keep the data, but the data subject can say, stop keeping it to get rid of it. So it's very limited. Yeah, very limited. And I like that. And I'll just say it one more time. If you don't have a lawful basis for keeping the data, that's the criteria. So removed. So that is the request for restrict processing. Yep. You can ask that it be stopped for restrict processing going forward. You can't, it's hard to erase the past. You can't do that, but going forward, yes. So one more question and then we will move on. Okay. Yeah. Sometimes it comes in the S-C-R-A, right? What's the S-C-R-A? S-C-R-A, the federal government. Oh, right. You know, ours are the requests that we have, I have not seen fair, because we are not a public organization like a government, and that's usually a governmental agency gets those for our grandma requests. Yes. And governmental agencies are subject to that Freedom of Information Act. Yep. Great, great question. So we're gonna just proceed and move on to our lessons learned and how do we respond to these requests quickly? Yeah, Paula. Okay, so we're gonna talk about lessons learned as we worked with our data governance team to kind of marry our practices together and work a little more smoothly with each other. So the first thing that we did is we recognized that we really did need an inventory of all of our data. And that's really more than just an inventory of your systems and the metadata you collect. You have to associate additional metadata with that data so that you can understand what laws apply or how it can be used. So there's a number of additional metadata elements that we've started adding to our catalog and to our dictionary that makes it much more helpful for us to kind of drill down and associate and respond to data protection officers around the globe, et cetera, et cetera. So we're gonna talk a little bit about what that means. You know, it's a great time to revamp your metadata standards and practices. So if you're not working with your IT teams closely around the way they design and develop metadata in systems, it's a good time to reconsider that. And for us, in our organization, and I assume a lot of you are making plans to transition to a lot of cloud applications where your data will be stored and held in the cloud. And sometimes that requires a change in format to your data, you move from a structured to a semi-structured environment. Be mindful of those changes in your data and make sure that your current plan can adapt to that. We talked about critical data elements in our keynote this morning. We're gonna talk a little bit more about some of the considerations for privacy around critical data elements as well as some highlights around data lineage proliferation and then AIML. So let's start with what's in your catalog. I want you to reconsider if you're practicing just general data governance as we've been practicing for the last 10 or 15 years or more, times have changed. And you know, I've been working in data for 30 plus years and as I started to work with Julie and we were evaluating all of these legal requirements around privacy, we recognized that we needed to really ramp up our information. And the more we ramped up that information, the more valuable, the more enriched the data became and the more valuable it became. And Julie and our legal team, they just drool now over the reports and the information that we can give them. So think about what's in your catalog and we gather this information about our systems and then our data. So we know and can clearly identify what personal regulated and governed data we choose to govern within our organization. It's laid out nicely and we can find it across all of our systems. So you know, the average company has, what did I read last time, 317 different applications. We have several more than that, a few hundred more than that. And some of you may not have that many but you've got data everywhere and you're gonna have more and more of it everywhere. So you need to be clear on who controls the data. If you have more than one controller, you need to be clear on who that controller is. If you're working out of different countries and you have different legal entities in different countries, you probably have more than one controller. You need to know who's processing that data and for what purpose it's being processed. And again, as I mentioned before, if you collect it for a certain purpose, you shouldn't be using that data for any other secondary purposes without at least notifying your customers and in many cases, you have to obtain their consent. Who is the data shared with as data governance experts were great at that? But where is it stored? Part of our inventory is knowing physically where it's at, how it's secured, what those security protocols are, Julie's constantly submitting reports to data protection authorities around our protocols that we use for security. We need to clearly understand data retention and we all know that that's a tough thing to do. And then in our data, we know how to go and search and find data that is about individuals and we are learning to better be able to provide that information to them in a timely manner so that we can act upon these requests that Julie's been referencing. So if some of this information isn't in your catalog, you might wanna think about how you can incorporate it in the catalog as metadata. It's very helpful when you're searching for certain types of things. Julie, let's go to the next one. Our organization, again, I mentioned, has decided to step back and look at our strategies around the management of metadata and I'm not talking about just the governance strategies. We are working closely with our data scientists, our data engineers, our data analysts and we're saying, you know, we're planning to migrate to the cloud. How do we need to adopt or adapt our current practices? So as this data begins to swell and grow and expand and we hope that it does, we all do. You know, we all want thriving businesses or thriving operations and we know it's going to grow and expand. What do we need to do to make sure that we're good for the next 20 or 30 years? It's really a great time to reconsider practices because the way we use technology and data today is very different than five years ago, 10 years ago, 15 years ago. We've made a number of changes. So like you, I'll let you read down this list. We know it's valuable. We want healthy and better practices. We focused on really identifying the critical data elements that needed to be governed. You can't govern everything as it grows so figure out what you have to govern and only govern that. Evaluate your structures and then figure out how to monitor that personal regulated and governed data. Not an easy task, but with automated technologies and some of the scanning tools that we now have. If you have the right standards in place, your ability to go out and search for and find that data is significantly improved. And we're starting to proof that out within our own organization and having great success in doing so. Okay, and so what was mentioned in the keynote was talking about critical data elements. And we've also found that that has been really, really helpful. One thing I will mention also that Paula had said, I don't know if I've ever said I've drooled, but I always said I was about as happy as Christmas. When we've been able to organize the data and classify it in a way that I can quickly respond and answer questions about what data is held, how is it used, having it all organized in a way that what's in our inventory or the catalog has been just tremendously helpful. And so I'm sure every organization, if you don't have a data protection officer, they're going to be coming to you and saying, hey, I need these reports, I need this information and I need it at my fingertips. So for us to, for any data privacy officer, they're gonna be saying, okay, why don't instead of inventorying, I don't, you know, we don't care about inventorying all the data, focus on the critical data elements, and then that's the most meaningful and relevant and demonstrating compliance for an organization. So one thing that something to consider is first off, inventorying data that is identified as information about a person. And I think it's surprising to see how much information that is held is about a person because the definition of personal data is so broad. We also recommend counseling with your legal counsel, your attorneys, to identify when you have information that is protected by a law or regulation. Because even if it is personally identifiable, sometimes you also have additional laws, there's employment laws that need to be considered and that can include on, that will be included in your critical data element list. Another thing of lessons that we've learned is that doesn't catch everything for critical data elements. Sometimes there are critical data elements that are not about a person. It's not regulated by a law or, it's not protected by a law or regulation. But the organization, it's important to the organization. So we have found that including that on what we call a critical data element crosswalk has been very, very helpful in identifying those different categories. So the data privacy office, it might be the best place to start is having the data privacy office determine what is personal data, having legal determine what is regulated by a law or regulation and having your data stewards or the business decide what needs to be on your crosswalk as a critical data element according to policy and standard. Now with that, building upon that, taking all the information, if you look at all the different data protection authorities and they have different forms everyone uses the different words just like the frameworks that we talked about with OECD and Asia Pacific and AICPA. They all use different words, but they kinda mean the same. And so one idea to consider as you're organizing your data and creating an inventory is to come up with a common terminology that is easy for you to map to whatever data regulator is gonna ask for. Again, this is not going, this is just a suggestion, just not this probably won't work for everybody's organization but come up with your own list of what will work. But the key is have it set up in such a way that it can easily be mapped to however other countries classify data types or they call it categories of data. And so you can easily do those reports or answer those questions quickly. The other thing to consider is we recognize that there are thousands and thousands and thousands of data elements out there. But only a handful, well there'll be many, but not all of those data elements are going to be critical data elements. And so something to consider also is scoping out anything that's not a critical data element and focusing all your time and resources on what are these critical data elements so that that can be a more mature, modern data governance program. It also will help facilitate automating responses to data protection or data subject access requests in the future. So building this framework and having these data elements roll up to the sub, this like a name is a subtype. The name rolls up to basic contact data. That would be an example of how that would work. But this has been again really helpful and that takes a lot of work on Paula's side or on the engineering side to make sure all those data elements are correctly classified and rolling up to these reports. But these are the reports that your data privacy officer will find incredibly helpful to have at their fingertips to respond quickly to any type of request. Anything else you wanna add to that Paula? Yeah, I'll just say in the keynote this morning I loved that presentation, it was well done. But at the very end, we talked a little bit about how we gather those critical data elements and it was suggested that we do that via Excel spreadsheet. I disagree. We started with spreadsheets. We then started with assessments. We now scan our systems and pull in our metadata and apply a number of regular expressions and if you were to rely on your spreadsheets I'm gonna tell you right now at least we found within my organization we were at least 25% of the time wrong. We claimed that we held data that we didn't hold and there was a bunch of data that we were holding that was completely overlooked. It's time for all of us to find a way to move into more automated processes and as overwhelming as that may seem having kind of swam through that swamp over the last five years, it's doable. There's great technology out there and if you are well organized within your organization it's much more simple than you can imagine. So if you ever want some ideas I'm happy to share some thoughts and ideas on how we made that happen for a very, very large organization and it's working. If we can do it, you can do it. All right. Well and I just wanna emphasize enough how we did learn that with the first pass and it was just one snapshot in time. It's really hard to be able to trust that because I come from an auditing background and I love the ability to go and actually get, I know that you go into the system you can scan exactly what's in that database rather than on something that someone just self declared. That just increases the confidence in the inventory of your data and your ability to respond with accuracy. So once we were able to proof out and get those scans that has just really increased the maturity of our program. So we're running short on time Simon and I'm just gonna give you a few thoughts on this. Manage your data lineage to keep in mind that as you plan to migrate to the cloud and you're moving from a structured to a semi-structured unstructured data format you really need to understand your transformations and make sure they're documented so you can keep your lineage intact. There are systems and technologies and these processes that we are talking about has strengthened our ability to do that. So think about that one and then controlling your proliferation within our organization. We're trying to walk away from these hundreds of API connections system to system and find authoritative pass-throughs for people to find the data that they need and that helps us, it gives us better control we're still working on the exact right solution for our down side proliferation but now that we are scanning and on entering our databases we know it's there and so we can connect it. So look for those automated processes and then put those standards in place. If your standards are in place the automation and your regular expressions and the way you scan your data is significantly improved. It minimizes the amount of manual work that you have to do. And again, we're working to bring those standards up because we want a fully automated process five to 10 years from now and it's gonna take that long to actually make it happen. So just know it doesn't happen overnight and there is no one magic tool and any vendor that tells you they can fix it all question that, make improve it but there's great technology out there and if you're willing to work through it you can make it happen. So keep those things in mind. And last but not least let's talk about AIML for a few minutes because it's such a wonderful topic. Yes, you cannot go to a conference without talking about GDPR and artificial intelligence business modeling, right? It's always seems to be the case but this is the future this is where data is being processed how it's being handled and there are privacy considerations that are involved with artificial the use of artificial intelligence machine learning when the inputs are information about a person. And so one thing that's really interesting is I was at a conference in October for a privacy conference in October and there was a movie, the director of a movie it's called Coded Bias. I don't know if anyone has heard about Coded Bias. Really good, it's available on Netflix but it's something to really if you have some time go watch that movie it was amazing and I loved what they had to share about the privacy considerations even the ethical, the protecting of civil rights in the use of artificial intelligence machine learning. One of the examples that they gave on the Coded Bias was there was an algorithm that was created or used to predict the fertility in cattle and then you take that algorithm and use it for a totally different purpose and it comes and it ended up coming out with incorrect outcomes. Well, this is where the price so think about when it's information about you and predictive decisions are being made about you using these models, these predictive models using artificial intelligence. If the outcome is wrong, it goes back to that principle why would somebody want to come and do an access request? Well, what information do you have about me? Is the information accurate? Is it correct? Why is it? Are you coming to the right conclusions about me? And so anytime there's an algorithm that's being used to influence behavior or predict behavior about an individual, their privacy considerations are triggered and that's where you do want to involve your privacy office and if you don't have a data privacy officer contact your legal counsel and make sure that you are evaluating the appropriate and ethical uses. One other thing to consider with artificial intelligence machine learning, if you haven't already, consider your organizations getting a working group together and have it be a cross-departmental, cross-functional working group, want to do an evaluation of the appropriate use of the inputs for algorithms, especially when its inputs are about a person and then come up with guiding principles about the appropriate and ethical uses of data with AI within your organization. There are articles and I'd be happy to provide links to different articles all over about guiding principles and ethical use of AI and what to include in your organizations. Anyways, there's just many, many resources available on the ethical use of AI. So, Julie, I'm just gonna point out this is the one area where we've done privacy by design well and it's because we got, we started this several years ago and we were all over it and our organization has adapted well to these requirements. But it also was possible by having a clear defined definitions that we all agree on, we all understand and having everything builds upon itself but you have to have that foundational inventory and those classifications used across the entire organization for it to effectively work. Yeah, and what's that? So we've got about a minute if anyone has a question and we apologize for going so long. So I'll try to talk loud so you don't repeat it. So one of the things we struggle with is we really wanna abide by we're not gonna use data that we don't have consent for purpose for, right? What advice do you have for us even tracking and keeping track of what consents for what types of purposes have we collected over the years because it's not the current policy or the current consent? Great question. So first of all, current policy, current consent we take those notices and we associate them with our technology that holds that data. And as that data changes or as our notice changes we know how that applies and we can begin to reach out to individuals. Try and keep your notices, minimize those as well. You don't want lots of different kinds of notices. Julie, what else? The only thing I'd say is if you do wanna keep those notices or consents and the legal basis for that is to prove that at the time when the data was collected you did get permission from that individual should they ever object to further processing. And I may have misunderstood exactly what you meant but that's how I would think is you do have a legal basis for holding that data. But we associate those in our inventory. We know exactly what notices applied to that data and that system at the time it was collected. Anything else? Again, thank you so much for coming. We have just appreciated being here and you can find us anywhere in the conference. Thank you.