What the Flock is a Data Map?

Key Takeaways

[Music] Hello and welcome to another episode of eiscocovery chicks, the podcast about all things eiscocovery and legal tech hosted by two gals who really need to not go on planes for a little while. Anyways, we're your hosts. That's Bri and that's Angie. I've had like I've missed two flights of my last two trips that I've taken. Oh my god, you're 0 for two. Yeah, I've never Well, actually that's not if we don't count the one time last year where I flew to the wrong state. I've never missed a flight. This time I was in Wilmington at Techno Security and it's a small little town and like literally the airport is 11 minutes away. How in the world does somebody miss this flight? Do you know how it rains? And when it rains, no Uber drivers want to come get you. And then when they do show up, all of a sudden, your whole entire road like shut down because of a goose crossing. Mama goose and daddy goose had all their baby little gooseies with them and they were going back and forth across the street and would not move. And we're like honking the horn. We're like I'm like, "Oh my god, I'm have to get out in the rain and move these geese so I can get to the airport." And I get to the airport and it's so small that the same people that check you in at the United Counter are the people that open the door to the plane and get you on the plane. And they had already gone to the plane. So there was nobody to check me in. I'm like, "But it's right there, bro. I could just go over there and they could check me in over there." And they're like, "Yeah, no. That's not how this works, ma'am. You need to check your bag." So I Yep. I I missed my flight. Oh my god. That's the dumbest reason I've ever heard for missing your flight. Yeah. But once again, a plane a goose. Duck duck goose. And once again, Delta saved me. They're the same airline I was on when I flew to the wrong state and they totally worked it out for me. So you called their customer service and they're like, "Oh, this again." Yeah. They probably put me on like some sort of flag on my file. Be careful for her. You're on a list. She does weird things. Exactly. Not a bad list. Just like a she might need some help list. She's a nut job list. She No, they just happen to be the next literally there's like two people that work at United and the next desk over is like two people that work at Delta and I'm like, "All right, I guess I'll start here. Do you guys have a way back to get to Houston tonight?" And the first option was $1,900. But then we found one for $300 and something dollars. I was like, "Okay, that sounds a lot more reasonable. Thank you." Oh my god. Yeah, I'm still stuck on this goose. When it was happening, I'm like, "Of course, of course this is going to happen. So, I'll just get a goose magnet to put right next to my Columbus Georgia magnet on my refrigerator. Anyway, oh my god. But you had fun on a on an airplane trip recently. I did. I did. So, last Saturday, my little brother texts me and is like, "Hey, I'm getting married on Thursday. Like, any chance you can be there?" And I was like, "Wow, thanks for the heads up, bro." Well, yeah. And he I was like, "Wait, what?" And he's like, "Yeah, sorry. I think I dropped the ball. Well, I meant to invite you like three times and I just forgot. I don't know. But anyway, what are the odds? Like, it's my brother's wedding. Of course, I'm going to go. I'm going to be there, but we don't have the child care infrastructure is not there. So, my only option is to take the three and a halfyear-old with me, you know, fly with her, whatever, do the whole thing. She's great. She's like an A+ traveler, generally speaking. But on the flight back, she's tired. She's decided to skip her nap like two days in a row. And so she just melts down. Biggest meltdown of her life. I had to physically restrain her from before we pulled out of the gate until the first drink service just bear hug her so she would stay in her seat. And she's screaming and I'm just embarrassed as all hell. I feel terrible. But I feel terrible for her too because she's so overt tired. I'm like, "It's not even your fault, kid." Oh, but I also feel bad for everybody else on the plane that has to deal with you. But anyways, after all this and the plane is like a million degrees cuz you know what that happens like for out of nowhere the plane is just like 80° and you're like no like this is gross. I'm breathing everybody else's air. I'm wearing a tank top. Everything is sticky. I don't know. I've got juice on me from my top. Whatever. Anyway, so I just decided to get drunk on this plane cuz it's just like Harper falls asleep. She falls asleep and I'm like, "Eespresso martini now." And it was like it was so bad that like the flight attendants came over and were like, "Do you need anything?" Like, "Are you doing okay?" And like multiple people turned around from their seats and they're like, it was like that that Chris Jenner meme of like, "You're doing great, sweetie." to me. And I was like, "Oh my god." So yeah. So I just started pounding espresso martinis. And then John picked us up at the airport and I was like, "Here you go. Your problem." Oh my gosh. Uh, did they make you pay for the espresso martinis? Like, how sorry for you did they feel? But they did not charge me. That's how you know things were really bad. Like the flight attendants on the house. They're just like, "You need this more than we need the $8, right? Can you slip into your daughter?" Yeah. They're like, "Give me a little whiskey thing." And they're like, "Just rub it on her gums. It'll be fine. Just make her be quiet." Our poor children. She Yeah. Well, you know, it's kind of ironic that we decided to talk about planes because planes must follow a map to get to where they're going. And today, oh my god, that was the dad joke of all segways. But yeah, let's talk about data maps. Our our plan was to talk about data mapping. And thank goodness you don't have to be on a plane to get there. So with today's planned episode was data mapping. And the reason why I like this is actually my fault because I have been speaking at several different conferences like I was at technical security last week. I was at the Arman conference um the la the month before that uh was somewhere else. I can't remember oh it was women discovery that that it came up again. Every time that I get somewhere and start talking about how everybody in organization needs to get at the same data, the topic of data mapping comes up and people have asked me all different kinds of questions about it. And sometimes the questions are like, "What the is that anyway?" Because they don't really understand what I mean by it. And it's become one of those terms that I feel like we're using very loosely and we all might not be talking about the same thing depending on who's saying it. So that's the reason for the topic today, boys and girls. I hope that you uh could buckle in and if your oxygen mask drops, you should use it first before helping your before assisting others. Um but what what is a data map? So when we talk about data maps, we're talking about it from the corporate perspective, Angie and I are today. So, when a company talks about a a data map, it's really like a detailed inventory or like a visual layout um that shows everywhere where a company's data lives or resides. There's going to be a variety of different formats that people use to accomplish a data map and we'll talk about that a little bit, but it's going to include details like what type of data is in this application or in this data source, what is the access that's been provisioned to the end users, who's able to use these applications or whose data does this belong to, what work processes are involved, and what are the contents are is there any, you know, private information here, confidential information. Is there personal identifiable information, PII or health information that's included? And then who owns it? Who is the data steward? That's a term that gets used sometimes. And then another another uh differential is who's the business owner versus who's the IT owner. So, we'll talk about that a little bit. And where does this data reside? What's the jurisdiction? So those are all things that we're trying to map out when we are talking about a data map. That is exactly right. And then as far as the question of why, you know, why do you need one of these and what makes them not terrible? Um that kind of depends on your discipline. For legal and eiscocovery pros, data maps really help prepare an organization for litigation. I'm I'm using the term litigation pretty broadly there. or by that I mean you know any kind of regulatory request or adversarial matter um or internal investigation. But anyways when you have a data map your legal imple your legal hold implementation is faster because it's easier to identify the systems that need to be preserved and then it's also more precise because it reduces over broad and underinclusive preservation. It's kind of like you know what you have and where you have it. And so if you were to go and this is going to be a really lame analogy, I apologize in advance, but if you were to be like, "Listen, I need to preserve all the ingredients I need to make banana bread and I don't really know where any of them are. So I'm just going to like seal off my whole pantry." Well, maybe your bananas are out on the counter and so you miss them. And also, you don't need to preserve all the other crap in your pantry cuz it's not necessary to your banana bread. So that's kind of what I mean by over broad and underinclusive. Bri's shaking her head at me right now like you. No, I just want banana. No, I'm like I want banana bread. I need it warm with a little bit of butter on top of it. Toasted so it gets a little crispy. Mhm. Let's do it. Also, having a data map will reduce your risk of foliation because again, you know where your data is and you're less likely to overlook relevant data. All right, I'm sorry. I'm reviving the banana bread analogy. It'd be like if you seal off your whole pantry to make banana bread and then your husband throws away the bananas because they're on the counter and they're he's like it looks like they're going bad and you're like, "No, but that's the way I want them. It's nice and brown for the banana bread." You want to make sure that none of your data or bananas get thrown out on accident. And then finally, having a data map will speed up your early case assessment. It's easier to know how much data you're working with, its status, etc. So you kind of know the volume and then you can also be aware of any data that might bode very well for your case as well as your soft spots. So you're talking about the legal perspective here. But in a corporation, having a data map is actually beneficial for more than just corporate legal or for legal professionals. Actually, it's very helpful for everybody else that works at that company, including IT andosc or information security professionals. It's important to them because they need to be in charge of where all of the sensitive or at least know where all the sensitive and at risk data is. Why? What happens if there's a security incident, for example? They are also tasked with uh manning or womaning. Oh, can I tell you one of my favorite acts of feministy microaggression? Okay. I'll refer to them as a male police woman or like a male firewoman. Um, and then whenever people talk about sports, I just assume they're talking about women's sports and I'm like, "Yeah, but how's the men's team doing?" They're like, "Wait, what?" Um, okay. So, back to today's topic, IT and infosc. It's important to these professionals because they are constantly responsible for understanding where sensitive data might be or where data might be that's at risk. They are also trying to prevent loss when we're talking about data that's being used by third parties or data that's on devices or data that's in areas that are not protected for example. Those are all fall under the umbrella of your information technology infosc folks. They're also the ones that are responsible for decommissioning legacy systems or enforcing data retention policies on applications. They're the ones who are building out internal IT workflows like for on and off boarding employees. They're also the ones that are very highly involved with auditing their own IT policies through an audit department or sometimes there's a separate IT auditing group um where you're making sure that all of your internal procedures are actually being carried through in real life. So it's important for IT professionals and and folks in data security or infosc however you want to refer to it. It's important for them to understand the data map. Also privacy and compliance folks these guys are interested in understanding data as it's required for privacy regulations like GDPR and CCPA. It's actually a requirement that they know where all of their data is. is they can report on where data might have personal identifiable information or PII. They are the ones that are responding to data subject access request or DARS where someone says, "Hey, I want to know everywhere where you have my data and I want a copy of it or I want you to get rid of it. I need to know." They are also the ones that are often they always come in that tone of voice too, like a howler. They do. Well, you know, it's so funny because when I first started dealing with DARS, I was like, uh-uh, this is not a real thing that people want to know unless they are an employee at a company and they want to know what their boss said saying about them. That's what this is. I know what what's going on. That's an interesting use case. And those are the ones that are actually the most problematic because they they cannot be easily backed down through like an appeal or or whatever. Anyway, I digress. Also we have our compliance professionals who are responsible for like infoggov like how long are we supposed to be retaining data. They create the retention policies. They also have data custodians throughout the company who are responsible for making sure that we're not holding on to records longer than we need to be holding on to records. But long story short, everybody in organization benefits from the the existence and the validity of a data map. Yeah. I mean think about it this way. Like if you were in charge of preserving data and you get like a a subpoena or something and it's for like a broad swath of data that involves multiple systems, then you're just sort of like fumbling around your org talking to different people trying to figure out what data you have and where it lives. And that friends, I have done that. That is a laborious process, especially when you're dealing with like 50 different systems and all of them have a different system administrator and different retention policies and different access issues and whatever. So, you really need a data map to simplify that process. I've done it the manual way and I think it takes like a 100 plus hours. I mean, it was massive undertaking. I mean, it's sort of like a library catalog. Without it, you're just pulling random books off the shelf hoping to find something. So, anyway, Bri, how do you make a data map? This is where things can get a little hairy because depending on the size of your organization, we could be talking about a whole heck of a lot of data that you somehow have to wrangle. In Texas, like we say, wrangle in the wind. It's an impossible task. So, I mean, you've heard me say that before. Is that like a thing in Texas? It's like, it's a saying. It's like wrangling the wind or hurting cats. I mean, people say that. Wrangling the wind. I thought you said wrangling in the wind and I was like pretty sure cows are heavy. Why would that be a problem? Or roping the wind, I guess, is another wrangling. Come on now. He All right, this makes a lot more sense. We love it. Anyways, back to wrangling the wind. Oh, we're ro Oh, fine. Maybe I should say roping the wind for you northerners. So when we go about creating a data map depending on how large our organization is will depend the next steps and we're going to talk a little bit more about that in greater detail later but it could be anything from uh a spreadsheet to you hire multiple consultants to help you get your act together because woo step one is we want to take a system inventory and I I said it's it's a family event and they spoiler alert they all need to be at the table. All the systems. Yeah. All the systems. Even your weird uncle. Exactly. I was about to say you're going to have to call your toxic aunt and tell her the list her systems and and or maybe the toxic aunt is the hoarder with like the boxes of paper under her desk. I don't know. God, you're going to have to get in touch with all the people in the family and all the personalities and all the business units, all the application owners, and everybody's going to have to weigh in. What do you guys got going on in your business unit? What do you have going on in yours? It what are you aware of? HR, what are you aware of? Everybody has to show up and take an inventory. And that can happen in a variety of different ways. But we want to remember when we're talking about data mapping, we're literally talking about everything from your email platforms to cloud storage to like Box, Dropbox, One Drive, your HR tools, your chat tools, your databases, share drive, your bring your own devices. Like try to try to wrangle that one. We also have to deal with things like IT departments that are very siloed. A lot of times the left hand doesn't know what the right hand's doing. Even in our own IT departments, trying to address how siloed are we anyway. We have to go out to individual subsidiaries. Maybe we are a company that's grown by acquisition and every acquisition seems to have a different way of doing things and a different set of applications. Those are all things. Yeah, those are all things to consider and those can be super painful. business units. What's happening in claims is different than what's happening in marketing is different than what's happening in accounting. And everybody's using a different application for a different use. Trying to keep an inventory of what all those are. Pro tip is to ask it at first because a lot of times IT folks are going to have already started with a list of systems that they're aware of that they support. So, I'd suggest if you're starting to start there so that you don't have to reinvent a wheel that might already exist and then separately go out from there to verify what they have and add to it. Pro tip number two is don't be afraid to get help. If you get involved with this and you're like, "Bruh, we have a hundred subsidiaries all over the world. There is no way our corporate department legal department can do this or whoever is tasked with this can do this. We need to go hire a consultant who does this every day. who can help us project manage this whole bad boy and get it done. Yeah. Well, and I mean I think to that point, Bri, is that this can be such a huge undertaking. I mean, imagine you've got like a hundred different systems for your organization. And that is not an outlandish number, y'all. That is like a pretty normal number of systems. Um if not on like the small pretty low, it's a pretty low number of systems. Yeah. So, I mean, imagine you have to go interview a hundred people. Each of those interviews takes at least half an hour. I mean, just start adding up that time and then you've got to figure and then it's still all manual and it's horrible. Anyways, there's also software that will do this that's like amazing. Um Oh, yeah. There's that. Oh yeah. Also, okay, so step number two, you've inventoried your systems, you got a list of people associated with those systems, whatever. Step number two, interview key stakeholders. Like Bri said, talk to it because they know the infrastructure. Talk to legal. They know the risks. Talk to privacy. They know the regulations. And talk to HR, marketing, finance, finance, and ops because they know all the workarounds. And when you're interviewing these stakeholders, ask openended questions like what data lives in your system? Where do you store documents? How do you communicate internally? Who uses this system? What tools do you use to share files or collaborate? Honestly, I think a great use case for AI if you are doing this manually would just to be to go to chat GPT and say, "I'm creating a data map. I'm interviewing stakeholders from these departments. What questions should I ask them about their systems?" And see what it says. That is so millennial of you. OMG. Guilty. Step three, some of the same that Angie just mentioned. when you're interviewing your key stakeholders, you want to identify the different types of data and the different custodians. So, when we're talking about this, in addition to what Angie's already said, we want to be thinking about where the data lives. Is this in China? Is this in Russia? Is this in the United States? And what's in this data? Is there anything specifically that we need to be concerned with that's sensitive? Or is it business records? Is it contracts? Is it performance or repay? Is it performance reviews etc. A lot of times we can leverage classification systems that already exist. You know you might have that already through Microsoft or some other um system that your company's using where you can identify hey this is a business record or this is an internal document or this is confidential. I would say be smart and utilize that stuff that already has been identified if you can. Um, we also want to think about data that's linking to outside sources. You know, are we using a vendor to host data somewhere? What is that and what type of data is being hosted there? And also think about who the IT and business owners should be that you should be talking to. When I say an IT owner, a lot of times that's the person who's responsible for attesting to that application and managing the backend, the technology of that application. The business owner is actually who's the business unit that's using this. Let's say Salesforce for example. The business owner might be sales because they're the ones that are actually utilizing Salesforce and keeping notes and yada yada. But the IT owner might be like a Salesforce admin or an engineering person that's in the in the IT department that's actually responsible for the way that that application behaves in your company's environment. Yep. And so after you've done all that, step four is going to be to track access flow and retention. So you're going to want to ask questions like who can access what, when can they access it, and how? Is there any encryption? Are there public links? How does this data move across systems? So for example, if something is uploaded to SharePoint and then emailed to vendors and then downloaded to laptops, you want to know how that data typically moves. And then you also want to know what the retention rules are and most importantly whether they are actually enforced. Is data piling up in legal hold purgatory or is it actually getting excised at the end of its retention period? Data mapping isn't just about what exists. It's also about how it moves. You wouldn't just map a castle. You'd want to know where the secret tunnels lead. And I say that because I'm a nerd. And I think that would be really fun to know. Yeah. I I mean a data map I think one of the greatest misconceptions is that it's a static one time thing or once a year thing. It's kind of like a living breathing animal to be honest because there's constantly things changing. There's constantly things that need to be updated or attested to. Sometimes when people first get started with making a data map, they're talking about a spread a spreadsheet or a glorified spreadsheet. They're passing around all the different business units or users um so that they can fill out the information for their particular application. That's where a data map a lot of times starts. But the bigger your organization is, the faster you come to the realization like this is not the most efficient way of doing this. I would say if you have 20 systems or more, you probably need to divorce yourself from the spreadsheet idea and then utilize technology. And when I say technology, there's a couple different ways of looking at that. One might be technology from the standpoint of your IT folks where they've got a change management platform where they've already created some of this because in a change management platform, people have to go attest to different applications on a regular basis. And sometimes this is because of regulatory reasons like through GDPR and things of that nature where you have to have the IT and the business owner show up on a regular basis and say, "Yep, this is still an application. It's still active. We're still using it this way. I can attest to the fact that we do have health information stored here and that it resides in the United States or whatever. You're going to have uh that information that's being managed in a change management platform like that. So if you have that already, great. then then utilize that for your benefit. You're also going to have software from companies like ones that are very close to my heart that have you know data mapping technology that's available for your entire company to benefit from too. So if your IT team doesn't already have something in play, certainly those tools are on the market today. My advice tip would be everybody is on the same page. And if it is utilizing something, then make sure your eiscocovery tools and your your tools that you're using for eiscocovery can talk to and sync with what is in play or see if there's a tool that you can both use together that meets your needs. Yeah, just to circle back to your point, Bri, about this being like a living thing. I was at an org once where we implemented Slack Enterprise which is like their premier tier or whatever and it allows you to set retention policies. Um, and so we did that and then later discovered that the engineers sneaky devils were like we want to retain everything forever though and so we're going to go ahead and just like figure out how to rewrite the code so that we can do that. And it was like oh okay yes we knew we were using Slack. We knew various teams used it in different ways, whatever. But it was like discovering that sort of secret passage that that allowed us to really sort of figure out our data map in a much more useful and comprehensive way. Mhm. We have talked a lot about you're going to need to interview different system admins and people and whatever, but let's move to talking about some specifics there. Who actually needs a seat at the table when you are creating a data map? The TLDDR is it's a lot of disciplines. I'm going to go back to banana bread. So, it's like making banana bread, right? So, like legal would be in charge of bananas. It would bring the flour. Infosac has the eggs. Privacy and compliance have your sugar and the business units are your baking powder. And like the banana bread will not come to fruition unless you have all of those people there. It's not going to taste right and nobody's going to want to eat it. So, you better bring them all if you're going to make a data map. So, Bri and I have actually developed our data map dream team and we're going to go through those people right now and what they do and why they're important. So first up is going to be legal. Uh legal drives the initiative. They understand the litigation risks and they ensure that the data map is defensible. Now legal may not fully understand where all systems live or how data flows but they understand the why. Why we need a data map and it's up to others to clarify the what and how. Next up we have it. It knows where the s what systems are hosted, what data exists, how the systems integrate with each other, and what's active versus what's legacy data. Now, they might not always understand the legal or privacy implications of certain data types, but if you involve it early, they will give you the boxes that you later need to check. Yeah. And I would say it, which also bleeds over into infosc or data security, which is our next uh category of folks that need to be at the table. uh they're also in charge of IT workflows where data is going how data gets provisioned and those types of workflows within an organization. So another reason why they should be there infosc or data security in particular is going to understand things like access controls encryption vulnerability risk uh they're going to be the ones involved for the tabletop exercise for breach response uh and the protocols associated with that. They're going to focus more on protection than discoverability like our legal folks would would, but you'll need their input to prevent exposure of sensitive data during eiscocovery or a DAR response or otherwise. Then we have the privacy folks, which privacy and compliance are being grouped together here a little bit and some of that's fair because both of them are going to be manning or womaning the uh retention policies and kind of carrying through those data retention workflows. Privacy is going to be wearing the hat under GDPR, CCPA, HIPPA, that sort of thing. Um, and they are going to understand the regulatory require hi regulatory requirements there. They are also going to be understanding the workflows and internal policies as they might relate to DARS and and that sort of thing. Compliance is going to be really dealing with data retention. They are also going to be helping with making sure that you're actually complying with all of the policies that are out there. Bring your own device and ID policies and legal hold policies and yada yada yada. I said that the infosc folks are voted most likely to be the driver of a tabletop exercise. I say privacy and compliance are voted most likely to forget implications of legal holes, which is probably like really mean of me. But the reason I say that is because a lot of times they get so in the weeds with retention policies that they forget like we have to also check if it's on legal hold. Then we have our rec record records and info manage info management folks. These are people that are actually managing uh the retention schedules archive systems um life cycle planning for documents etc. They are voted most likely to key your car is what I said. But the reason I said that is because the people that are actually carrying through records retention are the people that will get so mad if you do not comply with whatever legal hold or your compliance your retention policy and they are done with you. Like seriously done. So that's why I said they're most likely to keep your car. Unsubscribe from your shenanigans. Exactly. Uh okay. And last but not least, we have business units. So this could be your HR, your finance, your marketing, your PR, you know, whoever else. Now, these departments often use shadow IT, which is sort of like creating unstructured data in surprising and undocumented places. And they may not realize that the data they generate has legal or regulatory implications. So be sure to interview them and include them in math beam workshops. And don't assume that everything is centralized. The point of us giving you this dream team is to highlight that collaboration will cure your blind spots. Every single one of these players has their strengths and their weaknesses. And that's not a knock on anybody. It's just that we all have kind of have our lane, right? And so you want to make sure you include everybody. Well, we all show up to the table with our different perspective. It literally is like a family reunion. But how can we make friends without having to bribe them? Haha. Come on over, guys. You'll like what we're serving. We got banana bread over here. Yeah, we do. Here's some ways that you can collaborate well with one another so people enjoy the the experience and don't dread it. Number one, show up curious, not commanding. I cannot tell you how many times I thought I had it all figured out. I thought I knew exactly what to do and then all of a sudden somebody offered up their perspective and I'm like, "Oh, well, I didn't know that was actually happening." Well, that changes everything. Show up curious. Do not make assumptions that you've got it all figured out. Explain the legal why. So a lot of times eiscocovery folks are really they understand legally speaking why we have to do what we have to do. There's going to be risk or cost or reputation that is on the line, right? So as long as people know why they're being asked to do something, they are much more willing and happy to comply. Don't assume that they under they understand that why. Respect their time, please. and speak a language that shows them that they win, that makes them the rock star. Do not waste their time or waste your words confusing them because that is obviously not something that anybody appreciates. Understand the big picture. Understand that every single person that you're talking to actually needs to get at the same data for a different reason. It's not just about you. It's not just about legal. It's not just about eiscocovery. We all have to share our data. And so we need to play well together, boys and girls. And don't play in the sandbox and share your toys. That's right. And don't be a crazy hoarder. Oh my gosh, legal people like get rid of stuff when you're supposed to. Eiscovery and legal are so bad about doing that cleanup work and being diligent about, hey, attorneys, do we still need to have this legal hold? Yes or no? Then let's defensively delete it, please. And let's communicate that. That's how a way that we could actually play nicy nice with the rest of the family at the table. Yep. Absolutely. And so because this is an eiscocovery centric podcast, let's talk about why data maps are so important from an eiscocovery perspective that is spoliation horror stories. If you've ever preserved the wrong data and deleted the right data, you already know the punchline of this segment. But for everybody else, this we're going to move on and talk about why data maps aren't just nice to have. They're how you keep your job, your client, your dignity, and how they keep you out of hot water. All right, so let's talk about four highstakes use cases for data maps where these are really going to make a difference. So number one, legal hold compliance. We've kind of touched on this, but you need to know who your custodians are, where your data lives, what systems you're using, etc. So you preserve the right stuff and don't overpreserve. Now, if you skip this step, data could get deleted, opposing council could find out, you could get sanctioned and cue the awkward silence in the courtroom. And the ne So, the next use case for data maps is going to be a faster response to subpoenas and investigations. Regulators and opposing parties don't give you months to figure out where your data lives. And trust me, it could take months depending on the volume of data that we're talking about. So having a solid data bat means you will be able to more quickly identify responsive data scope more accurately and there's just like less chaos for internal teams. And finally having a data map will allow you to scope your eiscocovery in a costefficient way. The better your data map the more you can narrow your scope intelligently. That means we lessen the risk of overcolction. We have fewer irrelevant custodians. less data gets processed and reviewed and at the end of the day your costs are just lower and as we all know eiscocovery is often the most expensive part of a litigation and so to the extent you can lessen those costs you are also going to lessen the cost of litigation. So you know one thing we love to do in eiscocovery is we love our search terms. If we can understand our data map, we know how data is generated and stored, we can understand what might be important like metadata fields, naming conventions, communication platforms. If we can understand all of that, then we can be smarter about the search terms that we use and avoid those uh relevant hits and reduce the false positives, stop boiling the dang ocean every single time. If the data map, for example, shows that the customer complaints were handled in Zenesk, not email, now you don't have to waste time going through complex Outlook queries. You can focus where the signal is and not the noise. And here's a tip. Combine data map insights with custodian interviews to fine-tune keywords by platform, time frame, and data type. Ooh, that's brilliant. We love to work smarter, not harder. Having a good data map will also strengthen your position during meet and confer or negotiations or investigations. So when you can clearly articulate to opposing council to a regulator what data exists and why you're excluding certain sources, for example, they don't have relevant data in there and here's why. Then opposing council with a regulator is far less likely to challenge you on that. And courts are also more receptive to reasonable limitations on discovery when they are grounded in documentation. And nothing shows proactive diligence like a data map that will get you brownie points with the court and can help you narrow your data sources in a way that will drastically reduce your costs. So everything that we're saying all sounds nice, but we all know in a corporation the most important thing to do is to get buy in. Because if you don't have buyin from everybody involved, then all of a sudden you're sitting down at your family reunion and somebody didn't show up. So we want to get buy in from you traumatized by a family reunion. You have no idea so many years of counseling. But anyway, we want to give you some tips to get some quick buy in. So number one, remember who you're talking to. What are their business priorities? For example, if we're talking to somebody in IT, yes, it's a legal project, but tie it in to how we can help them achieve their goals. Use past pain as proof. Remember when we had to scramble to find that data during whatever that incident was, which might have been a potential breach incident? Remember that time when we all had to go heavily drink after work because we had to stay up here till 2 a.m. and we didn't know where anything was? Let's use that past pain as proof. Even worse, if we had a risk or a loss from as a company and we got a sanctioned or we got fined, we could use that passing for proof. Remind them of that. Automate risk prevention. Use API connectors or data ingestions overlays to communicate with your IT systems and your eiscocovery tools. Make your systems talk to each other and work together. Automate that is. Yeah. Okay. Two last tips for y'all. Number one, use metrics. Business people love numbers. So you could say something like, you know, here's what it'll cost. Here's what it cost us to overcolct last time. Here's the delta between that and how much it would have cost if we'd had a data map that would have allowed us to more handily reduce the volume of data. Secondly, find an ally. Partner with privacy, infosc, or it because they often have overlapping goals. And if you can share budget between different orgs within your larger parent or then you're more likely to be able to get funding for your project if you want to use software and also the more people you have on board from the more orgs the more farreaching and harder hitting your project will be. All right. So we've been talking about getting buy in from all the little people that you need to have at the table internally but I know from my own personal experience and the experience that I see every day from our clients buyin is not always easy to do. And you're going to be the person that's like on the raw cheerleading team trying to make this happen is going to be faced with some obstacles, shall we say? So here's some mythbusters you discovery chick style. Myth number one, we don't need a data map. We only use email. That's where all the important documents in our organization lie. Okay, first of all, this seems to be kind of I would hope an outdated myth. Most people know these days with the use of things like Slack or Teams groups or Google chat or however you guys are chatting back and forth, people have figured out a way to work very efficiently with one another. And a lot of times it lies outside of email. And if that's not enough, think about all the devices that are going on. I mean, do you have PCs where people are able to save data on their PCs or mobile devices? And then what about all the ways that you're you're you're doing business? Are you using a Salesforce? Does your IT team have any kind of ticketing technology your applications? How are you transferring files back and forth? Are these on file shares? Are they on Dropbox, Box.com? Think about all the business processes and all the different places that data may lie along the way. All right, myth number two. Our IT guy has this all in his head. Yeah, I mean, this is an obvious myth. this dude's going to hit the lotto and be out tomorrow and then where will we be? But even beyond that, when we have these types of records and knowledge, we need to have it in a defensible way in thinking ahead towards an incident or a privacy request or litigation in a courtroom. We need to be able to prove up in a way that makes sense, that's part of our business policies, that's defensible, that this is what we have and where we have it. It guy's head ain't going to fly. All right, myth number three. We made it in 2016. It's still accurate, right? Well, I think anybody probably listening to this podcast realizes that. Yeah. Um, no, bro. You're going to have to update it. And the reality is a lot of people, if they have international business, did this as a result of GDPR, I don't know, like 5 6 7 years ago, and they feel pretty good about things. But the reality is actually, you know, data mapping is a living breathing thing and your data is growing and moving all of the time. So if you don't have a system in place to follow up on your data map in a regular basis, you need to think about that. And if you haven't updated it since 2016, I can imagine that you have some updates to do. It's too expensive. Myth number four. We'll deal with it later. I mean, what's the risk? If we get sued for something, who cares? I mean, we'll pay for it then and then we'll fix it. We don't have the money or the time for that right now. But really, delaying data mapping is kind of like skipping your oil change because it costs $100 and then all of a sudden your engine breaks down. That's a bigger problem. Obviously, that was much more expensive. Organizations that proactively map their data reduce downstream discovery and storage costs by at least 25 to 30%. So, that's something to keep in mind. And not only that, the risk that could be associated with it really could be hundreds of thousands of dollars depending on how large your company is and how spread out your data is. All right, so I hope that we have been able to help you guys understand the mysteries of data mapping. Love to hear what's working in your world. Thank you for joining us today. Thank you so much for joining us on eiscocovery chicks. We hoped you learned something new, felt empowered, or just had some fun along the way. Don't forget to join the flock by following us on LinkedIn and Instagram, and check on check out our website at ediscoverychicks.com. If you loved this episode, share it with your network, leave us a review, or tag us on socials with your favorite takeaway. And don't forget to subscribe wherever you get your podcast so you never miss an episode. Catch us nips next time. Until then, flock on friends. The views we've expressed today are the eiscocovery chicks views and don't necessarily represent the views of our employers, partners or clients. The podcast is available solely for educational purposes to provide general information about eiscocovery principles and not to provide legal advice to any specific situation. It is not a substitute for legal advice from a lawyer you retained or who has agreed to represent you. [Music]