GDPR, Data Protection and you

GDPR, Data Protection and you

I’d like to thank Brian for inviting me to be a guest blogger with the exciting topic of GDPR. I agreed to write this after a drink in the pub with Brian, where amongst other things we were discussing how GDPR would affect a few of the websites he and I advise people about. He allowed me to have my usual rant about how there are people out there making money from advising companies about GDPR, but when you look at their advice what they actually say is “you need to think about” or “this is what the rules say”. What most small companies need is to be told here’s what you should do… so that’s what I’m attempting to do in this blog post.

 

Who is Matt Thornfield - IANAL?

Let me start with a quick bit of background. I run an online training platform for java programmers. We have customers in around 65 countries, and so have to comply with various laws, and the GDPR will be one of them. So we sat down and worked through what the regulation says, how it will affect us, and came up with a plan of how we’ll be compliant. Having gone through this process, I believe I’ve worked out how to the answer the “what do we need to do” question – and that’s what I’ll share in this blog post. Or rather, I’m going to tell you what we’ve done. However I’m not a lawyer, nor an expert in regulation, so please do your own research and don’t try and sue me or rely on what I say here… these are my thoughts, not legal advice!

This is for the whole world not just Europe!

I’m getting to the advice soon, I promise, but before I get there, there’s one really important thing to make clear. GDPR affects you if you have customers (or members, or other relationships with individuals… but I’ll call them customers to keep things simple) where the customer is a citizen in one of the EU states. It doesn’t matter if your company or website is being run in Russia, the USA, or Outer Mongolia, it’s where your cutomers are that’s important. This might seem odd – after all if you are based outside the EU, how is the EU meant to enforce rules on you? However this actually happens in lots of other ways – for example companies who sell digital products (like we do) also have to comply with the EU’s rules on Digital VAT. I’m not going to get into a discussion here about the logic of such rules applying worldwide, but be in no doubt, they do. Of course this also means that if you’re a UK company, like we are, and you have customers based in other countries outside the EU, this doesn’t affect them, only your EU customers.
Ok so now that we’ve got through that… here’s what we have done, and what we’re advising our friends to do…

So what do I need to do?

Write a document which you can call your GDPR compliance plan. You can use this document to demonstrate to the regulator or customers who ask how you’re compliant. You might even publish it on our website. It shouldn’t be that long – ours is about 3 pages. The document will contain the following information:

1 – Who do we hold data on / who is in scope.

List who you hold information about, and whether they are in scope of the GDPR. It looks like this for our company:

We hold personal information about our customers and potential customers. Some of our customers are companies, and any information held about these customers will be outside the scope of the GDPR. Some of our customers are outside the EU and therefore outside the scope of the GDPR.

As the only employees of the company are the directors, we do not consider any personal information held about them to require documentation. Should further employees be taken on in the future, this document will be revised to cover any personal information to be held at that time.

All 3rd party suppliers, including our support team, are companies rather than individuals, and therefore any information held about them is deemed to not fall within the requirements of the GDPR.

2 – What systems do you have?

Next list the different systems that you have in your company that store data. Include any 3rd party systems you have too. For each system, write down the purpose and where the data is stored. One sentence on each system should be enough!

We identified the following systems:

  • Our website
  • Our support platform
  • Our CRM platform
  • Our accounting system
  • An accounts reconciliation tool
  • Payment processors
  • 2 external services for email newsletters and onboarding emails

We also noted that we have development and test versions of some of these systems, but that they don’t contain live customer data!

3 – What info do we hold?

This is the trickiest part, and the most time consuming. Although to be honest it’s not rocket science… create a table with the following headings:

  • What we hold
  • How we obtained it
  • Where we hold it
  • Why we hold it

Then populate this table for every data field in every system / database that you have.

Here’s an excerpt from our table:

What we holdHow we obtained it Where we hold it Why we hold it*
Full name Entered by customer when signing up Main VPP Database
Accounts
Staging
Ticketing
 
Email address Entered by customer when signing up Main VPP Database
Ticketing
Mailchimp
Onboarding System
Used for marketing and general communication where customer has permitted such use.
Country Determined by IP address resolution at the time the customer signs up for a subscription Main VPP Database Used for the purposes of determining VAT and maintaining financial records to demonstrate compliance.

* In general the information is held to provide the service that the customer has paid for, and for us to extract and reconcile our financial information. Where there are additional uses of the data these are documented here.

Stop right now!

NOW STOP – you need to think about the table you’ve just created.

Going through the process of building this table makes you justify why you have the data that you do, and explains how it is used. This is a really important process. If you find you are obtaining data that you don’t need, then you need to stop collecting it. A good example (the one Brian and I were discussing in the pub) was a sign up form that asked for the user’s date of birth. The website was using that information to check the user was over the age of 18 (a requirement to be a member).

However under the GDPR rules, you could argue that the website owner has no ongoing need to maintain that information, and that it shouldn’t be stored once the membership has been approved. Alternatively you could decide that a simple tick box stating “I am over 18” would be a better option.

By the end of this step, you should know what data you are holding, and why you are holding it.

4 – How do we obtain consent?

Having worked out what you are holding, and why, you now need to document how you get the customer to agree you can do this. This is probably going to lead to a change for most websites… it does for us.

We decided that when customers sign up (and possibly on their membership details page) we need to provide 3 separate checkboxes, that say something like this:

  1. GENERAL CONSENT: I consent to you holding information about me for the purposes of providing me with any services that I am paying for, and which Virtual Pair Programmers’ are required to collect and hold to comply with any legal or regulatory requirements. I consent to you communicating with me by email and telephone to discuss any issues which may arise relating to the ongoing safety and management of my account. (Mandatory – customers must accept this option)
  2. ADVICE COMMUNICATIONS: I consent to you sending me emails after I have purchased a subscription or a downloadable course, with advice on how to use the service. This may include notification of new courses which I am able to access as a result of my purchase for no additional cost.
  3. MARKETING COMMUNICATIONS: I consent to you sending me emails advising on news and general marketing from Virtual Pair Programmers and AllThingsJava only. Your data will not be passed to any 3rd parties.

We’ll also be giving them a link to our GDPR document (or a cut down / easier to read version of it)

Customers must be required to opt in to any of these consent boxes. You can’t pre-tick the box and ask them to untick it (or alternative you can’t phrase it to say tick if you wish to opt out!)

Of course you then need to act according to what consent the customer has given you. If one of our customers doesn’t tick box 3, we’ll make sure we don’t send them marketing messages, for example.

5 – Subject Access Requests

Write a short paragraph saying how you’ll deal with Subject Access Requests (when a user asks you for a copy of everything you hold about them). We just say that we’ll deal with this manually, as it’ll be a rare occurrence hopefully, but that this document will guide us to extract all relevant data.

You have to reply to a customer asking for a copy of everything you hold about them within 1 month, and you generally can’t charge them for it.

6 – Right to be forgotten

Customers can ask you to delete the data you hold about them. There might be some data you need to keep (for example financial records, to demonstrate you’ve paid the right amount of tax), so we said what we would and wouldn’t delete…. And again we’ll do this manually if it occurs. Some of our data we can’t delete as it could break the integrity of one or more of our systems, so we will anonymise rather than delete it – changing the customers name to “Deleted Deleted” and their address to “1 Deleted Road” for example.

And that’s it.

By creating this document, you’ll have identified every item of data you hold, and:

  • That you have a valid reason for collecting the data
  • That you have a valid reason for ongoing storage of the data
  • That you know where the data is stored
  • That you have explained openly and honestly to the customers what data you have and why / how you use it
  • That you have gained consent from the customer to store the data you do, and use it in the way you do

There are some other things to think about (like what happens when a user tells you that something has changed – you have to update all relevant data items within 1 month), and of course the security around your systems (strong passwords etc) but I hope that this approach is practical and useful for you!

The web was meant to be read, not squished.
This isn't the way to test a responsive design.