We’ve got a year until the GDPR comes into force, by which time websites across the land will need updating to ensure they conform.

GDPR stands for the General Data Protection Regulation, the final text of which was confirmed in April 2016 after a 4 year consultation process.

But duh – Brexit!

Sorry folks, Brexit or no Brexit, if any visitors to your site are from EU member states, then you need to abide by the GDPR with regards to their data. In January of this year, 200 US companies with 500 or more employees were asked what they thought about GDPR compliance and 92% stated it was a priority for them during 2017.

GDPR essentials for web developers and site owners

Someone asked me the other day if websites should handle differently depending on where the user / visitor is from – but I think that is a question for the website in question. More often than not, it’s going to be simpler and cheaper to treat all data the same and just, effectively, be more careful with data from the rest of the world than you legally need to be. It’s all good practice after all.

It’s quite likely that our Government will make something like the GDPR for us anyway. Our Gov are going to have a lot of rules to write post-Brexit so why not “copy paste, file > save as” on a big rule book that’s already been written? Especially as there are caveats in it that Governments will love – more on that later.

Getting personal

The GDPR defines “personal data” as the following: 

“‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;â€
Article 4, GDPR

I added the bolding. Also, note “online identifier” – take this as meaning “IP address”. 

So if you’re collecting any of that stuff, the GDPR is relevant to you. And you need to collect it, handle it and store it in the ways the GDPR states. However… as important and sensitive as all of that data is, the GDPR then goes on to list some “Special Categories”. If you’re collecting / storing / processing anything from this list then Oh My Goodness you need to treat it carefully. 

GDPR Special Categories:

  • racial or ethnic origin

  • political opinions

  • religious or philosophical beliefs or trade union membership

  • genetic data / biometric data / health data

  • data concerning a natural person’s sex life or sexual orientation

That Government caveat I mentioned…

So whilst you need to take everything above into account and handle it very carefully… the GDPR does not cover the processing of personal data when it’s an issue of national security (Article 2). So there’s your get out clause – and why Governments will be cool with this stuff. If they can argue that it’s an issue of National Security then they can do what they need to (/wish to?) with it.

Knowing your rights

A big part of the GDPR is letting people know their rights – so as both consumers (albeit, outside the EU in not too long, for those reading this in the UK) and as website designers / developers / publishers / owners we need to know the rights of individuals and how those are handled by the GDPR.

The right to be informed

Everyone who gives you data – any kind of personal data from that list above – needs to know what they’re giving you. This is obvious if they’re filling in a form, but not so obvious if you’re also collecting tracking data about them. The info you give them about their right to be informed needs to be very easy to access – not behind a pay-wall (they can’t need to pay to see it) or hidden away somewhere in small print.

The right of access

Everyone who gives you their data needs to be able to access it when they want to, to see what you have on file about them. Ideally, the easy option for this allows them to login online somewhere to see it. But if that’s not possible then you need to give it to them within 1 month of them requesting it… or within 2-3 months if it’s tricky to get. Or you can refuse to give it in exceptional circumstances if they’re being a nuisance, but you’d need to explain why and tell them who they can complain to. So really, just give it to them. And you can’t charge for it – so the Data Protection £10 Admin Fee for giving people their info is out the window. (There is a caveat that you can charge in some circumstances if it’s really tricky to get – but as a rule of thumb it needs to be free.)

The right to rectification

People need to be able to update the details you have on file about them and you need to make sure these changes are updated across all platforms you’ve shared this data with. An easy example is MailChimp – if you maintain a mailing list with MailChimp and someone tells you their new email address, then make sure you update MailChimp. Which you’re obviously going to want to do anyway – but keep it in mind for less obvious examples too.

The right to erasure (A.K.A the right to be forgotten)

People have the right to ask you to delete all their data and completely forget about them. EXCEPT – you can refuse this request if you think some of the data is for the benefit of mankind. If you’re collecting medical data stats and you feel it’ll benefit society and be for the greater good, then you can keep their data, and explain that to them. Ideally, make it anonymous though if you can.

The right to restrict processing

A slightly odd one, but to me, this means that someone can request to keep using your services but just ask you not to process their data. So no profiling – no analysis of their likes / dislikes / habits – even no filtering of newsletter mailing lists based on what they’ve bought from you recently. Keep the minimum you need to on file but don’t use it.

The right to data portability

What the EU are aiming for here is the idea that you could log into your energy company’s website, hit a button, and all your data would be transferred to your new energy company. But I can’t see that happening in a hurry! So as a minimum you could consider letting someone download a CSV file of their data.

The right to object

People need to be able to complain and they need to be able to stop using your services at any time. And this process needs to be as easy as the process for giving you the data in the first place. So no more hiding away that “deactivate account” link and making it hard for people to leave.

As for making it as easy as giving you data, I’ve never designed a home page with a giant “join” button and an equally giant “leave” button – but they say it needs to be ‘as easy to’ so debatably making it 1 click is still as easy as, as long as that one link was easy to find.

GDPR essentials for web developers and site owners

“It shall be as easy to withdraw as to give consent.â€
Article 7, GDPR

Rights in relation to automated decision making and profiling

This is kinda a “computer says no” scenario. If someone is using your website to make a life changing decision or taking a radical action that’s going to affect them in a big way, then you need to let them speak to a human at some point in the transaction, if they so wish. Their future can’t just be in the hands of a computer’s algorithm.


A big topic in GDPR is that around consent. 

“Silence, pre-ticked boxes or inactivity does not constitute consent.â€

No more pre-ticked tick boxes folks. If they haven’t ticked it themselves, then it doesn’t count. Consent, especially “explicit consent” which is needed for the “Special Categories” cited above needs to be verifiable. Which, yes, may often mean storing more data about someone because you’re storing the fact that they gave consent but still – thems the rules. Or in theory, if a join form won’t submit until someone has given their consent then that is arguably still verifiable even though you’re not storing anything.

The trickiest part for me, in all that I’ve read in the GDPR, is what you can do if someone has already given you consent in the past. If you’ve already been given consent, you don’t need to re-ask for it in May next year as long as when you got it, the way you got it was in line with the GDPR. So if someone didn’t have to tick a pre-ticked box back then when they filled in your form 10 years ago – then their consent is no longer valid. 

How do you get around this? Well, you could email everyone and ask them to come back and give their consent again. But they won’t. And then they’ll get angry when they try to use your service next June and find you’ve deleted them. So we’re still thinking of a good way to target that one… but in the meantime, check your sign up processes ASAP and at least stop the problem getting worse if you’re still collecting consent in a non-GDPR-friendly way.

Data protection by design and default

When it comes to the actual data you’re storing, there are a few steps you can take to protect what you’ve got on file.

Data minimisation

If you don’t need it, don’t ask for it. Because if you haven’t got it, you don’t need to keep it safe. Marketers – before you ask someone for every last shred of info about them, ask yourself if you really need it – and if you need that responsibility. Developers – as tempting as it is to store this, that and everything about someone’s actions on your site, consider whether you really need to? Is it worth it for the extra hassle of needing to store it so carefully?


This refers to how you store data in your database. Rather than have, for example, a table of Users with their first name, surname, postcode and date of birth all in one place, you could store each in a different table and use application login (a function in your actual code) to cross reference everything and tie it all together. You’d need to create secret keys / handshakes that only your website could decipher. This means that if someone gets into your database, they’ve got a list of names, a list of DOBs and a list of postcodes, but they don’t know which belongs to who.

Whilst this is a great way of protecting data, it doesn’t actually make it anonymous and so data stored in this way is still subject to the rules of the GDPR.

GDPR essentials for web developers and site owners

Keep it anonymous if possible

If you can keep it completely anonymous, then do. But be honest with yourself about what “anonymous” really means – it means absolutely can’t in any way be tied to anyone. 

What is a data breach?

During my research on the subject, I got the impression that in the US a “data breach” is something that’s generally financial – credit card details being leaked or the like. However, a data breach in terms of the GDPR can be much more minor. Literally, someone working in a hospital opening a file they shouldn’t, and then closing it again when they realise it’s not something they should see, counts as a data breach.

There are lots of rules around how you should report data breaches and companies of a certain size need to appoint data controllers, so you’ll need to check with your industry regulator about that. But overall, the EU do claim that they will fine companies up to €20,000,000 or up to “4% of the total worldwide
annual turnover of the preceding financial year, whichever is higher” if anyone is found to be breaking the rules of the GDPR. The small print then says this is done on a sliding scale depending on the size of your company (big phew!) but still, they want to give the impression they’re serious about enforcing these rules, rather than just saying you might get a slap on the wrist if someone dobs you into the ICO for not having a cookie policy.

Spot the difference: Regulation vs. Directive

An important thing to know about the Regulation is that it’ll be law. The 1995 European Directive (95/46/EC) on ePrivacy which we currently use, and which brought us the beloved “cookie law” is – as the name suggests – a Directive which means each of the 28 member states of the EU need to make their own laws to enforce it. This then leads to discrepancies in how things are done across Europe, with some countries overseeing things in a different way to others. Meanwhile, a Regulation is a rule book for everyone and countries can’t put their own slant on it.

The slight caveat on that is that it took 4 years to agree on the text for the GDPR and the way they finally agreed was to have about 30 places where countries can use their own best judgment if they wish. One example of this is consent for children – the GDPR states that people need to give their own consent (rather than their parents give it)  if they’re 16 or over… but states that countries can make this age 13 if they prefer.

I don’t want to get off topic – but the point is that the GDPR does try to fix things in place, and if it allows a caveat it gives a backup rule to work to.

What’s next?

Next, is that you need to ascertain what you need to do with your website. Get in touch if you would like to hire our consultation services to help you with your plan.

If you’re a web professional, join the Guild to be kept up to date with the latest ideas and workflows around managing the move to GDPR, along with ways of protecting yourself when working on client projects. To celebrate Bristol’s first WordCamp and the fact that we spoke about the GDPR there, you can currently join the Guild for free for 2 years if you use the promo code WCBRS.

You can then decide whether you’d like your company to become a full, vetted member (also free for 2 years), but joining as a web professional yourself is as quick as filling in this form. Web professionals can then have public or private CPD logs, member perks, be kept up to date with any latest job listings you’re interested in (if you’re job hunting), and benefit from our training and industry awareness updates – such as on the GDPR!

GDPR essentials for web developers and site owners