In this episode of the GDPR mini-webinar series Amar Singh and Chris Payne discuss the topic of incident response.
Download the free accompanying study sheet here.
Amar: Welcome to Cyber Management Alliance’s GDPR mini webinar series. And today we’re talking about a very important topic, again, which is Incident Response. I am joined today by Chris Payne again; Chris Payne from Advanced Cyber Solutions and also our GDPR expert. Chris, thank you for joining us.
Chris: Thank you.
Amar: A quick disclaimer… can we all remember this is just information. You must seek your own professional legal advice before you make any decisions. So, please do. Moving on, Chris; what is an Incident Response breach?
Chris: So, I get this question very often, much like I do for most EU GDPR topics, but I think there is a lot of confusion out there about what a breach is. Most people who assume, based on normal IT security languages, a breach is when somebody external gets access to something internal or steal something. It's a slightly wider scope when it comes to GDPR and the exact text from the regulation is on the screen now. So, we’re talking about hacking, that can be a case of breach; we’re also talking about unintended destruction, so unintended deletion of records, loss, changes… so, it could be that I changed telephone number to something else and I shouldn’t have; unauthorised disclosure, so that could be malicious, it could also be accidental; losing data, sending it to the wrong email address; and, of course, access as well, somebody who shouldn't have access to personal data gains access to it, then that is, of course, a breach as well. So, it’s a much wider scope. I guess, in some cases, these things might seem minor to people but under the GDPR, they all constitute one thing – a breach.
Amar: And very important, can be accidental.
Chris: Yes.
Amar: It doesn’t have to be only an external hacker. People get really confused with this sometimes. It doesn’t mean if Russia, China or somebody else is attacking you, it could be an employee accidentally disclosing something or accesses that something, or changing something that he or she should not have to.
Chris: Yes. So, critically breach doesn’t mean breach in your network, it means breach in a regulation.
Amar: Ok, so, the breach notification. What are the points to keep note?
Chris: Yes. So, slightly different from the Data Protection Act, breaches now must be reported to the supervisory authority no later than three days after discovery, and that’s you actually discovering it; so, you as the data controller discovering it. So, that's not three days after the breach, that's three days after you’ve discovered it. So, there's a slightly wider scope that you have there for reporting than people are actually thinking that they have. Then remember, the term breach is not just the external attack. So, if somebody has gained access accidentally, like if you’ve given them the wrong privilege accidentally or somebody’s deleted something, or sent it to the wrong address accidentally, you must notify the supervisory authority within seventy-two hours of discovering that. So, that even though it’s very minor, minor problems that you’ve been dealing with internally.
Amar: Now that's including leaving an encrypted USB drive or hard disc with personal information accidentally in a cab; that is a breach.
Chris: I'm glad you mentioned that because if you look at the second point on this slide, there are conditions when you don't have to report this and that is if that breach is not likely to risk the rights and freedoms of the data subjects. So, if you have encrypted drives or if you have sent an encrypted email to the wrong location and it can't be retrieved by that recipient or the person that picks up that device, then you don't need to notify to the supervisory authority because the data has been protected. But, of course, you need to make sure that you keep the records because that is the case, just in case you get challenged to prove it.
Amar: Excellent. Later than seventy-two hours might… anything later than seventy-two hours must be accompanied by a letter why and very importantly processors shall report breaches to controllers without undue delay. Now, going on to the encryption date, Chris… before we do that, breach notification must include what?
Chris: Yes. So, when you are notifying the supervisory authority of a breach, there are certain conditions for that notification and if you remember back to our previous webinar video, it needs to be provided by either your DPO or your responsible person within your organisation. But you need to describe the breach; you need to note or kind of tell the supervisory authority how many data subjects are involved, so that’s individual people; the types of personal information involved, whether it’s date of birth, whether it’s political allegiance, health records; the number of personal records involved, that could be different to the number of data subjects; the name and contact details of your DPO or your responsible person so they can communicate back and possibly ask for more details; the likely consequences of the breach, not to you but to the data subjects… are they likely to, I don’t know, maybe get some phishing attacks? Are they likely to maybe get ransomware? You know, if somebody maybe going to give them cold calls, something like that. What are the consequences to the data subject of this breach? And also you need to describe the steps you’ve taken to control and rectify that breach. You need to tell the supervisory authority clearly why and how that's not going to take place again.
Amar: So, something very important, thank you, Chris, but something really very important in this particular topic is you must make sure you base all of this information on factual data, which means you have to take facts to ensure the data that you're referring to, you have to protect the integrity of that data, you don't lie about how something happened, you don't make things up and you have the full visibility in what is happening, and that you are able to describe to a great extent to the DPO, sorry, to the regulators, supervisory authority, how something happened. And it’s got to be factual. Do not make it up.
Chris: I think Incident Response plans are going to have to get a lot better after this. If there's anybody out there looking at internet response solutions and ability to consistently and quickly provide the information that you can see on the screen, that's a good place to look to because the supervisory authority is going to be expecting a very good quality breach notification. And not only that, they’re going store these so if you have another breach, they’re going to want to check to see if the nature of the breach is the same, and how your mitigating steps in the past have not fixed the problem in the future.
Amar: Do not lie, please. Base this on… base what you say on facts and it's really important that your Incident Response be consistent, repeatable, and able to describe what you've done. Notify the data subject. Obviously, this is another important point. Chris, what do you have to do if you are breached? You tell the regulators, but what about the poor data subjects?
Chris: Yes. So, there’s no notification period for notifying the data subjects but you are expected to do that in certain circumstances. So, if the breach is likely to risk the rights and freedoms of the data subjects or it is likely to cause them a level of distress - again, it’s a relative term so it's hard to describe what that means, I guess it’s down to the data subject ultimately - then you are expected to communicate with the data subject, not just the supervisory authority. And it hasn’t been included on the slide here but when you do notify the supervisory authority after seventy-two hours, they can actually issue you with the notification to speak to the data subjects. So, it's possible that you could be receiving instruction to do that as opposed to you just doing it automatically.
Amar: When is communication is not required?
Chris: So, absolutely. So, communication is not required again if the personal data in the breach is unintelligible… so, it's not able to be read. Encrypted is a kind of a by-word for what I’m trying to describe here and is pseudomisation. Also, if the controller has taken steps to ensure that high risk can no longer materialise. So, for example, let's say that they have lost a bunch of passwords and they have made all data subjects’ change them, and then it’s possible that you could prove that there’s no longer a risk and you don't need to notify data subjects anymore. And then finally, it would involve disproportionate measures. Now, that's a tough one to describe but if, for example, a data controller only has the email address of data subjects and they lose those email addresses, the data controller is not expected to phone all of the data subjects or send them a personal letter by mail. That would be disproportionate measure. They should just be expected to communicate by an email.
Amar: Excellent. Just for those listening in, and you know, we run a UK GCHQ Cerfified training called Cyber Incident Planning & Response, or CIPR, and we go into a lot of in-depth things on how you can make sure you do your breach notification, how you base your incident, how you orchestrate the incident, how you ensure that you know you do it consistently, etc. So, yes, do check it out but, Chris Payne, Managing Director of Cyber Advanced Solutions, thank you and look out for last episode which is working with third parties. That’s going to be really exciting. Chris, thank you.
Chris: Thank you.
