Pointless Compliance: Who cares about data protection anyway? With Nathan Heyes

Good afternoon. So this week we are speaking to Nathan Hayes as part of Buoy Consulting. So maybe Nathan, do you want to just give us an overview? Who you are, what do you do?

Yeah, so I'm well, thank you for having me. I'm obviously Nathan. I'm a Senior Data Protection Consultant with Buoy Consulting Limited. We're based in, not always so sunny, Cornwall in the UK. I've worked in data protection for the best part of 10 years now. I'm very much and genuinely enjoy doing what I do. I enjoy helping businesses to achieve compliance with data protection rules. Most people probably wouldn't say that, you know, "Oh, data protection is my dream job that I want to get into." Is that how you started off? What's your journey been like?

Oh, I fell into data protection entirely by accident. So I was getting towards the end of my second year at uni down here in Cornwall, gearing up for my third year, and noticed that my employment law lecturer had left the university and set up a GDPR consultancy and was looking for people to help out with that. So I reached out to her and said, "Can I be of any help?" and she said yes. So I shadowed her on a couple of GDPR audits—as they were, we call them data protection audits now, sometimes GDPR audits still, depends—same difference I suppose. And then very much got thrown in at the deep end conducting GDPR audits on various different organisations. So chocolate factory, multi-academy trusts, I did a slaughterhouse—or to be a little bit more PC, yeah—you know, so that's where it started for me. And I found that obviously I did a foundation degree in law because I was interested in law and still am interested in law. And obviously data protection is a piece of law, so I was inherently interested in it anyway. And I found that I really really enjoyed it. And I think being thrown in at the deep end sort of accelerated my excitement of it and the interest of it quite a lot to be honest. So I found that I really really enjoyed it and I still do after nearly 10 years.

Yeah, that's really good. That's really good. I think that's true with quite a lot of maybe compliance professionals find that they've fallen into the role. But all seem to really, you know, thrive on it. I hear some people say, like you, you know, some people think you have to be a certain kind of person, but I think once you really get into the detail and kind of see how it, where it really matters, that's then when people get more passionate.

But that's yeah, but that's good. You were saying—oh sorry.

Yeah, that's okay. No, I was just going to say yeah, perhaps that's true for some people, perhaps it's not. I don't know. For me, I mean, when I was younger I wanted to be an electrician and join the army and all sorts of different things, you know. So things changed as I got older and I've just found that I've not just got a job anymore. I've got a career. So, you know, it's just the way it works.

Yeah, no, excellent. Cool, no, great. So something you touched on there was about the change from it being GDPR to what did you call it? Data Protection Law?

Data protection, yeah. So data protection is a bit more all-encompassing. So the GDPR is one piece of law that's part of data protection. But in the UK we've also got the Data Protection Act, which is stemmed from the GDPR and it includes certain exemptions in the GDPR. So the GDPR, basically when it was first written from an EU perspective—and obviously still exists in the EU in its almost original form, there have been some minor changes over the years I suppose—allowed for member states of the EU to make their own decisions about certain things. So, you know, like the age of consent was recommended to be 16 but can be 13. So in the UK it's currently 13. So that was a piece, you know, a little bit of an area where the GDPR said member states can allow for a little bit of variance in that. So there's certain exemptions that are variant as well.

Now it's a bit different, obviously, since Brexit. We've got the UK GDPR, which for all intents and purposes is almost identical to the EU GDPR. So there's not really huge difference there. There are a few different things, but nothing too complicated.

Sure, sure. Okay. And I suppose, yeah, no, I guess, and I guess on, you know, if you were to say or explain what what's really encompassed by it at a top level, because most people don't know, you know, I suppose I think it's—well, I, it's my information like my email address, my name and address, being, you know, obviously I don't want that shared with Tom, Dick and Harry. Absolutely. And people see, you know, websites these days, all you see is cookies at the beginning, you know, having to accept various cookies and so forth. I mean, is that the core of it or is it a much—I'm sure it's a much bigger—yeah, it's much bigger fish than just someone's name and email address and cookies.

So cookies are actually, and the use of cookies, are actually regulated by a different law, which is the Privacy and Electronic Communications Regulations, which we call PECR for short. So although the two—you know, PECR and the GDPR stuff sits side by side and goes hand in hand—there are differences and they do regulate different things. So people that do a lot of marketing need to consider PECR essentially.

The GDPR and data protection ultimately stems from the fundamental human right that we all have for the right to respect for a private and family life. So data protection law, which includes GDPR, obviously helps to protect that right and basically says that any business, regardless of size, sector and industry, has to protect people's personal data at every level okay in the best way as possible. What that looks like for each business is different. And the GDPR is what's called a principles-based law. So a rules-based law would be "you must do this, you must not do that," for example. Whereas the principles-based law is very much, "here is a set of principles that you need to follow, but you've got some freedom in how you do that."

Okay, but I suppose in that, there's still an expectation you must have done something.

Absolutely. To demonstrate you're complying with that principle. You've absolutely got to demonstrate compliance. And one of the key themes of the GDPR is accountability, which basically means businesses should be able to demonstrate their compliance with the other principles of data protection or the GDPR specifically.

So if we were to kind of drill, you know—I think you alluded to earlier about electricians and so forth—you know, if you were to speak to one of those, then they would probably think, "Well, what's it got to do with me? You know, I'm Joe Blogs and all I do is fit lighting all day. How would that apply to it?" Like, what would be—is there an expectation or no? There is, there is an expectation for every single business in the UK, regardless of what they do, who they are, how big the business is—whether it's one person or a million people and everything in between—of course to comply with the GDPR. Okay.

And do you have any example of what that might look like for sort of Joe Blogs and Sparky?

It looks, it looks the same regardless of who they are. So there's no variation. It doesn't. The GDPR doesn't allow for sole traders to do less, and it doesn't say that bigger businesses have to do more. They may do more inherently because they do different things as a bigger business, perhaps. But there's nothing in the GDPR that specifically says you have to do—you only have to do this if you're a sole trader. You've still got to follow all of the principles and comply with all of the principles regardless of size. It doesn't technically look any different. It will look different because every business will do things differently.

Yep, okay. So that might sound quite scary then to, you know, say some of our listeners who thought maybe it didn't apply. But in practical terms, yeah, you know, in practical terms, say it was me and you owned a small electrical business—um, yeah, we had a number of different customers ranging from domestic and commercial. Um, yeah, you know, what type of data exists that's considered personal that I might need to be controlling?

So the definition of what constitutes personal data is quite broad. For the most part it's going to be names, email addresses, home addresses, phone numbers—that's going to be the core data that most businesses are going to process. But it can go further. There are little things as well, around a postcode on its own, can't be personal data. An address, an entire address on its own, isn't necessarily personal data unless it's linked to a name, then it becomes personal data. I see.

Okay, there are little things like that. I mean, a lot of businesses won't necessarily understand what GDPR is and what it's all about, let alone understanding those little nuances from within the GDPR and other data protection law as well. Which for me is where the fear comes from around whether they need to comply or not. It's just a lack of understanding. And it's not necessarily their fault that they don't understand it either.

Yeah, yeah, no, true. Because I think it's, you know, with going into business is a tough job in itself. But to worry about, you know, all of these things where you're worried about "well, if I don't do this thing correctly I'm going to get fined," but the time to spend investigating that, you know, you've still got a business to run at the end of the day. Yeah. For sole traders, you know, particularly trades people, they're out and about, you know, probably 8 till 6, if not longer, five, six, maybe seven days a week on the tools, so to speak. Which means have they got an awful lot of time, you know, aside from doing quotes, invoicing and things like that? Have they got loads of time to be focusing on data protection and other things as well, you know? It's not just data protection. Businesses have to comply with lots of other things as well. But beyond my areas of expertise, of course. But you know, it's still there. It doesn't mean they don't have to comply with it. But have they got the time to do it as well?

Because it's not—I mean, complying with data protection law is not a simple process. And a lot of people, um, you mentioned earlier about tick-box exercises—data protection is not in any way, shape or form a tick-box exercise. It's a journey. And unfortunately, it's a journey that will never ever be end. It's one of those things. No business will ever be 100% compliant. And that's okay. That's accepted in the industry. And that journey is made up of a lot of tick-box exercises along the way. But in and of itself, it's not a tick-box exercise. It is a journey. And sometimes that journey is rough and hard, and other times it's smooth and easy. But organisations like us exist to guide businesses through that, along that journey, along that road, and make try and make it as easy as possible for them.

Have you got any, um, scare stories, but any sort of really bad examples of, you know, the consequences of ones who haven't taken this seriously?

There are lots. There are lots out there. I think that quite a lot come out of the EU more than the UK in terms of enforcement. A lot of the, um, what we call data protection authorities or supervisory authorities—so in the UK we've got the Information Commissioner's Office or the ICO—or all the EU member states have one as well. CNIL is the French one, for example. There are obviously loads whose names I cannot remember or just do not know. But, you know, I think some enforcement agencies, some regulators, are a lot more on it if you like, so to speak, and will find organisations for—I want to say smaller things than just big things, you know. And that might not necessarily be the right way of phrasing it. But ultimately, as I've mentioned already, GDPR requires businesses to be accountable and to demonstrate their compliance. And if—usually a supervisory authority will get involved if something's gone wrong. So they've had a data breach that's been reported to them, or someone's made a subject access request and they're not happy with the response, so they complain to the supervisory authority who then get involved. And because they're involved, they dig a bit deeper. Most of the time in the UK, the Information Commissioner's Office will order businesses to do things so that they can then demonstrate compliance rather than just find them straight away off the cuff.

Hmm, but I imagine—and I don't work for the ICO so I don't know how they operate in that sense—but I imagine they do that because they don't want to scare businesses into thinking they're going to get fined. It's probably more a case of "look, we'll give you an opportunity to correct what you've got wrong. If you don't correct it, we're then going to fine you." But there are instances as well where businesses have made—and this is in the UK—like millions and millions of what we call unsolicited marketing, and they've been processing data without the correct lawful basis and things like that, where they've been fined substantial sums of money.

Okay, and I mean, so I mean, some people use, for example, mailing lists that they might have purchased online. Is there—is there a—I mean, there's an inherent danger in that. But are there any sort of good practices that one can put in place to help?

There's nothing that stops businesses purchasing mailing lists per se. But they, if I had a business and I wanted to purchase a mailing list, I would, in terms of GDPR and data protection, be looking to make sure that the peoples whose names appeared on that mailing list had given consent to the original owner of the mailing list for that mailing list to be sold.

Okay, is there a way then, you know, you're also doing that, or—well, yeah, before you even collect the data as a business, if you're looking—if the law, the only lawful basis is not always consent. So there are six lawful bases that businesses can use to process data. When businesses use consent, consent has to be very, very clear. It has to be specific and explicitly given, and it has to be opt-in. So there can't be any sort of implied or inferred consent. It has to be "yes, I consent to this happening," okay, essentially.

So if I was asked, "Do you want your email, name and email address to be on our marketing list?" and I said yes, that's fine. And that can be a tick box. It can be another method. It doesn't matter so much as long as it's clear and explicit. And again, has to be demonstrable by the business that's obtaining the consent from the individual as well. So they have to be able to demonstrate they've received that consent very clearly.

But then they could also ask me, "Are you happy for us to sell our mailing list to other businesses so that they can send you marketing communications?" If I said no, then my information can't be on the mailing list that gets sold. If I said yes, then it can be. But it has to be very clear what my personal data has been used for and what I'm giving consent to. It has to be very, very clear.

How much would you believe companies are doing that? So even if they're asking for that on their website, how much do we believe they're really—do I? Personally, I don't believe the vast majority of companies that buy and sell mailing lists are obtaining the proper consent. I obviously can't—I'm not going to tar everyone with the same brush, you know. There will be businesses that do have those practices that do absolutely do everything by the book. But there will also be businesses that don't do anything by out of the book at all. And there's probably some businesses in between as well.

Yeah, yeah, and I think the whole stigma of it is that everybody believes their data being stolen and used without consent anyway. That's like almost the state of sore that you're trying to build from.

Yeah, yeah, it makes things difficult sometimes. So if we go back to our electrical company that we've got—so what, um, you know, I suppose say we got to the end of the year and we wanted to approach our customers with a special offer or we've now got these, you know, a different type of service that we now offer—where does it fit in terms of our rights to go and contact them to offer that?

There are several avenues we could go down. So firstly, that would be a marketing communication, so yes, GDPR plays a part, but also you've got to look at PECR, which we discussed earlier, that plays a part as well. So if we wanted to send marketing communications to our customers, we would ultimately want them to have given us their consent for us to do that. However, there is in PECR—it's not explicitly called the soft opt-in in PECR—but it's known as what's called the soft opt-in. So if you have a customer and you meet certain requirements, which I'll talk about in a minute, you can then send marketing communications to said customer without their consent if it's about your own, same or similar products or services.

So okay, if we were offering electrical installation only and then we wanted to say, "Oh, look, we can now do electrical inspection and testing," that's same or similar. So we could market that under the soft opt-in. If we said, "Um, oh, we're also going to start selling fridges and freezers," that's too far away from the original service that we're offering. So we couldn't do that under the soft opt-in.

Coming back to those requirements to be able to rely on what we call the soft opt-in, you have to give customers the opportunity to opt out of receiving those further marketing communications before you send them. So if they opt out, then obviously you can't send them. And you also have to give them the option to opt out in every communication you send to them, which is why you get your unsubscribe links in emails.

Okay, okay, yeah, essentially. So it's just again, it's one of those nuanced things that's there that not a lot of businesses know about.

Potentially, the lawful basis stops being consent and it becomes legitimate interest. So it's in our—a legitimate business interest to do that. But then if a business relies on legitimate interest for processing data for any reason, they also then have to complete a legitimate interest assessment to make sure and evidence and show that their legitimate business interests outweigh the rights and freedoms of the individuals whose data they're processing under that lawful basis. So again, there's you—yes, you can rely on doing that. But there's more work that goes with it.

Okay, as a legitimate business interest, that we need to obviously retain their information as for things like invoicing and things like that—that would be under the lawful basis of contract because you've got a contract in place. It doesn't have to be written. Of course, in the business world, contracts aren't a necessary requirement, and you don't have to have a contract in writing. Contracts can be verbal, although it's obviously much more difficult to enforce a verbal contract. Contracts can be verbal. It doesn't have to be a physical "this is a contract" document. It can just be emails and text messages, for example, could form part of a contract.

So yeah, there's an engagement.

Yeah, absolutely.

Yeah, okay. Definitely. So, so I mean, I guess talking because, you know, we want we want our listeners to understand how this impacts them regardless of what size—so I mean, if we go, you know, something that many do is then referrals. So I'm going to refer, um, another service or maybe option, or you know, say I've been in talks with Margaret—Margaret said that she's looking at, for a conservatory or whatever—and then we we end up speaking to our builder. "Oh, Margaret looking for a conservatory here, contact that"—would be in breach of GDPR if we kind of did that without any prior consent?

Technically, it could be in breach. You would want Margaret's consent to pass that information onto our builder. So, "Hi, Margaret, um, are you happy for us to speak to our builder about you wanting a conservatory?" Uh, yes, that's fine. Okay, then you go and speak to the builder.

Okay, and so in that case, you'd probably want to send that in an email rather than a conversation because then you've got that record of her saying yes, that's fine.

Okay, yeah, that's what I was just going to ask. Is that—and what would your responsibility be to our builder, you know? Do we have to ensure that he's—now, because there's that knock-on, then isn't it? Is now he's got the ability to pass that information on to someone else?

Yeah, so he becomes controller in his own right when he takes on that job if it's his own separate business. So we share that data with him. Yeah, so you talk me through because there's there's a data controller and there's a data processor. Is that—yeah, so there's different relationships.

So your data controller is an organisation that determines the means of processing. So you're direct customers—you're the you're the data controller of your customers' data. However, okay, you've got a CRM system that you put your customer data into—let's use Zoho as an example. So you've got Zoho CRM or bins like a stripped-down CRM that they offer, whatever it is you use it—it could be anything: HubSpot, your name it, Salesforce, whatever—they are the data processor because they're processing your customer's data on your behalf, okay, essentially.

But you can also have joint controller relationships. So that's where two data controllers jointly decide the means of processing. And then you can have a controller-to-controller relationship, which is where a data controller passes the information onto another data controller who then also determine their own means for the processing.

I think—well, it depends on the business. So a lot of the time an accountant would be a controller-to-controller because you're the controller of your employees' data, but you're passing some of that data to your accountant for tax and accounting reasons. But they also have their own reporting obligations that they have to abide by, which would then make them a controller in their own right of that information.

Okay, I see. I see. Some people might argue they're a joint controller. Depends on who you speak to.

Okay, and so with our example to the builder, he becomes a data controller. But is there any expectation on—yeah, on us—as to what he does? Or that's all his own?

So when a data controller shares data to another data controller, it's not quite as strict as it is with a controller sharing to a processor. So I'll come on that in a minute. So when you're sharing data to a data controller, you would want to probably do a little bit of a research on the other controller to make sure that they're not going to start doing anything they shouldn't do with it. But once you share the data with them, they're then responsible for their own compliance just as much as you are for your compliance.

Whereas if you share with a data processor, you need to do due diligence on them to make sure that they are compliant with data protection law because you're still responsible for that data even though they're processing it on your behalf. The data controller is ultimately the responsible party.

Okay, see. So if something went wrong at the data processor's end, the data controller is still responsible for that, although if the processor can be shown to be at fault, it can mitigate the controller's liability potentially up to 100%. But not likely, because if something's gone wrong and it's found that the processor is non-compliant and you've not done your due diligence properly on them to make sure that they're compliant, then obviously you're in trouble for not doing that in the first place.

Okay, okay. Yeah, so I guess that's what that kind of applies to—for example, we're a software business. So one of the purposes of the software is that other companies load their data into it and that can be client's data or their own data. So we're processing it. But we obviously have to have controls in place that that data is secure the entire time they're processing.

Yeah, yeah, so you know, things like encryption—I'm not a cyber security expert by a long shot. But you know, things like encryption—it's good if you've got ISO 27001, help. Cyber Essentials or Cyber Essentials Plus are all good credentials to have to show that you are taking security seriously and you actually have got controls in place to enact that security as well. So that's what we look for when you do due diligence as a data controller on a processor. You want them to show you that they've got things like ISO 27001 in place, like they've got SOC 2 in place perhaps, they've got Cyber Essentials in place because then you can see that they're taking things seriously.

Okay, okay, yeah. And you can see that amongst other things, of course. But yeah, a lot more people expecting, you know, Cyber Essentials at a minimum across sort of business.

Absolutely. Yeah. So businesses, private sector businesses that want to work with any sort of government and public sector bodies, um, are most of the time required to have at least Cyber Essentials in place now as a minimum. Someone will require Cyber Essentials Plus, and then someone will require ISO 27001. Otherwise, you don't even got a look in when you're tendering for contract.

Yeah, yeah. And, um, no, that's that's really useful, um, to to understand. Is there, um, is there like a not-a-quick file list—that's the wrong phrasing—but is there a sort of top hits that if you were starting a business tomorrow you'd want to ensure you have in place to kind of get on the right foot?

Technically, you need everything in place. And there's, uh, part of data GDPR is what's called Data Protection by Design and by Default. And that is quite often misconstrued because it seems to be geared towards, if you're implementing a new piece of software, for example, you'd want to follow data protection by design and by default in so far as you're designing data protection measures into that system and data protection is the default setting for everything—like the highest security setting obviously. Users can reduce that setting down if they want to, but it should be, by default, the highest setting when a user first starts using that platform. And that's how it seems that data protection by design and by default is geared. However, if you really look at it, it technically means that a brand new business should be designing data protection into their processing, into everything that they do from the get-go.

I see, okay, yeah, great. So and it's not just about having a privacy notice on your website. I prefer the term privacy notice, could be a privacy policy. The GDPR calls them fair processing notices. So you know, multiple names for the same thing. But they all achieve a purpose. But you know, it's not just about that. And whilst it might make you look externally like, you know what you're doing if you've got a really good privacy notice on your website, that's not to be all and end-all. And it's what happens in the background as well, you know. Data subjects—so people whose data has been processed—don't see all the policies and procedures in the background that make sure that their data is safe.

So what would you suggest sort of creating, um, you know, are there any terms for documents, spreadsheets and stuff, you know, what what would you suggest the company starts with?

Uh, I'll give you a non-exhaustive list so of what, so there's what we call mandatory documentation. So you need privacy notices. You don't have one; you have several. So you wouldn't include all your customer stuff—what you're doing with your customers—in your employee privacy notice. You wouldn't put them together. You'd separate them out.

Okay, so on your website you would have a privacy notice that goes: "If you visit our website we get your IP address and your MAC address, for instance. If you fill in a form on our website, we'll get your IP address and your MAC address, but we'll also get your name and your email address, maybe your phone number—depends on obviously what the form is that's been filled in—and we'll get your query." If you then become a customer, we've got all of this extra information about you as well. And then you'd have your employee privacy notice—says we've got your name, your address, your bank details so we can pay you, where you collect your passport for right-to-work checks, which you've got to do—you know, there's lots of different things to consider there.

You need a data protection policy, which shows—and it's not necessary. Data protection policy isn't necessarily a public document. It's more of an internal document. But that sets out how that business is going to comply with the GDPR. So "this is what we'll do to comply with the principles, this is what we'll do to comply with data subject rights." So a lot of businesses—and I see this a lot—they will have a policy and a procedure around subject access requests, which is where a data subject or an individual can request what information is held about them from a business. And that's what's called an absolute right. So every person has got the right to request access to their data from a business who processes their data.

But then you've also got, uh, the right to erasure, for instance, which is sometimes known as the right to be forgotten, which is where a data subject can go, "I want you to delete my data." Well, that's what we call a qualified right. So if the business has got a continuing lawful basis to process that person's data, they can then go, "No, I'm not deleting your data." Obviously, you wouldn't be quite so blunt like that. But you know, but—and what, just as an example on that, have you got an example of where that might apply? Like, somebody wants to have their data removed and the company says no?

So I imagine if the right to erasure was an absolute right, every single person in the UK would immediately make a right of erasure request to all the debt everyone that they owe money to and ask them to remove their data. And then everyone will be debt-free, which is why it has to be a qualified right rather than an absolute right.

Um, okay, so there's lots of different scenarios, and it's difficult to sit here now and talk through everything. It sometimes you've got to—because the context could be very, very different from one client to another—so sometimes it's a matter of looking at what's in front of you and going, "I know the law, I can see the situation, this is how we should proceed."

I guess the thing is that maybe the question that people might ask is yeah, are they ever going to check up on me like, who's who's going to know? And is who gonna check up on me is the question?

I don't know. So I suppose like the ICO—so, yeah, you have to—the ICO and yeah, data controllers do have to register with the ICO. And the there is—I can't remember if it's been enacted already or if it's in the process of being enacted—uh, the government have basically put forward legislation for the ICO to increase their fees for data controllers by almost 30%, which—okay, so data controllers, when they register with the ICO, uh, there's three tiers of fees.

So tier one is for you, charities, not-for-profits, and you know, micro businesses. It was only 40 quid a year anyway. So 30%, it's not a huge jump on that, but it's still, you know, almost a third increase. So still quite a bit. Then you've got tier two, which is for slightly bigger businesses. And I think that's 60 quid, off the top of my head, or was. And obviously, 30% on that, then you got tier three, which is for your big players, and that was 2,900 pounds a year. So that's jumped almost a grand, yeah, for them. But they've probably got the money to pay it, so in the grand scheme of things, it's an annual charge. It's not huge.

Am I impressed that the government are increasing cost to businesses not particularly? But um, that's that's a story for the other day.

Yeah, what I mean, what what is that for? So do you know who must register with the ICO?

Every data controller—every business that processes personal data—and less you're processing core data. Um, the definition of which I can't remember 100%, so I don't want to say it and get it wrong. Um, but there are very, very limited circumstances where a business won't have to. Aside from not trading and not actually having any data, there are very limited circumstances where a business doesn't have to register with the ICO. But I would say 98, 99% of the time, you do. Most businesses in the UK are micro and small businesses. So they're only going to fall into tier one anyway. So it's not expensive just to have that little safeguard in place if you like.

I suppose something that a lot of companies or people won't know before starting a company is the ICO—does the ICO get in contact with you as soon as you've registered?

I mean, what about sole traders?

So it's difficult with sole traders because there's no way of tracking them. But I do know that if you start a company—so obviously, you register a company with Companies House—um, before too long, you will receive a letter from the Information Commissioner's Office saying, "We've noticed you've got a company. You need to register with us as a data controller, unless you don't need to." And there is a form on the website that you fill in, and you go through some questions that shows you don't need to be registered as a data controller if you don't need to be. And then you send that off, and they leave you alone.

Yeah, if you don't respond to the ICO about your whether you need to register as a data controller or not, or they think that you do and you don't register, uh, you can be fined. I think it's about four grand.

Oh, well, yeah, that's quite significant. I think we had—I mean, someone starting a business it would be—yeah, yeah, and I mean, you know, we we, we've been around for a little, for a few years now. But, um, it was the same with us. You know, we got the letter through, and the first thing we did was start Googling, "Well, who are the ICO? Are the ICO asking for money? You know, yeah?"

Absolutely. There's a lack of a huge, huge void of knowledge and awareness, um, across the whole country about data protection laws and who the Information Commissioner's Office is and what they do, essentially. And what is their job?

So the ICO's job is to regulate data protection law in the same way that the Health and Safety Executive regulates health and safety law. That's the easiest way of explaining their broad job. Uh, but they can also enforce—as the HSE can—they can enforce and prosecute in their own right for breaches of data protection law, which is where the fines come in. There are some circumstances where data protection law breaches can be criminal as well. So if people are doing things knowingly and purposefully, it becomes a criminal act. And again, the ICO can prosecute for that as well.

Okay, that's essentially there broadly speaking what their role is. There are—they also regulate freedom of information and environment regulations as well.

Yeah, I guess if you, you know, if you spoke to two people on the street and you asked which was more important: HSE or ICO? They probably—a not guarantee—they say, "HSE," yeah. Whereas essentially what you're saying is they they stand on the same footing. It's just for different—yeah, regulations. Yeah, absolutely.

Fair. No, that's that's something good for our listeners to know. But I mean, you know, trying to reduce the kind of stress and anxiety that it might be causing some—kind of just here inherently—does, you know, what, you know, we were talking about things that they might want to start doing—so privacy policies—yeah, I suppose quite straightforward. Maybe the thing people didn't realize was that that's not just for your website. It actually applies to your your staff and how you use.

Absolutely, yeah. And there are potentially other areas where you could have a privacy notice as well, depending—depends on what you do basically.

So is there, um, so is there a best practice way of kind of capturing people's data then, um, and what's the best way of keeping it secure? I guess do you have any suggestions?

It's going to vary from business to business how data is captured. You know, so Jo—Joe Blogs the plumber is probably going to have a piece of paper he writes everything on. He might have, uh, an accounting system whether he uses that system directly himself is a different question. They may, they may not. They may have a bookkeeper or their partner at home might do it, you know. So it just depends.

Um, so there's no best practice way to actually collect the data as such. Um, in terms of security, it's about—I mean, if you're at home, you could argue that your home's quite secure anyway. So you know, and if it's left on your desk and you're and your wife, you're and your husband, whatever, in the business, you've not got any kids, then the data is pretty secure just being left in as bits of paper on the desk. There is potentially an argument for that. I don't like the idea of that personally, and I would never advise that as a good course of action, of course. Um, but there is an argument now to suggest that it is almost safer to have your password written down because you can't hack a piece of paper.

Yeah, yeah, unless it's the same password for everything.

There is that. In some context though, you know, if you were in a big office and you had your password stuck on a sticky note on your screen—which I've seen—then you know, you couldn't, you couldn't prove that argument at all. But if you worked from home all the time and you had a little notebook and it was put in a cupboard out the way, you could argue that that's more secure than having them stored on your computer or elsewhere, potentially. But I don't know. There's again, there's no one right answer in terms of security. And it will depend entirely on the business and how—and how big they are as well. So you know, the bigger businesses will need to have much more stringent security measures in place.

But again, coming back, you know, encryption is always good. If data is encrypted in transit and at rest, that's always good. Yeah, because then, if it gets picked up without the decryption keys, it's just useless nothingness, essentially.

Yeah, um, you know, there's things like access controls are important in businesses. So only giving access to data based—I mean, be role-based. It could be rule-based. So this employee meets this set of rules, so they can access this set of data, or this employee's got this role, so they can access this set of data. Managers can obviously access a little bit more. And then, you know, head of department can probably access more again. But no one person should ever be able to access all data in a business.

Okay, I suppose it's also then considering, yeah, you know, where they're accessing it from and through what means. And I mean, I, you know, there was somebody told me about a story of—they were told by someone that, you know, even computer screens facing a window, they need to be careful of—privacy screens on the mirror, privacy screens, either on the PC monitor or on the window on the glass—you, the sticky stuff you can put over it. It's it's something to consider.

Absolutely, yeah. Yeah, I, if you're, yeah, especially if you're, you know, a data centre, you've just got customer logs on your screen the whole day, then it's high risk.

Yeah, yeah, yeah, yeah. But then that's that's another element of data protection law is risk as well. What's the risk of processing this? That has to be considered. So you do risk assessments on things. And it's like, what's the risk of processing someone's name and email address in an encrypted server that's on-prem—as we call it, so on-site—in a locked room that's covered by CCTV? It's quite low.

But and then we do as well, data protection impact assessments are a special kind of risk assessment. So every business in theory should do what's called a data protection impact assessment screening questionnaire if they're looking at a new process activity. Which then the answers given to that screening show if a full—we call them DPIAs, data protection impact assessments—if a full DPIA is needed. And that's your full risk assessment based on that. So if there's any potential for the processing activity to be high risk, businesses should then do a data protection impact assessment on that, which then shows how they can mitigate that risk or completely alleviate that risk potentially. And can you, can you give us an example of what like new type of processing you mentioned? You know, if they're doing any new processing?

Yeah, so it could be something—it could be migrating from one accounting or CRM system to another. It could be we've, you know, discovered the need that we now need to process this set of data in this different way. So that could be an example as well. And again, it comes back to data protection by design and by default as well.

I see. And then due diligence, if you're going to be using a data processor. So I suppose like our electrical business we we might have just always been capturing data for just general, yeah, customer contact. But now we want to look at marketing to them. It's a different, yeah, purpose for the data. And it becomes a different—it becomes a different kettle of fish. And technically, you technically can't process someone's personal data for a different purpose, okay, without—if the—if it's compatible with the original purpose, then there is a bit of a workaround there. Um, but if it's completely different, then technically, you can't do it. You've got to go through the whole process again of making sure that you've got a lawful basis, that your purposes are documented and defined, and you've got everything else sorted for it too.

So if you had a thousand customers on your books, you couldn't—you would have to get, uh, what's the word—confirmation, um, consent, consent, consent from them before you even started, um, yes, yeah, okay, yeah. You couldn't just send the marketing communications. You'd have to get the consent first, unless the soft opt-in applies, of course. But the answer is if you've not even considered marketing until that point, you've not given them the opportunity to opt out of the soft opt-in in the first place. So you can't use it anyway.

Yeah, so I guess good—because I mean, you know, people starting out businesses, ensuring that they've got those systems in place before they get their first customers—best.

Yeah, yeah, absolutely. Because then you've got everything there and it's to hand. No, no good. No good.

Um, yeah, I it sounds you've, you've definitely had a lot of experience in data protection. Sounds like you, you kind of know it like the back of your hand. That's been around the block several times. Yeah, that's good. That's good.

Yeah, um, there's probably a bit that a lot that I still don't know. But and I won't necessarily know it until I'm in front of it in the right context with the right business. But I can then apply my knowledge of the laws and regulations to this particular scenario and provide an outcome.

And is that what you're doing currently with Buoy Consulting?

So Buoy Consulting is a privacy and risk consultancy. So as well as offering data protection services, we offer services around ISO certification, predominantly 27001. So we can carry out implementation, internal audits on ISO 27001, um, and gear businesses up for their external audits, their certification audits. And I believe as of date, we have got a 100% success rate with that. You know, yeah. Um, in terms of data protection, uh, because obviously, that's what I, that's my focus—data protection—um, and obviously the PECR stuff as well—alongside that, uh, we carry out audits and gap analyses on businesses, and we do consulting and we also offer an outsourced data protection officer service as well. So I'm currently a named data protection officer for three clients. I've got three to four clients that I'm running consulting projects with at the moment, and I've got several audits ongoing, or upcoming rather.

Okay, typical, yeah, yeah. And is there a typical trend that you know? For example, I mean, I'm an aerospace assessor. That's my background. Um, one of one of the critical elements that we always find is in terms of non-performance, corrective actions, um, following up on the effectiveness, it's it's always a problem area for root cause. In aerospace specifically, it's human factors-related issues as well, yeah. Um, so trying to address those, which most companies always fall foul on. Um, another area is probably counterfeit product, okay, interesting. Is, yeah, yeah. Um, we're just companies haven't considered or they've they've kind of tick-boxed it. So they've they've done maybe what the standard expects at a minimum level, but they're not considered how it really applies to what they're providing.

Okay, yeah. Duh, it, yeah, do you find the same similar?

Yeah, I think in terms of root cause analysis for for why there are um non-conformities, shall we say, there it's probably lack of the regulation, lack of knowledge, okay, most of the time it's lack of knowledge. Or sometimes it could be that they've—I mean, during the what I call the GDPR boom—so late 17, 2018—um, there were lots and lots and lots of people popping up as GDPR consultants. And I imagine most of them probably aren't in business anymore and probably never knew what they were doing. There will be some still out there that maybe didn't know what they were doing at the time, but have probably progressed and now potentially do know what they were doing. Um, but I think uh businesses have probably inherited from other businesses like that, you know, these pop-up consultancies. They "Oh, let's jump on this bandwagon because it's going to be lucrative." They've probably inherited some really badly written policies and procedures that aren't worth the paper they're written on, I want of a better phrase. And then they just sort of run with that because their knowledge is lacking, and they think, "Oh, this person is an expert in GDPR," and it's like, "How? In 2018, when the GDPR's only been around for two years and isn't even—in any possible way—how can anyone be an expert in it? Well, you can't, essentially. Or not at that point, you couldn't be."

But I think, yeah, you know, and some businesses have probably had a stab at it themselves, you know. They've probably updated old data protection policies from the Data Protection Act of 1998 and hoped that they would bring them into line with GDPR requirements and probably fell short a bit. You know, a lot of a lot of the time, you find that people working in finance departments have got responsibility for data protection. Don't know why, just sort of seems to be the way it is. The role that gets lumped with a lot of the time, yeah, they sort of—and a lot of people in businesses—and I find this probably 95% of the time—aren't dedicated to that role. The data protection element of their role—they, it's just been dropped on them. It's just another hat they've got to wear. And it's not their full-time job. So they can't commit enough time and resource to it to make sure it's right. That's a problem as well.

Where, particularly, you know, if we were talking about risks, I mean, where, particularly, would you say is the highest risk area for a company? Or again, does it depend on the context?

I it will—is very context-specific. Um, yes, because obviously, again, different companies do different things. And even companies that occupy the same space in the same sector still operate differently to one another as well. So you can't even go, "Oh, this sector does it this way," and that makes life easier. It's because they don't. They're all individual unique companies. So they all do things their own way, and it all be very different. And then company size is a factor as well.

I mean, the biggest risk for data protection is people. Human risk is the biggest risk. And most of the communications we've had from clients is of "we've had a breach." 90% of the time, it's someone sent an email to the wrong person, or they've CC'd 100 people into an email that they shouldn't have CC'd into at all, or they've just done CC instead of BCC on an email, you know. There, the vast majority of creatures that we come across, and it's human error.

Yeah, yeah, that's it. It's interesting. You, I, I guess that's why, like, the aerospace standard, it's looking at human factors to prevent human error. But, um, what is there—some key things that you would say a company should put in place as best practice to kind of mitigate that before it happens in terms of mitigating human error?

Good training and an awareness program will be the best thing to combat human error. When I say good training, I mean training that covers what it's supposed to cover about the GDPR, that training could be scalable as well. So if someone's coming in at a very entry-level position—uh, I mean, everyone's responsible for data protection in a business. Compliance just is. Again, health and safety—everyone's responsible. Um, yeah, obviously, the business itself is ultimately responsible, but everyone's got a responsibility to try and support that. And someone that's coming in at the bottom, entry-level, at the bottom of the ladder, their responsibility will be quite low level. So it's about—rather than giving them a three-hour PowerPoint presentation on, um, you know, really in-depth GDPR and data protection—what they need to do—something a lot smaller and succinct to the point—would be more beneficial for them, especially as they're new to the role. They're learning. They've got a lot of other things to learn as well. So if you flood them with data protection, it's just going to defeat the object.

If someone's coming in at a management level, chances are they've probably already had some sort of GDPR training in another role anyway. Um, but their responsibility is a bit wider. So they would need to receive wider training. Training for data protection and security as well—including security—should always, always be delivered on induction and then repeated regularly. It doesn't say annually. It says regularly, yeah. Most of the time that is annually. Um, but in certain roles, you might want to repeat it quarterly or every six months, perhaps as well.

And then on top of that, supplement training with awareness. So a team's channel—this has just happened in our in our industry in terms of data protection—keep an eye out for it—things like that. Okay. Posters in the office—you've got an office space—put posters up. They don't have to be big and overbearing. It can just be small little simple things that just remind people as they're looking around the office: "Remember this. Don't forget that." Just little things. And it makes—it makes a huge difference. Huge.

Yeah, that's good advice. Anything, um, sort of, you know, if we talking about sort of physical things that have a risk of introducing leaks—so like tops, um, you know, if you've got company phones and devices—aren't necessarily the biggest risk because—okay, if you if the laptop is locked, in theory, it should be encrypted. No one's getting into it. And if the business knows what they're doing, uh, they've got some sort of remote wipe function, and you know, "Jane Doe's—oh, I've left my laptop on the table at Costa, and I've come back out of the toilet, and it's gone." Uh, okay, no problems. You're going to be in trouble tomorrow morning when you get to the office, but tap, tap, tap, wipe it—it's done. So even if they do get into it, somehow, just it's useless. It's completely defunct. Same with phones. Most businesses that that issue company devices that I've come across, my personal experience, have some sort of remote wipe feature on all their devices that they issue. So, you know, if a laptop gets stolen or gets lost, the chances are it's not actually that serious.

The more serious thing in terms of devices is got to be hackers. Um, but obviously, you know, there's a lot of simple steps you can take to prevent that as best as possible. I mean, if someone's committed, you're never going to stop them. There's always going to be a hole that a hacker can get through somewhere. But at the same time, you know, making sure access controls are good—you know, because the chances are that the people with the most important data that they can access are probably going to have more security in place than the people who haven't. And they're less likely to give away passwords and things like that. But it's about making staff—aware, employees. I don't really like the word staff. Staff seems quite detached. Um, you know, it's about making teams aware and people aware that if you've got a strong password—and the current guidance is a longer password that is changed less regularly now—and again, it's all about the passphrases now—make sure there's numbers and symbols in there. Um, for instance, the pound symbol—and I don't take credit for this; I got this up from one of my colleagues—the pound symbol because it doesn't appear outside the UK on keyboard is a really good symbol to include in passwords if you're in the UK, okay? It doesn't necessarily appear on, yeah, and I don't take credit for that advice at all, okay? In my memory bank.

Okay, um, yeah, you know, there's lots of different things. And again, it's contextual to the business. Some businesses expect staff to be in the office all the time, and it's easier to secure an office because it's one place. And if, especially if you've got desktop PCs, you know, they're not going anywhere. So again, that's easier. Whereas if you've got a lot of stuff that work from home—I'm working from home today, for instance—you know, I've got my company-provided laptop with me. So I've got to make sure that no one else can get access to that laptop. Not that there's any people in my house ever that would be like that, but at the same time, you know, I've got to make sure that my laptop's secure, that my internet's secure. And it's little things like change the SSID and password on your router, okay? If you get a new router, make sure that the back of the router—where the password and stuff are displayed—aren't facing the window so that people can look in and see the—people can't look in and see it, rather. You know, so my router's face is away from the window. I've got a different SSID than what it came with. I've got a different password than what it came with, okay?

Yeah, so people can't just jump on it and gain access to it.

Yeah, so it's about—it's about making it difficult for people to hack into systems. And there's lots and lots of little things that can be done that that take very little time and resource to make that easier.