Hello. Welcome back. We're back. We're looking at information security breach notification. My name is Raphael Brian, and it's worth having just a quick understanding of what breach notification requirements they might have. Breach notification is nothing new. We're going to focus on GDPR here again because that's my thing, but breach notifications do vary tremendously across the world. All 50 states in the US now have got local breach notification laws to the state level, there are breach notification laws across the globe, in Africa, in Canada. Actually, it's Europe who is actually quite slow for breach notification. It was only when the GDPR arrived in 2016 and enforceable in 2018 that we really even saw data breach arriving over here in Europe. But in order to report a breach, we first got to understand exactly what one is. The first error is what one is. Could use the GDPR definition here, but I think it's really interesting to look at how wide a definition of a data breach can be. This one here talks about a data breach meaning of breach in security, fair enough, leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to the personal data. Now I think this is brilliant because what we're normally used to seeing is unauthorized disclosure. In fact nearly every security breach you'll see in the media is focused on unauthorized disclosure. But if you look at the definition here you've got destruction of data as well, and you think why do I need some report destruction of data? Why is destruction a data problem? It's gone and no longer a risk. But just imagine for a minute turning up at your bank and looking at your bank account and finding out, oh my God, where's my money gone? Where's my account gone? I'm sorry we don't have an account for you. But my money was there. Or even being able to not gain access to that personal data, not be able to gain access to your bank account. That's going to be damaging. I think it's really worth actually thinking about if you've given someone else access to data they shouldn't have, that's a data breach. [inaudible] it even says accidental or unlawful. We could have done this accidentally if we've given access to the wrong access permissions internally, technically, that's a data breach. No different a data breach under the law here than it is to disclose thousands of people's data to an external party. Of course, even in the real-world there's going to be riskier concerned. We've got this definition of a data breach here, a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of or access to the personal data. I also want to talk about the difference between a data breach, an incident, or a vulnerability. I think that's important as well because at the end of the day not everything will be reportable, not everything is going to put people at risk. Occasionally, we're not even going to want to know about stuff that does. We're going to want to know about the thing that happened before the breach, the thing that might be security relevant but isn't a breach yet, to get that early warnings in place. Do we want to know that data has got a walkabout or do we want to know that there is a vulnerability that people potentially be exposed? I want to make the definition here between an incident and a breach or a vulnerability and a breach. This might be an exam question you might see in it, what's the difference between an incident and a breach? To me you really have to worry about a breach when the data subject or the individual is put at risk or harm, or where something has actually happened, something has actually occurred, whereas our vulnerabilities or incidence may well be security relevant. We're probably going to want to record them, we're probably going to want to use them to help us reduce our risk, but at the end of the day, nothing has happened, nothing has occurred. That risk hasn't been exploited. I think of it as an equivalent to health and safety. In a health and safety environment they will often ask you to report near misses, the trip hazard as opposed to somebody tripping over that trip hazard. That's why I think about the difference between an incidence and a breach. Let's say we've had a breach, who have we got to notify? The GDPR actually gives us a number of different notification routes. It says the processor has got to tell the controller. No one else, just the controller. Then it says the controller has got talk to potentially supervisory authority or the data subject. Let's go through those triggers. Let's really understand when those data breaches occur. Let's start off with our data processor. Let's draw our data processor and let's draw them right up the top here. This is our data processor. We know that our data processor has got to inform the data controller, so let's add in our data controller here. When does the GDPR say? Well, at this say people within 72 hours, a lot of people say within 72 hours, not actually what it says from processor to controller. It says, without undue delay after becoming aware of a data breach. What is aware? What does awareness mean? When do I become aware? If one person in my organization knows, does that mean my organization is aware? At what point do I become aware? I think in this situation, if a processor has told the controller, for example, typo there, then definitely when you are told you become aware, because the data breach actually might have been years earlier. But you only now finding out about it. Here's the data breach, that data breach has happened here. It could be something as simple as incorrect access permissions. It was accidentally being given the wrong access to personal data, clearly a data breach. Then now on, what's going to happen. Well, the data controller is going to take some decisions. It's got to decide if it tells your supervisory authority man or your regulator. Bear in mind, it might not only be data protection regulators, there are other regulators in the financial world, and the medical world, and the gambling world, that may also be required to understand and get to see these data breaches. What is the law here saying? Again, I'll focus on the GDPR. The GDPR says here, without undue delay after becoming aware, we know this [inaudible], but it says, any event less than 72 hours, here's your 72 hours, 72 hours, what's that? 24, 48, 72, three days there? Three days to let the supervisory authority know that you've had a data breach. Now, you might not have all the information at this point. It says, you can put in further notifications without further delay. You can give more notifications because you might not know everything within 72 hours. There's the data controller to the supervisory authority. But most importantly, it says only notify when there is a risk of harm to the rights and freedoms of the data subjects. Don't forget that risk of harm, really important. Let's just take our example, our MedSource example. Our MedSource example was that we had incorrect access submissions up here. Your MedSource has got a data processor, that data processor had given their staff incorrect access permissions. Is it a breach? Well we know, we've got an accidental access to the personal data. Yes, it's clearly a breach. The processor has got to tell the controller. Does the controller have go to tell the supervisory authority? I don't think so. I think the controller does not have to tell the supervisory authority. Why? Because I don't think there's any risk of harm to the data subjects. It's only internal. It is a data breach, but it's only internal. It's only the individual that has got access to that. It's been reported, access permissions have been changed. We don't think it's gone externally. We don't think there's any risk to the data subject. We probably wouldn't tell the supervisory authority. If we thought there was a risk to the data subject, then yes, of course we would tell them. Let's get rid of that one as an example. Now we've got a bigger data breach, a worst data breach. Yes, we're now going to have to tell supervisory authority, what do we have to tell them? That's more of an interesting thing. What we have tell them is the following. We have to tell them the nature of the breach. What happened? The categories of the personal data, is it financial records, is it contact details. All of that type of different data that might have been breached. Was it special category data, was it religion, ethnicity, disability? What types of data are being breached and who are the data subjects. Are they members of staff? Are they children? Are they your customers? Are they customers of somebody else? Who is the data subjects and how many of them had been affected. How many data subjects and how many records, the number of records, the number of data subjects. You've got even contact details. It could be a Data Protection Officer or it could be anyone else you nominate for this matter, perhaps someone in your security division. Then you've got to say what might happen. What's the consequences of the breach? What's the risk? You're only reporting to the regulator where there is a risk of harm. What is the consequence to the individual? What is the risk? What are you doing about that risk? What measures are you going to take to address and mitigate the effects of that risk? Again, I've said already, it may be communicated in multiple phases to the supervisory authority. There we go, we've told the supervisory authority all things we need to tell him, the nature of the breach, the categories of data and data subjects. We've told them the number of records. We've told them the number of data subjects. We've told them contacts, we've told them the consequences or the risk and the measures we've taken to deal with that. We've told them a lot. Then we've got to take the decision, do I tell a data subject? Let's put this little arrow there, and let's put the data subject here. Now, what does it say in the GDPR? It says without undue delay, after becoming aware, this should all be familiar. But this time it says, where there is a high risk to the rights and freedoms of the data subject, a high risk to the data subject. We have a high risk, to the rights and freedoms of the data subject. What is that high risk, when is a risk a high risk? That's something we're going to have to think about. The law actually doesn't help us there, when is the data subject placed at high risk. We have to tell them very similar things, including being transparent, all those things with improving notice. Just have some limited exemptions of the law actually, it says we don't have to tell him if the data is unintelligible. I think here we'll talk about things like a decent encryption here, where even though the data has been breached, we don't think anyone can use the data. We've said where you've fixed the risk, where you've taken some actions to remove the risk or reduce the risk. Therefore, it's no longer a high risk to the data subject, or if it's impossible to contact the data subject. Let's say you've got load of personal data, but you actually don't have their contact details. Well, then it says you got to take out press or PR to tell the data subject, to let them know some press release here, to let them know in that case. It says that the regulator can overrule your decision here anyway. A lot of information here about data breaches. The first thing we're going to have to determine, as I said, is it easy to data breach or not? Is it just an incident? If it's an instant, it doesn't fall into this category. If it's an actual breach, if there's some confirmed damage or harm, or confirmed disclosure of data, or confirmed loss of availability, or confirmed loss of integrity, then we're going to have to report. Who do we report to? Well, we report from the process to the controller without undue delay after becoming aware. From the controller to the supervisory authority, without undue delay within 72 hours where there's a risk to the data subject. We tell them the nature of the breach, the categories of data and the data subject , the number of the records, number of the data subjects, name, contact details, consequences, measures to address. Then we have to describe from the data controller to the data subject without undue delay, after becoming aware there's a high risk to the data subject. Unless that data is unintelligible, you've somehow fix the risk, or it's impossible, in which case you take out press release, in which case the supervisory authority can overrule you. Number of things there are to think about on data breach. What's clear to me in terms of your organization, is you're going to need some documentation to educate people what they are, what they're not, or when you report them, to who you report them, and who can tell what to whom. Who needs to communicate, you need to tell you a processes when to communicate to the controller. Your controller, when to communicate to the supervisor authority, or when to communicates to the individuals. Also you're going to need to tell your staff, what have they got to report? Why if they got to report it to? To whom? When do you want to report it, and what's going to happen next. We'll leave it there in terms of data breaches, and then we're going to just take a little trip for ISO standards through our next section before we move on to the managing the consequences of those data breaches.
