You should all know enough about GDPR, so I will not need to bore you with its history or purpose, except to state that this is the EU’s attempt to improve the protection of individuals' data and privacy, which is of course theoretically welcome.
As a business owner you will obviously need to become GDPR compliant and one aspect of this is to ensure your website – and how you run it – is also GDPR compliant. This needs to be achieved by (but ideally before) the 25th of May 2018.
As a website owner/manager, unpicking and understanding the EU’s 260 page directive is, however, quite an undertaking, and whilst some aspects seem quite straightforward and logical, other statements in the directive are quite difficult to understand without real world guidance as to what this actually means (and this guidance is currently lacking).
GDPR - why it is so scary
The main reason GDPR is so scary are the potential financial penalties - €20 Million or 4% of previous years annual turnover, whichever is higher.
This is enough to scare most companies, whether large or small, so most are taking this seriously.
So focusing on your website compliance, there are a number of rules and regulations which need to be adhered to, each falling into different topics:
- Consent. Ensuring individuals can opt in for data to be gathered
- Processing. Defining rules about the processing of personal data
- Securing data. Ensuring organisations protect an individuals privacy
- Breach notification. Informing individuals (and the authorities) about data breaches
- Right to access. Adhering to requests for access to personal information held
- Right to be forgotten. Ensuring individuals can be removed for your records
- Due process. Ensuring you have defined procedures to follow and individuals responsible for actioning them
In principle these are all quite straightforward, until you start to unpick each one, and this is where it becomes more problematic...
Things that made us scratch our heads
As we started to unpick the implications, some issues jumped out and caused us concern, so here are a few which made us scratch our head….
Consent - theoretically we need to ensure we get consent before we collect data about someone.
Whilst simple in principal, technically this is challenging, as it includes something as simple as server logs that record data about each request an individual makes (time/date, IP address, etc). The problem is that the server gathers this before we have had an opportunity to get consent…so what do we do? Do we stop recording server logs (which is going to give us interesting management issues, such a debugging errors) or develop complex functionality, which stops us recording this until they have granted us permission, which is not particularly realistic? Eeeek.
Rights to access - theoretically an individual can request all data an organisation has stored about them.
Even if we are not doing any nefarious tracking, we are gathering a fair bit of data in the form of analytics, server logs, form submissions etc, so we certainly have data they are entitled to request from us. The problem is that whilst we have data (such as an IP address), this is not actually related to an individual without additional processing to connect it to them. So what should we do when an access request is made? Only provide what we have related to them, risking breach (and a large fine) or process all data, binding it together into person specific data, which would obviously be counter to to the intent of GDPR!
Processing - you need to tell people exactly (in clear, simple, accessible language) what you are doing with their data and get consent for this…implied consent does not count!!
Even if you do not do any exotic manipulation of gathered data and you simply have a server log, or use analytics such as GA, then it can be assumed that you will be looking at this data at some point, which therefore classifies you as data processing.
With this in mind, the rules stipulate that you not only need to inform the individual about this but that consent is also required, which raises the question: do we stop gathering this data if they do not provide consent or block their access to your website unless they provide consent?
Mission control, we might have a problem!
With these points in mind we have some major issues… how on earth can we run our website effectively without falling foul of these points?
But wait, everything might not be quite as impossible as it seemed, as exploring the legislation in a bit more depth (as well as reading the ICO clarifications), we see that:
- the principal of the legislation is to improve privacy and that increased processing to fulfill data requests would be nonsensical….the ICO is taking a pragmatic view.
- we can gather data if it is required for functional purpose, defined as 'Legitimate Interests’.
- as long as we are not doing harm to the user (invading their privacy) and simply trying to run a website then the rules are not as scary as they seem.
OK, enough small talk, what do we have to do?
Whilst it is easy to get lost in all the detail, the real question is what do we have to do to make sure our website adheres to GDPR, uses and stores data correctly, and does not give us legal strife.
NOTE - For safety's sake, remember we are not lawyers, and this is only our interpretation of the rules - get your own legal advice!
Server logs -
Whist these were a major concern for us, we now feel comfortable that if the Server Logs are only being used for technical analysis of the website (such as server optimisation, CMS bug fixing or SEO review) without related individual IP addresses or sessions then this should not be an issue causing you to breach GDPR.
(Note - you do need to make sure your CMS does not create/record unique identifiable data via cookies, as this could be an issue)
Analytics - Is Google Analytics GDPR compliant?
Nearly everyone uses web analytics tools such as Google Analytics (GA), PIWIK (now branded Matomo), WebTrends etc, so the question is whether these analytics tools put you in breach of GDPR.
Obviously each analytics tool is different, so here we will focus on Google Analytics (GA) and GDPR, but you will need to check and review the platform you use.
So what is the deal with Google analytics and GDPR? Is GA OK to use or does this give me compliance issues?
Reviewing Google's guidelines on GA use and their pages on data privacy, it is clear that:
- in it's default and general usage GA does not store individual identifiable data about your site visitors
- that you are in breach of GA’s terms of usage if you add code that tracks individual users and their actions (so don't do it)
So in principal Google Analytics is fine to use as GA does not conflict with GDPR – as long as you do not customise it to collect individualised data about visitors.
If you do add additional tracking or enable the features such as User ID tracking, Demographic reports or Remarketing functions then you will need to get consent from the user.
We would even go as far as to suggest you configure your GA to anonymise the last octet of the IP address prior to its storage as the impact on you will be minimal.
You can find more details about how to anonymising your GA configuration on Google's how to guide.
UPDATE - google has now started contacting people about GDPR, helping to clarify points and also getting themeless read to be GDPR compliant.
One of the key principles of GDPR is that you need to let people know what you are gathering and why.
You should also provide details (including contact details) regarding who is your nominated officer in charge of data.
If, however, you are capturing more personalised data, and you are going to use it to track, profile, personalise, market or target the individual then you need to inform them beforehand and they have to actively choose to opt-in to this (rather than opting out). They have to consent.
Forms, data capture and consent
If we are going to gather data beyond analytics and logging – such as name, email address and telephone numbers, then we not only need to inform the user before we do this in a visible way (hidden in your T&C’s no longer counts) but we also need to get their permission and consent for this.
Permission needs to be ‘active' i.e. the visitor needs to agree to something, by checking a box or doing an action, and you need to document the consent they have given.
So if you are doing active tracking, doing reverse look ups on the user IPs to establish where they work, trying to profile them by combining cookie data so you can personalise and target advertising at them or sell the data, then you need to inform them of your intent beforehand – again in a clear and visible manner – and you need to get their implicit agreement for this.
GDPR aims to put rules in place regarding data processing. To be clear, if you have data and you in anyway view or analyse this, you are considered to be processing.
Reviewing web analytics and server log files is relatively uncontentious, as without additional processing this is not personalised so as long as you have stated in your privacy statement that you will be doing this then this level of processing is OK from a GDPR perspective.
If you want to do more personalised processing, segmenting individuals into groups, profiling them or building more information about them by combining data gathered, you are OK to do this as long as users were pre-informed about this and that they consented to this processing of their data, or you anonymised that data prior to processing.
If it was not clear in layman's terms that you were intending to gather this data and process it in this way, and if they have not given you implicit ‘active’ permission to do this, then you do not have the right to process the data and you will be in breach of GDPR.
Obviously there are many third party tools and services (Facebook buttons, tracking code, Online chat etc) that you can add to your website which may be gathering & processing data. Just because it is a third party service that you have added to your website does not absolve you from this responsibility or liability. If you add these to your website you need to make sure the provider is GDPR compliant and to follow the previous points regarding notification in both T&C's, as well as pre-notification and consent with the user.
The final aspect of GDPR in relation to your website is security. If you have data about an individual then it is your responsibility to keep it secure.
With this in mind you therefore need to make sure your website (Server, CMS, databases etc) and all the data you store on it is secure, as (obviously) usernames, passwords and personal details can be used to gain access to other systems.
It is worth noting that if you do not keep data secure, then you could be in breach of GDPR. If there is a breach you need to inform users and the authorities (ICO) within 24 hours ensuring they can mitigate any risk.
Note - there is a component here related to the material damage. If a breach provided an individual's name without further details, then the risk or damage to the individual is nominal and you will not need to inform them of this breach. However if, for example, you are running a health clinic, then someone finding out the names of website visitors could be used to individual detriment and they will need to be informed ASAP.
So all in all this is simply good common sense stuff… no real surprises.
If you apply common sense and follow these principles it will not be too hard to make sure your website is compliant.
- Only record and store what you have to - keep it simple… just because it is technically possible to get it, does not mean you should gather it. Minimise your exposure and only gather what you need and use.
- Double check any services you use such as webchat, analytics, social media buttons etc, as they may create their own issues.
- If you do decide to gather personal information, whether it is a form being submitted by the user or more 'creepy' tracking, then tell them what you are going to do with this data and make sure you have their implicit agreement (a pre-checked box does not count).
- Keep the data secure, be organised and structured and, if a breach happens, make sure you have processes in place to minimise the damage that is done to the user and to inform them of this within the timeframes allocated.
Finn is a founding director of Liquid Light, and he still (after 22 years of web design) likes to get involved in projects. When he is not worrying about the clients, he is studying Chinese medicine, working with young criminals and doing spartan challenges.