ashurst data seminar | london 28 Feb 2018 Data breach and loss: crisis management and incident response

Transcript 

Jon Gale (JG): Welcome to Ashurst and welcome … or welcome back to data week.  My name's Jon Gale.  I'm a partner in the Dispute Resolution department.  I specialise in litigation and managing business conduct and risk issues, including data breaches.  This is Gita Shivarattan, an associate and a specialist in data protection issues, including GDPR related issues.  This was due to be a joint presentation with Marc Kisner, a cyber-security consultant who has worked with Ashurst previously.  Unfortunately, and I apologise that Marc has been ill over the last couple of days, he's unable to make it.  Gita has very kindly, and very bravely, stepped in and she will take us through some of the specific GDPR issues relating to notifying data breaches.  It seems that data breach incidents are really out in the press these days.  I'm sure that many of the headlines that are on this slide, WannaCry, TalkTalk, the Central Bank of Bangladesh and the loss that it suffered from its accounts, are rarely out of the news, and I was just talking to a couple of people beforehand about an incident that they've had in the States, fortunately quite minor.  Now the ideal outcome, I'm sure, would be to stop data breach incidents and avoid headlines like this, but that, I think, is simply not the context that we're operating in.  The context is that data has never been more valuable, particularly due to innovative ways of getting the data and exploiting it.  There are a diverse range of threats, however.  With innovation comes risk.  There's a diverse range of threats, ever increasing range, ever evolving range of threats to the security of data and the integrity of data.  Now all of that means, I think, that there's no such thing as zero risk, and the focus needs to be on minimising those risks and preparing for the worst. 

So just to give you a bit of an overview of what we'll cover today.  We'll look at a survey that was done quite recently into the main causes of data breach and loss.  We'll look at the potential implications of a data breach or loss incident.  And the focus of this talk is gonna be on section 3, preparing for the worst.  What do you do when you wake up and you pick up a voicemail at 6.00 a.m. and it's notifying you of a potential data breach incident?  And, as I say, that brings into place some GDPR issues about data breach notification, which Gita will take us through.  And we'll leave you with ten questions to consider, which I hope will inform your ability to respond to a data breach incident.  Please do interrupt us at any time if you've got any questions, comments or experiences you want to share.  But first of all, we thought we'd begin with a couple of questions.  You should all have voting buttons.  You can take them up now.  Have you reviewed your response plan for dealing with a potential data breach or loss in the last 12 months?  One for yes, two for no, three if you're not sure, and four if you don't know if you've got a plan.  Right.  It's healthy, 60 per cent have reviewed it.  Unsurprising, given the issues around GDPR with some of the guidance about data breach notification, it becomes clearer, I think it would be very sensible to review plans.  A concerning 9 per cent saying don't know if they have a plan and that's certainly something that we'll be picking up as we go through the talk.  One of the key messages from regulators as they've been talking to firms and conducting some scenario planning, is a real feeling on their part that a lot of firms still don't have a plan or still don't have an adequate plan. 

A second question: Has your business conducted scenario planning to test your readiness and ability to deal with a data breach or a data loss?  One for yes, two for no, and three if you're not sure.  Okay, that's 57 per cent say no, I … really interesting, actually, and I hope one of the things that will come out of this talk is a realisation of the benefits of actually testing your planning practice and conducting some scenario planning to make sure that you're prepared for a serious data breach [or incident].  Let's move on though to look at a survey that was carried out quite recently by Blackberry into the main causes of data breach and data loss incidents.  I'm not gonna go through this one by one, but I just wanna pick out a couple of the key themes that seemed interesting to me.  And the first, I think, is that this isn't just about technology.  When we talk about data breaches, you perhaps instantly think about those headlines that we saw on the first slide, big cyber-attacks.  But actually people can often by the weakest link.  We see that the biggest cause of data breaches is accidentally sharing sensitive documents.  Likewise, using personal software devices, using personal email accounts, a big cause of the incidents, 16.5 per cent internal leaks and bad actors.  And we'll talk a little bit in a moment about the Morrisons case, which you may have heard of.  The second point, however, is 26 per cent hackers and attacks, 12.5 per cent ransomware.  And I know a point that Marc was gonna emphasise is that this is a problem which is really on the increase.  Last year, The National Cyber Security Centre had 1,100 … almost 1,100 cyber-attacks reported to it, and almost 600 of those were significant.  In real terms, the UK is dealing with a really significant amount of cyber-attacks every week.  This is a big problem.  It's increasing, it's not gonna go away.  

Gita Shivarattan (GS): And just while we're on statistics, an interesting statistic that I read in an IBM study was that the odds of being hit by lightning are 1 in 960,000, whereas the odds of experiencing a data breach as an individual is 1 in 4.  So just really emphasises the increase of those odds to individuals, to your customers and to your systems.

JG: Yep.  And the potential implications of a data breach can be really significant.  There's obviously damage to reputation, damage to consumer confidence.  We saw those headlines that were on the slide.  It can involve a loss of confidential information, your business' crown jewels are leaked or lost as a result of a data breach that can have a really serious impact on your competitive advantage.  It can lead to follow-on law suits.  And just to illustrate that, some of you may have heard about the Morrisons case that has attracted, certainly, a lot of headlines and a lot of concern, I think, amongst the legal community.  What happened there is that back in 2013 an employee within Morrisons was put through a disciplinary process.  Morrisons didn't realise quite how much it had angered this individual.  He worked in the payroll department and, in the process of the annual audit that was going on for Morrisons, he had access to the master payroll file for Morrisons and he leaked that.  He put it online on a file sharing site and sent it to several newspapers with the result that almost 100,000 employees of Morrisons found personal information out there in the public domain. 

Now the reaction of Morrisons to this was exemplary, absolutely textbook.  Invested a lot of money, a lot of resources in controlling this and making sure that, for example, the employees had fraud counselling.  They did a really good job and no individuals suffered loss.  However, a small minority of those individuals subsequently brought a claim against Morrisons, both under the Data Protection Act and common law duties of confidence.  And there was a hearing last year on the question of whether Morrisons were liable, and it was found that they weren't directly liable.  They'd done everything they could to stop the breach, there was no reason to suppose that they should … there's no reason why they should know that this employee was gonna leak the details.  They either had the appropriate checks in place or the checks wouldn't have made any difference to stop the data breach, but the court held they were nevertheless vicariously responsible because … for the actions of their employee.  So you're left in this slightly bizarre situation where the employee was trying to target Morrisons, his employer, but Morrisons have nevertheless been found responsible and liable for all of the … for him leaking this data.  Business interruption, distraction, a data breach can obviously lead to … well, depending on the significance of it, it can lead to distraction from your core business and making money.  And, again, talking to a couple of people before the talk, you know, they were saying they had quite a small data breach recently but nevertheless the scale and investment of time that it took up was quite significant. 

And finally, regulatory investigations, sanctions, fines.  To date the power of the Information Commissioner's Office had been quite limited.  Only have power to issue up to £500,000 in fines.  And most of the … the more significant fines have tended to be handed up by sector specific regulators.  The FCA fined Zurich Insurance £2,275 million when it lost the details of 46,000 policyholders.  So that is changing.  As I'm sure you're all aware, the GDPR is on the horizon and that will give regulators the ability to impose fines of up to €20 million or four per cent of annual worldwide turnover for the most serious breaches, and for lesser infringements up to €10 million or two per cent of annual worldwide turnover.  But data breaches will happen, and I talked earlier about that 6.00 a.m. voicemail.  What do you do to respond to it?  And here it is.  Imagine you get this voicemail, "Hi Jane, it's David here.  I think we have a problem.  I've just had a call from the IT team.  The monitoring system has flagged a brute force password attack.  The IT team are still trying to get to grips with the situation but it looks like the network has been compromised.  They think our data is at risk – it's not clear what yet, but it may include customer data.  It gets worse, we've no idea how but somehow the press have got the story and are asking for our comment.  Call me!".  So it's 6.00 a.m., you haven't even had your first cup of coffee.  What I wonder are the initial thoughts and key considerations that spring to your mind if you listen to this email. 

There needs to be a plan … a process in place and we need to start identifying who needs to be contacted so that you start activating that process to respond to it.  Any other thoughts before I move on?  Well, look, I mean I think these are the key considerations.  By no means the only ones but we'll just pick them out.  The first point to make is about time.  The first 72 hours are usually crucial and that goes for any sort of crisis management situation including data breaches.  It's not just because, you know, it's not just because that aligns with the GDPR notification requirement that Gita will talk about in a moment, but actually because the way you get to grips with a problem in the early stages is really important, and because early mistakes can prove costly.  There's a, you know, a lot of examples we could talk about on that, but perhaps the best example is how you interact with your regulator.  Whether you notify them but also how open you are with them, how you are seen to respond to this incident is likely to be quite an important factor that a regulator looks at when it's subsequently thinking about whether it will impose a fine.  And, if so, what that fine will be.  An incident response plan, absolutely.  Picking up the comment that was just made, essential to have a plan in place, and I think it's essential that it's tested with scenario based planning. 

As I say, the FCA has been conducting quite a lot of contingency planning at the moment with the firms that it regulates and it's been really critical, actually, both the absence of plans and the quality of plans that it's come across.  And again, the comment that was just made, you need to be thinking, actually, about who else needs to know about this.  It's quite likely that internally there are various functions that are likely to … need to be alerted about this.  IT this is obviously … they've involved already, but is it with the appropriate people in IT?  Legal, PR … it looks like the press have somehow got hold of this.  HR, Finance, the senior management, and all of this, I think, means that clear leadership and allocation of roles is important because the interest of those various stakeholders within the company might not be aligned. The interest of these people may not be aligned, but just to take an example, your PR people may be saying, "Well, you know, the press have got hold of this, we really need to manager how we message this to the press and, you know, we think you should really apologise for the fact that this has happened".  And, certainly, if I was in the legal team and advising you, I think I'd be saying, "Well, look, we need to be really careful, actually, before we start making statements to the press.  We hasn't told our regulators.  If we've got insurance in place, have we cleared any communications with the insurers to make sure that what we're saying could've been construed as an admission of liability that might even invalidate cover under the policy?  Does it constitute inside information, which means we ought to make an announcements for the market first?".  We'll come on to talk about those a bit further but there really needs to be someone sitting at the centre and pulling everything together. 

A really good point, a really important point.  And externally, you know, there may be a multi-disciplinary team that's needed that could involve lawyers, PR consultants, crisis management experts, forensic recovery experts, and I think it does feed into the plan because ideally you'd want contact details for who, for example, your lawyers are that … well, I'm sure it will be Ashurst, that you would call.  But what you don't want to do is find that this breach occurs at 6.00 a.m. on Saturday morning and you're hunting around the internet at the same time as senior management are screaming at you to give you guidance on what they can tell the press.  So all of that means for the communications plan, it ought to feature as part of your incident response plan and as part of that thinking about press, employees, customers, suppliers, regulators.  Have you got their contact details in case you need to contact them urgently?  The final point is records.  Really important to document the breach.  There are GDPR specific requirements about this that we'll talk about a little bit more in a moment.  But good practice, I think, whether it's a personal data breach or not, you ought to be documenting the breach, what's happened and how you've responded to it.  And another point about records is thinking from an early stage, obviously with help from Legal about your privilege strategy. 

Now this is likely to be something that evolves, but you need to be thinking about whether you want to make sure that legal advice you are receiving is protected by privilege because that is gonna dictate who receives that advice, who is channelled through, and the labels you put on it.  So if you want to make sure that certain advice is privileged, it ought to be clearly marked as privileged, and marked to make sure that it's not for onward dissemination.  A situation like this is obviously gonna be quite a fast moving situation and a lot of these points are quite likely to change, they need to be reviewed.  But we … those, I think, are the key considerations to have in mind.  Moving on then to how you deal with a data breach.  We think there are four key phases and we'll talk through each of these in a bit more detail.  But briefly outlining them, first of all, when you discover the breach, your focus is on containing it and recovering it.  Secondly, once you've done that as far as possible, identifying and assessing the risks that arise from the data breach.  Thirdly, thinking about who you notify and communicate who needs to be told about the breach, what do they need to know and when do you tell them.  And finally, the investigations evaluating your response and the implications of the breach is, you know, of course it's not gonna be discreetly divided, and now we move onto phase 2. 

Some of this stuff is going to merge, but it's quite helpful, I think, to think about your response in these discreet stages.  So we'll take a little bit … a look at these in a little bit more detail.  Phase 1, as I say, is discovering the breach, containing it, and as far and possible recovering the data.  Here the focus is on understanding what has happened and what can be done to recover the data and to limit the damage.  In our scenario, this voicemail, it looks like it's … the focus of that is gonna rest with IT.  They need to investigate … you know, the voicemail said they're still trying to get a handle on what's going on.  Is there any steps they can take to try and recover the breach?  But as the point was made there, it leaves me thinking quite early on who else needs to know about this, getting Legal involved, informing senior management of the incident.  But what is clear is that the time phase for this … the time period involved in this phase could be quite limited.  One of the biggest attacks last year, the NotPetya, there was a report that put the time for the total failure of all of the systems for one of the largest victims of that attack at 19 minutes.  They had 10,000 connected systems, all of which failed within 19 minutes.  And the FCA posed the question on the back of that: If you had 19 minutes, where would you start?  And I think that does take you back to the scenario-based planning.  You're gonna be much more comfortable dealing with this if you've tested your responses and you know who's gonna take responsibility.  Of course, as I say, this isn't all about technology.  This could be a situation where an email has been accidentally sent to someone.  We saw that was the biggest cause of data breaches, in which case discovery and containment might simply be notifying the recipient and making sure in the usual way – we've all been there, haven't we – making sure that they deleted it and that they haven't read it.  Phase 2 is identifying and assessing the risks.  And this is really about figuring out, right, okay, we know there's been a breach, but what actually has happened to the data?  And it's driving your ability to try and answer three questions. 

What are the risks that arise?  What's the likelihood of those risks occurring?  And what is the severity of those risks if they do occur?  And it's important because it will inform your next steps, particularly regarding who you notify and communicate at phase 3.  It's driven, I think, by a GDPR analysis, which Gita will come on to, about the likelihood of risk, the severity of risk, and it's quite a helpful way, I think, of analysing the risks in any data breach situation.  So a few questions, by no means exhaustive, that you might consider when you're identifying and assessing the risks.  First of all, what has happened to the data?  Is it in the hands of some malicious third party?  Or is it the case simply that the data has been lost but there's no reason to suppose that it's actually in the hands of some third party?  What is the nature of the breach and what's the nature of the data?  Is it sensitive?  Is it commercially confidential?  How important is the data in question?  And that involves, I think, thinking quite carefully about what the data is and how it could be used.  So just to give you a practical example of that, suppose Jane calls you back and says that we think the data that was lost was the schedules we've got for making deliveries to customers.  And you might think, well, that's pretty serious.  It's likely to have customer details on it. 

We're clearly gonna need to do something about this, but it might not be the end of the world, it's just a customer delivery schedule.  But if that customer delivery schedule shows, for example, when the customers have cancelled their orders, so it's got their names on it, it's got their addresses and it's clearly identifying when they're not going to be at home, then that data breach takes on an even more serious nature.  Likewise, you could have a breach, say for example, of credit card details.  Very serious, clearly a risk of fraudulent transactions, but if you couple that with thinking about how it could be used with other data out there, does it give rise to the risk of identity theft?  How easy will it be to identify specific individuals, data subjects?  That's likely to raise issues around the level of encryption you've got on the data, but I don't … you know, a lot of the guidance which is coming out from regulators emphasises the fact that you can't simply say, "Well, the data was encrypted, we're fine, don't worry about it".  You've got to think a little bit more broadly about that, you know, how comfortable are we in the robustness of the encryption?  Is it state of the art encryption?  And, as we say, at the bottom of that slide, all of this needs to be kept under ongoing review.  What is state of the art encryption now may not be in the future, and that may change the risk analysis.  What potential damage could result? 

We've touched on that a little bit already.  Are there any special characteristics of individuals affected that need to be taken into account?  Particularly, are there children?  Vulnerable individuals?  What is the volume of the data?  Again, picking up a point that was made earlier, how big is the data that's out there which is gonna drive an analysis and the significance?  And how many people are affected?  Hopefully that is gonna give you an idea of the significance of the risks, the likelihood of them occurring and what, in fact, those risks are.  And, as I say, that drives your approach to the next phase, who you tell about the breach, when you tell them, and who, when and why.  A notification needs to have a purpose.  Working down that list briefly, regulators.  The GDPR introduces a requirement to notify personal data breaches, which Gita will talk us through in a bit more detail.  At the moment, the fines for failing to notify personal data breach, up to two per cent of annual worldwide turnover or €10 million, whichever is the higher.  So clearly very significant, very important.  But also important to recognise that there may be a requirement to notify other regulators, sector specific regulators. 

There's a, sort of, in the box there, identifies some of the requirements, and I won't go through all of those, except to say the top one, FCA are really hot on this.  We've seen them take action previously about data breaches,  Zurich Insurance. I know for a fact on some of the stuff I'm involved in that they're really ramping up their resources to deal with data breach incidents, particularly around cyber security.  It's something they're really, really hot on, and they've recently issued a joint statement with the Information Commissioner's Office explaining how they will work together once GDPR comes into force.  So some of the legislation there that creates notification requirements.  I think, probably, if that applies to you, you're likely to already know about it, but there are other sector specific requirements that may apply.  But just to give you an example, if, God forbid, Ashurst were subject to an attack, and it does happen to law firms as we saw earlier this year, we'd be notifying our regulator, the Solicitors Regulatory Authority about it.  Affected persons, again, Gita will pick that up in a moment.  Thinking about whether there are any contractual requirements that mean you'd need to notify, and again, I think this comes back to the planning stage. 

If there are any requirements in your contracts, ideally you want a separate checklist of those that you could go through in the event of a data breach.  Insurance, Chris has talked about this.  You need to obviously know whether you've got insurance in place and be telling insurers, really strict time limits in policies about notifying them.  And clear in communications with them to make sure you're not invalidating cover by admitting liability.  Thinking about whether the data breach constitutes inside information and, therefore, whether you've got to make an announcement to the market or whether other corporate governance obligations are triggered.  And that interacts, I think, with who you're telling more broadly.  You certainly don't want to be telling, for example, your suppliers or your customers before you've made an announcement to the market if it is inside information.  But otherwise, you may need to contact them, you may need to contact employees.  You obviously need a strategy for dealing with the press and your … internally or externally, your PR people are likely to help with that.  But I'm gonna come back to regulators, the GDPR requirements.  I'll hand over to Gita to talk us through that in a bit more detail.

GS: Okay.  So, not a GDPR lesson, but just to put into context some of the terminology around GDPR and when your obligations will be triggered.  So the language that you'll see in the regulations are data subject, and so that's the individuals whose personal data you may be processing or have access to.  And those are natural persons, not institutional entities.  Personal data is really broad.  It's really any information that can be used to identify an individual.  Processing, again, very broad.  Any operation carried out on personal data, including the storage.  So they're thinking about suppliers potentially in cloud service providers who may store your data.  And then controller and processor, this is key in assessing what obligations you have to notify.  You may have an obligation as a processor to notify the controller, or you may as the controller have a direct obligation to notify the regulator.  In some instances you be considered as both a controller and a processor.  For example, in relation to your employees, you're probably going to be a controller, so you will have to consider whether you want to notify both the regulator and data subjects.  If you are both the controller and a processor, you may want to notify just the other controller whose data you have, as well as you may have direct obligations under other requirements, other industry requirements, to notify.  So going on to the actual processor.  What we've done is a little bit of a flowchart here going through where there may be a breach and the steps that you need to take. 

The first question is: Is it a personal data breach?  Under the GDPR, the definition of a data breach is very broad, and so it's accidental or unlawful destruction, loss or alteration.  And so there, I think, we tend to focus on loss or access as opposed to destruction, and so it may be that destruction doesn't necessarily have the same impact on individuals but it's still considered a data breach under the GDPR.  And here, I think, it goes back to what Jon was saying around doing that scenario testing, and so you should actually have an awareness before a data breach occurs of what the risk areas in your organisation may be.  Under the GDPR, there are these obligations to carry out privacy impact assessments where you're rolling out new technologies, and so part of that is assessing if those processing activities do present a risk to the individuals whose data you're processing, and so that should help inform the security measures that you implement against the data as well as documenting how you may mitigate those potential risks.  What's interesting here, actually, is that I think we may see a development into our relationship with suppliers or entities that are carrying out high sensitive processing for you, or just large processing of personal data on the basis that you want them to be on the same page with what you assess to be a personal data breach.  And so I think that will be a more open conversation as opposed to just sticking in contractual clauses to say, you know, you'll notify us when there's a personal data breach, and taking the definition that we have in the regulation, but actually being a bit more granular about what you see that breach to be and how you would want them to notify you in terms of time frames. 

Similarly, I think, traditionally to business continuity plans, I think we may start to see breach reporting plans and processes being put into large scale outsourcings where there's a high risk to personal data.  And I just … I think it's about managing your risk from the start as opposed to being on the back foot.  So here where we're talking about is it a personal data breach, hopefully that's something that you've assessed and you're able … so when you do get that 6.00 a.m. phone call, you know what is the supplier, what is the processing, what is the system, and you'll have an idea of the data that's in that system and the security that you've implemented in that system to be able to start doing that quick assessment of whether you need to notify.  So, going through the flowchart, we're going to go with "yes" here.  So we're gonna go to question 2.  And then question 2 is: Are you a controller or a processor in this situation?  So, as I said, if you're a processor, you do not under the GDPR have a direct obligation to notify the regulator, but you do need to notify your controllers.  In terms of time frames here, in the regulation it says, "without undue delay".  Helpfully, the European Commission article 29, "Working party has said immediately", and so I think, again, from a contractual perspective, it's about, you know, ensuring that the time frames accord with what you would require as a controller, your processors to notify you. 

I think in terms of processors, you need to also consider that they may have multiple other customers, and so you would want to ensure that their notification to you also accords with what they're notifying to other controllers to allow you to manage your notification to a regulator, because what you don't want to do is to be the last controller to notify a regulator where one processor has caused multiple potential personal data breaches.  And part of the notification obligations, which we'll come on to, and the information that needs to be notified, which we'll come on to shortly, is that the GDPR has a list of information to be required to the regulator, and one of those is if it's a processor of potentially multiple customers.  So there, you may be pre-empting someone else's notification before they've had time to assess what their potential risk is.  Processors may have other direct notification obligations.  So trust service providers, like cloud service providers, currently have a direct obligation under the NIS directive, for example.  So it's about balancing and managing those regulatory notifications.  And, as Jon raised, you may have other notification requirements. 

So where are you assessing if you're a processor and controller?  That's not the only assessment but it's to ensure that those notifications line up with your other requirements.  So when we're deciding, as a controller, if you need to notify the supervisory authority, the test is whether it's unlikely to result in the risk and freedoms of the individual.  If the answer to that is no, you … so I'll just read it again, sorry.  If you conclude that it's unlikely to result in the risk and rights or freedoms, if the answer to that is no, then you would need to notify the supervisory authority, and if the answer is yes, then you wouldn't.  So here, it's quite interesting because in the guidance, the article 29 working party gave ten examples, only two of which meant that you wouldn't need to notify them.  One was a temporary breach for several minutes of access to a call centre, and then the other one was an encrypted CD where there was no breach to the key and no unauthorised access would be permitted to that encrypted CD.  So really quite a low bar there, and I think the regulator wants to be notified.  And the indication from them is that you would need to notify if it was anything that would be more substantial.  Yeah?

JG: Just to pick up again on the distinction between controllers and processors that we were talking about previously.  And to emphasise the point, it's for the controller to conduct this assessment.  If you're a processor, your absolute obligation is to notify the controller, it's not for you to … it's not for the processor to conduct the assessment of likelihood and risk.

GS: Yeah.  And I think there, again, in the added complexity of this assessment, is whether under industry requirements, you are required to notify other regulators.  And so the FCA and the ICO had a joint statement which they released a couple of weeks ago saying that they would be working together and they would expect to be notified in tandem of such breaches.  So it's just being aware of those other requirements as well.  So this is what Jon spoke to you before, so I'm not going to talk in much detail about this but, again, it just goes to the assessment that you need to carry out before you notify however the supervisory authorities are aware that these are evolving situations and so there may be a phased … kind of feeling of the notifications and the information as it comes to light.  I think we'll go onto the next slide actually because the "when" is quite important and so, if we look at the "when" it's within 72 hours of becoming aware and so it's "what is that trigger of becoming aware", and under the guidance it's a reasonable degree of certainty that the incident has led to personal data being compromised.  And so, in those instances, the 72 hours would start ticking, clearly where you have done those initial assessments and as an organisation how certain scenarios that you've identified as presenting a risk you would be quicker off the mark to put together those notifications to the regulator. 

I think the key here is that … and as Jon stressed, it's the prompt action to investigate and having in place the appropriate plans to take notification forward.  And then the second part of the test is "Do you need to notify the affected persons?" and so again this is for the controller to assess if there's likely to be a high risk to the rights and freedoms of the individuals.  If the answer there is "no" it's important that it's kept under review.  It's not "no" and then we stop, it's "no" and then we assess the situation as we see it evolve.  And the nature of the data in this instance is likely to really drive and be one of the driving factors as to whether you notify individuals.  The more sensitive the data the more likely you are to want to notify them.  So, for example, health information, financial information and those types of things, and whether it's easy to identify the individual funding information that has been breached.  In addition to the severity of the consequence, so I think in Jon's example of the delivery schedules to the extent that it shows where someone may not be at home or may be on holiday because they've stopped the delivery, and if that information is in the hands of criminal it may present more risk.  And so it's really being able to assess the situation in a whole and I don't think it's black and white.  But again, the privacy impact assessments should really help you to pre-empt and identify where you see your risks would sit.  And so if you do think that it would result in a high risk for the rights and freedoms of individuals there's then a further assessment again, so looking at the safeguards that you've implemented around those … that data sets, however, it's appropriately encrypted or whether it can actually be accessed.   The steps that you've taken in the period just after being … becoming aware of the breach and whether you've mitigated any potential impact to the individuals.  And finally, this is around … not whether you need to notify but the method that you notify by, so you should notify each individual directly and also with sufficient information to allow them to know what steps they would need to take and how you are going to facilitate them as a controller unless of course it would be disproportionate in which case you would make a general public notification and so I think we'd seen these, you know, as banners on a website or notifications by email which are general to individuals. 

Okay, and then so, this is just kind of a recap around the notifications to individuals so in terms of the timing it's about "without undue delay", it may be that you, as an organisation, determine that there is no potential risk to the rights and freedoms of an individuals but your supervisory authority may require you to notify the individuals and so you need to work closely with the supervisory authority as they would have been notified of the breach.  And they may want you to notify and they may give guidance in terms of the information that you are required to provide there.  In terms of the information that you need to put in the notice, it needs to be clear, it needs to have actions, it needs to tell them what you are doing as an organisation and how you're able to help them provide contact details for someone at your organisation for them to be able to talk to in the event that they have any questions or need support.  And then, just a bit of information again about what the breach is and finally the cooperation piece that I spoke about with the supervisory authority.  So the next one is just in relation to record keeping under the GDPR.  This goes to accountability and transparency actually and show you have a further obligation to keep records of breaches.  This is not only breaches that you notify this is all breaches that occur and it has your decision making process in terms of why you've decided to or not to notify, what steps you've taken to mitigate.  Also remedial steps you've taken to prevent future breaches of the same kind and any potential consequences that may have occurred and the impact of that on your business.

JG: I think the way to think about this is, as well as a regulatory requirement it's defensive isn't it.  It's a tool that you can use when the regulator says to you "Well, why didn't you tell us then?", the answer is well … then, you know, this is what we need, we were still figuring this out.  We were conducting an investigation, and it can help you more broadly, it can help when you're having conversations with insurers.  I've been involved in some conversations with insurers quite recently in connection with a data incident where they really drilled down into notification questions and we were going back to the records that were kept for other purposes, to explain what we knew, when and the question of when the insurance notification was true.  That incident depend very much on the facts so depending on whether litigation is reasonably in contemplation there may be scope for making some communications subject to privilege and I think as a working rule where you are keeping your GDPR record keeping requirements it's your … you're gonna struggle to get into litigation privilege.  I'm sorry let me step back.  When we talk about privilege, broadly speaking there's two types of privilege: legal advice privilege, where you're receiving advice from lawyers or find how to manage the situation.  Now, in that situation you may well be getting advice from your lawyers about what you're obligations are, how do you manage that?  Now, that is going to inform your GDPR record keeping requirements and this comes back to the point I was making and the key considerations about determining what your privilege strategy is.  And you're getting this legal advice but do you want to keep it protected, do you want to keep it privileged, in which case you need to clearly mark it as privileged and there may be elements you take from that advice and record in your GDPR record keeping requirements saying lawyers advise this, X-Y-Z. 

The second category of privilege is litigation privilege which applies when litigation is reasonably in contemplation and the dominant purpose of the communication is contemplation of litigation.  I think that's gonna be very difficult for a number of reasons, because of some recent case law the circumstances in which you can say litigation is reasonably in contemplation of being restricted and in any event the dominant purpose of communication isn't gonna be GDPR record keeping requirements.  So the short answer is,  I think it is gonna depend very much on the factual situation and it comes back to this point about having the privilege strategy in place and getting advice from your lawyers about how you manage your communications to protect privilege if you can and making sure that's communicated to everyone who needed to know.  So, for example, if people receive communication that says privilege and confidential they're not sending it out, disseminating it outside of the organisation and waiving privilege.  Moving on then, phase 4, to the investigations and implications, this is going to be very dependent on the facts and what has happened, so I'm not gonna say too much about it except that in every serious data breach some kind of internal investigation is likely to be necessary.  Regulators are likely to inspect it and it's good practice, particularly for the lessons learned, the effectiveness of the response.  The lessons learnt is "Well is there anything we need to change?  Do we need to make changes to security, policies, training?", and adding on again on what has happened, that could be disciplinary action that needs to be taken against employees, that could be mitigation that flows, as per the Morrisons example, you may need to think about your PR strategy. 

We can provide more training on conducting investigations in the data breach context, let us know if you want that.  And likewise on potential litigation and data breaches.  I'll leave you with 10 question to consider, I am not gonna go through these one by one, I'll pick out just a couple that may not be that self-explanatory but I hope in light of what we've said these will act as a different checklist, you need to take that and think about how prepared you are to deal with a data breach.  To highlight a few … the incident response plan.  We saw that … I think some members of the audit, I think nine per cent didn't have an incident response plan.  When you get that 6.00 am voicemail, I hope of them because frankly you need a plan to go to.  Have you conducted contingency scenario planning?  If you've done that you're gonna be much better prepared to deal with these kind of incidents.  Are you addressing the basis?  This came out of the FCA contingency planning exercise they've been conducting where they said "Well, some firms actually have quite good monitoring systems in place for some of the really sophisticated viruses but the basics, things like changing passwords, patching on a regular basis, just wasn't being done.  What is the tone from the top, anyone who deals with the FCA over the last few years will know this is an obsession from their outliers, the culture of the organisation. 

I've seen the management have the board being briefed on this kind of stuff and is there a document trail of the importance of data issues, GDPR issues being cascaded through the organisation.  We saw from the survey the risks posed by employees of working practices which raises issues around training we've got in place and making sure that employees know what their responsibilities are.  Do you know what sector specific regulatory requirements might apply?  Very happy to talk to anyone in more detail afterwards about that, there's some guidance on the slides.  Are your contracts aligned with data breach risks and responsibilities?  There's a few things that you can think about there, for example, does your definition of force majeure cover data breach issues?  Would it cover cyber security issues?  If you've got indemnities, limitations on liabilities would they respond to potential damage and harm that might be suffered from a data breach issue.  If you need it have you got step-in rights to make sure that you can take over in the event of a major data breach situation.  Have you got the rights to do all this to make sure that your outsources, your processes are adhering properly to their requirements.

JG: So, taking this step by step and it's quite helpful to work through the flowcharts we had and I should have said you'll get these slides afterwards, so you will have that flowchart.  Just picking it up first of all, thinking, you know, do you have a contractual obligation to notify?  Well that will depend on the working with your contracts and it may be very sensible to define your contracts to exclude certain  obligations if you're comfortable doing that.  And if it aligns with the regulatory position.  In terms of the regulatory position, the GDPR, well I think one needs to work through the flowchart and the first question is … well, yeah sure, you've accidentally sent an email.  We've all been there, I did it for the first time last year. It doesn't automatically follow but just because you've accidentally sent the email is a personal data breach.  You need to go back to that definition of personal data breach which Gita looked at and I think that tells you whether you got it. 

In terms of the GDPR position, if you are a processor you do have an absolute obligation to inform the controller without undue delay and as I was saying that is not qualified by any assessment of the significance of the risk.  It's gonna be interesting to see how it works out in practice but … there's a lot of force in what you're saying.  It is helpful to keep the contractual position and the regulatory position separate.  As we've said the processor does have this obligation to tell the controller.  There is then an assessment to be conducted whether it is unlikely to result in a risk of the rights and freedoms of the individuals.  Now, let's just put ourselves in the situation you're positing.  You have sent this email, it's gone to someone, you managed to get in contact with them, they've said I've deleted it, I didn't read it, you trust them, there's no reason to suppose … there is then, I think, a legitimate question to be asked about whether this threshold might … is met.  And I think it is gonna come down to what the factual position is but I think if you do … as Gita said it is a low test and if you're telling the regulator is the Information Commissioner's Office really in that situation, can it be stomping all over you.  I think it's probably pretty unlikely.  I appreciate that's not the point you're making, your point is … and it's a very valid one, if there's a real administrative burden that's imposed because of this.  But I think it is unlikely in that situation where you conclude that you got the situation under control, you nevertheless need to tell the Information Commissioner's Office, but there are serious consequences that float.  My prediction of how things are likely to play out and actually I think a lot of organisations are gonna be in a position where they are gonna want to be able to demonstrate that they have made some of those [corrections] just to show that they're aware of their responsibilities.  And in terms of the contractual position that your positing and it's an important point.  It's a good point, you know, is this gonna cascade down and lead to a whole load of boarding rights.  It is gonna be difficult to define around that but I don't think it's impossible. 

GS: And it's interesting because I think there are a couple of actual practical measures that I've seen organisations taking in that regard, and so one is where they're sending personal data in an email file just to ensure that it's sufficiently encrypted, it's in a key or whatever and so the additional factors as a controller you may require your processor to take one sending data of that kind.  So, it's … if the content of that email also includes personal data there are additional safeguards which you may require to ensure that the data is protected.  In addition, you know, I've seen organisations turn off the auto complete on emails and so, there's that additional protection where you're entering in an actual email address that you have to actually type in.  I mean it's extremely onerous because everyone … so you should just type in the first couple of letters and scrolling down but there are those additional measures that you can take if you are aware that your processor will be funding, particularly sensitive, confidential even or personal data by way of email to implement those protections.  Yeah, I think we're at time, we're getting the flag … the red flag's up so … thank you for coming.

JG: Thank you all very much as I said these slides will be circulated afterwards.

With special thanks to Gita Shivarattan for her contribution to our Global Data Week.