 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining the current installment in the Monthly Data Diversity Webinar Series, Real World Data Governance with Bob Steiner. Today, Bob will discuss using data governance to protect sensitive data. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the upper right-hand corner for that feature. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Bob Steiner. Bob is the President and Principal of KIK Consulting and Educational Services and the Publisher of the Data Administration newsletter, TDAN.com. Bob has been a recipient of the Dana Professional Award for significant and demonstrable contributions to the data management industry. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will go to the floor to Bob to get today's webinar started. Hello and welcome. Thank you, like usual, for taking time out of your busy schedule to sit in on this webinar. As Sharon mentioned, today we're going to be talking about using data governance to protect sensitive data. And if you recall, last month we talked about using or really achieving data quality using data governance. And next month we're going to be talking about improving the understanding of data. So there's some themes that are here that are resonant throughout each of these webinars. So again, I'm glad that you're with us today. I've got a lot of slides to go through today, a lot of materials that I think that you'll be able to refer back to if you haven't started to use your data governance program yet to protect sensitive data. I can tell you that firsthand, several of my clients, that's been the entire focus of their program, is to set up data governance programs to protect sensitive data first, PII data, personal health information, intellectual property, and those types of things. So let's get started. Before I get started, actually, typically what I like to do is share a couple of the things that I'm involved with that are coming up. As you know, there's a monthly webinar that takes place on the Thursday of every month. And next month we're going to talk about using data governance to improve data understanding. And then in July we're going to talk about improving data analytics with data governance. So I hope that you have time to register and hopefully attend live as we're doing those webinars. One of the things that I talk about a lot is non-invasive data governance. And I just want to make you aware of the book, Non-Invasive Data Governance, that's available from your favorite bookseller where you can go to Techniques Publishing or through Amazon. The name of the book is Non-Invasive Data Governance. I will be speaking at several data-versity events that are coming up. In June I'm going to be in San Diego speaking at the Data Governance and Information Quality Conference. DGIQ is what it's known as. I'm going to be talking about how do you help a program that is failing? So if you had a data governance program that's not necessarily catching hold or it's been around a while and it's starting to decrease in its effectiveness, you might want to attend that session to learn about what you can do about programs that are failing. And then I'll be speaking at the Data Architecture Summit in Chicago in October as well. And I'll be doing a couple of tutorials at that event. One thing that I didn't have time to add to this slide is that I'll also be a guest on Eric Kavanaugh's DM radio show on metadata next Thursday. So I hope you'll get a chance to attend that. There's a non-invasive Data Governance Learning Plan, Education Plan that you could acquire through the Data-Versity Training Center. As Shannon mentioned, I am also the publisher of the Data Administration Newsletter. Please go out and look at tdan.com if you're not familiar with it. It publishes twice monthly and in fact, new content was added yesterday. And last but not least, there's KIK Consulting and Educational Services where you can go to learn more about non-invasive Data Governance. So what are the things that we're going to talk about today? There's really five primary topics that we're going to address in today's webinar that are all focused on protecting sensitive data. The first one is to share information about tips and techniques for classifying data and defining data handling rules. And during that section, I'm going to share with you a bunch of ways or at least certain ways that organizations have classified their data and what some of the data handling rules are that they've put in place in order to assure that their sensitive data is being protected. Then I'm going to talk to you about the different roles associated with data governance and how we can set those roles up specifically to focus on protecting sensitive data within your organization. We'll talk about data sharing and how that's an integral part of protecting sensitive data. We need to know what data we can share, who we can share it with, how and when we can share that data. So we'll spend some time talking about that. Then we'll talk about incremental implementation, because I've never seen an organization that's been able to flip a light switch and have governance come on for the entire organization at once. So there's a bunch of ways that organizations can incrementally expand their programs to protect data for the entire organization. And last but not least, we're going to spend some time talking about measuring that protection as a way to be able to demonstrate the performance of your data governance program. So sit back. We're going to talk about all these things. And if you have questions, please enter them into the Q&A section on your screen. So that'll be nice to hear from you in that way. Oftentimes when I'm getting started, I talk about different definitions that I use for different terms. The definition that I use for data governance, it has some teeth behind it. It's worded quite strongly, in fact. So when I say data governance is the execution and enforcement of authority over the management of data and for this purpose over the protection of sensitive data and the resources that are related to that data, again, the definition of data governance is worded very strongly. And it's meant to be that way, so people will sit forward in their chairs and ask a question as to, well, how the heck are you going to execute and enforce authority over making certain that our sensitive data is being protected? Data stewardship, and I do a lot of webinars on data stewardship as well. Data stewardship is typically the formalization of accountability and for this purpose for over the protection of sensitive data and data-related sources. And I've been known to say that everybody in the organization is a data steward. All the people that are defining, producing, and using data actually have a level of accountability for how they define, produce, and use data. So I typically say that almost everybody in the organization is a steward in some way, especially those people that are using data and using particularly sensitive data. How do they know what the rules are associated with how they can print and transmit and send different types of data that might be classified as being sensitive? So again, the execution and enforcement of authority and the formalization of accountability, those are the two definitions that I tend to use most often. I also want to share with you a definition of non-invasive data governance, which is really the practice of applying that formal accountability and behavior through roles and responsibilities that I'm going to talk about a little bit later in this webinar. We're going to apply governance to process rather than redefine and call all of our processes, data governance processes. We're going to make sure that the definition, production, and usage of the data assures all the things that we need from the data, that we're going to assure regulatory compliance, security, privacy, protection, all of those good things, especially we're going to focus today, again, on the protection of sensitive data. So really non-invasive describes how we're going to apply governance in the organization, and the primary goals are to be transparent, supportive, and collaborative. If you want any additional information on non-invasive data governance, please visit kikonsulting.com or go to the Data Diversity Training Center. Like I said, where there's a learning plan that focuses on non-invasive data governance. A couple more definitions to share with you, and these are very simple definitions of two terms that you're going to hear me talk a lot about during this webinar, and those terms are data classification and data handling rules. And basically, the simplest definition that I could find of what data classification is, is the act of putting data into a category. And I'm going to share with you different categories that you might consider using. You might already have some of these things set up, but if you don't, then some of the information I'm going to share with you might be good for you to be able to refer back to as you're setting up your categories for classifying your data. The data handling rules are oftentimes very much associated with the classification of data. So there's different handling rules, depending on how the data has been classified. And we're going to talk about that a little bit further into the webinar as well. In fact, in this section, we're going to spend some time talking about that. So the first thing that I wanted to do out of these two terms, the classification and the handling rules, is to talk about the benefits of data classification. So typically, if you classify your data, and oftentimes I'll just give you kind of a teaser as to what that means, classifying it as being highly protected or highly sensitive to being sensitive, to being public, to being internal use. There's a lot of different ways that you can classify your data. And if we can classify our data and understand which category the data falls into, we can significantly improve the way that we manage data throughout the information life cycle of that data. We can also provide the ability to systematically apply governance in the form of compliance and risk management. So when we're focusing on governing our data, we want to make certain that the people in the organization understand the rules, they understand how the data has been classified, they understand what the rules are that are associated with how they handle data that has been classified that specific way. So the first thing I want to share with you is a little bit about how we improve the information life cycle management processes and systematically apply governance across the organization. So if you've attended my webinars in the past, you'll know that I also talk a lot about three basic activities that people can do with data. And I usually think of it as the fact that almost every other activity that you can think of will fall under either data definition activities, data production activities, or data usage activities. So let's spend a little bit of time talking about each of those things. So the data definition activities that need to be governed include the requirements gathering. These are all things that fall under definition, the requirements gathering, the definition of the data itself and the rules that are associated with that data. And certainly some of those rules can be around protecting sensitive data, can be about sharing data, who the data can be shared with, when and how that data can be shared. And then oftentimes, as part of the data definition activities, there's the documentation and the recording of metadata about that data. And what I've found in a lot of organizations is that they'll provide a business glossary or a data dictionary that defines the data, but they don't go far enough. They typically don't include things like the different rules associated with the data. And certainly with the protection of sensitive data being so important to so many organizations worldwide, we need to make certain that as part of the documentation and the metadata, we're collecting information about how the data is classified and what the specific rules are that are associated with how you handle data that's been classified that way. So we need to know where data has come from. We need to know if we're allowed to see the data or the data that we're sending to other people, if the people that are on the receiving end have the permission and have gone through the appropriate process and understand the rules associated with how they can share that data. So data sourcing is very important. The certification of data and making certain that people understand, first of all, that the data has been through quality checks, but there's also certain rules and regulations around how that data can and can't be used. So oftentimes organizations set up certification processes to make certain that people that are accessing data that has been classified a certain way understand and will follow the rules associated with that data. And then there's also rules associated with the retention and the elimination of data. So we need to make certain that as part of data production with the information lifecycle management that we're taking care of at least these data protection activities within our organization. I often refer to the data usage piece, excuse me, as being really the no-brainer of the three. I mean, in an organization, if you're going to go to your management and you're going to say that we're going to explain the rules associated with protecting sensitive data only to these handful of people and have them understand the rules that are associated with how they can use that data, how they can share that data, then that's not going to cover the entire organization. So basically one of the things that we need to do is understand who in the organization is using different types of data that are classified different ways and make certain that we communicate like heck all the rules that are associated with protecting that data. So that could be privacy rules, regulations or regulatory rules, rules about the understanding, giving people better understanding of what the data is so that they can use it to get the most value out of that data. And certainly one of the things that we're going to talk about today is a lot about data sharing and making sure that as a person that's going to be sharing data with somebody else that number one we understand the rules associated with the protection of that data, but that we also then are sharing those rules with the people that are receiving the data to make certain that they too will follow all the rules that are associated with the, or will follow all the handling rules that are associated with data that is classified that way. So one of the things that I wanted to provide to you and this is something that I hope you'll be able to refer back to at some point in time once Shannon makes the slides and everything available to you is that there's different ways to categorize your data. So I wanted to share with you something that came from multiple customers of mine, but I'm kind of reworded it or added some not too many organizations have these five levels, but these are five that we may want to consider when we're setting up classification categories. There's explicit access required data. There's highly sensitive data, sensitive internal use only, and then there's public data. So what I want to do is I want to quickly go through each of these different categorizations and share with you examples of what some of that data might be and give you definitions as to what I mean by explicit access required or highly sensitive or all those different classifications of data. So I'm going to do that right now. So we're going to start with the explicit access required. And I don't want to reword for words to you what's on the screen, but this gives you a good idea of how at least several organizations have defined data as being explicit access required. So typically that category is reserved for the highest level of security within your organization. So typically data that's classified as being explicit access required is if that information was exposed, it's almost certainly going to lead to risk and risk in the terms of significant monetary or reputation loss. So only the data that's classified to the greatest extent would be considered to be explicit access required. And some examples of those types of data would be combined. Sales figures or metrics such as sales percentages, legal action, pending litigation, things like that might be considered to be explicit access required. And the rules associated with handling data that's categorized this way might be a little bit more stringent than even things that are considered to be highly sensitive. So let's talk about highly sensitive data for a minute. So typically that's the next category down. That's information that provides very significant competitive advantage to your organization. And then if you expose this type of information to people that's not supposed to receive it, it would potentially put your company at a pretty high level of risk. So the different types of the data that would fall into that category are listed there in non-public customer identifiable information. So PII that's not available through public means would fall into this category. Or non-public personally identifiable employee information such as their personal health information, bank account information. I'm not going to go through each of these examples, but you can see that data that's considered to be highly sensitive may be a little bit less sensitive than the explicit access required, but it needs to be handled with kid gloves. And we need to make sure that this data is being protected to an extent that we can, number one, convince our leadership and demonstrate to our leadership that this data is being protected. But in order to assure that, we need to kind of start by walking before we run and defining the rules and communicating the rules significantly to the organization so they know what data falls into this category and all of the other categories. And then there's sensitive data, which is again non-public company information that would pose a potential risk, a moderate level of risk to your organization. And some of those things would be, the examples of those things are listed here as well. So again, I don't want to necessarily go through each of the examples, but what I hope to be able to do or hope to accomplish in this webinar was to provide you with examples of each of these categories of data and provide you with at least a starter definition as to what I mean by each of these different categories. Then there's data that would be classified as being internal use only, and that's data that's not supposed to be shared outside of the organization. It could cause minor risk, but it could also cause problems with the competitive advantage we have through some of the things that we've set up in our organization, things like corporate policies or charts, how to access content, information that's coming out of different meetings. So you might identify and categorize some of your data as being internal use only, and in a second, you'll see how some organizations actually set up handling rules to be specific to that specific category of classification for your data. And the last one really is public data. So that's information that's really safe to be posted externally. It's meant for general information. Oftentimes that's information that's made available through your organization's public website, through reports that your company issues, annual reports, regulatory requirements and things like that. So there's five examples of categories that you could slot your data into and you could understand that going from the highest level of protection to the lowest level of protection that the handling rules associated with that data is going to be different really depending on how you've categorized the data within your organization. So let's talk a little bit about the handling rules because we spent a little bit of time talking about data classification, and so we need to make certain that we're defining data handling rules that are associated with each of the different categories that we use as part of our data classification schema. And so some of the things that we want to collect and make available through these handling rules are how the data will be handled, who will be able to handle the data, when they'll be able to handle the data, and what data can be shared and what data can't be shared. So when you're setting up your data handling rules, again, making them appropriate for each of the levels of classification we want to make sure that we are at least categorizing and adding to the handling rules the how, who, when, and what associated with data that falls into that level of classification. Things that need to be recorded for each of these different benefits to completing data handling rules. The first one clearly states how the data must be handled. How can we print the data? How can we display the data? How can we transmit or transfer data via interoffice mail? Things like that are things that we need to consider when we are sharing data that has been categorized and classified in ways that where data handling rules apply to that classification of data. There's also rules associated with how the data can be discussed within organizations. So one of the first things that we can do is under the how of how data must be handled is make sure that we're at least outlining those categories that we understand as being important. How data is being shared through it being printed or displayed, transmitted or discussed. Associated with granting permission for people to receive data. And if you've experienced anything like I've experienced, when somebody tells you, or asks you if you could share data with them, they're not very specific as to what data it is that they're looking for. They say, oh, just give me all the data and I'll figure out what I need the data for. Well, the truth is that the person, granting permission to that person may require that they understand that this data that you're sharing with them is categorized and classified different ways and they need to understand that that data needs to be handled the same way that you're handling that data before you grant somebody permission to receive that type of data from you. Oftentimes the same thing applies to access to data. So if we're giving people access to systems, they need to understand how the data is categorized and how the data needs to be handled within that system. So we have rules associated with the access to the data and we should also have rules associated with how we're sharing these rules with the people that are receiving the data or the people that are accessing the data. So there needs to be, as part of sharing data between entities or parts of the organization or people, there needs to be a formal process for making certain that we're sharing the handling rules with the person that's receiving the data. So certainly when they receive the data, they're going to be held to the same level of accountability as you will be, which means that they need to understand how that data then, once they have access to it, can be printed and displayed and transmitted and those types of things. So there's certainly a lot of things to think about when we're putting together the data handling rules. So clearly state when they can handle the data. So certainly there's rules that are associated with when specific data is going to be made available and when the access is going to be given to that data and when the access is going to be taken away. Oftentimes in organizations, access is granted to data, but then there's never a review process to figure out how to take that access away from somebody. So you might have access to data that was relevant in a prior position or a prior job within the organization, but there need to be rules associated with how do we know, how do we review this to make certain that people who had access to the data at some point in time either still have a business reason for having access to that data or that access might be taken away. And clearly and certainly there's one last piece of the data handling rules that clearly states what data can be shared. So what are the rules associated with how the data is classified, rules associated with who has the responsibility for classifying the data? And we'll talk about that a little bit when we talk about the tactical level of the roles and responsibilities and what responsibility and accountability they have for classifying the data that falls within their domain. And then also the rules associated with how these rules that we've talked about are being communicated between parties. So when we share data, we make certain that we're sharing the rules associated with that data as well. So typically as I mentioned before, the handling rules are really associated with the way that the data is classified. So I'm just going to use, for example, the highly sensitive, sensitive, internal use and public since the explicit authorization classification level. I haven't found that too often within organizations, but I have found it within organizations nonetheless. So the things that we need to define around the handling rules should contain the rules associated with printing that data, electronically distributing the data, physically distributing the data, whether it's through reports or through interoffice mail, how we can display this data and how we can discuss the data as well. So I'm going to give you some examples, and these are actually client examples of handling rules associated with highly sensitive data. So again, I don't want to read through all of them, but I want to kind of pick at the highlights of the rules associated with highly sensitive data. So data that is classified this way should be marked as being highly sensitive. Oftentimes people need to go through some prior process to make sure that they need to know that data and that they might require some type of identification. Here is this example, quarterly validation by the data owners to make certain that that person should still have access to highly sensitive data. You know, it also alludes to the physical copies should only be printed when necessary and stored in internal locations. You know, it's fine. There's an organization, well, maybe it's not really funny, but there's an organization that I was working with that the reason why they started to put governance in place around protecting sensitive data was that the CIO or the CEO of the organization was walking around the office one day after hours and found reports sitting out on people's desks, you know, face up where the data was there to be seen. And so it's not just a matter of printing the data or printing the reports that the data resides on. It's what do you do with that once you've taken that data off the printer? And in fact, in some organizations, data that is categorized as being sensitive or highly sensitive, oftentimes if you send that information to the printer, it won't print unless you go over and enter your code that says, I'm here, I'm ready to accept this information so it doesn't sit on the printer and potentially be seen by somebody who's not supposed to have access to that data. So let's do the same thing for sensitive data. Again, the idea is that we need to mark the data as being sensitive and therefore let people know that the handling rules associated with data that are marked sensitive are set up a certain way. And in this situation, the access is given on a need-to-know, also requires an ID. It might be encrypted. Again, this should only physically be printed when necessary and stored in places that people cannot get access to unless they're supposed to have access to that. If physical media should be sent across the organization through accountable commercial delivery services, oftentimes the receipt of that data needs to be confirmed and logged. The people that were set to receive that data or were intended to receive that data actually received that data. So now we know that that data has been collected and has been collected by somebody on the other end that now knows the rules associated with protecting that data. So they're the same for internal use data. The data should be marked internal use. It should be access. It should be granted on a need-to-know. Physical copies, again, should only be printed when necessary and should be stored in the appropriate manner. And the same thing would hold true to physical media and the discussion of the data. Again, you can see examples. And the idea here was to provide you something to refer back to when you're setting up your handling rules associated with the different classification of data. And as you'll see, for public data, there's not a whole lot of rules, handling rules that are associated with public data, because, again, it's being assumed now that that data is available to people to be able to access either publicly through the Internet or through issued reports, but typically there's no other data handling requirements for data that's marked as public. It really makes sense to mark that data as public so people know that there's less restrictions associated with that data itself. And in producing and using data, well, you need to make certain that you've governed the processes associated with defining the classification and handling rules. So engaging people that are domain experts or subject matter experts to make certain that they know the rules associated with how that data needs to be protected and that information is being collected, as I mentioned before, in the glossary or somewhere where people are going to get the understanding of the data, some of that understanding should also include the classification of that data and how that data should be handled. You might want to store off the handling rules and the classification rules in data policy and refer to those, so you may not want to include those definitions with the definition of every piece of data, but at least let people know what the category is that it's classified and then the handling rules could be kept in the policy associated with classification and handling of data. We also want to make sure that we govern the process of producing those classification and handling rules and making that information available to people. So we want to make certain that communications becomes a very big part of what we do around protecting sensitive data. Again, we need to communicate with people how the data has been classified and what are the rules and how we're going to enforce the rules that are associated with data that has been classified that way. So the next subject that I wanted to touch on with you was talking about the different roles associated with the data governance program and what role they might actually play in the protection of sensitive data. So I often talk about when I'm talking about the roles, the roles, not rules, associated with data governance, I often break it down into these five different categories of roles. There's executive roles, strategic, tactical, operational and support roles, and I'll share with you the operating model that I typically use for data governance. I could probably spend a whole webinar, in fact I have spent a whole webinar talking about the different roles and responsibilities associated with data governance. We're going to kind of spin these in a little bit of a different way to make certain that you understand how these roles are appropriate for the protection of sensitive data. So oftentimes when I'm talking about non-invasive data governance, I share this non-invasive data governance framework. And the roles are so important that I make them the first category that I typically discuss. And you'll see that there's different levels that these things are defined at. There's the executive, strategic, tactical operation, like I said before, but then the roles might be specific to those different levels. So at the executive level, you would have a steering committee at the strategic level, a council, at a tactical level, the domain steward, or the enterprise data subject matter experts, data stewards at the operational level, and then the data governance group, the team, the office, whatever you call the group that has the responsibility for data governance, as well as the working groups and the partners associated with the data governance program. So you may have seen this framework before. I just wanted to show you that I emphasize the roles as being a primary piece of the data governance infrastructure and the data governance roles and responsibilities. And this is the model that I share most often, is the pyramid diagram, as people typically refer to it. You can see there's kind of an executive level, a strategic level, a tactical level, and an operational level. And there's different names that people call these things. There's different names for the roles that are responsible within each of these different levels. In fact, in this example, I'm calling the executive level the senior leadership team. Sometimes there's already existing names for what we call the executive level within the organization. At the strategic level, we talk about data governance councils, and that seems to be something that's used quite often throughout many organizations. They refer to the folks at the strategic level as being at the data governance, being on the data governance council. The tactical level is where a lot of the work associated with data governance takes place. I typically refer to them as data domain stewards. Those are people that have responsibility for a domain or a subject area of data, and one of those responsibilities associated with protecting sensitive data is to make sure that they document the handling rules, but they document how the data that falls within their domain should be classified in their organization. The operational level, the level at the bottom, is typically the people that have the responsibility for following the rules that are being defined. On the left-hand side of this pyramid diagram, I'm referring to the different support roles, which could be the data governance team, data governance office, regulatory compliance, PMO, information technology, all these different areas that are kind of shared business services within your organization that have a relationship to data governance, and again, focusing mostly on the protection of sensitive data. Oftentimes, in the webinars, I share something that I call a common data matrix, and I've written about it in the book and done webinars on it, and this is just a piece of a typical common data matrix. Oftentimes, I'm going to try to mark something here on the screen. Oftentimes, there is information that you'd see to the right of what's being showed on the screen right now. The reason I'm only showing this subset of the common data matrix is that different data might have different subdomains of data that might be classified different ways, and that data might reside in a whole bunch of different systems within your organization. For example, ERP, MDM, the Enterprise Data Warehouse, the Data Lake, wherever it is that you're storing data within your organization. We want to make sure that we have a list of the domains and we categorize how that data needs to be classified within the subdomains that make up the domain of the organization. The executive level, typically, they mandate that it's necessary to protect sensitive data. They view data governance as playing an integral role in the protection of sensitive data and within a lot of organizations, like I mentioned earlier, that's one of the key reasons why data governance is set up, to make certain that data that is classified certain ways are only being handled in the appropriate ways within their organization. The strategic level, the counsel, they oversee the protection of the sensitive data. They're the ones that we may take the rules to to get them approved, the classification rules and the handling rules, and also, typically, the counsel is there to support ample communications and why it's necessary to protect sensitive data and how we're protecting sensitive data within the organization. At the tactical level, as I mentioned before, that seems to be where a lot of the work takes place, where people have the responsibility defining the rules associated with protecting the data that falls within their domain, making certain that those rules are being communicated effectively across the organization. So they're, again, communicating the rules that are associated with protecting the data that falls within their domain, and oftentimes they play at least some part of a role in seeing that these rules are being enforced for the protection of sensitive data across the organization. At the operational level, these being, again, the operational data stewards, the people that define and produce and use data as part of their daily job, well, they have a responsibility around protecting sensitive data in the absence of people within your organization. They need to learn the rules associated with the data, with the sensitive data. They need to follow the rules, and they need to make certain that when they're sharing data with other people within the organization, that those rules are part of what is being shared. So we make certain that the next person down the line from us that receives the data is following the same rules that have been set up for us to protect the sensitive data within our organization. Next when it comes to the rules, the support rules are a very important role in all of this. The data governance officer, the data governance team, IT, project management, legal communications, they're the ones that typically guide the effort to protect the sensitive data. They define the rules to make sure that they're being understood by people that have access to sensitive data within the organization, and that they might have the responsibility of then putting the enforcement in place to make sure that those rules associated with the data being protected are being followed throughout the organization. So basically I walked through each of the different levels of the operating model and shared with you at least some ideas as to how we might augment our existing level of roles and responsibilities with the roles and responsibilities that are specifically associated with the protection of sensitive data. So let's spend a little bit of time talking about selecting the different data sharing processes that we're going to govern within our organization. And so the first question that I would ask is, well, when does data sharing take place? So any of the times that any of these things are being produced within your organization, whether they're hard copy reports, electronic reports, even ad hoc queries, things like that, the results of these things are data. They might be formatted data, but again it's data nonetheless, and that data still needs to follow the rules that are associated with how that data is classified. Certainly when we're transmitting data or we're sending data via inter-office mail, if you look at the protection rules, the handling rules that I shared as the examples, there was some mention as to how the data needs to be marked. So data that's marked as being confidential or sensitive is handled differently from data that is being marked as being public. So we need to understand and we need to recognize all the different ways that data sharing is taking place within the organization and make certain that we've defined the data handling rules associated with the way the different data, the result of these different activities, how that data can be handled within the organization. So what are some of the data sharing processes? Actually we need to do a bunch of things associated with the rules for data sharing. We need to define, validate, and approve the rules. We need to define, validate, and approve the rules for determining who the data can be shared with, when it can be shared, how it can physically be shared, and there might be some limitations as to how data that's classified a certain way can be shared, physically shared throughout the organization or outside of the organization. And we want to define, validate, and approve the rules for sharing those rules. And I keep emphasizing that because it's very important and it's one area that a lot of organizations lack in, is making certain that the next person down the line who's receiving the data is as educated and as informed of the rules associated with protecting that data as we are before we send that data to them. You know, the organizations that set out to protect sensitive data within their organization are not, you know, typically don't boil the ocean. They don't try to do it all at once. They pick a specific area that they want to start with. So my suggestion is that you're going to take an incremental approach. You're going to learn from your mistakes and you're going to improve on them as you take on additional areas of the organization. You know, the same thing could be true for improving the quality of the data. You might not focus on the whole of the data of the organization at one time. You might focus on subsets of the data and get those rules working before you extend that into other parts of the organization, identifying the appropriate place to start and learning from your experience. And you know, it's really important to communicate how the data can be handled. So again, I emphasize that it's important to over-communicate these, so people are so well aware of the rules that it just becomes built into what they do and they're not even thinking about it. They know the data that's classified a certain way it needs to be handled in the appropriate manner. So again, do not boil the ocean. You know, start with a focused group. You know, maybe pick a functional area within your organization and start there and use them as your guinea pigs as you're starting out to make certain that those people understand the rules around protecting the data and then expand it across additional business functions or across different locations and markets that are being addressed by your organization. So again, you don't want to start by trying to cover the entire organization at once. You might want to focus on smaller groups and then gradually expand. It's not like you're taking a picture of a pie, taking a piece of the pie or even a piece of a piece of the pie and starting there before we start to expand this across the organization. You know, looking for an appropriate place to start, well, you might have an idea as to where the most appropriate place is to start within your organization, but oftentimes, selecting that place will depend on the data that you're protecting and whether it's optimized as being PII data, PHI data, intellectual property data, those different types of data might also be handled in different ways. And oftentimes, it'll depend on who's supporting the effort for data governance. They may have an idea as to where you should start. And, you know, so again, not trying to address the entire organization at once, but make sure that you have a plan for incrementally expanding from where you're starting and learning from your experience as you go and move to different parts of the organization. So some of the things that you can do to learn from your experience within a smaller group is to audit your process and learn from your experience, measure the time that's being taken per step, and be able to recognize where there's inefficiencies and ineffectiveness with your processes associated with this. Recognize people for their participation. Let them know that they're being recognized for protecting sensitive data and following the rules that are associated with protecting that data. And, you know, oftentimes what I find is that organizations that really focus on learning from their experience relate their governance efforts to calls for continuous improvement. And so I'll talk about this in one second here, which is one of the ways to measure the success of the governance to protect sensitive data is to recognize how many people and what parts of the organization that you have educated and onboarded with the whole concept of protecting sensitive data. And the last one under the rules for incremental implementation is over-communicate wherever possible. You know, and I mentioned here, placing reminders of appropriate behavior in appropriate places. Well, one of my clients actually put up signage all across the floors of the people who were working with data that was highly sensitive. They put reminders by the printers. They put reminders on the bulletin boards. You know, anywhere where they could put reminders to people about protecting sensitive data and how important it was to the organization, they took advantage of it. And they really, again, over-communicated wherever it was possible. You know, so leverage the existing channels that you have, whether you have internal websites or things like that, but also be creative in the way that you're finding new ways to be able to communicate the classification and the handling rules associated with the data. And that could be through newsletters, bulletin boards, lunch and learns, town halls, whatever methods you have available to you. If you don't, then now is a good time to start. If you don't do lunch and learns, maybe you want to try to handle a whole lunch and learn or a town hall associated with the importance of protecting sensitive data and the way that we're going about it within the organization. And the last thing that I want to talk about today before I turn it back over to Shannon is talking about measuring protection to demonstrate how data governance is doing around this area. So there's different ways that data governance can measure data protection. One is by measuring the completed steps that need to be put in place around data protection. As I mentioned, the education by group or function or location or different people within the organization. And then also look at the different outlets that you have available to you to communicate with people about protecting sensitive data. And you can measure what percentage of those outlets you're taking advantage of. So let's walk through each of these real quickly. The steps that you need to take in order to put data protection in place might be the definition of the data classification rules, that they're defined, that they're validated, that they're approved. Same thing with the data handling rules that I mentioned earlier that are associated with the classifications, that those rules are being defined, validated, and approved, that you have a communication plan in place, that you have an enforcement plan in place. All of these things are not traditionally looked at as being ways to be able to measure the program. But if you can say that you put these things in place, you can definitely show advancement or performance of data governance associated with protecting your sensitive data. You just want to make sure that you're communicating to people when the classification rules have been defined, when the data handling rules have been defined, that there is a communication and an enforcement plan. The way to measure data protection is, as I mentioned before, being able to define how much of the organization you have addressed with this type of communication. So the number of groups or the functions or the locations or the number of people that have been onboarded, the percentage of the organization that you've onboarded and that you've gotten to be very familiar with the importance of protecting sensitive data as well as the classification and the handling rules, and then whenever updates are being provided to the educational materials, you can measure that information as well. And the last thing that I mentioned here was the data protection communication outlets. There might be a bunch of different outlets that you could use, whether it's an internal website or those lunch and learns, the face-to-face meetings, but count the different available outlets that you have to you and then measure how many of them you've taken advantage of. And then most importantly is talk to the people that have been on the receiving end of that communication to see how effective that communication is. Obviously, you can also measure then occurrences of where data classification has been breached or people have handled data incorrectly. You can measure those types of things, but I'm really focusing on the positive here and saying we want to make sure that we are addressing the appropriate amount of the organization or using all the channels that are available to us to help people to understand how we're using data governance to protect sensitive data throughout the organization. So in this webinar, like I said, I thought I had a whole bunch of slides to go through, and I did. In this webinar, we discussed those five most important things. First, we talked about the classification rules and the data handling rules. We looked through the roles and responsibilities associated with data governance, and we added some things to them, to those roles and responsibilities about protecting sensitive data. We talked about looking at the different data sharing processes and the things that we might want to apply governance to. Again, to try to stay as noninvasive as possible with our approach to governance. We talked about the incremental implementation, making sure we don't boil the ocean and try to do the organization all at once. Again, start small and incrementally expand it and measure how you've expanded it throughout the organization. And then there's the measuring of the protection to demonstrate that data governance is doing what they need to do associated with the protection, again, of sensitive data. So with that, I'd like to turn it back over to Shannon and see if there's any questions from today's webinar. Thank you for another great presentation. As always, and just to answer the most commonly asked questions, I will be sending a follow-up email to all registrants by end of day Monday with links to the slides and links to the recording of the session, as well as anything else requested throughout. And lots of questions coming in, Bob, right from the get-go. So just want to dive right in here. You talk about this a little bit, but this came in right away, but maybe you want to expand a little bit. Should data governance team be a data steward for one of the lines of business and be actively involved in issues, an issue remundation in that line of business? Sometimes it really depends on how you define your data governance team or your data governance office. Sometimes it's made up of people within different business areas that are lending their time or participating in the definition of the data governance program. In that situation, yes, the people that are part of the team potentially could be the data stewards for a business area, but typically I don't recommend that. I typically recommend that the data governance program team or the data governance office, however you call it or label it within your organization, they have the responsibility for defining what the program looks like, administering the program, facilitating meetings. Typically the people within the data governance office do not participate as stewards before they're actually part of a business area that defines, produces and uses data as part of their job. Typically I would say no, but it really depends on how you make up your data governance team. Should the data handling rules be defined for each data point or should they be at each classification level? You know what, I have them synced up with the classification level, not at each of the data points within the organization. The classification of the data is going to change. If it does, then you need to be able to note that the classification has changed as it's moved from one data point to another point within the organization, but oftentimes the data that is defined as being highly sensitive at the get-go at the beginning is still going to be highly sensitive at the end. So unless there's some change along the way, I would suggest defining the handling rules as I presented in the webinar, associating those to the classification levels rather than having them defined specifically for different data points. Do you not boil the ocean completely? Great, several comments on that. However, I believe that we should communicate the overall plan and value of the program. Any advice on how to achieve that? For example, avoid falling into one of two extremes? Well, you did this in other webinars. Put together a communication plan. And oftentimes the communication plan falls. There's really three sections to a communication plan. There's the orientation piece, the onboarding piece, and then the ongoing types of communication. So for the orientation, certainly we need to make certain that people understand the importance of protecting sensitive data and the risk that they run or they potentially could fall into if they don't follow the handling rules. So I typically suggest that we define the rules, we communicate them through orientation to new people within the organization. We bring them on board. So from that point forward, they're expected to follow the handling rules because you've communicated them effectively to them at that point. And then the ongoing communications is a big part of it as well, in case the classification of data has changed or the rules associated with handling that data has changed. Yes, it's very important to set up a communication plan that's going to address classification levels, but make certain that you at least address the orientation, the onboarding, and the ongoing communication to make sure that you're covering all your bases when it comes to communicating the importance and how you're protecting sensitive data. Follow up on the first question. How should the data handling rule be represented in the business glossary for each data point? Well, you know what, I agree with the data classification. And so in your policy, your data classification policy or it could be part of your data governance policy, you would define how the different handling of the data would fall for that data that's categorized that way. I wouldn't necessarily include the handling rules within the glossary. I know I might have mentioned that earlier, but if you do that and the data handling rules have changed, then you need to go back to all those entities within unless you're using a pretty well-defined relational structure, you're going to need to redefine those within the glossary. So what I would say is refer in the glossary to the data classification policy so that people will get used to looking there to understand the handling rules instead of listing each of those with each item, each term within your business glossary. So why would data stewards not be part of the data governance team? Why or why not? So why I want to mention before it could be anybody in the organization who finds or produces or uses data as part of their job, and that's why I say that potentially everybody is a data steward. You could have data stewards represented on the data governance team, but oftentimes I don't find them as... I find usually the person from the business unit or from IT or shared business services, those are the people that typically make up the data governance team. You may talk to the data stewards and see what their issues and concerns are and give them a feedback loop so that they can provide feedback to what data governance looks like. But from my experience, again, I haven't really seen a whole lot of data governance teams or data governance offices that are made up of the data stewards themselves. It's not to me that there's not a way to be able to do that. It's just that I haven't really utilized that in the approach that I followed. All right, I think we have time for the organizations to get data stewards to understand and do their function. Do you have any additional comments on that? Well, I mean, typically if there's defined rules, and let's focus specifically on the protection of data, whether they're identified as a data steward or not, they're going to be responsible for following the handling rules associated with the classification of the data. So I think it's important that the data stewards are educated and brought up to speed and that we get them actively involved in the protection of data because they are the eyes and ears. They are the hands. They are the people that are touching the data hands-on within the organization. So they need to be very educated and they need to be monitored so that you can make certain that they are following the appropriate rules whether the data is classified. Well, Bob, thank you so much for another great presentation. I'm afraid that is all we have time for. Thank you all of our attendees for being so engaged in everything that we do. We really appreciate all these questions. And again, just a reminder, I will send a follow-up email by end of day Monday with links to the slides, links to the recording of the session and all the additional information. So Bob, thank you and thanks everybody. Hope you have a great day.