Hi. Welcome to the next session on performing assessments on your Data Protection Management Program. My name is Ralph O'Brian, and we're going to be looking in this next section of risk assessment and gap analysis. Let's begin. Let's look at gap analysis and the difference between that and risk assessment. I think in our previous section, we already looked at the difference between conformance and compliance. This idea that it's a gap against something, you're trying to evidence whether you meet something or not. I think we'll talk about that a lot more when we look at auditing later on, this idea of just trying to evidence that you meet some criteria. That's what this sense can be called a gap analysis. You started all auditing tools whereby you're trying to evidence you meet some criteria. Risk assessment is slightly different because risk assessment, we're looking at risk against somebody's risk appetite. What that means is there's no fixed statement of compliance. The only compliance there is whatever your management decide. I think that makes privacy laws quite an interesting area. Because what you're doing in privacy law essentially is you're setting your own road path. You're saying to yourself, this is the level where I feel comfortable in. I think that's quite appropriate. Even though we have got laws and things like that, the laws all use words like necessary, adequate, appropriate, proportionate. Therefore as management, you do have to take decisions, decisions about what those risk appetite is going to be, and what level you're comfortable of your privacy program becoming. Compliance with the law then becomes this kind of interesting, movable fixed where you have to admit, yes, you have to guess at what the regulator, once you have to guess at what the individuals want, and then you have to balance that against your business needs. Your risk assessment becomes really critical to making sure. I think it's interesting toward risks to humans well, until about PIA is, and we'll talk about them a bit later. We're looking at the risk to the data subject. Well, we don't have ever forget that we should be placed at the individual, at the heart of what we do. The most risk assessments we see. Actually, looking at risk to the organization. One Medical in this case, you are going back to that case study. What's the risk to One Medical as opposed to you? What are the risks to the individuals which they serve? We the staff members or customers or medical clients, for example. Before my risk assessment, we've got to work out what the target of our risk assessment is, as you know, is that the business is a business unit system, is it the individual? Then we go through a process. We go through a process of identifying what those risks are. We try and work out how big those risks are. Then we try and find out the options to manage those risks. What we want to do about those risks, which probably results in some sort of his treatment plan which will need to be approved by someone with an implement any changes to our control environment. The thing that lives in our business that manage the risk. Then we measure and monitor how effective that's going to be and we improve. This should look very familiar to you now, this whole Plan-Do-Check-Act we talked about on a macro scale in the organization and on a micro-scale applying to each risk assessment. Let's just do a little bit more in-depth there. When we're identifying our risks, we generally look at three aspects to identify the risks. In the security world, we tend to call things assets. These are the things of value to you. The thing that we're trying to protect, the asset could be a building. Then we got to think about what could hurt that building? We tend to call those things threats. We've got threats, something that can hurt the building or a virus that can hurt the system, or losing an individual to a competitor. Asset of a person threatening might leave to go to a competitor. Asset of a building, threat of fire, for example. Assets, the individual threats, their identity might be exposed. But of course, these harms don't happen on their own. We know that there are things of value, but we know that there are harms, what we don't know,of course, is how to bring the two into proximity to each other. We don't have a risk until that threat reaches the asset. We did a third thing. The third thing we tend to call a vulnerability. Assets plus threats plus vulnerability will take asset plus threat plus vulnerability. These things give us a list of risks. The next few of them need to do is work out how big those risks are. I'm sure you're familiar with the fact that we tend to use impacts multiplied by some likelihood. Impact times likelihood tends to give us our scale of our risks are. We've identified the risks, we come up with a list of risks. We're now measuring how big they are. Here there are different ways to do this, different ways to do this, it could be 1-3, it could be a 1-5, could be a high, medium, low, could be a percentage. But do the way it's normally sum product of impact and likelihood. Sometimes even reduced by the amount of control you already have. You're looking at the difference between the inherent risk and the current risk. Then what that gives you a broad category, then obviously are our risks would manifest the areas, points. On our scale, risks would manifest in various points on our scale. In extremely high risks, we might have a number of extremely low risks, for example. I just think it's worth talking about that, that we've got those different risks manifesting on our scale. Going back to our risk methodology then, our next thing is then is to work out what we're going to do about those risks. If you can imagine, as we said, we've got, sorry, impact scale, we got our likelihood scale here and we've got our risks, boom, manifesting at different points around this graph. This is just a standard way of looking at things, for example, so here's a risk here. Of course, these risks are in impact and our likelihood scale. What can we do about risk? Quite often these are called the five Ts. Not all people tend to think about it in these ways, but obviously the most current one is risk treatments. You're going to add a control or reduce a control that you've got in place. Then we've got the option to tolerate. I'm happy with that risk. I'm going to monitor that risk. I'm going to make sure that that risk doesn't come back to bite me because actually you can accept quite a lot of low risks and that can be a difficult thing to do as well. I think all risks require monitoring no matter their size. We could take risks different from tolerate, because actually you're inviting more risk here, very rarely happens in security and privacy. We're not venture capitalists generally speaking, but we do end up in mobilizations that do like risk. With risk, comes ward. Therefore, they might decide to take the risks. There might decide to not comply with the law, for example. If it's too risky, we may decide to terminate or stop what we're doing. Perhaps it's too risky to carry on doing what we're doing, so we're going to stop that process entirely. The last thing we might do is try and give it the risk to someone else. A question whether that's ever really what you're doing here, transferring the risk, but that tends to be some insurance or outsourcing activity. Going back to our graph, in this case, what we tend to find is easily decisions don't happen at different points on the graph. We can then say, well if it's a high impact and a high likelihood, what's more likely to occur? What decisions we're more likely to take? Let's go back to my diagrams here. Let's get back to my diagrams here. Within those diagrams, I want to draw that risk diagram again here. Again, we've got our scale here and our scale here with impacts going up on the vertical and our likelihoods going across on the horizontal. Then what we can do is split the graph into four like this. It doesn't really work into four, it's more like a small area at the bottom and a small area at the top, and then a small area here and quite big area down here. For the purposes of this say, well, up here you've got high impacts and low likelihood. Up here, you're at high impacts and high likelihood. Down here, you'll have low impact and high likelihood, and down here, you'll have low impact and low likelihood. What I tend to find is you take different wise decision in each area. For example, where the risk is really high, that's where you might take your terminate decisions, where the risk is extremely high, too high for you to manage. Equally down in this corner, that's where you got to take your tolerate decisions down here because the impacts and the likelihood is low. Therefore, you're more likely to tolerate those decisions. Where things happen all the time but don't hurt you very much, that's the stuff we tends to treat, stuff that happen all the time, but doesn't hurt you very much. Where things would really, really hurt you, that don't happen very often at all: fires, floods, declared war pandemics, for example, this is the stuff we tend to insure or outsource again, the business continuity events, if you like. That's where we tend to take the transfer decisions. Obviously, the next step is to then come up with some risk treatment plan. Risk treatment plan has got to spell out the actions or the controls we want to put in, all of the controls we want to add or remove. When I say controls, of course, I mean, they could be anything. It could be from having a policy and a procedure to doing staff training, to putting in some whizzy technical thing. Privacy announcing technology could be any thing here. We're then going to need that retrieval plan approved. Why? Because the management would probably going to fund or resource it. There's going to be some residual risk leftover as well, residual risk leftover that the management they've got to be happy with. We put the controls into operation, we measure and monitor how those controls are going to work, and then last, but certainly not least, we take some improvement actions and then Plan-Do-Check-Act, the wheel never stops turning. Eventually, we're going to want to look at redoing that risk assessment, plugging in what we've done into a next iteration. I hope that was a useful little way of going around it, looking at identifying risks, measuring the risks, and then looking at risk management on avenue of a wider basis. That's how a lot of people do. I've used methodology here from the Information Security world. I think it applies very equally here to any privacy or risk management activity. Identify the risks, work out how big they are, decide what you're going to do about them, talk of a plan, get that plan approved, change the controls, operate the controls, measure and monitor those controls, take any improvement actions as a result, and the wheel never stop turning. I mean, that's a quite detailed way of doing a risk assessment. Sometimes you might just want to do it quickly. Sometimes you just might want a quick version of a risk assessment. Do it quick and dirty, and Data Protection. I've come up with a little bit of a methodology you want. What I do perhaps is I put the business units down the left-hand side and then perhaps come up with perhaps five or 10 different risk categories that I think would make a Data flow more or less risky in Data Protection terms, stuff that I can just give me a yes or no answer to is database big. International transfers are third party involved. Is it based on consent or legitimate interest or one of those legal bases I'm not quite comfortable with? Does it have special category data? I can use those five to ten categories to generate a rough school. You can see here very quickly to create priority, which Data flow do I start first in perhaps. He's got 5/5 marketing. Marketing, probably my priority. Big database international transfers, third party involved, based on consent, special category data 5/5. Then I'll go to operations, our operation is one in this case because we got 4/5, then probably into IT with 3/5. Just a quick and dirty way of prioritizing which businesses or dataflows I might want to come to next. We also have to understand for the exam different risk types. I mentioned these a little bit briefly. But essentially that's three different types of risk that we can monitor and lookup. Obviously, there's our inherent risk. This is our risk. Have we have nothing. Had we add new controls whatsoever, would call our inherent risk, count how risky we are had we had no controls whatsoever. Obviously, we then got our current risk, impact times likelihood with what we've got in place at the moment. Then finally, we've got our residual risks. After we've done some treatment, after we've introduced new controls, are we happy with our level of residual risk that would cope in the business? I mean, we always have risk. Every time we get out of bed, we face risk. If we don't go out of bed, we face a different kind of risk. You are never going to get away from risk. The final thing we want to consider is then taking improvement actions. Say what improvement actions might we take? Well, we might have to correct the problems. Of course, there takes some corrective action. If we've identified a problem that needs to fix, we might equally do a risk assessment as a preventive measure to prevent those problems from occurring. But the best type of action we can take is a preventative action. This doesn't just correct a symptom, but addresses the root cause. Therefore, when we talk about fixing things and we took the actions and improvement the check-in Act phase a bit later on in the course, we're going to focus not just on treating symptoms, but I'm looking for the real cause. I'm trying to coordinate multiple problems across the organizational issues or improvement activities or improvement options to try and really find what the root cause or issue is. We can take one action, one single action that delivers the most amount to change the best bang for your buck, if you like, than doing things on a smaller scale. Thank you for listening. The next session we're going to look at the next wavefront of assessment we're going to look at is actually PIA, privacy impact assessments. It's as GDPR cousin, the data protection impact assessment. See you in the next course.
