ashurst data seminar | London 26 Feb 2018 GDPR: hotfixes and life after implementation

Transcript 

Andreas Mauroschat (AM): Good morning, everybody.  Hello, it's good to see you all.  Thank you for coming through the disastrous outside weather.  So for us, from the continent, it's a surprise to see snow in London.  But, nevertheless, you all made it here so we're happy about that.  So Gita and I will give you a talk about, say, last minute actions to take on GDPR.  Gita and I and perhaps of our Ashurst organisation worldwide are advising many clients on … from all over the world on GDPR project, so we see many different approaches, we see many different issues arising and … so the … I think the purpose of this talk is to tell you a little bit about the key work streams that will come up and about what we would do if you were to start now, just three months before application with your GDPR project which, to me, is a bit surprising, but we do get quite a few projects that are starting now, clients just calling us last minute saying, "Well, our IT folk read something about a new regulation in the EU, can you please help us?".  So it happens.  So we have something like a last minute emergency plan and this is a little bit what Gita and I will be talking about.  So my name is Andreas Mauroschat.  I'm a partner in Frankfurt doing data protection and IT work from there on the continent.  And Gita? 

Gita Shivarattan (GS): I am an associate here in London and I work in the digital economy team focusing mostly on data protection but also in the IT space.  So just going to the … at the agenda, what we're gonna talk to you today about is, we're gonna start a bit with what the regulators are saying where are they're at with that.  We're gonna look at what compliance means, mostly from off of what the regulators have been focusing on recently.  We're gonna talk to you about what to focus on and those are … Andreas has termed them hot fixes, and then we're going to give you a bit of a conclusion and looking forward.  And then hopefully you'll have some questions or maybe just experiences that you want to share, and we can talk through them.

So what is the EU Commission stating?  Well, with less than 90 days to go, where are we?  On 24 January, the Commission released a statement and, surprisingly, only two out of 28 countries have adopted national relevant legislation.  So if you're feeling like you've still got a lot to do, so do the other member states, and the Commission is telling member states that they need to really speed up with national legislation and assisting organisations with compliance.  It's fascinating because I think part of the aim and drive of the regulation is to build harmonisation, but there are over 50 articles in the legislation which allow for a national derogation, for example, determining how old a child is.   

The EU Commission has acknowledged that member states need support, they've dedicated €1.7 million to support national data protection regulators, as well as €2 million to help train data protection professionals.  It's not clear what that training is going to look like as yet, however, they have launched an online tool as well as realised certain fact sheets on certain subject matters.  In the 24 January statement they also reiterated the importance of data subject rights and the need to provide fair information.  So this is very much a point to organisations needing to update notices and make sure that they're clear to individuals.  And highlighted the new rights to data subjects, being data portability, but really saying that this should also be seen as an opportunity for businesses presumably for focusing there on SMEs and the entrance to markets.  And then the Commission also took the opportunity to remind organisations of the 72-hour breach notification requirements, and with their sanctions that's saying that this is very much a regulation that has teeth and deterrent fines. 

So it doesn't really say anything new, but there is a focus on the commission, not surprisingly, that organisations and member states do need to quicken their pace with compliance and although 25 May is not a drop dead date, sanctions will be applicable from that date, and so there are certain areas that you would need to focus on.

AM: Yeah.  Exactly, and I think, as Gita said, so there's more than 50 articles, there's more than 80 opt-out options actually for member states.  So looking at the German law, say it's reasonably … it's not a different world.  GDPR's main principles are not changed.  There's quite a … there's some things that we've always done differently than the rest of Europe, for example, the data protection officers which we still have to appoint with nine employees being active in data processing.  So that always, you know, we've answered the question.  Some member states will have a binding obligation to appointed a DPO, the others will, for example, just have the requirement to have one group DPO.  So what do you do?  Do you double the DPOs or do you just appoint one because you have … you can use one for the whole organisation?  So the answer to the data protection organisation that's correct for your group will depend a little bit on what the local laws will say.  There's quite a few … Slovakia, for example, we know that have similar rules that the existing data protection officers will remain in office.  So generally the opt-outs that Gita mentioned, some of them are quite relevant. 

You can opt-out of legitimate interest tests and others.  So it's likely that we will see that your GDPR project within the group will have to focus a little bit on the national acts, but it will be not a new world, it's more of a modification of your existing systems.  But it's surprising, as Gita said, that, I mean, the Act, that GDPR was much thought about.  It's a lot of politics that went into it, so many member states reserved their right to, sort of … maybe not so painful for their core businesses, but nevertheless it's surprising to see there will be going on still lots of national items that you need to think about when implementing the GDPR.

GS: And so just specifically looking at the UK, the Information Commissioner spoke to the DMA, the Direct Marketing Agency, on Friday and reiterated the aim to make the UK the safest place to be online.  So I think there's very much their focus is, as I'm sure you're all aware, of online services and users of online services.  Interestingly, she mentioned that she sensed a much more subtle mood and people embracing the GDPR.  I, kind of, thought maybe it was resignation but, you know [laughs].  In any event, the ICO, like other national authorities, has been issuing guidance thick and fast, and so has been committed to providing resources dedicated to businesses including FAQs and a help hotline. 

As you may know, they've also opened up a secondment opportunity for businesses.  I think very much they're looking for partnership with organisations who wanna offer people to up skill, but then also to provide and [assure] themselves with resources to help with implementation and the volume of work that they have yet to get through.  Finally, she mentioned that they would be releasing a roadmap for the data protection bill, but no exact timelines around that.  And she reserved … and kept her position, which she's been consistent with, saying that fines and sanctions will be for those who wilfully and persistently breach the law.  It's interesting, also a recent report from the ICO was issued to say that there has been an increase of 19 per cent in breach reporting in the period of October to December, so there, I think, probably giving the ICO an indication of the amount of breach reports that they'll have to deal with and hopefully they're being appreciative of companies being transparent.  I will talk a bit more of their breach reporting in the next hour.  

Okay, so what does compliant mean?  I think here, and as everyone knows, we're talking about awareness and the first steps to understanding your organisation's data state.  I mean, I'm sure all of you are sick of hearing about a data audit and a data mapping, but it's absolutely unavoidable and key, and so you have to establish and should have established by now, what personal data your organisation collects, how it's processed, what it's used for and then clearly notifying that to the individuals and ensuring that your notifications are accurate.  And then, the follow-on from that in terms of importance, is having appropriate breach notification, procedures in your organisation that people are aware of, and we'll talk about that in detail.  And also advising data subjects of their rights and having appropriate mechanisms and technology in place to be able to facilitate those rights.  Okay.  This is just a bit of … an agenda of what we're gonna talk about to focus on.  And so we've got records light, data subject rights, what notices and policies you need to have in place, a little bit about marketing, preferences and refreshers and then about the data breach response procedures.

GS: We have a draft bill.  The ICO has been clear to say that we will have the GDPR implemented as of 25 May, and so we have a bill that's ... we're looking at putting in force, but it will probably be after that 2020 transition date for Brexit.  

AM: Yeah.  Before I start with this one, a few words.  First of all, the ICO, from the continent's eyes and from the view of the continent, it's an excellent regulatory authority, just definitely the best.  Whenever we think with clients about who's gonna be the lead authority, we try to find … I mean, given Brexit, it's a bit more short-sighted, but we try to find any opportunity to move the centre of data processing, which is the decisive question for what's gonna be the lead authority, to Ireland or the UK.  I think the continental authorities, many of them have an issue with being just completely understaffed.  If you look at basically all of the east of Europe, they're understaffed or they have a different approach of dealing with their partners, so … in particular, the word "partners" is something that, say, German or French authorities have not yet really embraced the way of, you know, whether by consultation and other means, trying to get the opinion of the companies, is something that we are … it's difficult to do that on the continent.  So it's good to see the way the ICO gives practical guidance, so you're much better off than the rest of Europe in that respect.  I'm talking about a couple of hot fixes where we in our projects see that work streams are, sort of, take longer than you think and at some point in time you … you have to do some emergency approach, quicken things up.  So the records … and I'm focusing now on the records of processing activities here. 

I'm sure all of you who are involved or connected to a GDPR project know that this is … that that can be quite a painful exercise because it's a lot of information; you need to collect about, basically, all of your applications or other activities like monitoring, cameras, outsourcing.  The problem is that the theory of the GDPR that you have to register your processing activities is fairly easy.  If you think about processing activities, you will … so I've been to a lot of workshops where people and clients told us, "How many processing activities do we have in the company?", and that ranges from 30 to 3,000 which gives you an idea of how people interpret this.  So what's the processing activity in the HR world?  It would be recruiting, on-boarding, payroll.  Others say it's HR administration and others go down even into further level of detail.  So the question is what level of granularity?  And it turns out that you should try to follow the main business flows in your organisation, focus on those many of them and then break it down to a group of anywhere in the range of 80 to 100 processing activities, typically as something that makes sense.  Then what people struggle with is IT systems or solutions and applications, because obviously the organisation and the IT teams think in applications while the data protection folks think in processing activities.  And how do you get that aligned? 

Typically, a processing activity is generic, it's payroll.  Your payroll systems in the group, there may be 10 systems you are running to do payroll, so that is … those fall into the processing activity payroll.  So you have to, sort of, do a connect.  And why are the systems are important if GDPR only requires you to look at processing activities?  The systems are important because if you want to do a DPIN, actually check what risks do I have here.  Am I encrypting data?  Where are we … am I using third party providers?  All that, you can only assess when you look at the systems, at the applications, so you have to record both.  But if we talk about a hot fix and how to do things … how to get across the finish line by May, you definitely … the first thing you need to do is set up a reasonable and smart catalogue of processing activities and make sure you've got that filled with content.  You need the input, obviously, from the business owners of each processing activity, which is why you need to following your business lines.  So you need an owner from HR, you need an owner from Accounting, you need an owner from Controlling, one from Production, Manufacturing, although logistics, there's not a lot of personal data there, but, nevertheless, you follow your business and try to capture it all.  And then you get the input on the processing activities and with a, say, reasonable effort you're there, that you get at least a GDPR compliant record.  The problem, of course, is then looking at the systems. 

Many of our clients and projects … so the typical is 1,600 systems but it goes up to 6,000 systems which do process personal data.  Sometimes that's just operating a manufacturing line and people have to register with their ID numbers, so all of that is not critical but, nevertheless, it's there, so you want it in the activities.  And then, of course, where it becomes really critical is somebody maintains an Excel file and pulls together information from two different systems, so delivery status, customer contact person, and then maintains an Excel file which is not an application but which is, sort of, a secondary database which feeds from other originally, primary databases and is used for its own purpose.  It's a processing activity or its at least a system that needs to be recorded, so that's where it gets difficult.  And you're not gonna be there by May 25 to have this all complete.  This is a moving target.  Nobody will be there.  I've talked to the data protection officer of Deutsche Telekom, and they've done … they are super professional with this but they are the ones where he mentioned they have 3,000 processing activities.  So the way they are doing it, it is almost scientific and beautiful, but even they are not gonna be there by May 25.  And just, you know, the ones of us who have limited resources to deal with this, definitely we're not gonna be there.  So you take a risk-based approach, you look at your systems from the HR [word], from the customer [word], you want definitely all of your HR admin, payroll, recruiting systems … we definitely want all of our CRM systems reflected in there and then we trickle down as soon as … or as quick as we can.  But let's try to cross the finish line first.  Do you want to mention a couple of … I mean, there's some other records … processing agreements, it makes sense.  This is … this falls under the heading of vendor management.  It makes sense because you have to roll out agreements with your service providers who process personal data for you, and the painful part of that is to find all these agreements because there is another central register. 

Sometimes procurement is very engaged, so they have some sort of register, but in most … I haven't … I don't have any organisation which is in a position to push the button and get a list of all of their service providers.  That will have to change because you need to make sure first that now all the agreements are rolled out, second, that you audit them regularly, and third, that whoever hires a new service provider, a data destruction company or a new freelance had to work on your systems, that they are aware of what they have to do which is roll out a C2P, controller to processor agreement.  And in order to be able to do that, you should set up a register.  So that means whenever somebody hires a service provider, just give a quick notification to the data protection officer or your data protection responsibles if are the mother structure, and then make sure you have a register which allows you to comply with it.  The auditors will ask for that, it's just part of the adequate and appropriate organisation.  Okay.  Yeah, I think the others are side registers, but I think Gita rightfully mentioned them here because GDPR requires you to record also other things such as the breaches, such as the data subject requests that you have.  A lot of that will need to be registered.

GS: Yeah.  And I think we'll talk a bit more about some of those in more detail in a little while.  So the next one is your subject rights, and so this is an important area of change although some are familiar if you're familiar with the current Data Protection Act.  So your subject access rights and your right to object, for example, in relation to direct marketing and our automated decision making, exists under the current law.  Other data subject rights are new and … or have been revised.  So, for example, the right to data portability or right to transfer data between suppliers.  Those of you in financial services will have something similar or have gone through a similar kind of technology update with the open APIs or the My Data initiative.  And to the extent … under data protection this is an extension of the right to access personal data but, importantly, it's not an unconditional right and only applies where personal data has been processed on the basis of consent or pursuant to providing services under a contract or obligations … formal obligations under a contact and where that processing is carried out by automated means. 

The next one … the next biggest extension is, and probably the most publicised in the media, is the right to erasure, so colloquially known as the right to be forgotten, and very much again around giving data subjects increased control over the personal data that is held about them.  But, again, it's not a standalone right and so very much tied to the right to request restriction or object to data processing.  Both the ICO and the Commission have stressed that it's really an obligation and incumbent on organisations to have clear notices.  So that's … in terms of actions for organisations, we need to ensure that our notices are clear as to when these rights are applicable and when data subjects can request their rights and to help them enforce them. 

So what are the actions?  What are the practical steps that you need to do around data subject rights?  I think first, internally, those that are handling … employees that are handling personal data, both on the consumer and the employee side, need to be aware of these rights, what they mean for the organisation.  So this is the whole education piece internally.  Secondly, as Andreas mentioned, very important for IT stakeholders to be up to speed with these rights so that they are designing new technologies or updating old technologies to be able to help facilitate the implementation of requests, so where data needs to be suppressed or marketing lists needs to be updated, to remove names from those lists on request or to stop processing where there's an internal assessment of whether a data subject can request that their data is no longer processed.  And finally, as I mentioned before, ensuring that notices are updated so that they're clear, and individuals clearly informed of their rights and how they can go about requesting the enforcement of them.

AM:  Yeah, so the question is now how do we do this in the project, actually?  So you tell people about it, they are aware and they then come back to you and tell you we have all sorts of problems.  We have systems that cannot delete data, smaller systems like SAP.  We have backups which, you know, we simply … we can't … access a backup and delete data of a specific individual.  We have unstructured data where … emails.  How do you respond to a data subject requests for emails?  It's easy to have the sent and received, but what about where that individual is mentioned?  Are you gonna do a keyword search across your email server and delete any third party and images from there?  So in practice the organisation comes back to you with lots of issues and no solutions, so what do you do?  What we do with our clients is … so first of all, ICO says, and I thought that was a bold guess, they said in HR you typically have 24 systems where HR data sits, employee data sits.  I think that's probably way too low but you'll have a lot of doubles, for example, all the systems where employees login with name and ID.  No need to worry about those because name and ID you already have in your main HR admin system.  So you basically go on a risk-based approach and identify the … probably around 10 to 20 main systems where your employee data sit. 

And so we talk about a cookbook.  Basically each of these systems is potentially a recipe, and you need to find the recipe for each of these systems.  That's the painful part.  So you meet together with the system owner and IT, sit down and draw … draft or create a query or a report that extracts the information you need.  That sounds easy.  I mean, master data is easy; it's easy to generate a master data field report in SAP but to get the transaction data, of course, it's much more difficult.  So you need to be smart about it.  First of all, you generate the master data reports for each of those systems, then you should be aware of the [two] data collections you have.  So we have payslips over the last five years, we have performance reviews over the last five years, so what you don't want to do is put all that together in 15 gigabyte of information that you put into your response to the data subject request.  So it makes sense, as part of the recipe for the system, have an extract of all the master data that sit in the system, and then we need to tell the individual what transaction data you have, and you can ask them whether … what they're after.  You can ask them whether they would like to see a specific transaction data and then you can expect that in the second step.  So the recipe for each system will be put together.  You have 24 recipes and then we have a … a sort of a template for a response where exactly the person, the request owner.  How we do it from the procedural way is, whenever there is a data subject request, you have to make sure it gets channelled through the data protection or legal organisation and you have a request owner, because simply you can't have people trying to respond to requests themselves.  It's absolutely essential that these are channelled particular because you want to know centrally, you know, if a person's doing the second or third request, you want to know … you want to keep the know-how. 

We've responded to a request already so we need to see how we've done it.  So we could put them … eventually we'll have the template for the response and we will tell for each of the system, "This is how you get the data", and then they will also tell people who are the owner, "Now how do I deal with the transaction data, which transaction data do we have?".  And if, in the second step, the individual asks for these, this is how to extract them.  So a pragmatic way to deal with this.  The software developers are thinking hard about … about these things, so we will see in the future systems that are organised in a way that we do have a data mining concept across, hopefully, our landscape which allows us to extract data much better than it is now.  But, obviously, we have living systems, we have systems of hundreds, sometimes, of providers, so this will be long track.  And for the moment, I think, we are still working with the reality of lots of different systems that are not harmonised and that simply do not technically do what they need to do at the moment.

GS: And I think, importantly, in Andreas' cook book is that all of these data subject requests and rights come with very dictated German timelines by the regulator, so it's ensuring that with all of the wealth of information that you have to process, that you are able to communicate back to the data subject in the mandated timeframes.

AM: One month.

GS: Yep.  Okay, so that's [number two].

AM: Yeah, there's a couple of must-have policies.  So you definitely need a general data protection policy that the constitution, basically, of your organisation, it explains how we deal with data.  So there's a lot of stuff that goes in there.  We've expanded the client's policies by factor 2 or 3, or 10 sometimes, which doesn't mean it's a huge book but, nevertheless, it's a policy that has 20 to 25 sections and it also deals with issues like how to avoid shadow IT within the organisation, so there's quite a bit of rules and procedures for employees.  It also is … it's like a frame for other policies like your data breach procedure.  It will tell employees … if you discover an incident that may be a security incident, then look at the data breach response plan and act in accordance with that.  So it's, sort of, any other policies you have, they sort of feed into this constitution piece of work, which is a very important … it's like your central compliance document on the policy side of things.  One more data retention policy, very important, and also for the supervisors, one of the core documents they look at. 

So the problem with retention policies is they are very much national and they are very much business oriented because simply you have different retention periods applying in the financial world, in the healthcare world.  And, of course, in each country, in each member state, you have different tax and commercial and criminal law rules applying, so … and, of course, where you are … if you look at your integrity line, there's just completely different retention periods which are relevant than for your HR administration and payroll.  So it's … I think it's decisive that you have a flowing retention policy that sets, basically, the general rules for the organisation, and then part of your organisation, whether it's territorial or business aligned oriented, you give them a blueprint for their part and then they plug into the central policies with the specific periods that apply to them.  So the retention policy does not always need to state 5 years, 10 years, a specific period in years or months, it sometimes will only give a generic approach that you take to data.  For example, if you have an employee feature on one of your websites or an internal publication, then for that type you can say, "We retain it for a certain period of time", but you would say, "Data will be deleted once it's no longer required for the purpose for which it is processed and there are no statutory obligations for us to retain the data". 

So that will apply in quite a few instances rather than a specific time period.  The security policy, the data security policy, that's also important.  It's … most organisations do already have that.  It comes from the IT world, which means it's usually not very data protection focused and it's sometimes very expensive so … and it may be spread out in lots of different policies, password policy, laptop policy, portable device policy, database policy, HR file policy, so you need to somehow build a structure into all this because you should be able to present your data security concept in a readable format and digestible format.  So that's a bit of the task where it's good to pick up the bits and pieces that are flying around in the organisation and try to bring it into a concept.  I think those were the main policies that … that you should have in place and by any means.

GS: Okay, so notices.  I think transparency as we know it is key and central to data protection and a little bit of it [paired] off because the regulation is so granular in terms of what is required and what you need to put in your notices.  So often your notices are very long and almost impenetrable because of the amount of information that's in there.  And the … and largely unread.  I think that the most common example that we hear is, you know, Apple's privacy policy and who's read it and you just go and click "accept".   And actually that goes against absolutely everything that the regulators are trying to achieve with having individuals, you know, understand how their data is being used.  I guess there's a question of whether people care but, you know, they're really driving at providing information.  And so what we're seeing is different tools coming about and guidance from the regulators about how notices should be provided, and show in terms of your approach when you're repapering.  The example the ICO has given and is very much in favour of, is this layering approach. 

And so it came about initially when they were giving guidance in relation to mobile apps and having notices that are easy to read on phones and devices and showed this idea of having your layered privacy notice.  So you have all of your high level general points at the top and in bold, and then having further link-through's with the more granular detail in the event people did want to read that or wanted to have the further information about who they could contact, they could very much go back and click through on that more detailed information.  Or if they just wanted to click "accept" after scrolling down half a page, they could do that too.  The other one is the just-in-time notices.  So these are notices that pop as your processing activities change.  So, again, very much in the mobile online world where you have additional functionalities that people could opt in for.  There's this idea of pop-up notices that appear as someone clicks "I want this service" and you inform them at that point, again, going to that intelligible type of notice for people.  There's also … it was noted when they were drafting the regulation, the use of icons.  It's still being discussed.  I think probably helpful, but we would need to have universal icons because if everybody was using a different icon for a profiling, then nobody would have any idea what it was and it would be completely unhelpful and just confusing.  So I think if they do bring in icons and it becomes best practice potentially in different industries, they may [lead] this with the codes of conduct and certification. 

But the use of icons could potentially help individuals to understand what bits of the notices are about.  And then finally, what we are seeing as well is different media being used to communicate privacy notices, and so we've seen examples of videos.  I think the Commission actually had an interesting video that they put out about data subject rights and so the use of cartoons for people.  I don't know who wants to sit there and watch a cartoon.  I think they'd probably … perhaps it's quicker if they'd scroll down the Apple terms and conditions but just … there are examples of different ways to really help individuals understand what is being done with their data but still very much a focus on providing that information in a format that is accessible.

AM: Yeah.  So actually drafting these things, of course, you're aware of what Gita just discussed.  Basically, whose gonna read it?  But when you draft those, you are being faced with quite a few specific issues.  So you have to point out the specific legitimate interest that you have for processing data, and if you look at … as an example, if you look at the employee or the customer notice, that turns out to be quite expensive.  So, for example, customers.  You process personal data of customers for regular customer purposes, for [sanctions] purposes.  That, you basically either do in performance of a legal obligation, so you have to tell them about it, or in performance, or based on legitimate interest where there's not a specific act but where your regulator tells you you have to do things a certain way.  So you have to tell … in the general customer notice, you have to tell the customer also about, you know, these compliance matters.  And if you look at the catalogue of legitimate interest-based processing of customer data, that typically is in the range of 8 to 10 different items, if you get the right input from your organisation, what they are actually doing with the data.  So those … simply because the GDPR is such a long catalogue of painful things, for example, when you transfer the data abroad, you have to tell people what is the safeguard, so the C2P clauses, which, for example, are binding corporate rules or privacy shield or what have you, which I'm using to transfer the data to a third country. 

Now how do you do that in a data subject notice?  There are … I've seen it, there are companies who actually tell them, "We will do this based on a data processing contract with each of our service providers.  You can obtain a copy of this contract with blackened commercial data at the address below".  Now that's worst case for me.  Then we can see others where the company will say, "We will do this on the basis of appropriate safeguards.  Please click here to see what those are".  So you click, you get on the EU Commission site where the decision … the general C2P clauses are.  So this is just a totally, massively different understanding of the same concept, and so we need to try and find a smart way through this jungle.  The main rule for me is make sure that your main notices … there's actually, I think, three of those.  There's the customer and leads and opportunities for all business contacts, there's one notice for those, there's the employee notice and there's one for applicants.  So these need to be in shape and wherever we can, make reference to those.  Publish … the one for the customer is obviously on the website, the employee notice on the intranet, and whenever you do something that's very specific that may not be covered by that notice, you explain what's different here.  So, "We're collecting data for the purposes of documenting a company event", or so.  You take pictures of people so you tell them … if that's not covered by your general notice, you tell them what you're specifically doing, but otherwise you make reference to the main notice.  Just, you know, you don't want hundreds of notices flying around because obviously you have to update those, so it's important that you know which notices you are giving.  And it's important that … that sentence always shocks the client teams. 

There's no processing of data without notice, so whenever you find … you come across a personal data field, there has to be a notice to the individual, so you have to think, "Did we really tell the individual what we're doing here?  And, if not, we had an issue".  So because of potentially there being so many notices, you have to streamline and make sure that you avoid redundancy and hundreds of customer notices flying around.  It definitely should be one.  Oh, marketing permissions, yeah.  So what we get asked quite frequently is, "Can we rely on our existing customer consents or basically the whole marketing database we have?", with thousands or ten thousands, depending on your business model of contacts.  "Can we continue to use that?".  And the answer is in principle is yes, which in practice means, in most cases, no.  Because you can rely on it if it meets the requirement of GDPR. 

The challenge is, first of all, do you know who owns the contact, who is the responsible controller?  That in many cases not … simply we don't know, so we can't even name a responsible controller because the data is shared among many entities and we don't know which entity actually has a contract with that individual or if there ever was a contract with that individual.  Second is, we don't typically have an auditable trail and the proof that consent has been obtained, plus on which information basis it has been obtained.  That's … you need to pluck those two things together also going forward.  So say it was another systems that are used as a tool to get your marketing permissions, what they have to do and what they do is, they enable you to save in an auditable way the wording of the consent plus the wording of the information.  And you have to have version control, obviously, because if your information changes you have to make sure that you know what was the information that consent was given upon.  And if you do a material change later, you may have to obtain new consent.  So that's how it works.  And if then clients look at their database and really ask them the questions, "Are we safe here?", then typically they will see we're not able to comply with that.  So what's the risk? 

The risk is actually really big.  It's probably the biggest of all because this is our direct interface to the outside world and, you know, with thousands or ten thousands of contacts, 99 per cent of those are gonna be happy to receive emails from us but there may be the one occasional troublemaker or data protection specialist or what have you, and that's where it gets really problematic because that would a direct complaint to the Data Protection Authority.  So they come to you and look at your … at your compliance system and they do a documentation of marketing permissions.  So it eventually turns out, and all of my clients and all of the projects I'm doing have decided to do a refresher, a refresher campaign, sending an email with … I'm sure you've received lots of these in the last months, so "We'd love to stay in touch with you.  Please let us know if we can, and herewith our data privacy notice, and this what we would like to do with your data", or "Manage your marketing preferences".  Check email, check sms, check whatever.  Generally check which parts of … or which specific documentation you're interested and the challenge is to word your consent so that it actually really covers all that you want to do.  There's lots of new technologies that you typically don't think of which require consent, so if you think of newsletter tracking, of course, website analytics ,and those are sometimes things where you think probably, you know, do we need consent for that?  Newsletter tracking, if you don't use a data trustee and you link the click behaviour and the reading behaviour of the individual to that individual, you will probably need consent.  At least that's the current state of the discussion.  So we need to make sure that we have these analytics as part of the … of the consent declaration.  Of course also, events, we want to do training, we want to do newsletters, we want to do customer surveys.  So make sure anything you do with your … with your contacts is covered by the consent.

GS: And then I just click reference to PECR.  So obviously in relation to electronic communications and marketing, we still have PECR which is the soft opt-in and that trumps almost the GDPR requirement for … in relation to consents and marketing online and getting those consents.  The ePrivacy regulation was meant to come out and be enforced at the same time as the GDPR, but that's still very much under discussion, and so until then, we're still able to rely on the soft opt-in in relation to online obtaining of consent.  Okay, and then … so our last one is in relation to data breach responses.  In the EU this is a real game changer in relation to privacy.  Some member states already have mandatory notifications and some industries have mandatory notifications for data breaches, but there's a new requirement in the GDPR where controllers must notify the relevant authority within 72 hours.  Yep, 72 hours of awareness.  And so that's … unless, of course, the breach is unlikely to result in a risk to the rights and freedoms of an individual. 

And so a couple of terms in there which will require assessment at the time of the breach.  And so it's quite a low risk threshold, actually, and most modern day breaches are likely to satisfy that threshold, and when you couple that with the financial sanctions and penalties associated with non-compliance for not notifying potential breaches, it's likely that most companies will take quite a conservative approach to that assessment.  And at the end of the day, you know, that means we're probably gonna see an increase in breach notifications post GDPR and, as mentioned before, the ICO has already seen an increase in the months running up to December.  The "become aware" language is critical because it understands the importance for having an airtight incident response plan that … and that ensures that events are quickly escalated to the right stakeholders and through the organisation, and pulls the relevant work streams together.  And, I mean, practically it means, I think, that most organisations are really gonna be in the unenviable position of going to the regulator without having all of the facts in place, but also meaning that you'll have to take substantive substantial advance preparation in terms of putting these plans in place and having teams that are quick there and ready to go.  In addition to notifying the regulator, there is also an obligation to notify data subjects where there's a high risk to the individual's rights and freedoms. 

Again, some vagueness in that standard, and an assessment will have to be done at the time, but any breach that includes financial information, health information, national IDs, are likely to meet that standard.  And I think, interestingly, you know, if we look to the US, and I think the Ashley Madison is probably a really good example because there it was just contact information and members of this website, but actually the nature of the website was that it facilitated illicit affairs, and so that nature of the website itself meant that under the current GDPR standard, that notification to individuals is likely to be required.  So it's not just the information but it's how that information could potentially be used.  So it's a clear sea change, I think, that will result in a parade of hurdles and expenses such as needing to engage with external counsel, potentially having forensic analysts there to assess the risk, potentially considering [full] monitoring products for certain data sets, having public relations firms ready to help communicate those messages effectively.  We've seen messages being communicated badly and the impact that's had on businesses and reputation in the market, which can all be very expensive, but important.  And I think also this has an impact on deal negotiations and to your supply chain management.  And so where you have suppliers that are processing high volumes of sensitive personal data, it's about ensuring that you have the contractual mechanisms and those are all updated in time to ensure that they are notifying you that they are also implementing and contractually bound to implement any mitigating responses that you require or a regulator may require, as well as the obligation to notify you.  Under the GDPR, the obligation on the processor is to notify the controller and then the controller needs to make the determination whether to notify the regulator or the data subject.  And so that [break in audio] notification is quite important to managing the controller's risk.  And so … as mentioned previously in the records piece, then documenting and having a register of these breaches going forward, as well as the way that your organisation handles them, is key to showing accountability and your audit trail of managing those risks.

AM: Yeah.  So that means you need a separate database for [some procedures] simply because it's so important, you don't want to hide it in 500 pages of IT security procedures where all that already basically is in, at least as regards the system world.  But on the other hand, you don't want to re-invent the wheel and you want to make use of your existing resources.  Now there is, in the IT security, of course, a lot of resource and exactly the know-how and the people that are doing … that they will just continue to do what they are doing today.  They will do first level response, they will do containment of a data breach, of a security incident in the system, so that's exactly what we need.  So our response procedure needs to make sure that we use that, that on the first level response we have the ISO, so the local information security officer, that deals with the incident on first level.  He has to liaise with the data protection responsible on the local level, and they both together either kick the incident out immediately because they are able to assess, which is the case, in 90 per cent of all incidents this is not a data breach, or they escalate.  So typically in your organisation you should have a central … a general information security officer, or whatever the corresponding position is in your organisation, plus the central data protection responsible.  That's a DPO or a data management officer or whatever. 

That's the top level.  So at least typically what we see in these procedures is 24 hours, the local team has to escalate to the top level information security plus data protection.  They have to assess within 12 hours are we in the land of data breach, and then they bring this matter to the attention of your data breach response team that will have, in addition to the data protection officer and the general information security officer, it will have the legal team.  It may have, depending on how critical it is, and if you approach actually a notification, it may have public relations, and it certainly has the business that's concerned, and they will have to decide then within 36 hours which are left whether this is a notifiable breach or not.  Obviously there is continuous stream of further information from the first level containment team which may tell you, "Well, if we've dealt with it now and, actually, the data that was lost was encrypted so we may not need to worry about this".  So there's continuous stream, but then the top level team, the data breach response team, has to make the final call.  And it's interesting to see how clients actually have board or other functions bowing to this final decision.  There's client's where actually the board just resolves the final say on whether a breach will be recorded or not, and there's others who say, "Well, from a compliance perspective this should rather be a decision of the data protection officer".  So, you know, this is where your procedure needs to reflect your internal understanding of your corporate governance and how you want to deal with these things.  I mean, there may potentially be significant messages to the outside world, so it's good to put some thought into these procedures on the top end as well as on the lower end, which we discussed.