What does the GDPR mean for web developers and marketing professionals?

The General Data Protection Regulation (GDPR) is the new European legislation coming into effect on 25th May 2018, and it’s a pretty big change to the way we’re able to receive and hold personal data in general. It covers all means of data processing and controlling, not just digital means - for example medical records in hospitals and HR policies in organizations.

It’s another layer of regulations on top of the existing Data Protection Act (DPA), and is in desperate need considering the latest DPA was introduced in 1998 when only 10% of UK households had the internet. This short post will give an overview of what this means if you’re a web developer.

As a disclaimer, I’m not a legal professional by any means, but I have had to do research into the GDPR for work and general web development. This is not legal advice, and if you notice something not quite right, please do let me know and I’ll update :)

The data controller and processor

A data controller is the person who “says how and why personal data is processed” - i.e. a client/organization which you as a developer are working for, whereas the data processor is you, the developer of the system. In the Data Protection Act, it’s the client (controller) who takes on the majority of responsibility for how the data is processed and takes most of the legal burden in the event of a breach.

However, in the new GDPR legislation, the data processors (developers/marketing specialists) are beginning to take on a lot more responsibility and legal liability, especially in the event of a breach. And rightly so - data controllers inevitably look to data processors for professional advice and guidance when it comes to securing their data.

What about Brexit?

Irrelevant. The GDPR still applies to the UK.

Asking for data

It was (legally) acceptable under the Data Protection Act to pre-tick a marketing comms opt-in box, or have it a “tick to opt-out” scenario, however under the new GDPR rules it’s now only acceptable to offer users a positive opt-in.

When asking for data, it’s also required that systems are informing end users in clear, concise and transparent way about exactly who is taking their data, how they are taking it and storing it, and what will be done with it. This is nothing new and should be done under the Data Protection Act.

Systems must now also keep a clear and informed log of exactly what information was agreed to by a person, and when. A good way to do this could be by versioning privacy policies and storing each version in a database, relating the policy to the person who has agreed to it. This is important as if a policy changes, or more importantly the way the users data is processed changes, the user will need to be re-informed and their consent taken again.

Removing data - the right to be forgotten

Again, comparing to the 1998 DPA, it was acceptable to “flag” a user as being deleted from a system - the user could only request complete removal of data if it is causing “unwarranted and substantial damage or distress”. Now though, a user can ask for their personal data to be erased under the following circumstances:

• Where the personal data is no longer necessary in relation to the purpose for which it was originally collected/processed.
• When the individual withdraws consent.
• When the individual objects to the processing and there is no overriding legitimate interest for continuing the processing.
• The personal data was unlawfully processed (ie otherwise in breach of the GDPR).
• The personal data has to be erased in order to comply with a legal obligation.
• The personal data is processed in relation to the offer of information society services to a child.

This may cause more problems than you think, especially when it comes to removal in database systems. The data which processors are responsible for removing is PII (Personally Identifiable Information) which could be usernames, date of births, emails etc. This does not include business related “anonymous” information such as orders on an ecommerce website.

The users PII can be hidden away in many unusual places in a database, including order tables, other small plugins/sections of your system, and even third parties you’ve supplied the end users data to. The GDPR may require a little re-jigging of existing systems to ensure there are no errors dotted left, right and center.

Final thoughts

There’s heaps more legislation which is needed due to the GDPR, and this post covers a tiny amount. If you’re unsure about anything, my advice is to see if it’s not already covered on the ICO website, and if you still have questions, the ICO do take messages and will respond pretty swiftly.

I’ll try and keep this post updated when I run into issues or bits I find out for web developers. Tweet or email for questons or to give me updates!