Keith GDPR | Q-Hub Webinar | 22/03/22

Yeah, we're talking about GDPR in hospital landscapes. I'm going to talk about what's changed since we left the EU because it has brought about some changes.

So we're going to talk a bit about dual regulation and requirement for EU and UK agents, changes to cookie bars, the age of design code also known as the children's code, the UK government consultation that's been carried out and where that seems to be going, and then some latest changes since January this year. And then what do you need to do?

Begin with: when did it change? Because everybody thinks it was the first of January 2021, but it wasn't. Actually in UK time it was 11 o'clock on the 31st of December 2020 because Alberta European Central time is an hour ahead of us. So actually it changed for us at 11 o'clock UK time. It doesn't really matter too much, but it said any data which you collected after 11 o'clock on the 31st of December 2020 falls under UK GDPR as opposed to falling under EU GDPR.

But you might have situations where you actually fall under both. And if you meet those criteria then you need to comply with both EU GDPR and UK GDPR. And you may need to have an EU agent or indeed a UK GDPR agent if you're based in the EU. So if you're based in the UK, you don't attract any sales from within the EU and you've only got clients and staff within the UK, then thing to say it's simple because you only need to comply with UK GDPR. But if you're based in the UK, attract sales in the UK and within the EU, and you only have a place of business within the UK, then you need to comply with UK GDPR and EU GDPR. And that means you need to appoint an EU GDPR agent.

An EU GDPR agent can be anyone with a business in the EU. So why do you need the agent? Because the agent acts as the interface between you and the EU regulator in whichever country that agent is based. And I normally recommend my clients to two agents that I know in either Ireland, Republic of Ireland or in the Netherlands. The simple reason that they both speak fluent English so it makes things really easy.

But why do you need them? Why would you bother with an agent? Well, because if you don't have an agent and you breach GDPR—and that might be a data breach or it might be some other breach of GDPR—if you are based in the UK, you have no EU agent and you have a breach of GDPR, each of the 27 countries in the EU can levy a fine on you. So even if each country only fines you 500 euros, 27 times 500 euros is 13 and a half thousand euros. Contrast that with if you've got an EU agent. You don't get fined by one EU country. Very unlikely that one EU jurisdiction is gonna fine you 39,000 euros for that sort of problem. So you probably get away with only being fined 500 euros, which makes a thousand euros or so a year you might pay to have an EU agent—a really good investment.

But what about the other way around? Well, if you're based in the EU, you don't attract sales from within the UK and you only have clients and staff in the EU, you only need to comply with EU GDPR. But if you're based in the EU, attract sales from the EU and the UK, and only have a place of business within the EU, then you need to comply with EU GDPR and UK GDPR. And this time around it's the opposite of before. You need a UK GDPR agent—someone like me. And again the same rules apply.

However, if you're in the US, let's say, or Australia or somewhere outside the EU and the UK, and you track sales from the EU and the UK, you need to comply with EU GDPR and UK GDPR. And you need an EU GDPR agent and the UK GDPR agent. And they're not allowed to be the same person, by the way. They have to be two different people.

Changes to cookie bars is the next thing I want to talk about. You'll probably be familiar with cookie bars. It comes at the bottom of the screen and it says this website uses cookies. If you're happy click here, if you're not happy click here, or if you want to change which cookies it sets click here. Normally what lots of sites do is that actually, if you click away from that landing page using the menu at the top to a different page, that cookie bar just disappears and you haven't clicked on any of the buttons on the cookie bar. It's just gone.

The ICO is really cracking down on that. And so they're now saying that's not acceptable. If you display the cookie bar, you have to wait until the user has selected one of those options—either they decline all the cookies, they accept all cookies, or they choose which cookies they want to have. And so if they can navigate away to a different page without clicking on that bar yet, you gotta put that bar there again. And that bar has to stay until they've chosen one of those options. And they're getting really quite heavy on that. So it's really important that you do that.

Now, one topic talked about the children's code. The children's code came in on the 2nd of September last year. And the children's code is about putting children first and making sure that what you're doing to their data is transparent to them and the content is age-appropriate. What does that mean in practice? Well, it means you have two options. Either you can say nothing on our website is designed for children under the age of 16. And so we will just have a paragraph. And this is set wording for the paragraph. We will have a paragraph within our privacy policy that says our website's not designed for under 16. If you are under 16, please don't use our website.

But if you do want your website to be used by under 16s, you have to provide your privacy policy in a style and a language which a child of that age can readily understand. So if you have seven-year-olds using your website, then you need to write your privacy policy in a way that a seven-year-old can understand.

And what we're still currently awaiting clearance from the ICO on is whether that privacy policy has to be in words. Because personally I think for a seven-year-old, and for some adults come to that, to be fair, it would be easier if the privacy policy was a cartoon rather than actually being lots and lots of words. But at the moment there's no clearance on that. At the moment it's just to be lots of words.

So come on to the government consultation. The government launched a consultation last year. Today, a new direction. It closed on the 19th of November last year and it proposed some fairly radical proposals to make UK GDPR light touch. One of the government ministers was quoted as saying we want to make the UK the Singapore of data. Since then, they have had lots and lots of responses. And in fact, when I was last talking to somebody at the department, their best guess would be it's going to be somewhere mid-summer before they finished collating all the responses they received. And they then try and base a formula out of those on what they will change about GDPR.

The other thing which has happened is that our actual Information Commissioner has changed. Elizabeth Dennin, who was the Information Commissioner in 2018 when GDPR came in and was responsible for an awful lot of UK GDPR, she's now left. She's gone back to Canada. And we knew I have a new Information Commissioner from New Zealand. And he has actually been in the press this week saying I don't think GDPR needs many changes at all. So in a way that's good because that's the message that practitioners like myself have been pushing back to the ICO. That really don't change it yet. It's still too soon. So hopefully there won't be any significant changes.

I actually think if there aren't going to be any changes at all, they're not going to happen this side of the next general election. That would be my best guess. So I think in this term of Parliament, there's so many other things going on already. I mean, obviously COVID had a big effect. Now, of course, we've got Ukraine. I simply can't see government time being allocated to it. But we'll see. I could be wrong. So it's something I'm keeping a watch on in brief. But I wouldn't worry at the moment about changes to GDPR. The order fundamentals GDPR.

So what has changed or where there's been recently? The first one is in terms of digital analytics. If you use Google Analytics on your website, you must have in your privacy policy that you use Google Analytics and people must be aware you're using Google Analytics. And the reason for that is because Google Analytics is actually sending information back to servers in the US. And the problem is that the security that's used on that communication has been deemed to be not compliant with GDPR because the US state can intercept that data. And GDPR doesn't allow for state interception of data. And so therefore it's not compliant. And so you need to be very careful to include in your privacy policy and in your cookie policy that you are using Google Analytics.

If you're using it on a similar vein is Google Fonts. Google Fonts can be used two ways. You can either download the font onto your web server and serve it from there and that's fine. Or you can call it by the Google Fonts API, which is what most people do. That same method used in the Google Fonts API is also transmitting data back to California in a method which is not acceptable to GDPR. So if you're using Google Fonts via the Google Fonts API on your website, you as a company or an organization are not GDPR compliant.

And this one can be expensive because what the ICO has said is if we carry out an audit of your website and we find that you're using Google Fonts via the Google Fonts API, we'll write to you and let you know that we've discovered that. Oh, and by the way, we're fining you a hundred pounds for each day that you continue using Google Fonts until you rectify the situation. And so that can be very expensive. So if you're using Google Fonts, then make sure you use them locally.

Do bear in mind the children's code, as I mentioned earlier, came in on the 2nd of September last year. So did some honeymoon period for that has now passed. So if you are serving data to children, make sure that you are compliant with the children's code. And I'm not going to go into detail within 10 minutes I should use now just to tell you the children's code. But you know, please follow up with me if you want to know more about that.

Make sure you have a data retention policy. So part of GDPR is that each piece of data has a date of life. It's very important you have a policy that documents what those data lives are for different types of data that you hold. And that you have a process in place so that means you're actually actioning that data retention policy. So if you say you only keep it in three years, then make sure you've got a process in place which means every six months, three months, you're going through the data making sure you haven't got anything more than three years old.

But really important thing is to have the data retention policy in the first place. Because there's a company in the Midlands who within the last couple of months got fined ten thousand pounds solely because they didn't have a data retention policy. They had everything else. They were doing everything else absolutely correctly. But they didn't have a data retention policy. And that cost them ten thousand pounds. So get a data retention policy.

If you're using energy monitoring or activity monitoring, again this is something you need to think about. Because on a Facebook you might think whether energy monitoring, activity monitoring, that's not GDPR. It's not personal information. That's what we thought when we started working with a company who's currently implementing energy monitoring towards being carbon neutral by 2030, which they've set in their company perspectives is what they're planning to do. We don't really can't identify an individual from that, can you? Until you realize that the sensors are recorded 24 hours a day, and at night there's only one security guard in the building. Suddenly you have personal data. And so the energy monitoring data falls under GDPR.

If you return to the office in this hybrid environment—so maybe now as people going back to the office you're working part in the office, part at home—then the ICO is saying you need to carry out a data protection impact assessment. You need to assess how data has been affected by the fact you've been working at home and now you're in a hybrid environment. How do you make sure there aren't two copies of data? How do you make sure data is kept up to date if there's a discrepancy? How do you make sure it's done in both sets? All these sort of things need to be taken into consideration in a data protection impact assessment. It's really important to do one of those.

The other thing which the ICO is starting to tighten down on is make sure that you have a GDPR training register. So you have a register which details for each of your members of staff when did they receive GDPR training, who delivered it, and was there an exam? If there was an exam, what happened? If it wasn't an exam, it doesn't actually matter. But it's important we tracked it—whether it was an exam or not. And just as importantly, when they had refresher training and who delivered that. And it doesn't need to be a complicated document. It can just be an Excel spreadsheet. But it's really important that you have a training register.

And the other document which is absolutely crucial that you have is that you have a data breach register. And again, it doesn't need to be complicated. It can just be a spreadsheet. But it needs to have in it the date that the breach occurred, what the date breach was, did you notify the ICO? If you didn't, how did you decide that you didn't need to? And either way, what you did or you didn't, what actions have you taken to make sure that that, or to minimize the chance of that particular breach happening again?

And I always said people look on your data breach register like you would an accident book. You wouldn't fire somebody for cutting their fingers three times in a week and putting it in the accident book. So don't fire somebody for three minor data breaches in a week. Do the training that person needs—enable them to stop making all those data breaches.

Next one: beware of the showroom. And this is something which the ICO has now started doing. They're equipping their inspectors with body-worn cameras. And so they can go into, for example, a car showroom, attract the attention of one of the people sitting at a desk. I stood up at the car. What they're actually doing is they're filming what that person does when they stand up from their desk. Do they actually lock their PC or their Mac or whatever they're using so no one can see what's on the screen? Or do they just walk away and leave the screen open to everyone?

Yes, which is a breach. So again, just be aware that they're now doing that. So just be cautious. If you or your clients work in that environment, do make sure whenever you stand up to serve somebody, you're locking your screen.

And the final one—and this is recent, structured. This only happened on Wednesday. The ICO has now approved the new UK standard contractual clauses. So if you are sending data outside of the UK—whether that's to the EEA or outside of the EEA—then you need to include the new standard contractual clauses as an addendum to any data processing agreement.

If you have an existing agreement that's already in place, there's a honeymoon period of 18 months to actually get these new clauses into place. However, if you have a date of processing agreement there's not yet been agreed and signed, then you need to get the new clauses into it straight away because the honeymoon period is only for pre-existing contracts that are already there.

So in summary, can you do all this yourself? Well, yes you can. But I would say that, rather like if you try and fix your car by getting the hangman's manual, don't be surprised if when you put the engine all back together you've got a bolt left that you've absolutely no idea where it goes. And so yes, you can do it yourself. But sometimes it's better to get some professional help.

I'm obviously going to say the best person to get professional help from is me. I've worked in cyber security since 1997. I've specialized in GDPR since 2016. I'm presenter and producer of the GDPR Weekly Show, now officially the number one GDPR podcast worldwide. I'm the author of a book called GDPR Made Simple, which you can see there, which is available now on Amazon. And I'm managing director of Ensurity.

So I hope that presentation has been useful. And thank you very much. You and I will end this photo and then back to you.

So yeah, thanks Keith for that. That was really, really insightful. Yeah, a lot of information there to kind of take in and think about. So I had a couple of questions. Maybe I don't know. With so just with regard to all those GDPR requirements, who exactly does what size of company does it apply to? Absolutely everyone from—well, I say absolutely everyone assuming you've got clients or you've got staff, then which most companies have because otherwise how do you make any money—then it applies to you.

So the sole exception, probably I didn't immediately think of, is somebody who practices trades in stocks and shares and they do it all themselves and they don't, you know, there's no one else involved in the company at all. Then yet, they probably wouldn't apply to them. But we were everyone else? Yeah, it applies. It also applies to charities and organizations like that. So it's important to think it's not just business. It's any organization which is holding data.

So if we're going to talk about some of you mentioned data retention policy, so different types of—if we've got customer names and contact details or supplier names and contact details—are there generally sort of acceptable time periods? I mean, most things are generally accepted to be six years or, you know, which falls in with accounting things, of course. But some things aren't. For example, the accepted period for keeping details of job applicants who were unsuccessful. But you know, sometimes you might have people apply for a job, you'd give somebody a job. But you keep the details of other people. Do you think it'd be useful to keep them?

Transcript generated from the video's captions.