Lessons Learned: Data Mapping Made Easier
The rate of information growth and their consumption are exponentially increasing within the business environment. If harnessed properly, businesses gain valuable insight through the depth and variety of information at their fingertips. However, on the heels of this growth come external threats and increased regulations.
This unwanted attention and scrutiny elevate the need for a data map, which when properly implemented, postures businesses to proactively address compliance matters and security issues. But the development of a good data map can be challenging.
In this presentation, our presenter takes you through his experiences developing data maps focusing on lessons learned, so that when you are volunteered to create one, you can effectively navigate through the common pitfalls that doom data mapping projects. Data mapping is not easy, but by avoiding common challenges it can be easier!
Audio-described version
Transcript: Lessons Learned: Data Mapping Made Easier
Duration: 0:44:41 · Recorded: 2020-03-24
Speakers: Soo Y Kang, General Counsel & VP of Consulting, Zasio Enterprises, Inc.; unnamed session moderator (shown as Speaker)
Lightly edited machine transcript. Slides are summarized where they carry information not spoken aloud.
Soo Y Kang: Ideally, when you go into projects, you are hoping that they will go well. But I, for one, have had my share of the exact opposite experiences. And this is especially the case with data mapping projects. And it's because these projects have a tendency to easily and quickly get out of control. So while I wish I'd be looking out the window with my feet in the air, more often than not, I have moments like this, which I think a lot of professionals in our industry can relate to, when you're trying to gather a lot of information and be able to say, how do I collect and represent and present this information in a digestible manner?
And so even though you face a lot of these challenges, it's okay, because with these, the key is to learn from each so that you can build a better experience the next time around. So let me share with you some of the key lessons that I've learned so that you can avoid some of the headaches that I've come across when I've been dealing with data mapping projects. As I was thinking about today's presentation and the time we have today, I came up with these five key lessons learned. First, begin with the end; second, design with purpose; third, trust and confirm; fourth, keep content relevant; and fifth, technology limitations.
So starting with the first lesson: when I was a little kid, and even to this day, I really enjoyed doing puzzles and games, and this included, back in the day, mazes, which were challenging as a young child. And then one day, someone gave me the key to how to solve these mazes, and it was that you start from the end and work backwards, and then it became so much easier to solve these mazes. And as I thought about today's presentation, I think this is a great lesson for planning a data mapping project as well: start from the end and it becomes much easier to complete. And by that I mean, what purpose will the data map serve? A key consideration, one that often gets overlooked, is that purpose and why you are creating that data map.
This can be influenced by the particular perspective of your sponsor, and that sponsor will greatly change how you approach the data mapping project. But the typical types of data maps are usually from the perspective of records management, and the focus here is on the common elements that most of the people on today's call are probably familiar with: the record or category of record, what purpose they serve, where they are located, and when they are disposed of. Then recently there's been a lot of focus on personal information through the data privacy perspective. The focus here is on data identifiers or personal information identifiers, such as a name, address, date of birth, and similar items. Most laws require you to understand what you have, where you store it, who has access to it, who you share that information with, and how you secure and protect that information.
The third type of data map is related to discovery. And this is usually in litigation or where there's a claim being alleged. And the focus here is on the ability to enforce litigation holds and to recall information so that you could properly disclose to the opposing party. While paper is a concern, discovery is particularly concerned with ESI and the repositories that hold that information and the capabilities of such repositories to implement litigation holds. And then lastly, there's the perspective of IT.
And I actually don't and haven't partaken in a lot of these types of data maps, because they're usually handled by IT teams within the organization. Most of the time the focus is on the list of applications or systems and other technology tools. It's an inventory list, and it has various other factors that are combined within it. And as you can see, each perspective brings with it a different focus, which alters the way that you approach the data map. It is also important to identify the end result and the perspective so that you can define your success.
What is that end goal, and how do you properly communicate expectations with stakeholders? How do you explain the project or the purpose of the project to those that you're going to be interacting with? And what happens when you get requests to merge these different perspectives together for a more comprehensive data map? I would caution you against that approach, because as you can already see from the way the end goals are and what the success story is, you have very distinct goals in mind and objectives for why you are creating it. And so while it may seem easy to add on a couple of additional data points, the effort it takes to collect that information is exponential and complicates the process.
So for example, if you start with a records management data map and then add on identification of personal data, you now are in a position where you have to explain what personal data is, differentiate it from what a record is, and then all the other elements that distinguishes one data map over the other. And you can quickly see how complicated that process can get. And so defining your success story, saying, this is why we're doing this map, this is the perspective we have, and this is our ultimate objective, and being able to communicate that and be able to respond to questions such as, why can't we add a couple more data elements, is very important to the success of your data mapping project.
So lesson two is to design with purpose. Data maps in my experience often fail because it is not planned for purposefully. So I would say if you plan it out by using what you have in lesson one, which is what is the end objective you're trying to achieve, you can prepare a successful plan of attack.
And key to design is to be honest with yourself, ask those tough questions, and then trusting your intuition and collaborating with your fellow partners within your organization.
So when I think about designing a data mapping project, there are key questions that you want to ask yourself. First is from a perspective of establishing a framework: understanding the perspective you're taking, are there any laws or industry guidance that provide any type of framework for the data map? So for example, if you were focused on a data privacy data map, the GDPR and Article 30 has certain items that are required, and it kind of lists them out in a bullet point item. And so from right there, you have a great starting point. Of course, you have to still refine it, and that is, again, a starting point, and you add on extra data points as you need for the objectives that you're trying to achieve.
And there are those instances for records management, for security purposes, for e-discovery as well. The next is to identify your resources. I think most people are familiar with the PPT, which is people, processes, and technology. And so answer those questions of what people are going to be involved, who can you leverage, who can you use, what technology are you going to incorporate into this project, and then what are the processes that you have to design so that you can make sure that it runs smoothly? Will this be internal or external or both?
And then structure that hierarchy and map it out for yourself, including the leadership who will drive the project and green-light the funds. This will play into what you can realistically accomplish. And this is the part where I think a lot of people have to be very honest with themselves: what can you accomplish with the resources that you have? Don't be overly positive about that outcome, because there are going to be a lot of hurdles and challenges that come forward. And so if you try to do things too fast with the limited resources that you have, you are going to be planning for your own failure.
So I often try to buffer expectations in that regard. And then, what are the time constraints that may potentially impact the project? Does the project need to be completed by a certain date? And are there any priorities that need to be expedited? And so if you are getting a push from legal to do an e-discovery map, then priorities may be certain systems or repositories that hold a lot of information that legal tends to go to, to identify documents and other information that you have to disclose to the opposing party.
And most often those consist of shared files and email repositories. And so for each one of these perspectives and the sponsor that you have, you can identify potential time constraints or time drivers for your project, and you want to make sure that from a planning perspective, you incorporate that into your considerations. Next is to set the project scope. And so based on those time constraints, how are you going to achieve your objectives? How are you going to design that data map?
Where you have records and information management, you may start that data map by identifying, within the initial columns, the function or the record series. Privacy may start with data elements or the identifiers. E-discovery traditionally starts with the naming of the repository where the records or information is being held. So in other words, how will the people who will be using it actually search for that information? And that will help you dictate how you want to organize the columns and the data elements that you want to collect.
And then, as noted, what is the information that you're going to collect? And that's to achieve your end goal, and that's really important for the planning purposes as well, which goes into our next slide.
So based on our discussion so far and the different perspectives that data maps can support, here is a list of some common data elements that are captured within data maps. And this is a very high-level overview, and you can see some overlap between the types of information that are collected. But I can tell you, in my experience looking at various data maps and working with various data maps, working with clients on what elements they want to incorporate, these can easily exceed 30, 40, even 50 discrete data points. But one of the things that you want to keep in mind is that the more information you need to collect, it increases the time required to complete and the complexity of the map. And that compromises its usefulness.
So this is another key area where I've seen a lot of attempts go wrong and lead to either not finishing the project or essentially never using it once it's been completed. So don't forgo this step, and really give consideration to what data elements you're going to collect and why. And question yourself: "Do I really need this at this point in time? What purpose does that data element serve?" And as you are mindful when you pick your data elements, and you have an overall design and picture in mind of how you want to do that, it becomes easier for you to say, "Okay, I have a justification for why I'm picking these data elements, and I'm ready to move on," rather than doing an overly comprehensive, "I'm going to pick 30 or 40," but not really be able to identify what purpose they each serve.
And so it helps you just organize your mind a little bit better about the purpose and the project, and then align it to the end goals that you had originally planned for in lesson number one.
And it also helps you take that first step. Because with all the considerations and choices that you have for a data mapping project and the elements that you want to collect, it's so easy to get caught overanalyzing the project. But you have to remember that this is intended to be a living document. And the best thing to do is to take that first step, understand and accept that mistakes are going to happen, as with most projects, but they can get fixed, so get started.
And lesson three is trust and confirm. As mentioned, mistakes are bound to happen, but you can implement certain measures to mitigate those mistakes.
I like to use a multi-layered approach to collecting information. This is because no one method is going to get you to the level of information that you need for your data map. So again, strategically understanding the purpose behind each one of the data elements and their best uses, as well as the collection methods, is going to be very important towards achieving success with your project. And so if we take a look at these four items, you could collect information by conducting surveys, conducting interviews, reviewing existing documentation and leveraging them, and then applying technology to help you where you have bandwidth issues. The first one being surveys.
So in my experience with surveys, they can be hit or miss. And where I've gone more granular, I recognize that the response rate is a lot poorer, and so is the quality of information provided. And I keep on reflecting back to why that is the reason, and it's due to the subject matter, as well as the need to explain and define practices, purposes, and terms of art that are not widely known to the people that you are asking to fill out these surveys. You have to understand that they are not experts in records management. They are not experts at data privacy or e-discovery.
And so you have to take, with each layer that you're going to incorporate into the questioning and the data points that you're trying to collect, you have to communicate that to them and expand on that to say, this is why we're collecting this information, and then also define within their certain terms. And you can easily see how confusing this can be for your audience if you're not communicating that in a proper order or providing them with the necessary resources for them to complete. Now, I will qualify that statement by saying that this also depends on the maturity of your audience and your program and the training that you have incorporated for your stakeholders. But based on my experiences with surveys, I like to try to keep them as simple as possible and also use them as more of an investigative tool to understand the bigger picture than trying to get granular details. That approach has never worked for me.
And so where I use surveys is to target, again, big picture items, such as what is your business process, and can you define what you do within your department or group or function? What are the types of tools that you use? What type of relationships do you have with vendors, and what do your vendors do for you? So you have it as more of a high-level type of questioning, so you could get a better feel for who your audience is or who your stakeholder is. So then you could use other approaches to get that more granular detail.
I find that that's where the survey is the most beneficial and most effective. Then you follow that up, typically. And this is one of the key items for collecting the information: conducting interviews. And interviews are a great resource, because you get to have time alone with that stakeholder or group of stakeholders, depending on how you want to approach to gather information, and be able to have a more natural conversation and see how the conversation flows, so that you could drill down where you need to or skip over certain items where you know you have enough information. But it's easier said than done, because oftentimes you're competing for their time, because they have their regular day-to-day jobs and other time constraints on their end that you have to work around.
And so you may have a plan in mind about how you want to approach the interviews, when you want to get them in for the interviews, and you have expectations that they're going to be prepared, so that when you do interview them they're going to have this information ready for you. But again, understand that due to the time constraints, they have competing interests for their time, and the fact that they are not experts in the industry like we are when you're approaching them, that there is going to be certain elements of teaching and qualifying and communicating with them to get them prepped, so that you could have the best outcome for that interview. And based on that, you also want to make sure that you understand who you want to interview. You don't want to interview every single person, because there's just not the luxury of time within an organization. And so from my perspective, when I target who I want to start out with, similar to the survey approach, I like to go with a higher-level person that understands both the documents and the processes that are being used to execute the functions of that particular group or department, to give me a lay of the land.
And so if there is a mature program in place, you have records coordinators already positioned within that department or group that you can leverage to ask them questions about, "Okay, now that we've had the survey, we understand where you're coming from, what you guys do. But in order to get more granular information, who else would I need to talk to about this, this, and this process or this system?" Because you can use the survey and the records coordinator to kind of drill down and identify who the prime targets are going to be. And you also want to make sure that you're not overly conducting interviews. You want to cover your bases from a compliance and due diligence perspective and hit each one of the departments or groups.
But at the same time, if you have a very good understanding of the records that are being used, such as common business functions, HR, accounting, finance, and the like, where you know the types of documents that they're working with on a day-to-day basis, where you know, "Hey, I don't need to interview up to ten people or five people, I could really get away with interviewing the records coordinator or one or two people," then try to minimize that, because that will help a long ways in buying time back for your project, as well as making sure that you're not going to run into hurdles of time constraints as well, trying to fit them in for interviews where they are not really necessary for the overall project and goals. And another tip that I would have for conducting these interviews is to introduce the interviews in advance. So prep them for the interviews by giving them key definitions, what the purpose of the meeting is, and the like, before you go into the interviews with these stakeholders. Now, I think that creating that type of guidance is important, but the timing of when you communicate that to them is important as well. If you start at the beginning of the project and do a general introduction to the potential interviewees saying that this is going to be coming, and then giving all of this information out, then two months later, a month later, trying to target them and hit them up for an interview, they're not going to remember the things that you're saying.
And so it's important to have consistent communication throughout the information gathering process, by having an overall communication at the beginning stage and then a week before or a couple of days before you are to meet with them, refreshing their memory by providing them that guidance sheet again, or catering a guidance sheet just particularly to their department, so that they know what to expect when they meet with you. The third thing that I like to look at from an information collection perspective is existing documentation, and try to leverage that as much as possible, because this again can limit the scope of the people that you have to interview and give you a better understanding of your organization. And so what do I mean by this? Well, a lot of business functions, groups, and departments already have business process flows mapped out. And so to the extent that they have that type of documentation, I like to ask for those.
And I also like to approach the IT department, because they oftentimes have an applications inventory or systems inventory that they've already created, with a lot of great data points and input already placed in that document. And so if I could get that in advance, and I can align that to the different departments that an interviewee is going to be speaking with, it gives me a much clearer picture and can help me have a narrower focus during those interviews, so I know that I'm not wasting anybody's time and I'm collecting the information that is truly going to be valuable as I move forward. And then lastly, you always do have the option, to the extent that your budget allows or you already have this capability within your organization, to use technology to help you with this process. And what I mean by that is what's termed in the legal world as technology-assisted reviews, or file crawlers. And of course, there are valid tools for searching for information, but you want to make sure that you keep in mind that not all tools are the same, and they don't have all the same capabilities.
In the legal world, what they focus on is statistical validation, which is really focused on the two areas of precision and recall, and recognizing that 100% is not optimal for conducting the searches, and expecting that 100% follow-through rate on that is not a reasonable goal. What you have to identify for yourself is, what is an acceptable level for your needs? And also properly set your own expectations that the purpose of using technology-assisted review is not to have it complete the task for you, but the objective is really about limiting that haystack, which will require further manual review. Again, it's not about eliminating the manual process, but eliminating the amount of things that you have to do from a manual perspective, and relying on technology to limit that haystack with the level of precision that you feel that you have done your due diligence of gathering the right amount of information. And so using these four layers of attack, and strategically and tactically determining how you want to use these different elements together for your overall plan for executing on the information collection phase, will help you achieve a greater level of success, as well as save you time as you go about moving your project forward.
And what I always advise is, once you have this plan in place and how you're going to approach everything, it's great in concept, but things tend to fall off the tracks when you go to the implementation stage, because there are always some things that you just didn't consider. And so what I typically recommend, if time allows and the project is able to be phased out, is to implement phases and do trial runs. Now, when you do a trial run, there are two different approaches that you can take. One is to go with something that is easy, a department that doesn't have a lot of information that you need to collect for your particular data map, so that you can just see and get a quick win to show progress to your sponsor and show that you're moving the project forward. The second way to approach this trial period is to pick the hardest department, either by the number of information that you're going to have to collect or the stakeholders that are going to be involved, that may be more critical or provide more constructive feedback to you, but you know that it's going to be time-consuming.
Now, if time permits, and continuing to provide justification for the validity of the project is not a concern, I recommend that you go with the harder approach. And I say that because that's where you're going to get the most and the best types of feedback for where you might have gaps in the process that you've planned. Now, again, you will definitely find areas for improvement, but this is going to be at the sacrifice of time, because you're going to have to take a little bit more time to complete this phase as you interact with this group, either due to, again, the level and the number of information that you're going to have to collect or the degree of difficulty of interacting with these particular stakeholders. Now, it may be that you have both, and you have to do a middle ground. And so you just have to remain flexible.
So you may move with an easy target first, because you want to prove the win to your sponsor and demonstrate value, but then, to really be sure that you get the critical feedback that you need to assure the success of your project, you may also want to target a hard group at the same time. And then that dual approach can work to really help you identify and serve your needs of advancing the project, while also identifying the gaps that you have to cover, and help you refine the remainder of the processes for the remaining departments that you have to deploy to. If you can do this on a phased approach, then you can target a department or business function, one group at a time. If you want to do a more holistic view, then I would at least target one or two test cases as a phase prior to deploying corporate-wide, so that you just mitigate some of those time constraints, some of the mistakes that are going to occur. And that way you don't have to go back and have to fix that and then have to re-approach your stakeholders for a second pass at gathering the information.
But again, the key is to take these small steps, identify areas to refine, and then deploy to the next phase, and cycle through that again and again and again, so that you can keep moving forward and get the best quality information possible.
Now you've gone through, you've planned it, and you've identified what information you're going to collect, you've identified the best way to approach from a tactical perspective, the different types of tools at your disposal and the resources to collect and get that information, and how you're going to organize that information when it is completed. And you have this great product that you're able to deliver to your sponsor, but it's just as important that you give focus to what's going to happen after delivery.
Because the value of that data map is directly connected to its currency. With how fast information flows through the organization on a day-to-day basis, it is vital that, for its usability, you need to continue to update it, and you need to update it with the technologies that are being used, the business information that's coming into play. And as you probably know within your own organizations, companies retire and get new applications and systems all the time. Companies divest, they merge different departments, they create different and new business processes within the organization. And so the question is, how do you maintain that data map, and how frequently do you have to maintain it for due diligence purposes and to make sure that it is a usable product?
Similar to planning the project in the first instance, you need to give consideration to all of these elements for a move-forward plan. And identify, I would say, in addition to everything you're going to have planned, identify existing processes that can be used to update the data map. I think that if you can rely on something that people have been doing already, instead of having to teach them a new method of accomplishing things, it's going to be a lot smoother transition for the updating process, because then you don't have to tell them to do another thing. You could say, "All you have to do is do what you've been doing, but just add this element to it," and then you can show them in an easier fashion how they could accomplish that. And I find that that is one of the best ways to maintain a data map.
So if I have to give an example, it would be the procurement process. If you have to go in there and say, "I want to get X tool," whether it's an application, "I want to use this vendor," or whatever that is, usually you have to justify and fill out a form saying, "This is my business reason for it, this is what it's going to cost." And there are certain things and fields that you have to populate in order to get that procurement process started. Well, as part of this, and from a data mapping side, you could have elements in there that say, if you were to use this product, what information are you going to collect? Does it involve personal data?
Does it involve items that are commonly used in litigation, or whatever it's going to be? And incorporate those questions under a conditional logic tree, so if they answer yes, they have to answer four or five extra questions to be able to populate that and get that information as part of that workflow process that already exists, rather than waiting until that system or application or the vendor is already in use and then trying to get that information from them at a later date. I think that you have a better chance of success when there is a need to acquire at that point, because they're willing to fill out the forms, rather than waiting until afterwards, where something's already in place, because then there's a lack of incentive to have them fill out the forms and the necessary fields of information that you want to collect. You also want to identify the personnel and the resources that you're going to need to maintain this project, the data map. Are you going to rely on and leverage the existing records coordinators, department coordinators, to the extent that you have them, to help with the mapping process and updating process?
Are you going to use tools? And if you are going to use tools, how are you going to leverage those tools to help with maintaining the data map? And so from a frequency perspective, as always, in time or as it happens, the real time is going to be the best way to capture the changes. But I know from a work process or workflow perspective, it's not always realistic to set that kind of expectation for yourself. So is this something that you could again do a test of, and say, "Okay, in a month, how many requests do we get in for changes to the data map that we have to review, make modifications, and then implement?
How does that cycle work?" And if you can start to see the frequency of times that changes occur, then you could time your reviews and your maintenance to that. So typically what I would recommend is to look at maybe a quarterly review at the latest for an initial project, and say, "Okay, at a quarterly cadence, am I getting too much information, or am I not getting enough information, where there isn't a lot of change that are occurring within my organization?" If you're getting a lot of information, then maybe you don't want to wait until the quarterly time to be able to do a maintenance for your data map, but maybe you want to do that on a monthly schedule. Now, you can also have these interim changes that occur through the records coordinator or somebody else, and you could structure it that way, with a big review that can be structured at the end or midway through the year as well.
So there are various ways that you could create or posture your maintenance cycle, along with the frequency, to make sure that you're at least capturing the information as close to time or real time as possible, under the time constraints that you may be facing and realistic expectations for your department resources that you have. But it is important to make sure that this document is maintained, because the last thing you want is to undertake all this effort to create this great data map just to be having it sit on a shelf and nobody uses it.
And then, we've mentioned technology a couple of times during today's presentation, especially with respect to technology-assisted review, but there are technologies and vendors that are out there that help specifically with data mapping projects as well. And so one of the common questions that I get when I work with clients is, isn't there a tool that can do this for us? And the answer is yes, but. And the but is, you have to understand their limitations as well.
And this isn't specific to data mapping projects, but questions that we all face when we want to undertake or acquire technology for different departments. And what we want to do with them is, what problem are we trying to solve, and what requirements will the technology need to meet? So specific to data mapping, and I want to use the data privacy side as an example, there are tools out there, OneTrust, TrustArc, WireWheel, all of which say, "We can create data maps for you, we could automate processes, we could create these beautiful workflows," and the like. But you have to keep in mind that for most of these tools, their effectiveness to automate relies on their ability to integrate into the corporate environment. So what does that mean?
It means that they need to be able to tap into the capability of current systems and applications, usually through an API, so that it works within that and gets access to the information that it possesses or it stores within those existing corporate tools. And a decision has to be made oftentimes, not just from an assessment of capability of the existing tools themselves, but also from a security perspective: are you okay letting another software tap into the information within your existing tools? Secondly, even with the integrations that are in place, based on the data points that are typically associated with data maps, it still requires extensive interviewing to adequately collect that information. It's not an auto-populate, "here it is," because there's going to be some questions dealing with purpose, how you use, retention periods, and the like, that have to be defined by a conversation with the stakeholders in question that are really leading those, the decision makers for the information and the data points you're collecting about it. And so where it's not auto-populated, you still have to expect and anticipate that even with the use of these tools, you are still going to have to go through the exercises of doing a survey, looking at other documentation, and conducting the interviews to really be comprehensive about the information that you're going to collect.
And while some of these tools, or most of the ones that I mentioned, do offer surveys as an add-on feature or a feature of their tools, so that you could collect some of this information, as previously mentioned, surveys in my experience are not always helpful when you get to a certain degree of granularity. And so, again, how useful that feature is is going to be dependent upon the maturity of your audience and how well educated they are about the purpose of the particular data map, whether it's privacy-related, e-discovery-related, or records and information management, and how knowledgeable they are about the purposes behind those concepts and those practices within your organization, as well as key terminologies and terms that are being used to describe or to really leave the questions that are being asked, so that they understand the question that is being posed to them, and you're getting the quality of information that you need for the purpose of the data maps. So overall, when companies are just initiating a data mapping project, I always feel that it's best to start low-tech: go through the process of doing it manually and understand the challenges that you face, because that's going to help you identify question number one, the problems that you're trying to solve with the technology. And once you figure out what the problem is, then you could also identify what the requirements are for that technology to help satisfy or address those problems for you. And so, for example, with that technology-assisted review that I mentioned earlier, one of the requirements could be, "I want an accuracy rate of 70% or 80%," but you may not be able to figure out what that looks like and how much of the haystack is left for you to do from a manual perspective. You wouldn't really be able to identify those needs off the bat unless you go through the challenges of developing a data map in the first instance.
And so I think that there is value to the low-tech option at the beginning, so that you can identify where the technology can be most useful for you, and you happen to go down that path. And so, as a parting thought, data mapping is a very labor-intensive exercise and does require a lot of forethought and planning. But I'm hoping that through today's presentation, some key considerations and key areas where I've seen hurdles and challenges faced by companies when they're creating their data maps, that some of those considerations laid out today will make your efforts a much smoother process as you move forward, or if you get called on to do that. So with that, that ends my presentation, and I am available for any questions that the audience may have.
Speaker: And I think I figured out a way to just let you ask a question. So if you've got a question, maybe respond in the chat, and I'll turn your audio on. Okay, we've got a question here from Bruce. It doesn't look like I can turn your audio on until you enter your PIN. I'm not sure what that means.
So what I'll do is I'll just read out your question here, Bruce. [audience question] "A lot of times we don't know what we don't know. We get asked key questions and realize what we don't know." And so I think just a comment from Bruce there, Soo.
Soo Y Kang: I completely agree with that, and I think that hits upon two items, which is to identify what you may not know. I think that's an area of overarching, high-level question that you could potentially probe through your survey, and depending on what you don't know may be, if it's something about a hidden process or a business process that you later find out and say, "Oh, I didn't realize that I need to probe into that more," then I think that survey could help kind of key into that and identify those areas for you. But then the other part is, again, the whole point of creating a data map for your organization is to consider that to be, and understand that it's going to be, a living document. And so, again, reasonableness takes the forefront on that, and say, "Okay, I've done my due diligence and gathered as much as I can based on the information that I have before me and what I've been able to collect," but then understand and be able to be flexible to adapt to changes in the environment or when new information comes about, so that you could readily incorporate that into your process and make sure that your data map stays relevant and current.