When Data Becomes a Record: How to Tackle the Master Data Retention Dilemma

Duration: 0:59:46 · Recorded: 2025-03-25

Speakers: Rick Surber, Senior Consultant and Co-Manager of Consulting, Zasio; Warren Bean, Vice President of Technology & Product Development, Zasio; Jerry Manter, Zasio, moderator (advances the slides and reads attendee questions)

Lightly edited machine transcript. Slides are summarized where they carry information not spoken aloud.

[Slide: Today's Agenda: Foundation: Record vs. Information vs. Data; Traditional Approach; Privacy Curveball; How Things are Evolving; Technology; Q&A.]

Rick Surber: There's our agenda. We're going to do a little foundational stuff so we make sure everyone is on the same page going into it. We're going to talk a little bit about traditional approach. We're going to talk about how privacy has thrown a curveball into everything. Talk about how things are evolving, technology, and then talk about some solutions, and we want to spend a lot of time on the solutions. We're going to move fairly quickly through these initial foundational things, hopefully, but do ask questions as they come up, because I just feel like it flows better if we talk about questions as the subject matter is being addressed instead of having to go back and talk about something we've already covered. Go ahead and go to the next slide, please, Jerry.

[Slide: Foundation: Record vs. Information vs. Data. Venn diagram: Record is a small circle inside Information, which sits inside Data.]

Foundationally, let's talk about the difference between these things: records versus information versus data. We've got a little Venn diagram here showing it, data being the most broad thing. It's the raw material collected through various means. It could be sensors, surveys, databases, could be a lot of different ways to collect data. When data is processed, so when it's analyzed, organized, summarized, anything like that, it becomes information that provides meaning and is useful to decision making. That's the orange bubble that's a little bit smaller. Then when information is documented and stored as evidence of activities or transactions or needed for a business reason to be retained, it becomes a record, so it's the smallest subset there. Just a quick example of the relationship. For data, a database might store individual sales transactions that list a data point for the item sold, the price, the date, who the customer is maybe, all of those different data points. Information could be a monthly sales internal report generated from the database, summarizing revenue and trends. Then the official record of those types of things could be an official financial report that is then retained for regulatory compliance. Let's move on to the next slide, Jerry.

[Slide: Traditional Approach: ChatGPT-generated image of an ornate traditional room. Caption: "ChatGPT Image Generator Pro Prompt: Create an image that represents 'traditional'."]

Just a little comment: we've used ChatGPT to generate some of these images, and I've got the prompts that we've used. This is what ChatGPT thought would represent traditional. I thought it was pretty wild, especially the huge lamp in the front right, but we'll have [inaudible]

Speaker: Lots of vases in there. That's kind of a collection.

Rick Surber: Yeah, it is a good collection. Rich mahogany. Traditionally, we've had this distinction between records on one side and then information and data on the other side. Retention schedules traditionally have covered records, not necessarily information or data. A lot of that is because records have been regulated. They were in paper format, not electronic. There was no kind of blurring of what a record used to be. It was a record. It was typed or it was paper, and it was filed away for a retention period in file cabinets and boxes. Pretty clean differential, and records retention schedules were really targeting the records themselves. I'm not positive that this is just my experience or if it was more widely experienced by y'all, but categories for non-records, like redundant, obsolete, trivial information, or communications as a category, like email and messenger categories, those were really traditionally frowned upon, at least the way that I learned RIM. I learned that those should be managed separately by maybe a policy within the records and information management policy, or a line, or even their own policy. At least in my experience, those weren't traditionally categorized within retention schedules, and maybe I'll open that one up for a little bit of feedback.

Warren Bean: In fact, if I can jump in there on that one, Rick, just the name itself of what we call the records retention schedule. This is something I learned from you. We call it that because it's a retention schedule for records, not for non-records. Just by its name or definition, we've kind of put that fence around the information and saying that we're only going to worry about the things that we've declared as records.

Rick Surber: Yeah, and I think that was the traditional understanding. I even remember some of the people that taught me RIM and that I worked under and was mentored by kind of dissuading us from using categories within the retention schedule for non-records. I think things are changing a little bit, and that's kind of the point of this: to explore some different avenues of more inclusively managing information and data. So let's launch our first poll question. And I want to preface this by saying we aren't doing this to collect any information about you all. We're doing this to try to just collaborate and kind of involve everyone in this webinar, and so completely optional. You don't have to respond. But for poll question one, let's go ahead and launch that now. [poll] So, does your records retention schedule currently have categories covering non-records?

Speaker: Votes are coming in fast and furious. And we're seeing a lot that say no, so kind of following that traditional approach that we just described.

Speaker: Don't skew the results until the votes are in.

Speaker: Oh, sorry, sorry. They can't see what I can see, can they?

Speaker: No. At least I don't think so. This is a new version of the GoTo Webinar platform, so who knows what they can see at this point.

Speaker: All right. Looks like the voting has slowed down. Just a couple more coming in. So let's go ahead and call it now, and we will end that poll.

Speaker: All right. So, I don't know. Jerry, are you seeing that? Oh, here we go. Share results. Found the button.

All right. So now people should see those results.

Rick Surber: So we've got a majority that say no, that categories covering non-records are not a common thing, although 40% is significant that say yes. I think that that's new. I really do think that that's a new development. Okay. If we can advance past the poll and then go to the next slide.

[Slide: Privacy Curveball: the same Venn diagram (Record inside Information inside Data) with a new "PII" circle overlapping the Record, Information and Data areas.]

I think that what is driving a lot of that, or at least what I feel like is driving a lot of it for my clients, is privacy. It has thrown a giant curveball into traditional records and information management. It specifically regulates information, personally identifiable information, and not records. And it can even potentially regulate the data itself if it's, like, a Social Security number, for example. Of course, the tying of the Social Security number to the person that it belongs to is crucial. So whether we're blurring the line between information and data, I'm not positive. But in any way, there is kind of now this need to consider information based on these privacy regulations. And they're significant. The typical language that they use is keep personal information either for the purpose for which it's collected, or maybe they're even saying keep specific personal information only for a specified time. Like, don't keep biometric information for longer than a few months or something like that.

And these GDPR, CCPA, CPRA, a lot of the states are now passing these. I think a majority of states now have them. Some are more restrictive, some are less. Europe, of course, it's a huge thing there. And some of these penalties are sizable. I just read an article about how they're not sizable enough, because companies are still just breaking the rules because they're making so much money breaking the rules that it's not really a deterrent to breaking the rules. But I think that those are the big players that are doing that. I don't think that most companies are able to just do that. But GDPR— [Speaker: Did you read the same article?] [inaudible] But GDPR is 4%. The penalty for violating: 4% of an organization's global turnover or 20 million euros, whichever is higher, so pretty significant. CCPA: $100 to $750 per consumer, or actual damages, whichever is greater, plus the possibility of civil penalties ranging from $2,500 to $7,500 per violation. So for most companies, and for those that are averse to violating the law, they're considering those and they're being proactive about those, which means that we have to kind of extend in some way. It doesn't necessarily have to be through the retention schedule, but there needs to be a way to extend our management to information, whether that be through a privacy compliance team, a legal department, or perhaps, and what I'm going to advocate for, it's us records and information managers that can play a big part in helping with that. And so we'll get to that in a little bit. Let's do our second poll question before we get there. [poll] Does your records retention schedule have special treatment for personal information? Let's do a poll question on that.

Warren Bean: While we get the poll results, I'm just kind of thinking out loud here, Rick, in the sense that because there are regulations behind those privacy requirements, that part of the diagram that said PII, I kind of picture that being pulled into the record space because there are regulations around that information.

Rick Surber: That's a good point. Is there an argument for that? There is an argument for that, because in our definition for a record, we said when information is documented and stored as evidence of activities or transactions, including for regulatory compliance, it may pull it into a record. Now, clients are a little bit split on whether they're automatically categorizing personal information as a record. I do have those clients that do say, you know, if privacy is involved in this, even if it doesn't meet the traditional definition of a record, we're going to say it's a record just because privacy is involved.

That creates some kind of funky, unusual situations where you have to kind of schedule non-records on the retention schedule. But I think we're going to advocate for that anyway here. So yeah: 50/50 split, special treatment for personal information. So for those that say no, I would bet that you're maybe in jurisdictions that privacy isn't a big factor for you, or maybe you've got a separate privacy policy and a separate privacy team. There are probably other ways that that's being managed.

Jerry Manter: Hey, guys, can I chime in real quick? I've got a couple comments and a question here. [audience question] First comment just says: "Government entity here. Until the 1980s or 1990s, a different retention schedule had to be created for each medium. Then the state law changed to creating retention schedules describing the record with all mediums encapsulated in that one retention schedule."

Rick Surber: Yeah, and I think that that flows a little bit with the evolution of retention schedules too, being like the shift from departmental to functional big buckets. So yeah, I think that that resonates and makes sense, absolutely.

Jerry Manter: And then—

Speaker: More media agnostic in that sense, too.

Rick Surber: Absolutely.

Jerry Manter: And then a follow-up question: "Do you mean big players like the government, state, local, fed, or big tech?"

Rick Surber: Big tech is who I was really referring to, but governments are, foreign governments are definitely guilty of it too.

Speaker: Or financial, big financial firms as well.

Rick Surber: Probably not even just foreign governments, honestly, but that's a different conversation. But yeah, big tech is the one that is in the news for it, like billion-dollar fines. And a $4 billion fine, for example, seems significant until you see, oh, it was like $100 billion in revenue based on mishandling of personal information that got them there. And so it's hard for that to be painful for that particular company if their revenue is so dependent on their use of personal information in that way. So yeah, there was a recent article that popped up that said that there should be different mechanisms for enforcing this, potentially. And it talked about a few. Maybe we can try to share that article in a follow-up if people are interested.

Jerry Manter: And I got one more question really quick here. [audience question] "We are finding the business is easily confused by the term 'non-records' on the schedule. Is there any benefit or disadvantage to calling non-records what they are, explicitly data and explicitly information, on the retention schedule?"

Rick Surber: Or explicitly redundant copies, working copies, communications like email that wouldn't roll up into another category within the retention schedule. For those that are using categories for non-records, I do think you would want to term it in a way that makes sense to the users, because that's where the confusion is coming from. They want to look at one document and see all of what they perceive as their different records. And whether they're electronic files that are working copies or duplicates or trivial or whatever it may be, they want to see it on the retention schedule and be able to schedule it that way just for ease of use and understanding. That definition of a record hangs up a lot of people. And so I do think that using terminology for whatever that may be, if you're going to schedule it, is the most intuitive way to do it, being specific about what it covers and what it doesn't cover.

All right. Let's move on to how things are evolving. Next slide, please.

[Slide: How Things Are Evolving: two ChatGPT-generated images. Caption: "ChatGPT Image Generator Pro Prompt: Create an image that represents 'evolving'. 2nd Prompt: Make it less abstract."]

And again, there's the ChatGPT. The first image in the upper left is what I got when I asked it to describe evolving, which was pretty out there. So I asked it to make it less abstract and got this bigger visual, which is pretty cool, I think. I love how easy this is making presentations. So I think that where this is going is advocating to challenge traditional understandings about retention schedules. And if you challenge it and analyze it and decide to stay with the traditional approach, so be it, but ask the question. But another thing is I think that for records and information management professionals, this is a huge opportunity for us, this data and repositories and information kind of explosion and this blurring, because records managers are experts at appraising and determining retention like no other professional in the business. And we're experts at the consistency and the continuity of a well-developed retention schedule, which, if you choose to go this route, can be leveraged towards timely data disposition, timely information disposition, with privacy and legal compliance taken into full account. And of course, managing all of this isn't just a one-professional game. Records and information managers play a role, but really all of the branches of information governance have to be on board with this. You have to have HR.

You have to have privacy. You have to have legal, technology. All of them need to collaborate to make this happen. And so, with that introduction, let's move to our third poll question, which is, Lauren, if you would launch it, please, [poll] "Are you a member of an IG committee or initiative at your organization?"

Jerry Manter: And Rick, we got another comment that's come in. [audience question] "Personal information is embedded within records. Most records that have PI are not findable without that PI. So we keep our retention schedule periods as short as possible for categories that contain large amounts of PI. We have a transitory material guide and a retention schedule."

Rick Surber: Yep. And I like that. That's key. It's created this shift in retention schedules where historically it was all about regulatory compliance and business need, and kind of making sure that we err on the side of over-retaining, at least before GDPR. And since GDPR and all of these different privacy laws have become more prevalent, it's flipped it. It's really defensible disposition based on the actual need for those records, with little to no over-retention, especially for the records and the categories containing personal information. Many of our clients, and exercises that we do with clients, we're looking at a retention schedule and we're flagging the different categories that might have personal information within the records that are in that category. And then we're saying, okay, these need special treatment.

We need to make sure we're not over-retaining them. We're either going to try to align them to the longest legal requirement, so the minimum retention period required by laws, or we're going to have to have a really good justification to keep them for longer, or maybe we're going to have to set them based on a maximum privacy requirement. So, great comment. IG committees: it looks like that split 50/50 as well. And I do think that that's kind of, or I hope that that's kind of a trend that continues to grow: recognizing the importance of information governance and having a higher level committee to help manage and be strategic about it, considering records and information as an asset and not just a liability. So, good stuff.

Warren Bean: This is making me think, and this is kind of playing off one of the other comments about, there's actually a couple of them. One was talking about changing the records retention schedule to just a retention schedule, which includes data and information. Another one about kind of the definition of record, information and data, which we might want to revisit here as we go through this. But it makes me wonder if we should, instead of calling it RIM, like records and information management, maybe just more like information retention management.

Rick Surber: Turn these around: IRM. IRM. Yeah. And yeah, retention schedule versus disposition schedule has been kind of discussed a little bit. And for some companies, those are two different things. They have a retention schedule that tells you how long, the minimum you have to keep them, the records, and then maybe they have a disposition schedule for privacy. And as long as you're keeping it for longer than the retention schedule, you're good. There's no disposition attached to it, right? Whereas I think that the retention schedules that we're creating for clients, we're really trying to promote retaining the records and information for the period stated, and then fairly promptly disposing of it, whether it be on a quarterly basis, an annual basis at the latest, or maybe even the closest you can tie it to when that record becomes due for disposition, really the better. So, some different things and concepts going on here that don't all necessarily mean the same thing, and can have different understandings. [Warren Bean: Very true.]

All right, so let's go ahead and advance the slide.

[Slide: Technology: ChatGPT-generated images. Caption: "ChatGPT Image Generator Pro Prompt: Create an image that represents 'technology'. 2nd Prompt: Create an image that represents 'chat gpt'."]

Now, one factor here that's going to play a big role on the data disposition side is the technology, the repositories that we're dealing with, that the data is in, or where the data lives. There just may not be functionality or feasibility to destroy information in some of those repositories. I know of one HR platform, for example, that doesn't allow disposition of employee information until after termination. And so that can cut against some of these employee related records that might not need to tie to duration of employment or termination. So I mention this now because technology is going to be a factor in this analysis that we talk through, but it shouldn't be something that just creates an excuse to keep information permanently. It should really be, okay, we need to be strategic about how we catch the technology up and how we onboard new technology so that we can dispose of these things when we need to. And some of that's happening naturally, just based on the privacy laws, like GDPR.

This HR platform that I'm speaking of didn't used to allow disposition at all. But because of GDPR, they're now making it so that there is at least some disposition. They're under the same kind of constraints from a regulatory perspective as all of us are. And they're trying to make their software compliant so that its users can be compliant with things like the GDPR. So I feel like we're moving in the direction of many of these applications, repositories, places where we're managing data and information, to have disposition capabilities that can align to whatever policies we create for them.

Warren Bean: You know, one of the big issues I see with this, Rick, is that in the days before computers, if you produced a document, it was typically either handwritten or typed up. You put a piece of paper in the typewriter, you type it, and you produce the document. And so it was an object, and it was kind of self-contained. Now, what we see is that the output of systems are really more like assemblies. They're information gathered from multiple places. If you're talking about a customer record or employee record, they've got bits of data in various different systems that they're pulling together to produce the output. So once it's output, sure, it's self-contained, in most cases, and you can say that that's your record. But you still have to contend with the fact that you may not be able to destroy a record if the underlying data is gone as well. So it all has dependencies sort of downstream, or I should say really upstream, from the record that's output. And so we have to take into account where is that master data?

How is that being managed? How does that play into the records that are being produced? It makes it much more complicated when you think about what is a record and how do you grapple with that data that's producing it?

Rick Surber: Yeah, you've done an excellent job right there of kind of highlighting the problem that we're dealing with, that we're up against, the biggest hurdle that we're up against in this conversation, which is, it's not even the data and the information. It doesn't always tie to a record output. It doesn't all come from the same place. It's just all commingled. And it's all kind of a blur that has, some have record outputs, some don't even have record outputs to tie to. And so I think that that's a good segue into our next slide, which is this concept that I think will help us with this.

[Slide: Process-Driven Retention Management (PDRM). ChatGPT-generated image of a recycle symbol labeled "Process based defensible disposition of data." Caption: "ChatGPT Image Generator Pro Prompt: Create an image that represents a 'process-based defensible disposition of data' using the recycle bin to represent disposition."]

And what we're terming it right now, and I'm not super sold on it, but I think it's the best title for it that we have now, is this: it's process-driven retention management. So what you described there, Warren, is the information can be pulled from various different sources, but it's all related to a business process. The business processes are what drive the need to manipulate the data, the need to pull data from different sources. It's all centered around these processes. And even if there's not a specific record output for every single data element, there's going to be a process that each data element is involved in. Even if that process could be workflow processes that are duplicative or trivial, or just helping to lead to a final result or a final product enhancement or whatever it may be. And so the number one rule is to try to tie retention to the record outputs, if there are record outputs to the data. And there might be multiple outputs, and so we have to keep that in mind. But there is going to be this instance where there is no direct record output. And that's where you roll up to the process, and then you look at that process's outputs. Because even if particular data points aren't a part of a record output, that process in general is going to have record outputs. And so we're going to tie the data to the process, and then to the record outputs of that process. So I think that's really key. I think it addresses a lot of the issues that just don't fit anymore with that traditional approach, in terms of recognizing all of the different pieces and parts that are involved in it.

Well, and it is, it's really kind of a recreation of what we did when we bucketized department schedules. We're rolling up to processes, or we rolled up to functions with that. But we're going to roll up to processes here because they're slightly more granular than those functions. And then we're going to tie to the record outputs of those processes, and then we're going to tie back to the retention schedule in that way. And so there are some rules to it. If there are multiple record outputs, which there probably are going to be multiple record outputs, it's going to be the longest record output if personal identifiable information isn't a factor. So you're just going to want to tie it to the longest record output, because, and kind of the basis for the defensibility of this is the thinking that a regulator might question that specific record output.

And you may need to defend that record. And so to defend that record, you're going to want to go to the supporting information and data that you've used to create that record. And so that's the defensible way that we're getting from the data to the record outputs. So if there is PII involved, it's going to be more of a risk-based determination. It really must, if you're going to follow the law and follow those purpose-for-collection requirements, tie to that purpose for collection. So you have to make sure that the record output that you tie the data to still follows that rule. But if you have a well-designed records retention schedule, that should already be a consideration that the retention schedule uses, is that those retention periods within the retention schedule tie to the purpose for collection. But there may be ways to kind of manipulate this, tie to record outputs that are maybe longer, and there's risk there. So that's the kind of murkiest risk element of this equation: how do we do it for the PII, but make sure that we tie to the right record output, especially when we're going through a process to get there.

So that's the risk-based analysis that needs to go into it.

Jerry Manter: Hey, Rick, can we get a couple of questions in?

Rick Surber: Yeah, absolutely.

Jerry Manter: Okay. [audience question] "Is it unreasonable to require a system to parse the individual data elements that make up a record and allow them to be destroyed, and not by writing custom code every time? Is this not lifecycle management?"

Rick Surber: I think that that's perfectly reasonable, but technology people might disagree with that. But I do think that's why RIM and information governance, it's crucial that they're a part of the conversation when you're onboarding these repositories and applications, and that they're a part of the conversation when they're being upgraded and at every stage of the repositories that are managing this data and information. Because if RIM isn't considered and data disposition isn't considered initially, it's just going to create big problems down the line, where there's no feasibility to do it, or custom code is created every time you want to try to parse any information and dispose of anything. So I think that that's an expectation that is reasonable. And that's a battle that's worth continuing to try to fight.

Warren Bean: I would add to that, Rick, that the trouble with that is how granular are we talking, because an individual data element may not have enough information to know when you can destroy it. So for example, if you have a customer name, if you don't also have information about when that customer name was entered or by whom, in other words, a little bit more of the surrounding context, you really wouldn't be able to know when it's eligible for destruction. Other than maybe if it's a deletion request, like if you get a request for deletion of private information and you want to delete that customer name because it's part of that request, that might be a case where you can, if your systems and your processes can get to that level of granularity, down to, say, a database field, and be able to purge at that level.

Rick Surber: Yep. Yeah. And I agree that this isn't, it's problematic for a lot of existing systems, because they just don't have the capabilities or the metadata built into them to know when a data point was created or how to tie that data point to something in particular. But there are still ways that we can go through and align or map that data to the record outputs. And we're kind of talking around data maps right now a little bit. And I'm not talking about the super granular data map that aligns every single data point to its repository and is a huge, complex map that is only really up to date, like, probably the instant that it's created, and then it's out of date instantly and takes a ton of effort to recreate and maintain and manage. I'm talking about a higher level data map that kind of maps data to the processes and the record outputs, and does kind of some of the equation of, okay, this is the output that we're going to use for these pieces of data so that we know when they're due for disposition. Hoping that we have that metadata available, or we can start tracking that, about the creation or other attributes of that data.

Warren Bean: That's a good point.

Jerry Manter: All right. Let's sneak in one more quick question here. [audience question] "Are you assuming in PDRM that you would be able to delete the data at the end of the retention period for the records that were created?"

Rick Surber: Yes. The hope is that the technology functionality is there. But before you get too far into this analysis, technology should be a question, and I have kind of a formula that you can use that I'll go through, a method for this that we can talk about, to make sure that we're not getting too far ahead of ourselves and trying to schedule disposition that's not feasible based on technology. Because that is a factor. But even if it's not feasible to make the kind of slightly more granular dispositions tied to record outputs that might have triggers and things like that, it doesn't mean that disposition shouldn't still be kept in mind, even if the feasibility isn't quite there yet. Like, we've got some clients that are scheduling some data analytics categories for well into the future, knowing that that technology isn't there and that they're going to have to figure things out.

But it gives them something to work towards. And it shows regulators that they are working towards a solution like that. Don't be too aggressive, because we don't want to miss our own policy requirements. But I think it is okay for the ideal state to drive the technology a little bit. And the ideal state certainly is not to keep data permanently or indefinitely, especially personal information, because that's where you're going to get in trouble.

Warren Bean: That really should be the new paradigm in terms of how we think about information. It should always be thought of in terms of how will this be at least managed, and at best disposed of at the proper time, because too much information just creates too much risk.

Rick Surber: Yeah. Yeah, even if we're doing the old, we'll set it for 50 or 75 years and let our kids worry about how to actually do it. I mean, at least assigning some value to it. Make sure that we've got priorities in the future to make sure that it happens.

Warren Bean: So can I throw a wrinkle into this? [Rick Surber: Oh, yes. Yes, please.] So this always comes up these days, and that is AI and the issues surrounding AI. And so I'll just throw out one example of something that I've been thinking about and how this might fit into this kind of a situation. And that is a lot of different businesses and organizations are creating their own AI, I'll call them data pools. They're often called RAG, retrieval-augmented generation. So it's basically creating a database of information that an AI engine can analyze, and it's all self-contained. It's not in the cloud or anything like that. And so businesses can analyze their documentation, their financials, etc., any data that they want to pump into that. So in that process, when you basically index something into an AI database, it's basically turning that text into numerical values.

They call them vectors. And so when they're vectorized, it kind of makes a numerical representation of it so it can do the mathematical calculation. So let's say you've got all kinds of information you're pumping into that, including PII. And now someone says, well, if we have to get rid of that, how do we extract that PII out of the vector database that you're using internally for analysis? And what if the data scientists say, well, we want to keep that for a long time so we can do the trend analysis and other predictive work that might be necessary for that? Any thoughts on how we might tackle that?

Rick Surber: Well, again, what I would say is you're going to look at the processes that you're running analytics on that data based on, and then you're going to want to either align to the longest process, if the longest process could generate a record output, to align to the retention schedule, if there's no personal information involved. But like you said, if there is personal information involved, you're going to have to do a risk analysis and potentially keep that information for a shorter period, especially if you can't get back in there and anonymize or selectively delete the personal information involved. [Warren Bean: So scrub it before it goes in, then?] Scrub it before it goes in. Absolutely. Because then it's not as much of a privacy risk to be having it.

That's exactly right. But we do see and we do hear about regulators scrutinizing these practices where personal information is being kind of pulled into analytics like you're talking about, and customers not being strategic about how they're following the privacy regulations when that's happening. And so this is really designed to be a method to be proactive about that. And it could mean that if you're going to pull in personal information, and it's something that you need to pull in, that you're going to have to be satisfied with the fact that there's going to need to be a shorter retention tied to the purpose for that initial collection. It is a processing to be pulling that information into an analytics tool like that. And so the purpose needs to be related to that analytics processing, really. Yeah, so it gets murky. And I know that these things happen.

There are consent mechanisms and some other mechanisms around some of those concerns. But if it's going to be a long-term analytical tool, it really needs to get scrubbed, or it needs to be kind of a shorter term. Like, we've got some clients that are scheduling analytics like that for as short as three years, to even one year, or even months, unfortunately, just because of the data that's getting pulled in and the justifiable kind of record output processes that are tied to that data.

Warren Bean: Yeah. In fact, by virtue of you saying that, it makes me think that having audit trails to show what has been put into AI systems would be key. So you have a record of that, as well as the ability to recreate these vector databases so that you can basically pull out the PII from the source data, recreate the vector database for the analytics part, and know that basically, by that refresh, you've now essentially scrubbed it, maybe after the fact. So instead of trying to pull it out, you're basically just recreating it without that information.

Rick Surber: Yep, yep, that's exactly right. And so I said I would describe a method for this kind of process-driven retention management. And so here it is. I'll go over it quickly so that we have time for questions. But what it's going to require is collecting information as an initial phase: building a list of systems and repositories, understanding the disposition capabilities of those systems and repositories, which may require some vendor support if it's not clear whether disposition capabilities exist, talking to the vendors that are providing those services or those applications or those repositories. If the capabilities are limited, you'll want to document your efforts to enhance and maybe set some long-term retention periods, but not just go permanent and sweep it under the rug, like we already discussed. So technology first, so that we're not kind of getting ahead of ourselves. But then you want to understand the data and the record outputs from those systems and repositories. And again, if no direct record outputs, understand the associated process or processes, and the record outputs from those processes, to tie retention back to the data. And then you're going to want to determine priority. Priority is probably going to go, maybe sensitive customer PII is first. That's what a lot of clients have done, because that's really what a lot of these privacy laws are targeting, and there are direct fines and sanctions associated with that. Maybe sensitive employee PII next, because many of the more kind of stricter privacy requirements are also going into employee PII. Then maybe other types of PII that you could have. And then I would even advocate that if personal information isn't involved, you should still kind of consider doing data and repositories that don't involve personal information, for the same reasons that we set retention on records that don't contain personal information: because it's still going to go stale. It's still going to be, as my mentor David Stevens used to say, it's compost. If it sits around for too long, there's no value in it anymore. It's just taking up space and adding liability and all of those things. And so determine the priority. Align, based on this process-driven retention management that we've just discussed, aligning to the retention schedule the data points, based on the processes and the record outputs. And then you'll probably want to collaborate with stakeholders again to ensure that that alignment of retention to data points meets needs. And then you'll want to get approval through legal and privacy teams, and then the business units that you're working with that the records may relate to. So if it's that HR employee repository that we're dealing with, we'll want to talk to HR and make sure that it's meeting their needs, because some of those records may have really long-term needs, like benefits. Being able to pay benefits is a really long-term thing, potentially, for pensions. And a data point that is sensitive could still have a long, justifiable need, like a Social Security number could need to be retained for a long period so that you can implement and still pay out those pension benefits. And then the final stage would be working with technology and different groups to implement. Some of the things that really help with implementation is if you can try to get rid of triggers. And so if we're able to calculate to a creation date of the data, great. That might be a metadata point, like Warren said, that is being associated with data. It might not be. So we might need to think outside of the box, and different ways to dispose of the data as well, if some of those metadata points surrounding creation and other kind of automatic disposition triggers aren't workable or aren't available. So that's kind of the method, the method of this process-driven retention management.

Warren Bean: I know we've got a lot of questions, but I'm going to just throw in a real quick plug for software that can manage this, because that's kind of my world. Because as you're describing this, I'm thinking, okay, that's brilliant, because we've got the retention schedule. We can apply the different priorities and such, saying, does this category have PII? Is it subject to certain regulations? We've got the citations that drive that. And then we can map the retention schedule categories to the systems.

And then we basically can break those systems down into the processes that either are used to generate the information stored in those systems, or maybe those systems represent a process that generates other information that gets stored elsewhere. So it's like going from schedule, with its attributes, to system to processes, and using that as a basis to really get down to the nuts and bolts of where you apply retention. And then you get into, of course, the technology and how you're going to actually apply the rules to those elements of data.

Rick Surber: Yeah. And all of this should, or is typically, used by clients, and we help with this as well, to create kind of a disposition plan for different repositories that exactly does what we've described: ties it to processes and then to record outputs, or directly to record outputs if there's a direct record output. And then what you said is exactly right, Warren. What technology does is it makes things a lot less manual. It allows us to set some of these things up and alert us and help implement the disposition, instead of a lot of it being kind of more manual in nature. And like one of our commenters noted, like having to write a script to implement a disposition like this, a custom script to do it each time you have to do it. So software takes a lot of that out of the equation. And then even, and I think that you're getting into this a little, Warren, with our capabilities, but even some of the newer advances in, like, crawling will help kind of identify what the data is, so that there's not as much of a manual effort required in discovering and collecting information about what you have.

Warren Bean: Yeah, very true. Well, looks like we've got a bunch of questions. Jerry, have you highlighted a few that we can answer in the next few minutes here?

[Slide: Questions? ChatGPT-generated "Z" logo image. Caption: "ChatGPT Image Generator Pro Prompt: Create an image that represents 'Zasio Enterprises'."]

Jerry Manter: Yeah, I do. And thanks again, everybody, for getting those comments and questions in. It's appreciated. [audience question] "What are your thoughts on approaching data retention management from a risk-based approach? For example, focusing on retention for PII data rather than our entire data universe. We have so much data that this seems to be the most practical way to approach this issue."

Rick Surber: Yeah, and I addressed that a little bit in priority. I do think that sensitive customer information gets the number one priority because it's the most highly regulated, and then sensitive employee information would be number two. I do think it makes sense to go for repositories and applications that relate to those two topics first. But I would also advocate that, ideally, with unlimited resources, we don't stop there. We really try to apply it to all of our repositories and applications. And that when personal information isn't involved, sometimes it's cleaner and easier. You're just aligning to the longest record output if no PII is there. And it can sometimes make setting a calculated retention period fairly easy. And it can also involve a lot more of the data points. Whereas what the sensitive customer personal information does is it makes us kind of have to be more granular in the data points that we're looking at, and more strategic about setting pretty short, tied-to-reason-for-collection retention periods. So I agree that from a risk perspective, sensitive personal information is the riskiest and the priority. But I would say don't let that stop you from going after some of the other stuff, because it can maybe be easier to schedule and have processes set for disposition.

Warren Bean: You know, one thing I really like about the risk-based approach is that it, well, there's a couple things, but one is that it really does set the priority, as you were saying, Rick, as far as using a priority method, but it sets the priority based on the risk analysis of the impact to the organization as a whole. So the likelihood of a problem and the cost of that problem. So you're immediately setting essentially a monetary risk value to that issue. And so it raises the awareness level. It puts the records manager kind of at the table, among those people who are trying to manage risk for the entire organization.

And so I think it's a great way to drive the priority and highlight the importance of this whole concept of information retention management. [Rick Surber: Yeah, absolutely.]

Jerry Manter: Oh, Warren, this is probably for you. But this question is: [audience question] "Does the software provide certificates of destruction?"

Warren Bean: Oh, yeah, indeed. So if you are destroying records through the Versatile software, it'll have an audit trail of what was destroyed and who approved it and all of that. And that can be used to generate a certificate of destruction.

Jerry Manter: Okay. [audience question] "How have you been able to capture what the process is behind the data and store it or connect it to the data through a form indexing?"

Rick Surber: That's been part of our information collection, and talking to the knowledgeable stakeholders, understanding their process, what they're using the data for, the analysis that's going into it, and then the different kind of record outputs of those processes. And so it's certainly something that we use. This is kind of another piece of this that we haven't gotten into yet. But when you're setting retention, whether it be for a record category or a record, or whether it be for a data element or information, whatever it may be, especially when personal information is involved, the method that we really recommend is documenting the reason for that retention period. And it might be the longest legal citation, and so you can flag that citation as setting the retention period. Might be a mandatory destruction requirement that requires something short, so you're setting that. But it might also be a business need tied to the purpose for collection. And that's where kind of some of the process element gets into it. And regardless of what it is, even within our retention schedule management software, Versatile, you're able to create a user citation to document your business need, so that you've got a really good business need that is promoting the retention period or defending the retention period that it's set to. And by that, we don't mean just "this stakeholder said this is what they need." It's really getting into the weeds and understanding why this retention period is necessary and why a shorter retention period isn't possible, and documenting that in the same way that you would document a legal citation, so that you're sure that you've got a good rationale for the retention period.

And I think that's a good way to kind of document some of this process stuff, especially where it promotes a certain retention period.

Warren Bean: And I think you could further build on that to say that there's sort of three different aspects to a process. There's the generator of information; that could be a person, it could be a system. There's the use of the information, some sort of application or something you do with it. And then there's how you store whatever is the output of that use of the information. So generating, processing or using it, and then storing it: those are the typical elements of a process. If you can kind of chart those out, put them on a, I don't know, spreadsheet, whatever you want to do, it's one way to look at any given system and try to at least make some sense of it. [Rick Surber: Yeah, absolutely.]

Jerry Manter: Okay. [audience question] "When there is guest data involved, what would be the appropriate approach to retain the data?" [Rick Surber: So, guest data. Warren, can you elaborate on that?]

Warren Bean: Yeah, I'm not sure if I'm— [Speaker: Third-party data, or?] Yeah, it could be third-party, like if you're bringing in information from other systems. Yeah, that sort of depends on the nature of the data, I suppose, as to whether you're allowed to keep it, if there's any proprietary considerations with that. Yeah, I would say that that's tough to answer without getting into specifics about what the nature of the data is.

Rick Surber: Well, if we just assume that you're able to bring it in and process it, which has hurdles in and of itself, based on the privacy laws, but assume you got there the right way legally, and you've got third-party data that you're dealing with. I mean, it still goes back to the process. What are you pulling this data into, and what is the analysis? What's the process related to analyzing this data? What's it for?

And what are going to be the record outputs of that process? If it involves personal information, again, we're going to want to tie to short retention periods that are related to the purpose for collection. If it's not related to personal information, then we can tie to any of the longer record outputs that that guest information might be tied to.

Warren Bean: Yeah. And do we have to be able to go in and pull out that guest information on request? That's going to play into it as well. [Rick Surber: Yep.]

Jerry Manter: Okay, we have time for one more. I'll do one more comment here. [audience question] "Organizations really need to work with IT to appoint a records and information architect to represent them in the architecture meetings. So many decisions happen in the IT world, and records management needs representation."

Rick Surber: I agree 100%. And that can be a role within the information governance committee too, all part of the same team with the same objectives. Same with, a lot of companies have data disposition teams that are just going through and trying to proactively delete, especially personal information. And so all part of the same team, trying to defensively delete records and information.

Speaker: Yeah, and just as a stay tuned, we've got a virtual coffee coming up in May. We'll be sending out details, but we're going to be talking about artificial intelligence and how records and information management is a part of that, and how we can be a part of this AI revolution that's going on right now. So stay tuned for that. We're looking forward to that. Probably have some more AI-generated images in those slides, because those are fun and handy.

Speaker: So true.

Speaker: Well, thank you, everyone. This has been a pleasure.

Speaker: Yeah, been a good discussion. Thanks for everyone's input.