Beyond Records: Why the Future of Retention Is Process Driven

Duration: 1:02:10 · Recorded: 2026-02-05

Speakers: Jennifer Chadband, CRM, IGP, CIPP/E, licensed attorney, Senior Consultant / Consulting Co-Manager, Zasio (host); Warren Bean, CRM, CISM, VP Technology & Product Development, Zasio; Rick Surber, CRM, IGP, licensed attorney, Senior Consultant / Consulting Co-Manager, Zasio

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

[Slide: Meet Our Presenters: Jennifer Chadband, CRM, IGP, CIPP/E, Licensed Attorney, Senior Consultant / Consulting Co-Manager; Warren Bean, CRM, CISM, VP Technology & Product Development; Rick Surber, CRM, IGP, Licensed Attorney, Senior Consultant / Consulting Co-Manager.]

Jennifer Chadband: Hi, everybody. Good morning, good afternoon. I see some familiar names out there, a lot of new ones as well. So, very exciting. For any of our attendees who are not familiar with Virtual Coffee, I think we really have one rule, and that is bring your coffee or other beverage, and we keep it casual.

So, I don't know if anybody had a chance to attend the presentation at ARMA or heard about it, but this topic today, I think, on process-driven retention has been really popular. We've gotten a lot of questions about it. At ARMA, it was standing room only. So really excited to be able to kind of bring it into this forum, where we get to have a little bit more of a conversation and talk about some of these things. We welcome questions. It's supposed to be kind of a collaborative forum, where, people, please don't be afraid to kind of raise your hand or submit a question for us. We'll have a dedicated time at the end to do some Q&A.

And we always love that part. So anyways, with that, I will go ahead and I'll hand it over to Warren to kind of get us started and walk us through the agenda for our discussion today.

[Slide: About Zasio: Established in 1987 by Kevin Zasio; IG software & consulting; first full lifecycle RM software; global IG consulting; electronic and paper records management; retention schedule development.]

Warren Bean: Great. Thanks, Jen. And just for those of you who might be new, just a quick word about who Zasio is in case you haven't heard of us. Been in the business a long time. It was started by Kevin Zasio in 1987, and basically our niche is information governance software and consulting.

So we started way back in 1987 with the first full lifecycle records management software. And from there, we've migrated into all kinds of different consulting expertise: electronic and paper records management, retention schedule development. So you name it, if it's in that niche, we're involved in it. And we like to think that we are thought leaders in this kind of space, given the kind of content that we deal with with our customers each day. Which is why we're here talking with you as well.

[Slide: Today's Agenda: Introduction & context; Traditional retention scheduling; The complication of data; The complication of privacy; A new approach; Examples; Implementation; Q & A.]

So as far as today's agenda, it's pretty straightforward. We're going to just do a brief introduction and give you some context. We'll go through pretty quickly just the setting of the stage for traditional retention scheduling, how that gets complicated by data and privacy, but we want to get as quickly as possible into this new approach. So we're not going to spend most of the time just talking about the problem, but really get into the solution of things. And we'll actually give you some examples, kind of a workshop type of options, so you can see how this actually plays out in the real world, and talk about ways that you might implement this, some of the hurdles, some of the ways you might go about it.

So with that, I'm going to start with just a quote that I think helps to set the stage before we dive in about why we're here, what we're doing and our purpose in this industry. So this quote is from our friends at Utah State Archives. It says, "Without records that show how, why, and by whom data was collected, it's easy to misinterpret. So what we preserve helps turn raw information into real understanding." And I think that's important because we're gleaning understanding from the data, and it highlights the fact that context is key to understanding not only the records themselves, but the process by which you manage them. So we're not just keeping things for the sake of keeping them, but we are actually preserving meaning and understanding, which ties into accountability, governance, and all kinds of things. So with that, let's kick off with just a brief recap of kind of the old-school way that you think about destroying things, and I'll let Jen take that over and help us understand that.

Rick Surber: I'll actually do this one.

Speaker: Oh, okay.

Rick Surber: So, can I destroy that? That's kind of the fundamental records management question, isn't it? Once a record has fulfilled its purpose and obligations, disposition is how we let it go. And we know we can't and shouldn't keep everything, but we can't just delete things willy-nilly. So defensible disposition is having a routine, rules-based process that balances business needs, legal obligations, and of course accounts and follows those legal holds.

So that kind of frames what we're after here. When can I destroy it? Back in the old days, recordkeeping was really document-centric. The record was paper. It's evolved into being electronic, but it's a thing. It's a file or it's a piece of paper.

It was simpler before these systems came into play. Records were self-contained, and we categorized them based on the records retention schedule by looking at their content, their purpose, and how they aligned to the records retention schedule, whether it be older, kind of more granular retention schedules that accounted for every type of record, or whether it was a newer kind of big bucket retention schedule that is functional and purpose-driven. You find a place for that discrete record in the retention schedule and you schedule it that way. But those paper days are long behind us. Records now live in sprawling digital systems where deletion is anything but simple. Warren, I think I'll throw it back to you so that you can walk us through how recordkeeping has developed and why it's a little bit harder to determine what a record is these days.

Warren Bean: Yeah, thanks, Rick. And really, computing, of course, changed everything because it was no longer those discrete pieces of... Sorry, Bluetooth cut up right at the right time there. [laughter] But data just changed everything because of the fact that everything got broken up into smaller chunks, as you can kind of see on that left-hand graphic there, lots of ones and zeros. It's kind of the fundamental piece of computing, where everything is in these little quantized pieces. And at some point, that information comes to be something more than just bits and bytes.

It becomes actually something important, but it's hard to distinguish when it's the raw information versus the actual record. So one of the things that we want to do is kind of talk about: is data a record, or when does data become a record, and how does that tie in, because of the fact that it is so kind of broken up and fragmented.

[Slide: Then came data: pyramid of Data, Information, Records. "Does data = records?" Data: raw material of computing; Information: processed data; Records: information documented as evidence of activities (not self-contained; may be regenerated after deletion; various media); not typically in the retention schedule; to keep, or not to keep?]

So one way to understand this is just in this sort of simple diagram here, where you've got data at the bottom, some of that becomes information, some of that becomes records. So data, in essence, is just the raw material of computing. It's what drives both the storage of the information but also how the information gets processed. So if you take enough of that data and put it together, it becomes a little bit more meaningful and becomes information, and that can be in all kinds of different forms. And if you take that information and use it to document something or make decisions, it's evidence, then of course you've got a record according to traditional definitions of records.

But as opposed to those physical records that you mentioned, Rick, it's not self-contained. So you might have one document, let's say, that is comprised of multiple pieces of information from different places, which means that if you delete that document, you can regenerate that information oftentimes, maybe in whole, maybe in part, but it's not fully deleted. And it could be in all kinds of different media, of course, not paper. It could be PDF documents, spreadsheets, databases, videos, audio recordings, websites, you name it, all kinds of complication there in terms of what you're seeing and how it's contained. And as you see here, it's not always in the retention schedule because we're not sure if it's actually a record or not.

And so it begs that question, well, can we keep it? Should we keep it? Do we keep it? How do we keep it? All of those things that play into it. So that's kind of that background. Jen, you had a comment?

Jennifer Chadband: Yeah, I was just going to say one thing. I feel like I kind of hear, and you try to put your finger on it, but I think one of the big challenges that we see is that with traditional records being compartmentalized, you can kind of really identify a single owner, usually. There might be a business or a specific owner. I think one of the difficulties with data is that it's repurposed across teams. It's used for so many different reasons.

So sometimes there's not even really a formal handoff. So from a records management perspective, we're kind of accountable for this disposition process and the ultimate outcome. But where is the kind of governance over the process that kind of gets us to that ultimate end? And there's a little bit of a gap there. I feel like that's kind of, when we have these conversations, that's really where the crux of the struggle seems to be.

Warren Bean: Absolutely. Yeah, you don't know where the data is coming from necessarily or how it's going to be used later on. [Speaker: Yeah.] So to highlight that, let's play a little game. We need some audience participation here, and you can use your chat window in order to respond. And this game is very sophisticated, and it's called Data, Information, or Record.

So I'm going to put up some stuff on the screen. I was going to say information, but I'll just put something on the screen.

[Slide: Let's Play a Game: Data, Information, or Record? Items revealed one at a time: "01"; "01010111"; "Will"; "Final Will and Testament"; further items follow as described.]

You have to tell me whether it's data, information, or a record. So let's start with a very simple one. Just some of those bits and bytes that I showed on the previous slide. Is that data, information, or record? So please use your chat screen if you can call that out.

Speaker: Or the question box. Just go ahead and use the question box if you can't find the chat. [Speaker: Yeah.]

Warren Bean: All right, we've got a vote for data. Yeah, this is a pretty good giveaway in this case. This is data for sure. Really no intelligible information at this point yet. So you got that one right. That was an easy one. All right, we'll expand that a bit, and we'll throw in some more zeros and ones.

So is this still just data, or have we expanded beyond that? All right, still showing a lot of votes for data. Yeah, for sure. And just so you know, this happens to be the binary representation of the letter W. So it is somewhat informational, but still looks kind of like data. But just so you know, it starts to blur the line already.

So I'm trying to mess with you there a little bit. All right, so kind of playing off of that, if we took the W and added some more letters to it, of course, all that's binary behind the scenes. Now, is this still data, or have we graduated to another level? All right. [Speaker: We're going back and forth between data and information here.] Yeah, we are.

[crosstalk] Which is kind of the point, right? Because you might still think... Yeah, because that could be the name of a document, right? Could be the name of a document. It could be the name of a person. It could be just part of a sentence.

So there's a lot of different ways that that could be used. So how informational is it? Yeah, it's questionable. All right. So let's give it a little bit more context. So now this gives us a little more information.

And here I'm just using the word [inaudible] [laughter] in my prompt. But is this still just data, or has it now graduated to information? Someone says it's a record. Okay. [Speaker: Well, it's the name of a record, for sure, right?] Yeah, it's something you could probably classify in your retention schedule if you happen to be keeping those kinds of things.

Okay. Yep. Some people are calling it record title. Some still say data. We've got information. So that one's a little more ambiguous.

All right. Let's try another one here. How about now? Okay, we're getting some feedback here. Lots of people saying it's information. Well, we get those responses. I think it's interesting to know that we all see that as a name, partly because we have a colleague named Will Fletcher.

But also, it just looks like a name. And to tell a computer why that's a name and not something else is kind of intriguing. It's hard to teach a computer that that's a name versus something else.

Speaker: Combining the fact that we've got Zasio there and Will Fletcher, and we know he's an employee, now we've got identifiable information. So maybe PII.

Warren Bean: Yeah. So it looks like most of the votes are for information. Good. All right. Let's throw out one more.

And let's see what people think of that one. All right. Looks like we are getting the vote for a record, which is also kind of where I saw that going, because now we've got a name, a date of birth, a Social Security number. Hopefully that's not a real one that I just plugged in there. I bet you somebody does have that, but who knows. Hire date. So that looks like an employee record, right? Someone's basic employee information.

So you can see how it sounds straightforward at first, but it's not necessarily, because it depends again on the context and what information you're putting together and whether that makes something that is elevated to that idea of a record. All right. Thanks for your participation. Let's go ahead and move on. And Jen, I think you've got this one.

Jennifer Chadband: That was fun. I think that's always really fun, trying to figure that out. Yeah, great transition into privacy. We just shared some of Will Fletcher's personal information with our audience. [laughter] So yeah, I think we can all agree that privacy has certainly complicated things. And I love this forget-me-not. It's kind of appropriate, not only because we're getting close to Valentine's Day, but it also happens to be the 10-year anniversary of GDPR this year, initially coming out.

And so I know we all have some kind of a love-hate relationship with GDPR, privacy and everything like that. [laughter] It certainly makes things complicated. When we're kind of thinking about privacy in the context of dealing with data records, applying retention, process-driven retention, I think we can kind of go into these different ways, or think about the different ways that it makes things more complicated for us. We have, for example, a lot of data subject access rights that have come about, different data subject rights, including requests to have information deleted. And this is relevant for some jurisdictions. How do we track that information down? How do we make sure that we find information that must be deleted across every instance in an organization?

That introduces certainly a complication there. Also, kind of the tension between maximum retention periods and minimum retention periods, privacy usually kind of driving those maximum and sometimes targeting specific subsets of personal data or information. Whereas maybe a minimum retention is telling us that for regulatory purposes, we might have to actually keep that information for certain purposes, whether it's compliance or reporting or various reasons. Maybe it's a personnel minimum requirement for records. And so that's kind of one of those struggles.

And then the data dependencies. We can have a core set of information, for example, on an employee or a customer, and that information, that data might be intermingled throughout different types of records, different processes, have different purposes across the organization. And so if we delete it in one place, how is it going to impact other things downstream? So that certainly makes things more complicated. And then, it's not always the case that certain categories of personal data or information are necessarily really directly addressed within the retention schedule.

Sure, they might be a component of a record, but on its face, we don't really have a category that says employee name, employee's Social Security number, or kind of these different specific subtypes of information data. And so that certainly, I think, complicates things, and we start to have to really ask the question: it's not really "can I delete it?" but also "when can I delete it?" as well. And so I think that in particular, as we get into the details on what the flow looks like and making these determinations in process-driven retention, it really is something that can help us address some of the complexities that come along with privacy.

Warren Bean: Yeah, it certainly throws a wrench into that whole idea of just, when can I delete it? Because sometimes you just have to.

[Slide: User Poll: How much has privacy or embedded data impacted your ability to implement your retention schedule? Options: Not at all; There are some records we can't destroy; There are many records we can't destroy; We can't destroy anything.]

Yep. So with that, let's take a quick poll and find out from users how this is impacting them. So the question here is, how much has privacy or embedded data impacted your ability to implement your retention schedule? So we will give that a few moments here. Getting some responses already. [poll] I get the fun part of watching the little meter kind of go up and down in the different categories. I don't know if the other panelists can see that, but...

Speaker: Yeah, I can see it.

Warren Bean: Okay, kind of fun. All right, we've got about 40% voting. We'll need to get at least to 50%. Almost there. All right, it's starting to slow down now, so I will give it just a couple seconds more and we'll share those results. It's kind of interesting how that played out.

All right, let's go ahead and share that. Oh, got a couple more still coming in. All right, I think we're good to go. Let's go ahead and take a look at that. All right, so I assume that you can see those results.

At least I hope you can. [Speaker: Yeah.] Okay, great. So quite a number of people actually said that it's not affecting anything, which is good to see. But as expected, that idea that there are some records you can't destroy certainly is the highest one. Some have said that there's many they can't destroy, and just a handful have said can't destroy anything. So it's definitely had a big impact in those areas.

All right, thanks for that input. And let's jump back into our slide deck here. So Rick, why don't you help us understand then what this new approach is about.

Rick Surber: Yeah, so this is the solution that we've come up with that we think is going to revolutionize things: process-driven retention. And it really is... It's considering the context of a piece of information or data, looking at upstream and downstream dependencies, looking at privacy, legal risk, all of these while assessing overall lifecycle, and looking to connect it to the category of records based on process that it may relate to. And so, to kind of summarize what Jen just discussed and what we just learned in the poll, privacy and data have turned recordkeeping from a puzzle into a game of Tetris. Systems are evolving, rules are changing fast.

If you're not proactive, those Tetris pieces are going to stack on top of each other and you're not going to keep up. So let's look at this model here, this new approach. So looking at this diagram down here, upstream is where data or information enters our world. Could be through a lot of different ways. Could be through a survey, could be through scanning a license.

Maybe it's a salesperson's diligent notes. Lots of different ways that information or data enter our system, and maybe aren't formally a record yet at that point.

[Slide: A New Approach: Process Driven Retention. "Process-driven Retention Management considers the context of a given piece of information by incorporating upstream and downstream dependencies, along with privacy, legal, and risk concerns when assessing the overall lifecycle." Diagram: Up Stream Processes → Data or Information (with Privacy, Legal and Risk) → Down Stream Processes.]

Once it hits our ecosystem, the pressure is on. Privacy rights, legal obligations, risks like security threats, they all demand our immediate attention. But we also have to remember that that data doesn't stay put. It flows downstream. It shapes employee reviews.

It's incorporated into contracts, whether they be with clients or vendors. Maybe it's even related to a pension payout decades later. So it's going to a lot of different places. Today's upstream data points might be a key piece of tomorrow's critical records, and that's important to remember. So this is where process-driven retention comes in and is the game changer. It connects the dots, tying data points to the processes and the records they create.

And then it uses our best friend, the records retention schedule, also known as our defensible deletion guide, to keep everything compliant, consistent and clean.

Jennifer Chadband: So, let's say kind of one thing there, Rick. One of the things I was thinking about when you first kind of introduced this slide is that I feel like it more closely aligns with how organizations are actually operating, because working with business units, working with end users, people who are operationalizing the schedule, they're not really thinking in terms usually of record outputs. They're thinking about workflows and outcomes, obligations along the way. And so I actually do feel like this, just by aligning retention more to the process, is just more intuitive and easier for people to understand and relate to the schedules.

Rick Surber: That's the hope. And that's also the hope of a process-based retention schedule as well.

Warren Bean: Great segue, because that's a perfect way to talk about some of those characteristics, Jen, because you've really nailed it as far as how it is different than the traditional method. So to begin with, as is obvious by the name, it is a process. It's a process in itself, because it's not just sort of a singular event. It's not a simple category that you just say, oh, I've got this thing, this thing is in the retention schedule, it goes away at this time, and we're all done. It's much more fluid and has a lot of different things to consider.

And also it takes into account more the purpose of the information. How has it been used? How will it be used? How is it being used now? Because as a piece of information flows through processes, its context can change.

And so that changes what you do with it and how you deal with it as well.

[Slide: Characteristics of Process Driven Retention: Process based methodology; Purpose driven; Holistic, fabric oriented (Metadata, Privacy, Security, Risk).]

So if you can think of this as more holistic and more sort of fabric oriented. That's a term that we've seen coming about more, and that is data fabric, meaning that it's kind of more of a mesh, if you will, where you've got metadata coming from different systems, and that metadata flows into different processes, and you've got to think about the privacy concerns, security concerns, risk management as well. So all of those things kind of are part of that fabric. You pull on one thread and it could make things unravel down the road. And you can also think of this as sort of positional or relational. So I call this GPS, in the sense of: you've got some people or systems that are generating information, like you mentioned in the beginning, Rick, that there are things that are coming from upstream flowing down. So those are the generators, anything that is creating information.

You've got processors, the applications and systems that do something with the data, whether it's number crunching, massaging the data, creating reports, whatever that might be. You're doing something with that information. And then you eventually store it, whether it's storing it for the purposes of backup or you've got it stored for evidence, all number of things. You've basically got that flow where it gets generated, processed and then eventually stored, and that's sort of its position within the system or that flow. And then lastly, true to the definition of information governance, it does break through the silos, because it's not just legal information or HR information or financial information.

All of it can be used everywhere. You think about a customer name, for example. That can be used in so many different contexts. There's no way to silo that and say, "Well, that's just IT information." "No, that's marketing information. No, that's customer management information." It flows everywhere. So it does really break through those different silos.

[Slide: Process-driven retention flow ("Can I delete this data?"): Start → Part of RRS? Yes → Follow the RRS → End. No → Downstream dependencies? Don't know → Check with process/system owner(s) → Re-evaluate. Yes → Keep until downstream records meet retention requirements → Default to downstream records destroyed or no longer dependent? No → keep; Yes/No dependencies → Does it involve privacy data?]

All right. With that, Rick, can you talk us through sort of what this looks like, nuts and bolts, how it actually works?

Rick Surber: Yeah, absolutely. And this is the flowchart that we have developed to kind of try to orient ourselves to a particular piece of data or information. We'll start off by asking, is it part of the records retention schedule? It's going to be easy if it is, because we'll go and we'll follow that records retention schedule if it's in there, and hey, that's the end of the analysis. But that's not really what we're here to talk about today. We're here to talk about where it's less clean, and where it's not part of the records retention schedule and it's not as easy.

And so let's say no, and then we'll go to the downstream dependencies. So we're going to ask, are there downstream dependencies, and what are the downstream dependencies? You may not know this, and that's what that little roundabout on the right there is. You might need to check with systems owners. You might have to check with the users of the system. You might need to check with the collectors of the data. You might have to do a little research, a little bit of background, a little investigation to figure out what the downstream dependencies are, because those are important.

And so once you've collected that information and you've re-evaluated, if there are downstream dependencies, which typically there are, we're going to shift left there. And we are going to default with the presumption that we are going to keep that data or information until the downstream records meet their requirements or the downstream processes are resolved, and that the data is no longer dependent on those downstream processes.

[Slide: Process-driven retention flow, continued: Does it involve privacy data? Yes → Work with legal/compliance to evaluate PII risk; Consider adding it to the RRS; Keep for no longer than necessary based on the original purpose for collection and in conformance to minimum and maximum privacy retention regulations → Can it be separated and deleted on its own? No → Anonymize/sanitize/consolidate, keep until related data destroyed; Yes → End/Destroy. No privacy data → Can it be separated and deleted on its own? Yes → Evaluate risk/benefit factors → Delete when no longer needed, or when risk level is too high → End/Destroy; No → Keep until related data has been destroyed → End/Destroy.]

So we don't necessarily have to make the decision yet, or we shouldn't make the decision yet, because there's still a second part to this analysis, which, if we go to the next part of this, is: does it involve privacy data? So we're going to err with the presumption that the downstream dependency... we're going to align to the downstream dependency or the downstream record, but then we're going to also ask at the same time, does it involve privacy? Because that's a crucial piece of this. And so if we're in the yes boat, which a lot of the time we are with these things, especially the ones that we're worried about, we're going to work with legal and compliance to evaluate the PII risk.

We're also going to consider adding that to the records retention schedule. I've got some clients who default to, okay, personal information, we're going to declare it as a record. There's going to be a place for it on our records retention schedule. That's just the posture that they take with it. But certainly every one of my clients is at the very least trying to be privacy-mindful.

And they're carving out some sections of their records retention schedules based on personal information, adding a little bit of granularity there to make sure they account for personal information and bring in some privacy by design into their retention schedule. So we're going to work with legal and compliance to evaluate that risk. And then we're going to default to GDPR, CCPA, CPRA (yeah, a mouthful) [laughter], and we're going to keep it for no longer than necessary based on the original purpose for collection. And we're also going to keep it in conformance with those minimum and maximum privacy regulations that Jen talked about when discussing privacy. And so that's going to be the default: we don't want to keep it for longer than the purpose for collection, because when we start to do that, we're going to get in trouble with the privacy regulators, and we're going to run afoul of the GDPR and the privacy regs.

So then we're going to ask, can this be separated and deleted on its own? If not, we might think about anonymizing, sanitizing, maybe consolidating it and keeping it until the related data is destroyed. We might not be able to do that, because it might be a crucial piece of the process or the record output. And so that's where we're going to end up. We're going to align to the downstream dependencies.

We're going to align to the records that are outputs, or, if it's a process and not a particular record, related records to that process, with privacy considerations in play. It might not contain personal information, and if that's the case, we say no up at the top of this page, and we go through a kind of similar analysis and say, can it be separated and deleted on its own? If it can, we're going to evaluate the risk and benefit of keeping it, and we're going to delete it when it's no longer needed or when the risk is too high. If it can't be separated, again, we're going to keep it until that related record or downstream process has been destroyed. So conceptually, that's the way that it works. I think this works a lot better if we explain it in context with some examples, and that's exactly what we're going to do, to give a little bit of context to this diagram and flowchart.

[Slide: Customer Energy Consumption: Example 1. Entity: Electric utility. Data: Hourly energy consumption logs collected from meters. Question: Can you delete this data? When? Investigative questions: 1. What are the record outputs? 2. What are the process considerations? 3. What are the retention considerations?]

And so for this first one, I'm going to be quizzing Jen. For the next one, keep in mind, not only is the audience going to get to pick the subject matter, but Jen is going to be quizzing you all. So you might want to pay attention, because you're going to be in the hot seat next. Jen's in the hot seat now. So our first example is going to be customer energy consumption related. And so our entity is an electric utility, and the data point is hourly energy consumption logs collected from meters.

Our question is, can you delete this data, and when? So Jen, investigative questions. What are some of the record outputs that hourly energy consumption logs collected from meters could be involved with?

Jennifer Chadband: Okay, so just kind of brainstorming different ideas here. Certainly as an energy consumer myself, I can say that this might go into billing statements. [Rick Surber: Absolutely.] For sure. That was an easy one, right? And then I can imagine that these are being used for various internal forecasting or reporting purposes, or maybe energy efficiency initiatives.

And I can only imagine how many different ways this type of information could kind of flow across different processes, functions in an organization. Sure, sales and marketing will figure out something to do with it too, you know. So, but yeah, those are kind of my record output guesses.

Rick Surber: Absolutely. Yeah. And you're talking processes, too. So you're answering that second question as well.

[Slide: Example 1 answers revealed. Record outputs: Billing statements; Demand/usage/outage reports; Energy efficiency reports; Usage forecast reports. Process considerations: Sales project management; Customer success management; Marketing project management. Retention considerations... (thumbnails of the two flowchart slides).]

Jennifer Chadband: Yeah. So, billing. Here we go. Oh, yeah. Sales project management. There we go. Customer success management, marketing, finance and accounting comes into play there. So, yeah, lots of different stuff.

Rick Surber: Yeah, you got that exactly right, Jen. Now, a lot of the forecasting stuff and the energy efficiency stuff is actually regulated. And so there are going to be regulated record outputs of those. Actually, pretty much all of these record outputs are regulated in some way by most state utility regulators, and to some extent at the federal level as well. And so, absolutely right. And there's probably some sales process considerations, customer success. All of those are going to be relevant.

And so when do we delete it? So let's walk through this process-driven retention flowchart and see how it works with this energy usage data. So to start off, is it going to be part of the records retention schedule? Maybe. There may be a dedicated category to it.

There may not be. But whether that particular data all flows to one record series... It probably doesn't. It's probably not going to be cut and dried, that we've got an energy usage category that covers it all. It's probably going to flow to multiple categories in the records retention schedule, just because of all of the things that we just talked about.

So we're going to say no. What are the downstream dependencies? We already discussed all of those. Jen did a great job of pointing them out. So we don't have to do any information collection at this point or re-evaluate. We can move right to yes, there are downstream dependencies.

So we're going to default to keeping that data until the downstream records have met their retention requirements. Now keep in mind, there are multiple. And so we're going to have to be careful about these data points and not deleting them before any of those records really have met their retention requirements, because they could be useful in different ways to all of them. And maybe different components of that usage data will flow to different records. Some of it can be deleted at some times, some of it at others. But our retention strategy for defensible disposition is going to be to align it to those records or the process outputs and keep it until they're no longer dependent.

But before we're done with that evaluation, we also have to ask, does it involve privacy data? Because that's another crucial factor. And yes, I think this very much does. There are a lot of different things that energy usage data can reveal, from things like whether there are medical devices plugged in in households, to whether there are potential illegal operations, maybe like marijuana growing or something like that, to maybe things just as simple as: this household seems like they've got kids, because every light in the house is on all day and the lights never seem to get turned off. Probably have some kids leaving lights on. I know that that's a situation in my house. I'm constantly walking around the house turning off lights. [Speaker: Sounds like you speak from experience.] [laughter] So it can reveal a lot more than you would think. And so we're going to work with legal and compliance to evaluate that personal information risk.

We're going to consider adding it to the records retention schedule in some ways. Now, adding a bucket just for this is going to kind of... it's not going to work well, but making sure that where it flows into the retention schedule, it's listed as potentially a high-level example, or somehow accounted for. I think there are some ways to incorporate it. And you could maybe carve out a category dedicated to that sales and marketing aspect of it and align that to no longer than the purpose for collection. But that's going to be our default for all of it. We're going to keep it for no longer than necessary based on the original purpose for collection. So maybe that's once the bill has been generated and the retention period for those billing records has run, just in case there are disputes on those bills and we need to go back to that data to confirm what we're billing, whatever it may be.

And then we're going to ask, can this be separated and deleted on its own? Now, that's where there might be some room for anonymizing, consolidating, sanitizing, for example, the forecasting aspect of it. We probably no longer need to know the exact names and addresses or user accounts, or however it's captured, of the energy users at that point. For forecasting, we might need to know where they're located, generally, to be able to account for those forecasting things, those outage-type contingency plannings. So that's a situation where rolling it up and consolidating it may very well satisfy our needs to be able to meet the obligations of that record and still keep the data.

So that's a good example of a time when it could be. Now, if it's related to a bill, we probably have to keep that user identification to be able to confirm the bill and support the bill, or rework the bill if that's necessary. So, great example of where some of it could be maybe consolidated, some of it can't be. But we're ending at destroying when no longer needed for both the original purpose and the downstream records, based on the process.

Warren Bean: And so, Rick, one of the things that I noticed in this process is that you could have multiple destruction points, because you could have, after consolidation, the destruction of the raw data with the PII that's on a short schedule. And then the other information that's maybe rolled up into hourly measurements by substation, that gets kept for one period of time. And then later on, you may only need the monthly rollup to be kept for forecasting, rate adjustments, things of that nature, versus, say, peak demand. And so, yeah, I can see different stages here of deletion, depending on the kind of data that you're getting from it.

Rick Surber: Yep, absolutely, Warren.

Warren Bean: All right. So at this point, we can again ask the audience to kind of name their own adventure. We've got a couple of options here that we can go through. So let me grab that other poll that went away.

[Slide: User Poll: Which example do you want to go through next? Options: HR Information System; Salesforce.]

There it is. And let's get your input on that: either an HR information system or something like Salesforce customer management. [poll] And actually, Salesforce is used for lots of different things now. So we'll see which one of these examples wins out. We have a little friendly bet on what we think the audience will pick. [laughter]

Speaker: I don't recall wagering anything on this. It's not a real bet. It's just a pretend bet. [laughter] Good comment in the chat about it should have been data related to the Super Bowl. [laughter]

Warren Bean: All right, we've got just about 60% voting. So it looks like it has slowed down. I'll go ahead and call it there. All right. So Jen, did you win your bet?

Jennifer Chadband: Yes, I was... That was my guess, and I was hoping: good old HR system. I think that's a really great classic example. And a lot of us can kind of... we've had some sort of visibility to this at one time or another, for sure.

[Slide: HR Information System: Example 2. Entity: Internal human resources department. Data: Clock-in/out logs for hourly employees. Question: Can you delete this data? When? Investigative questions: 1. What are the record outputs? 2. What are the process considerations? 3. What are the retention considerations?]

Big, big deal. So, yeah, great. Well, I am going to kind of poll the audience on these questions. You can go ahead and submit. I'll walk you all through this. And so let's see what you all think.

So first of all, let's talk about the data: clock-in/out logs for hourly employees, a very kind of granular type of information data that we're collecting there. And I want to get some ideas. What are, theoretically, some of the record outputs that would be related to these types of logs that we're gathering from employees? What do you all think?

Warren Bean: And I should set the stage on this, Jen, because I think there's a few different ways that this information could be coming in. It could be electronic logs of when people do their pass card at the door lock. It could be the old punch cards. It could be an online thing that you check in whenever you start your day. So there's a number of different ways that this information could be collected.

Jennifer Chadband: So true. There are so many different ways, thinking about the more traditional way where you just put your ticket in and it punches it in and out, versus, we even have clients who are collecting this via biometric information for various purposes. So yeah, that's a great point. I'm seeing some ideas here. So, pay stubs. Awesome. Yes. Payroll records might be implicated there.

Attendance monitoring. Absolutely. Security reasons. 100%. Overtime. Great. Security, fire logs. Safety logs. That's... Yeah. Wow.

This is even kind of way beyond what I was thinking about. So these are really good examples. Frequency of clock-in, clock-out. Yep. [inaudible] [laughter] Privacy. Security, payroll, time sheets. 100%. Wow. Lots.

So those are a lot of really good examples. Absolutely. I think they could all be verifiable record outputs that would include or implicate this type of information data. And the process considerations. I mean, these examples provided, these go even beyond kind of some of the processes that I was kind of brainstorming myself. Throwing it out to the audience: do we want to go through what these processes are that relate to the record outputs?

[Slide: Example 2 answers revealed. Record outputs: Timesheets; Payslips; Withholding records; Pension / benefits eligibility. Process considerations: Accounts payable; Employee time management; Payroll and PTO/leave management; Performance review; Benefits management. Retention considerations...]

Performance. Performance management. Performance improvement. Absolutely. I'll say this came up in a couple of the record output suggestions, but security management is one that I kind of had not been thinking about.

Let's go through them. All right. Pay management too, you know, payment management, potentially trickling into benefits in some way. I saw building safety, safety management kind of came into this equation, too. So that was a great kind of surprise.

So definitely all the different processes, outputs just points to how this is a complicated matter. We must go to the flow. Let's go through the flow.

Speaker: Yeah. And I think all of these and more were mentioned in terms of the comments.

Jennifer Chadband: Yep. Yeah. All right. All right. So let's kind of start here.

So this kind of granular log data, is it part of the RRS? I think on that type of level, we probably typically would not see it as having its own records category or explicitly addressed in a records retention schedule. But I think that's a little bit debatable, too. But for purposes of making sure we can kind of go through the flow, let's say, yeah, generally we wouldn't see that. So, no.

Downstream dependencies. What do you think, audience? Do we have downstream dependencies that we have to be thinking about with this type of information? Absolutely. You're right, Bruce. I think I agree with you. Mary says yes.

Yeah. Just thinking about those outputs and those processes, it's easy to imagine how tangled the web is that gets woven here, and how there's various dependencies across these processes, the cross-disciplinary idea: people are using this information for various reasons. So, certainly. So we want to keep until the downstream records meet those retention requirements. And so we'll go down here and think, kind of default to this: downstream records destroyed or no longer dependent? We'll kind of think about that.

And let's just assume that yes, those have kind of been met. And that takes us to our next question, and I'll put it to the audience. Does it involve privacy data? That might kind of speak for itself a little bit, but yeah, I think we all know where this is going. [laughter] Absolutely. Yes. So that kind of triggers us.

And this is kind of a parallel process, too. It's not necessarily running consecutively when we're thinking about privacy and working with legal and compliance to evaluate PII risk. That is also kind of part of that process flow when we're thinking about the information that we're collecting, because that is kind of part of that privacy by design.

Rick Surber: Yeah, that's a good point, Jen. The privacy and the system analysis: we've displayed it this way, as system first and then privacy, but in reality, they're running together. These both need to be gone through before you make the determination on what to do. That's a great point.

Jennifer Chadband: Yeah. Privacy being kind of embedded throughout this process, but it is a super important question when we're thinking about retention and deletion. And so we are kind of summoned to think about our privacy principle, enumerated throughout many different privacy laws. But we want to think about keeping this information really for no longer than it's been needed. So if our dependencies have been met, it brings us to kind of think about: can this information be separated out and deleted on its own?

And yeah, I think that might be kind of difficult, right? Because this is kind of employee-specific information that's used for that purpose. And yeah, that might be kind of difficult to do, but...

Speaker: I could see maybe having some records kept with personnel information, specifically for an employee, but others being consolidated. So, statistics on when generally people are arriving or leaving, kind of getting some of the more aggregated data analysis there if you needed to.

Jennifer Chadband: Yeah. 100%. And I think Michael brings up a good point. So, mentioned here in the comments: legal hold considerations. I think that is... it's not expressly included, I think, in the flow diagram, but it is kind of our overarching umbrella, something that we're always thinking about when we're thinking about retention and deletion. So that's a really good point.

Speaker: Legal holds put a hold on all defensible disposition activities. So that's a great point, Michael. That operates independently to throw a halt in all of our defensible disposition activities.

Jennifer Chadband: Absolutely. Maria brings up a good point. Yeah, that kind of plays into this piece here: when no longer needed. [laughter] Or when the risk level is too high. And I just would point to... Maria just mentioned this: the biometric information is totally concerning.

Absolutely, to that point. And I mentioned that some organizations are collecting this information. Maybe it's via fingerprints for entry into facilities, exit through facilities, et cetera. And that is high risk. It's definitely regulated.

We have some jurisdictions with maximum retentions on those. And even risks surrounding class action lawsuits for over-retention of that type of information. So that's a really good point, Maria. Thanks for mentioning that.

Rick Surber: It's a great example of where the maximum retention period will impede aligning to the record output, potentially, and it needs to potentially be carved out on its own. We see a lot of clients carve out a biometric category that just covers all of those records, no matter what process they're used in, and schedules them for a very short period of time, in conformance with all of those different laws that are aggressively short, and as they should be.

Jennifer Chadband: That's a great, great point, Rick.

Warren Bean: All right. So we've kind of gone through a couple of examples there.

[Slide: Customer Relationship Management Platform: Example 3 (shown briefly, then skipped). Entity: Sales department. Data: Customer email address. Record outputs: Sales quote; Order Summary; Contract; Renewal. Process considerations: Sales; Customer account management; Customer satisfaction; Legal. Retention considerations...]

I will skip the one we had queued up for Salesforce information, and we'll get into implementation. We've got just a few minutes left here, so I want to make sure we've got at least a couple minutes left for Q&A.

[Slide: Implementation: Foundational change; Steering committee (Interdepartmental, Risk analysis, Dependency analysis); Policy changes; RRS changes; System/data mapping; Aggregate data where possible; System onboarding/offboarding.]

But just a few notes about implementation, because, of course, this will be different for every organization, but just some things to consider as you think about how this might work. So to begin with, as the picture implies, this is a foundational change. So it changes the structure, perhaps, of how you consider retention, how you consider disposition, how you go about it. So that's going to have a lot of impacts in and of itself. So to start with, we do recommend in this case thinking about a steering committee, and that's going to be important, because you do have to have that input from various departments in order to understand the impact of how data is used, who's using it, the downstream, the upstream components of that.

So if you're not working with other departments, it's going to be hard to see that. And it will also involve a risk analysis. You may not know the potential risk of a certain piece of data, but someone from another department who works with that more closely might, and so you can be informed by that. And then it also just helps in that dependency analysis, so you know the various ways in which this might be used downstream, which of course will lead to potential policy changes in terms of how you guide users, the criteria for how things get destroyed, how you evaluate your retention schedule, a number of things at the policy level, which of course means your retention schedule might change. We talked about some potential carve-outs for things like different privacy considerations, maybe carve-outs for security considerations or risk considerations.

But also you might have to add to your retention schedule this idea of the system or data mapping. In other words, knowing not only what a record category is, but where it lives, or what generated the information, or who's going to use it next. That may not be something that you have as a category, but you at least need to have information on those categories to know where and how this data is going to be used. And we mentioned in a number of cases there something that tells you when the data might need to be aggregated. So you'll have to have decision points along the way to say, this granular PII data needs to be destroyed now, but we need to keep the aggregate of data for later.

Again, kind of just mapping to those downstream processes. So you have to consider some of those issues. And then lastly, building this into your onboarding and offboarding processes for different systems. So if you are evaluating a new system, make sure you have this kind of information tracked, or at least some checkbox to say that you've checked with the steering committee on how it impacts the retention aspects of the data in this system, and what's going to happen when you decommission that system as well. I know that's a lot of stuff just kind of thrown out at the end there, but just want to make sure that we at least have some visibility on the implementation implications there.

[Slide: Questions? Rick Surber, CRM, IGP, Licensed Attorney, Senior Consultant, rick.surber@zasio.com; Jennifer Chadband, CRM, IGP, CIPP/E, ECM, Senior Consultant, jennifer.chadband@zasio.com; Warren Bean, CRM, CISM, VP of Technology & Product Development, warren.bean@zasio.com.]

So with that, we've got just about two, three minutes for some questions.

Jennifer Chadband: Okay. Yes. If you want to get a question in, please do that now. Rick, we did have one question come in regarding your process-driven flowchart. [audience question] The question was, "Many companies would look at this process and see if a process can be fed into AI.

Would you recommend using AI to help evaluate the information that is not part of the RRS, or would the risk be too great?"

Rick Surber: I think that this would be a potential use case for AI, prompting it or creating an agent that goes through this evaluation and is helping brainstorm downstream record dependencies. Of course, every time we're using AI, we would need to look at it critically and make sure that it's not including things that aren't relevant or getting things wrong. But I do think it could help with the analysis on this, absolutely.

Warren Bean: One comment on that I have is that in order to do that, the AI system would have to have visibility to all of the systems and processes and data flows.

Rick Surber: Oh, I don't know if I would do that. Unless that's already set up, I don't know if I would do that. I would do it at a higher level of brainstorming the downstream dependencies, understanding where the record would flow, and aligning at a high level, not at a seeing-everything level. Well, you may already have AI systems that are set up that way, and potentially you could leverage that. I wouldn't set that up to access the entire system just for this.

Warren Bean: Yeah, maybe you feed into it just the flowcharts and things you have. Sorry, Jen, go ahead.

Jennifer Chadband: No, I didn't mean to interrupt. I was going to say, I know we're running really short here on time, but we also had another pre-submitted question, so I wanted to make sure we got that in. [audience question] This individual said, "We're looking to revamp our decision tree to not only include 'is it a record?' but 'where does it go?' Any tips or an outline that you would recommend for this?"

Rick Surber: Yeah, that's a good one. I think that that depends on a lot of things. It depends on your records retention schedule. Well, it depends on what the question is getting to, whether it's aligning to the correct category in the retention schedule or finding the correct place within a file plan or a system to store it. And so all of it is dependent on the particular situation of the person trying to set something like this up.

If it's to the retention schedule, there are some high-level decision tree things you can ask. Like, if you're a big bucket retention schedule that's process-based, an initial question could be, is it core, vertical, or is it industry-specific? Things like that, to align to the category. If it's system or file plan related, it would really have to be dependent on the way those are structured. And so that's a great question.

Warren Bean: I think those are possible, though, decision trees like that.

Jennifer Chadband: Yeah, I agree. Okay, let's do one more question. I know it's the top of the hour, but let's try to do one more question. Drop if you have to. [audience question] [Speaker: Yeah.] "Many process management systems don't allow purging or deletion of data.

The resulting documents created from the system can be assigned a retention period, but the core information still exists in the system. What do you recommend for managing these types of systems?"

Rick Surber: That's a great one, and we work with clients on that all the time. You have to be careful about setting retention in a way that doesn't conform to your reality. But you also have to be careful not to use system limitations as a way to kind of impede doing the right thing and scheduling based on purpose for collection in accordance with privacy, based on regulations. So there's a balancing act there. I think most systems are working towards allowing for disposition in accordance with GDPR.

I know all of the HR systems are moving in that direction, but still have limitations. So it's really a risk balancing act of trying to set up the retention schedule to conform with the reality while still moving in the direction of doing the right thing based on the legal requirements, the business need, and not over-retaining personal information. But it is an inherent risk in our business, that is the software business, because most software systems were not built with that in mind. They were just built to capture and maintain and use the information, but then it was an afterthought to say, "Oh, we have to get rid of this at some point."

Warren Bean: Yeah. Yeah, more and more it's a consideration, I think. So then you also just think about your onboarding process for new systems software. Make sure they have disposition capabilities, and just work towards that.

Rick Surber: Hence that onboarding question.

Jennifer Chadband: Absolutely. Well, Warren, I want to thank you. You are the highest guest-rate presenter that we have. I counted it up, and I think this is your fifth Virtual Coffee appearance. [Speaker: Yay.] So, thanks again.

It's always [inaudible] to have you on Virtual Coffee.

Warren Bean: Glad to be here. It's a fun topic.

Jennifer Chadband: It is. Yeah.

Warren Bean: Thanks for letting me join.

Jennifer Chadband: Stay tuned. I think we'll have a Virtual Coffee in April, is what we're targeting, so stay tuned for more information on that.

Speaker: Yeah.

Jennifer Chadband: Thanks, everyone.

Speaker: Thanks. Thank you.