GDPR and Data Protection in Northern Ireland: Your FAQs Answered

The following is an extract from a webinar held on the 17^th April 2019 with Scott Alexander from Legal Island and Laura Gillespie and Anna Flanagan from Pinsent Masons.

Scott: Good morning, everybody, this is Scott Alexander from Legal-Island. I'm here with Laura Gillespie and Anna Flanagan from Pinsent Masons. We're going to be looking at GDPR updates.

Impact of GDPR Breaches

So Laura Gillespie, aside from a hefty fine, damage to your reputation, and the loss of trust in your organisation by the consumer, are there any other ramifications of a breach of the GDPR?

Laura: Well, thank you, Scott. The short answer to that is yes. Those are all very serious considerations for any business in terms of the commercial and reputational impact. But the other key impact that might arise from a breach is that of civil claims.

Under previous legislation, there was historically a requirement for a data subject to demonstrate financial loss before they could get compensation for damage or for distress, but that's, a case law did away with that and GDPR follows that through. So data subjects can now receive compensation purely for distress as a stand-alone right to compensation.

Scott: So presumably it will be reckoned that it's in-built into the process. So if you lose my medical records, it's expected basically that I will suffer some stress. At some point, I could take a claim and get damages just because, not even having to prove, it will be just accepted that there will be stress. Is that what . . .

Laura: It's not accepted. You would still have to prove that that has followed as a consequence of the loss, but certainly that door is now open, whereas before, you would have had to have demonstrated that you had suffered financial loss before that question arose.

Scott: Okay. And there are some cases ongoing at the moment. The Morrisons case, for instance, has been given leave to appeal to the Supreme Court. So any background on that or anything you want to say?

Laura: Yes. So with that, obviously the decision that's going to the Supreme Court is around liability, as to whether or not Morrisons are vicariously liable for their actions of an employee. What the case hasn't yet determined is what the quantum of any loss that the subjects might have suffered will be, so that question remains unanswered. And this part of the case, the Supreme Court will not give us the answer to that.

But the other important point to note is that the Morrisons case obviously was pre-GDPR and therefore any compensation which might arise from that may be tied back to the previous legislation rather than being GDPR-related.

Scott: Okay. Anna Flanagan, what is the likely fine if you withhold information requested under an SAR, a subject access request?

Is there anything there? Do I have any idea? Because there's quite a number of people here — we had about 10% in that survey — said that they have been contacted because a data subject did complain about them to the ICO.

Anna: Yes, well, we don't have any indication of the likely fine at the moment. In theory, noncompliance of a valid subject access request is something that under the GDPR, a controller could be fined, higher-tier fines. We're talking about that €20 million or 4% of global annual turnover. It's very unlikely, I think, that the ICO are going to fine controllers at that level for noncompliance.

But what is more likely is that, as I think some listeners have already experienced, a data subject could make a complaint to the ICO. The ICO may investigate. They may ask some questions about what searches were undertaken, what the organisation's policies and procedures are, and they may uncover things that they are unhappy with.

They also might point the data subject towards the courts as a means to A, achieve compliance with a subject access request, and B, achieve compensation for the organisation's non-compliance. That's something we've seen clients struggling with at the moment.

Scott: Yes, it's a kind of, I suppose, a spin-off type of thing, because the organisation of data protection commissioners and so on — it used to be the Article 29 Group — they kind of indicated at the start and made that they weren't going to really be coming in with a big heavy hand and do fines.

But those peripheral types of things that are happening, where it's not going to look good if you're a serial offender, it's going to be held against you, all of those are just building up at the moment. And giving access to people, it's going to be used against you in tribunals, that you were sticky, you weren't giving subject access requests and so on. It's just the way that it infects almost everything else, it's going to be a problem.

Anna: Yes, I think that's right. The European Data Protection Board as they now are have made it clear that anticipate fines are going to be proportionate and not out of kilter with what they've been before. But equally, if organisations are continually coming to the attention of the ICO through noncompliance with data subject access rights, requests, or, indeed, breach reporting and that kind of thing, if they're seeing the same names coming across their desks, they're going to start to ask a few more questions.

Role of Data Protection Officers

Scott: Okay. Laura, looking at data protection officers, quite a number of organisations listening in will be required to have data protection officers. So how do you know whether you need to appoint a mandatory DPO?

Presumably, some of the organisations, if they haven't done it, and they're in that group, they could face the €10 million fines. So hopefully you're not there if you're listening folks. Is there a list of organisations or public organisations or activities where it's mandatory to have a data protection officer?

Laura: Yes. That's clearly set out within the regulation. There are three broad categories. Firstly, if you're a public authority, and the ICO has been clear that you point to, or they look to the public authority's defined under the Freedom of Information Act, set out within that. So if you're a public authority and responding to Freedom of Information requests, you're automatically caught.

But the other two categories are if you're regularly or systematically monitoring data subjects on a large scale or if your core activities concern criminal convictions or special-category staff, and so things like health or criminal records. So those are the three categories.

What we haven't yet seen is any real guidance on the second two categories, and that's where organisations will have to sit down and assess what are their monitoring activities to decide whether or not they fall within that bracket.

Scott: Okay. And Anna, how independent must a data protection officer be?

Anna: This is one really key important point when organisations are considering if they need to appoint a DPO, who to appoint. So it could be someone internally with another role. That is acceptable. But I think what you need to be careful about is making sure that's not a role that would conflict with their DPO responsibilities.

For example, the individual in charge of marketing within the organisation, for obvious reasons, would not be an ideal candidate for the DPO role. They also need to be of [indecipherable 00:12:19] that they can report to the highest levels of the business, and that the highest levels of the business are going to understand and appreciate the advice. So it's important that they are independent and sufficiently senior.

You can appoint an external DPO. Maybe especially a number of organisations might want to use sort of shared service. And the other advantage to anyone considering taking on a DPO role is they actually can't be dismissed for carrying out your tasks in relation to DPO role. So an employer can't decide we don't like the advice you're giving us. And if it's, you know, it is compliant and it is right, then you can't be dismissed on that basis.

Scott: But you need a fairly strong character to stand up to the chief exec and say, "You know what? We've done something really bad. We now have to report, we have to tell all the individuals that might be affected." Because the temptation might be to try and hide that kind of thing, but the DPO has a responsibility to say, "No, you do it. This is a breach."

Anna: Yes, I think that's right. In a commercial organisation especially, there's going to be some pressure on a DPO to take a commercial view on things. But at the end of the day, the legislation's pretty clear in terms of breach reporting, data subject reporting, compliance with subject access requests, and that kind of thing.

So I think it's important that the individual can stand up and has a sufficient training and resources available to them to do that. They do need to have some expertise and experience. It's not just whoever historically, maybe in HR has been dealing with these kind of requests, would necessarily be qualified to undertake that mandatory DPO role.

Scott: Okay. And I suppose the survey that we have, where some people found it very easy and some people found it very difficult might be a reflection of that.

Data Processors and Controllers

Scott: Laura, data controllers, they could be held liable for a processor's breach as well. So a processor is somebody who does work on your behalf.

Laura: Precisely.

Scott: And a data controller is the person who controls the data. It's the original one. In her case, it might be employers who are looking after the personal files. So how does the controller protect the business?

Laura: Big question. So effectively, GDPR now requires mandatory contractual clauses to be put in place between a controller and a processor, which effectively sets out key terms like how information is to be managed and also requirements around breach reporting if an incident does occur.

It's important to note, however, that processors can now also be directly liable for breach, whereas before, under the previous legislation, that liability usually only fell to controllers. So that is an important distinction now under the regulation. But in order to protect, how the controller protects themselves, is having those mandatory contractual clauses in place and making a clear delineation of responsibility between the two as to who is responsible for what.

So with that, it is important, and often we've seen clients misunderstand what the relationship is between the parties because they haven't been clear as to where responsibilities lie. So it's always important that there's a clear division of rules and responsibilities so that both parties understand what it is that they're doing and that the controller can identify whether in fact the entity is a processor or in fact potentially another controller.

Demonstrating Compliance with GDPR

Scott: It shows the complexity. Anna, there's an issue here about mandatory training in data protection. If controllers face fines, do they really need to argue that they went as far as they could by training everyone in data safety, and might fines be higher for those organisations who fail to train in data protection compliance and safety?

Anna: Yes, so in terms of the information security requirements in the GDPR, there's a reference in the Article to both the technical and organisational measures that a data controller must take. Obviously, the technical measures are generally out of control for individual employees, and that will relate to the appropriate, for example, cyber security, etc.

But the organisational measures are the bit where training really comes into play here. And it's really important that the organisations do have that training and awareness in order to comply with the organisational measures requirement.

One thing we've noticed in assisting clients, for example, with personal data breach reporting, is that when reporting a personal data breach to the ICO, any appropriate training or organisational measures that have been taken are something we would provide to the ICO in order to mitigate and demonstrate that really, our client in that instance, was doing everything they could to ensure information security.

So there's no excuse, really, for organisations not having, at the very least, annual training and refresher awareness for employees, because very often, it's sort of employees on the front line that have access to you or can cause the biggest harm to you, the sort of sensitive personal information the organisation holds.

Scott: Yes, and it's recommended by the ICO that you have annual training, and it's on their website there. So presumably, if they're investigating, Laura, they'll be looking at their own standards and saying, "Well, you failed to comply with our standards."

So would you recommend running some kind of data breach simulation exercise?

Laura: Absolutely. Your survey earlier showed that the two key concerns are staff taking issues seriously and the risk from cyber attacks.

Scott: They are linked.

Laura: And they absolutely are linked, and also, I think in many ways, it's only putting yourself in that position that you really understand the pressure that the business could be under if it happens. Because in the Pinsent Masons team, we've been acting for a range of clients following breaches, quite often cyber attacks. And with that, it's quite clear that some clients can struggle to understand who is responsible for what within the organisation once the incident occurs.

Running a simulation exercise enables you to prepare and practice your incident response plan, because obviously any report to the ICO should be made within 72 hours of becoming aware. And if you spend the first 36 hours trying to organise internally as to who's going to be responsible for what, you're losing valuable time. So carrying out that simulation exercise in a controlled and calm environment means that you're well equipped to then actually carry that out if the worst happens and you do have to make a report in the event of a real incident happening.

Scott: I suppose, Anna, one of the things that people would do, is they'd send 'round a kind of spam email and see how many people opened that, too. You've probably tried that at Pinsent, have you?

Anna: Yes, I tried that a couple of times with varying . . .

Scott: I just never opened up . . .

Anna: . . . varying degrees of success in Pinsent. Yes, that's something we would really recommend. As I said, we've been helping clients with personal data breach reporting, and Laura mentioned sort of the after-effects of cyber attacks.

We've really seen the consequences of an employee clicking on a phishing email, which can be everything to accidentally perpetrating invoice fraud right through to an employee's entire mailbox being synced by an outside third party, which can have really quite serious consequences for the organisation and the individual. So any training that is sort of real-life and helps employees really think practically before opening those kinds of emails would be something we would definitely recommend.

Scott: Well, I don't want to advertise too much, but Legal-Island does do e-learning on data protection and safety and so on, very reasonably priced. You can find out about it on the website if you want.

Laura, it's not always clear, however, that a data breach has occurred. In fact, you might end up with some organisations who have little sleeper things on you, and you don't know there's been a breach. But when should the organisation contact the ICO, and indeed, the data subjects, if there's been a breach?

Laura: Taking the first of those, when should you contact the ICO?

Obviously, the regulation says that you should contact them as soon as possible, and in any event, within 72 hours of becoming aware of the breach. So the question is then when do you become aware, and the Article 29 Working Party guidance talks about having a reasonable degree of certainty that the issue has occurred.

And in helping clients manage incidents such as this, what we have often done is effectively take a layered approach to notification, because often clients are concerned about a potential failure not to report and therefore making an initial report, saying this is what we know so far. We're continuing with our investigations, and we'll update you as soon as we have more information.

And so that helps mitigate the risk of a failure to report but yet means that you're reporting in a controlled way, so that you effectively are telling the ICO as you go. So that's the way in which we recommend those sorts of situations to be handled.

Scott: So it's better to be up-front than hold back and hope that it isn't a breach. You'd better say, "We think there is one. This is something we can deal with."

Laura: Mostly, but having said that, we do undertake very careful consideration of clients, whether or not we think it is something which has triggered a reporting obligation. There have been a series of incidents where we have looked at the circumstances and said we do not think that this is something which is yet reportable because of what we know.

And the ICO has issued a word of caution around over-reporting. So you need to give very careful consideration to the circumstances, but once you think that threshold has been met, then yes, that then takes you to a point where, and we could take that layered approach.

Just, I suppose, touching very quickly on the question of data subjects. There isn't that same time limit expectation with the data subject notification, but if there is a high risk to their rights and freedoms, again, there's a mandatory requirement to notify them.

Scott: Yes. So if you go back to the Morrisons case, which is pre-GDPR, I mean, it was their bank account details and all kinds of things that were put on the internet by the accountant. And clearly, that's something that you have to tell them about straight away, pretty much, because they could lose money if you don't change your bank account.

Laura: Yes, precisely. So the Article 29 Working Party guidance on this particular issue does again talk about the risk to identity fraud, and therefore if that's something which is a live risk, then that would be a high risk and require notification to the subjects.

Scott: Okay. Anna, there was a report recently about Google in the US refusing to provide gender pay gap information on the grounds of cost. Now Gender Pay Gap isn’t in in Northern Ireland. There are reporting’s in Northern Ireland, although the bill's just been published in the Republic. And it's had its second year of reporting over in GB.

So this might have been through some kind of Freedom of Information request, but,

Is there any cost defense in dealing with subject access requests or for one that's too big or just a fishing exercise or where it's deemed to be onerous?

Because SARs seemed to be a big issue when we just did the survey.

Anna: Yes, and I think they are, particularly, I would suggest, when it's an employee who makes a data subject access request, and because actually searching and locating their personal data can be something that's quite tricky. You have a right to access your personal data, so an employer or a controller can't say, "No, I think this is just a fishing exercise and on that basis, you're not entitled to it."

There are a couple of things in the regulation that do assist controllers. Firstly, Article 12 allows for the time line for compliance with a request to be extended when the request is particularly complex or you receive a number of requests, albeit that's the number of requests from the same individual, not that you receive a number of requests from different individuals. So you can extend the time line to comply, which can sometimes be of assistance.

Additionally, in the recitals to the regulations, there is a reference to a controller being able to refuse on the basis of disproportionate effort. This is something that, I think, controllers and employers should exercise with caution and have a think about, and perhaps take some advice on before actually engaging. But that is there.

Additionally, in Recital 63, there is an ability for a controller, where they're processing a large quantity of information, to ask the requester to specify the activities or the information they may relate to. So then it may be the case that if an employee makes a very wide request, that initially you could go back to them and say, "Look, we processed a very large quantity of information about you. Can you give us some dates? Can you tell us what it is you're looking for? Can you give us some ideas, some keywords that we could conduct the searches are for?" So there are some things to help controllers there in the regulation.

Scott: And the trouble is, if you have an argument, then they make a complaint to the ICO, and they'll have to investigate. And they may complain if you've taken the right advice, anyway, on the side of the employer in saying, "Look, that was just a fishing exercise. It was too much." It's perfectly reasonable to say, "Do you want the emails between X and Y dates, or wherever it happens to be?

Anna: Yes. We've seen the ICO, following receipt of a complaint, come back to an employer or a controller and say, "Well, look, tell me a bit more about what you actually did. How do you think you complied with this request?" And as part of that, then the employer can give information about how much information was actually involved, the sort of quantity of data, and the steps that the organisation took.

But the ICO do expect organisations to undertake a certain level of searches. You can't simply have a quick look at something and say, "No, that would be disproportionate," or, "No, that, you know, that, we're just not complying." For that you need to really think it through and be able to back up your decision.

Scott: Okay. Laura, is there anything that Anna hasn't covered or differences between subject access requests now and pre-25th of May of last year?

Laura: Yes, I think there are probably three key differences. Firstly, proportionality in terms of refusing, that Anna has touched on. The other two are time and fees. Obviously, the time period within which you have to respond has shortened down to one month, albeit but that can be extended to three in cases of complexity.

But also, albeit the £10 was never a particularly big ticket in terms of actually getting cash in the door, it could have been a disincentive to some data subjects in making the request. So the removal of the ability to charge a flat fee obviously was the other big change that we've seen.

Scott: Anna, what happens if a SAR comes in during term time, say, there's a school or some kind of closure. Does it impact, that it's just a calendar month?

Anna: It's just a calendar month, and as we've gone through with a few clients, that does include February, even though it's only 28 days. So it's really important that an organisation has the facility available there that if a subject makes a request during a bank holiday period or Christmas holiday, so that kind of thing, it's still picked up and dealt with within the relevant time.

And just bear in mind that it doesn't need to be in a particular form. A data subject can make the request in any form that they wish. They can tweet to request, and that still could be deemed a valid request.

Scott: And just following on with that, Anna, can you refuse to provide emails, say, because they provide information on other people? Because where a lot of requests will have multiple names and such like in?

Anna: Yes, and again, that forms part of why compliance with subject access requests, I'm sure, it can be very burdensome for controllers, and because one of the exemptions that you can use under the Data Protection Act is around third-party information. So if a third party's name or other personal data about them is in the information you're supplying to a requester, really, you should either be seeking consent from that third party before disclosing it or balancing their rights and freedoms and their right to privacy first with the individual's right to access their personal information.

So unless you're very comfortable, either that you have their consent or that that balancing test comes out in favour of disclosing it, we would recommend that you redact third-party information before disclosing it.

Scott: So there's quite a lot of work done there. But you can get software to redact other names, and you can type it in, it will take all references to Scott Alexander out.

Anna: Yes. We have that available here in Pinsent Masons, and we've been using that to assist clients with the data subject access requests, where you can use software to redact the third-party information out. And it means then you can disclose that and be comfortable you're not inadvertently breaching . . .

Scott: Somebody else's rights….

Anna: . . . somebody else's rights to have their information held securely.

Scott: Okay. We are just about to come to the end. There were some other questions we'd like to go through, but if you have any, you could maybe send questions in and we'll see what we can do.