Data protection laws are put in place to protect the data subject, which is the person that the data is about. For example, if we had a record that had my name, phone number and address, I would be the data subject.
It’s all about protecting my PII (Personally Identifiable Information). That could include my full name; address; email address; national insurance number; passport number; credit card number; date of birth; phone number and plenty more information.
We also have what we call ‘related’ information. This is where, the single piece of data would not be enough to identify me as a person. For example, knowing that I am between 25 and 30 years old, is not enough to identify that the data record relates to me, but if you were to link that to other information, such as gender, job title or city, you would know that you’d be looking for a male Big Data Architect in Woking between 25 and 30 years of age. It then becomes possible to identify me as an individual.
If we think about it in the telecoms arena. Knowing someone’s device is a Blackberry Curve 9100 is not personally identifiable information. But, knowing that in conjunction with their age band and city definitely is. There aren’t that many of those devices left, so there may only be one 25-30 year old in Woking using one of those devices & therefore it may be possible to distinguish them from the rest of the customers.
Some examples of relatable information would be:
- First or last name. This would only be if those names were common, like Ben or David. If you have a very uncommon name, it would be PII.
- Country, city, postcode
- Current employer and job title
- Gender
- Race
Finally, we have data which is definitely not PII, which can include IP addresses and cookies.
It’s important that we categorise PII data correctly. If it is personally identifiable, we need to treat it differently to non PII data. We don’t really need to encrypt Non PII data as a customer would not be identifiable, should there be a breach.
What is the main regulation I need to worry about?
This section will provide an overview of GDPR (General Data Protection Regulation), which will give us the principles / guidelines that we need to follow to make sure our customer data is safe.
The GDPR regulations were introduced in May 2018 to replace the Data Protection Act, which was written in 1995. As you can imagine, with rapid advances in the way we are using, sharing and storing data, a data protection policy written 23 years ago isn’t going to cut it.
The purpose of the policy was to give European citizens more control over their data and to prevent companies from misusing that data for things that the data subject (the person the data is about) doesn’t agree with.
At a high level, those guidelines are:
- Processing data lawfully and fairly
- Collect data for a specific purpose
- Only keep what you really need
- Store data securely
- Hold people accountable
Let’s dive into each, starting with processing data lawfully and fairly. This all starts with the data subject giving consent for you storing and using their data. Without this consent, you can’t store it or process it for any reason.
You have to be absolutely transparent with the user and have to tell them exactly what your intentions are with their data. You need to tell them things like: exactly how are you going to use that data?; are you going to share it with third parties? And how long are you going to store it for?
You are also committed to making sure that data is accurate and up to date. If you ran a marketing campaign last year and you know some of the email addresses on your list were incorrect, as people complained. You must rectify or delete those email addresses as you cannot store data that you know to be incorrect.
You must also give the data subjects the means to request that their data is removed or updated to be correct. If such a request is received, you must do it within one month.
You must also only collect personal information for a specific purpose and only retain it for as long as it’s supporting that purpose. For example, if you were Facebook, the specific purpose of holding your information would be to provide the service that you signed up for. Without your email address & password, it would not be possible to login. Without retaining your phone number, the forgotten password process wouldn’t work and without storing your full name, you friends would be unable to find you.
If however, I was a company like a local grocery, there would be no need for me to collect your phone number and email address, before selling you a broccoli. Therefore, collecting this data is not supporting the specific purpose of providing you with the service you requested.
Then it comes down to only storing the data that you really need. First, you need to ask yourself about retention. Do you really need to retain the details of someone that closed their Facebook account 5 years ago? Probably not.
We then need to question whether we actually need all the information we hold. For example, does holding my gender, race and income support you in providing the product or service to me? If you’re a bank, probably – they use this information in machine learning algorithms to predict the likelihood of defaulting on loan payments. If you’re a personal fitness trainer, you probably don’t need it.
It’s important to delete the data that you don’t absolutely require to reduce the risk exposure that you have and reduce the impact of a potential data breach.
Now we get to the technical element of GDPR – storing data securely. Let me give you an example of how not to do this. I used to do some work for an online company and they stored all of their customer and order details in a spreadsheet. That would be fine, but that spreadsheet was on a server, which had no authentication and was indexed by Google. So, all customer details were exposed to anyone that took the time to try and find them.
Clearly, that is an extreme example but it’s a true story and these things do happen. It is our responsibility to make sure that we put appropriate security provisions in place to stop breaches happening. These could be simple mechanisms, like enabling multi-factor authentication and storing our data on Google Sheets (rather than the dodgy web server I described above), or we may choose to implement more complex solutions.
The key thing here is that it must be a reasonable provision. Password protecting those spreadsheets on the server would not be reasonable; it wouldn’t be much more secure than having them passwordless. Equally, investing in a £500,000 system to manage those spreadsheets would be unreasonable from the company perspective – a huge cost. There is a balance.
Finally, we need to hold people accountable. In my mind, this is a combination of the company as a whole, where we must document exactly how we’re using and managing customer data, but also we must drive a data culture in the business, upskill our staff and hold them directly accountable for the safety of customer data. Ultimately, the more individuals in the business that can demonstrate your compliance to the GDPR regulations, the better position you will be in.
Money, money, money
Beyond just doing the right thing for your customer and making sure their data is safe, we also have an additional motivator in the form of huge financial fines. These can be either:
- Up to €10M euros or 2% of annual turnover (whichever is greater)
OR
- Up to €20M euros or 4% of annual turnover (whichever is greater)
Which fine you receive depends on what you’ve been perceived to have done wrong. Below are a few examples of things you can do if you want the biggest fine possible:
- Are not processing data lawfully
- Don’t have consent from the data subject
- Transfer data to third parties without the data subject agreeing
The difficulty with GDPR is, you cannot possibly estimate the value of your fine. Firstly, there isn’t a huge amount of precedent yet – we haven’t seen that many organizations being fined… yet. The second reason is that there is not absolute criteria in place. The behaviour and intent of the organization will be taken into account when calculating the value of the fine.
What does that tell us? It tells us that the governing bodies are well aware the data breaches happen and companies can’t always stop them. So when they investigate, they take into account our intent to comply to regulation.
- Did we drive a data culture within the team?
- Did you have appropriate mechanisms in place to identify and report the data breach as soon as possible?
- Did you have policies and procedures in place to manage data appropriately?
It’s fair to say that you’re still going to get a fine. But, if you’ve done everything in your power to prevent a breach it should be lower than if you’ve had blatant disregard for the safety of your customer data.
If there is a data breach in your organization, it is mandatory that you send a breach notification to all impacted parties within 72 hours of having become aware of the data breach. So again, having the processes in place to identify breaches early, will lead to a better standing with your customers and the regulatory body.
Data subjects have more rights too! They have the right to access & the right to be forgotten. The right to access is the right to see what data the company holds about them (which must be done free of charge, in electronic format) and how that data is being used and processed.
The right to be forgotten is the right to request their data to be erased and processing halted. The user can only request data to be erased under certain circumstances though, including: if the data is no longer relevant.
It’s important that you don’t fall into a trap around these regulations. There is a misconception that US businesses don’t need to adhere to GDPR as it’s a European regulation. This is however untrue. It’s very likely that you hold at least some data on your servers that belongs to an EU citizen and as such, you must comply to the GDPR regulation, or you could find yourself in a world of pain!
If you don’t have no intention of doing business with an EU citizen, you can use rules to drop requests from EU countries on your website, so you don’t risk the users creating an account or filling out a form. Of course, doing that could damage your reputation for US customers that have travelled abroad and are unable to access your website, but it is certainly a strategy which could be adopted.
So let’s say then that you are going to be dealing with EU citizens, how do you get their consent to store data? Well, it had to be an affirmative action. That means, the user has to acknowledge that you will be storing their data and agree to it – you cannot pre-tick the checkbox or implement other workarounds which mean the user passively agrees.
You must also keep a log of how and when the person gave their consent and you must respect requests to withdraw consent immediately.
So, who’s been fined?
At the time of writing, the GDPR regulation hasn’t been in full force for very long, but we already have some big names with some very big fines:
- British Airways: £183 million
- Marriott Hotels: £99 million
- Google: £50 million
The list above shows, GDPR is no joke. These fines are probably relatively insignificant to the likes of Google, but small companies are getting hit with several thousand pound fines which could kill their business.
How can I avoid those fines?
To avoid the fines, you need to adhere to the regulation 100%. In addition to those regulations, it’s also important to have some best practices within the business.
First off, you should only give people access to the data that they absolutely need to carry out their job. For example, Sue in retentions absolutely requires access to customer records so that she can service the customer when they call. Robert in Finance doesn’t need to look at customer details, so he should not have access to do so.
It sounds simple, but very often I see access requests coming through saying ‘I need the same access as Bob’. The thing is, you don’t do the same role as Bob, you just know he has access to the system and you don’t really know what you will need, so you want everything you can get. It’s not a valid request and that sort of thing should be challenged.
Additionally, just because Bob needed access three months ago, doesn’t mean that he still does. His access requirements may have changed and we need to carry out an audit to validate if changes need to be made.
We will talk about some more of the policies, processes, controls and technical security that you need to implement to keep your customer details secure in subsequent chapters / sections. This isn’t supposed to be an exhaustive guide or legal advice but hopefully it will support your GDPR compliance.
