Hi, and welcome to Module 5 of the IAPPCIPM. This one is all about data assessments. By data assessments, in module 5, we're looking at different ways. You can look the data that you have and understand exactly what it is in terms of data protection, that you need to protect about it. My name is [inaudible] Brian, and it's a pleasure to walk you through this next section. We're going to start this section by looking at data inventories. Now, data inventory, often a misunderstood term. We sometimes use loads of other definitions, and words for it as well. But the idea of a data inventory is it's basically privacy one-to-one. Privacy one-to-one is, where is my data? What data have I got? Where is it? Without altering those questions. Without having a database or a spreadsheet or some understanding of the data about your data, the metadata, it becomes very difficult to understand how to manage it. Very difficult to understand how to manage it. This correlates with the principles of privacy by design. We're going to talk about privacy by design a little bit later on in the course. But I think it's worth talking about the fact that we've data protection, you have to get it right first time. You have to do it first time, you have to get privacy involved early, organically build into new products and services. If you do it later, after the products and services have been built, it's often too late. It's often much harder to build things in, and I describe privacy as somewhat of a Pandora's box. Once something is known, it cannot be unknown. Once something is unleashed into the world, you can't really put the lid back on it. Getting it right the first time is really important for us. There's lots of different techniques and tools people use, but they're basically asking exactly the same question. Where is my data? You're going to find that a lot of people around the organization that might have already done some where is my data type activity. Either creating a data inventory that we're talking about, creating the data about the data, but you might already find that IT might hold some inventory of data assets they have. Some people might have done some data mapping exercises, which is trucking data through its life cycle, diagrams, perhaps. In the EU, because the GDPR, we equate, we have this obligation to do what they call records, or processing activity. Essentially, what all of these are doing is they're educating you about the types of data you have, and where it lives, and how it moves across the globe and how it's protected. Let's just take the EU example of what they call records of processing. Now, in the EU they see, you got to do this some more 250 employees, unless the processing is risky, that's the legal trigger, if you like. But I think when you look at the information they're asking for, they're they saying, who are you, who is your representative, who is your data protection officer, what are you going to use the data for, the purposes of process signals so you could break up your data inventory by purpose? We do it for marketing, perhaps. We do it for service delivery. We do it for HR. We do it to protect our legal rights, number of different purposes of processing. Then they say, well, describe who the data subjects are. Are they children? Are they adults? Are they employees? Are they beneficiaries of some service? Are they commercial customers? Are they targets that you want to market to? Who are the different types of data subjects? Then what types of data do you have on each one? Is it just contact details? Is it just name and address? Is it their financial details? Is it their sexual life, is it data on their families, and their dependence? Is it data on contracts, and interactions that you've had to do? What types of data do you have? Obviously, some of those types of data will be more risky than other types of data. The first thing we need to do is really understand, who we're dealing with, and what types of data that we have. Then who are you going to give the data to? Obviously data doesn't stay still. It moves around. Who are you going to give that data to? Who's the data on? What are you going to use it for? What types of data do we have? Then who are you going to give it to? Who are going to receive that data? I think, going back to the international transfer stuff we were talking about, where are they? Are they across the globe? Are they local in the US? Are they local in the EU? Is the data on EU people moving to the US, is the data on US people moving to the EU, for example? If we're going to move into an international, and the EU law says you've got to have the justification for that transfer, and very similar actually, when it talks about the purposes of processing under EU law, you should really think about the legal basis for even holding that data in the first place. Generally speaking, I'm thinking here about time limits. When are we going to get rid of it? When are we going to erase it, and how is it going to be kept secure? If we're processing on behalf of other people, well, what have we got on behalf of which other person? Which categories of processing are we going to be carried out off each controller? Generally speaking, my advice to people here is do it on a cradle-to-grave process. Look at data from collection to disposal, from start to finish. Then as we go through that data, we can ask questions on collection such as, where do we get it from? Is it directly from the individual? Did we got it from a third party? Where are we going to use it? What systems does it live in? How have we been transparent? What's the legal basis to use? What types of data have you got? Are anyone particularly more sensitive than others, then we can go on to thinking about storage, and use, and disclosure, and access, finally free to disposal or deletion. Really, we want to get inflammation metadata. Data about the data along its life cycle, as much data as we can get. Of course, to do that, you need to be able to break down the organization in the first place. Number of discrete Data flows perhaps, or by IT system, or by department. We need to find a way to break down the organization. That's going to depend on who you are and what organization you are. Some organizations will have. HR as a single data flow. Someone comes on board, or you recruit someone, they come on board, they spend a bit of time with you, you delete the data or get rid of the data after they leave, perhaps. Then you have people that your really large organizations that may think, well, actually, no, that's a number of data flows. Recruitment is one data flow, On-boarding is one data flow. Benefits is one data flow, pension, payroll, other data flows. Off-boarding is another data flow. Really depends on the size and scale of your organization, how you decide to break down those data flows, but as I said, once you've broken down those data flows, you can then get that cradle-to-grave metadata out of the system. But why are we doing it? Well, we're trying to manage those risks. We're trying to apply privacy principles along that data life cycle. Even once you've actually got a data inventory, the real problem I would suggest, is keeping it up to date. Having a data inventory is one thing, and how we practically manage that data inventory is quite another. There are all sorts of tools out there on the market. I mean, the most common one is probably your Mark 1 Excel spreadsheet, or your Mach one piece of paper, and that's going to be fine for small organizations minutes you are massive, large global enterprise, things are going to get complex. Excel spreadsheets sent around the place aren't going to work. You might need a centralized document storage, and there's even vendors out there now that will sell you a tool. An online database with all of the right boxes in it to begin to create your data inventory. Once you have it though, organizations don't like doing it. I'll be honest. Your privacy team may well be involved in it, but they don't have the information. They've got to go to the IT teams, they've got to go to the business teams who will be able to answer the question and populate the data inventory, but they don't like writing it down. It's a tax on their everyday work. They sure, solely, don't like keeping it up to date. Keeping it up to date, I think, is a real issue with data inventories. Processing changes, the law change, what you do in a business changes. It's probably less of an issue to keep it up-to-date than it is to do it in the first place, but I meet a lot of people that have done a data inventory to comply with the GDPR back in 2016, 2017, perhaps even in 2018, but now it's now 2021, and they're found, oh, we haven't kept it up to date. It's now three or four years out of date. The final thing I want to mention when it comes to data inventories. From this, all things have passed the spring. Without knowing what data you've got, without knowing your data footprint, without knowing how it moves across the globe, there's no way you can manage your privacy. There's no way you can manage data protection law. There is no way you can manage risk without having an understanding of exactly what the data is. This is pretty much privacy 101. The next thing we got to say is, well, do we comply? Can we compare the data against various sources to see do we comply? I wanted to mention two different types of compliance. You might see this in exam. There's compliance , and there's conformance. Conformance. I think the difference is largely about internal versus external requirements. Do we comply with the law? Well, that law is an external requirement, but do we conform with our own internal policies? We've got our own internal policies. Do we conform with them? We've got the law. Do we comply with it? We've got regulations. Do we comply with it? A lot of this going back to our Plan-Do-Check-Act management is, as well as identifying the data, and identifying the way that data moves, and the way that data is managed, is it also identifying the requirements that come into our business? The legal, the regulatory, the statutory, the policy requirements, the management requirements, and then once we have our data inventory, we can look and get that match, and that's a data assessment in itself. Does that data inventory match what we want and where there are gaps well, then we can identify actions we want to take, but of course, we can't do everything on day one. We can't learn from day one. We can't boil the ocean. Most organizations are massive, and we need to know where to start. As we know, all these data protection laws has words in it like, appropriate, up-to-date, necessary, adequate. What that means is, we have to have an understanding of where our priorities lie, where to start. The next section, we're going to talk about risk assessment.
