Your website and the GDPR compliance – a practical checklist
Knowing what you can, can’t and must do when it comes to collecting user information on your organisation’s website.
In this article we provide some guidance for businesses to follow to help them work towards making their website more compliant with the GDPR Data Protection regulations that become enforceable after 25th May 2018. There’s a list of some ‘must have’ processes and a checklist of the important aspects that the owner of website must follow. This is not meant to be a complete guidance for all data protection best practice but a guide in respect to how to ensure a website can be more compliant – after all, a website is often the first place a business interacts with its customers.
Let’s start with a little preface. The General Data Protection Regulation (GDPR) is a good thing.
Administratively and logistically, it’s going to be hard for a lot of small & medium-sized businesses to cope with the change as it will take lots of time and therefore money, to change the way data is captured, stored and used.
However, morally and fundamentally, it’s the right thing to do and here’s why –
You value your privacy and all the private things about your life – your name, address, date of birth, place you were born and what movies you like to rent – even your favourite pizza order toppings. But you would want the organisations that know these things about you to look after that data. Especially sensitive information that relates to where you live and your family.
GDPR is in place to make sure that those people look after the things they know about you in a proper way. But in the same respect, you as a small business must do the same.
Example: Let’s say a builder scribbled down the name and telephone number on a post-it note in his van of someone who’s called him after seeing his website. That builder will be sending them a quote for a new extension. Nice. However, that night the builder’s van was broken in to and now, the name of someone along with their home phone number and address are out there. A burglar’s Christmas and birthday all in one. The data is loose and now cannot be controlled or forgotten. A data breach in every sense of the word.
Whilst it’s an extreme example, it’s no different to how data is stored on a website or sits on a note on a desk in an office and then goes in the bin at the end of the day. People go through bins.
Fundamentally, it’s all about taking better care of the information you, as an organisation, hold about other people and how it’s used.
The key questions you need to start asking:
It all must begin with a data risk assessment. This is not limited to just the data revolving around a website but the entire organisation’s practices. However, let’s keep it website relevant. As an organisation, you need to be asking the following questions:
- What data is being captured and held?
- When and where is it captured?
- How long will the data be stored?
- How is it being used?
- Do you have explicit consent from the user to have and use the data?
- Do you display who to contact to find out what data is held about a user and request how it’s being used?
- Do you display the process for a user to ask to have all the data you hold about them permanently removed from your system? (AKA The Right to be Forgotten)
KEY POINT 1:
You must prove you have been given explicit consent to hold the data and what it will be used for.
For example: if someone contacts your company or organisation through your website with an enquiry, it does not give you permission to add them to your email marketing list. However, if the enquiry form had a checkbox that explicitly asked if you wanted to be added to a newsletter/marketing list and the user accepted the terms stated how your data would be used (they were ‘sought consent’), then this would be acceptable. A log of when they agreed to the terms must be recorded somewhere so that it can be recovered and provided to the user if they request it.
What IS permissible is to contact that person in direct relation to that enquiry – you have a clearly legitimate reason for holding their details. If the enquiry leads to you doing business with them, then you will handle the data in the appropriate way. If the enquiry does not lead to them becoming a customer, unless they have agreed to receiving marketing from you by, you cannot contact them any more and it is recommended you delete their details to avoid holding data that you do not have permission to hold.
KEY POINT 2:
The user must be able to withdraw consent at any time.
The must-have processes
Organisations need to make sure they:
Have a data breach process
The GDPR requires the data controller to have suitable processes defined and in place in case of a data breach. Depending on the severity of the breach, the data controller has a legal obligation to report a data breach (of identifiable or un-pseudonimised data) within 72 hours. Further information on the reporting of a data breach can be found on the Information Commissioner’s Office website.
Appoint a Data Protection Officer (DPO)
All public authorities and any organisation that processes personal data (the data controller) on a significant scale must appoint a Data Protection Officer (DPO) responsible for monitoring internal compliance of the GDPR regulations within the organisation. Even if you don’t feel that your organisation falls into this category we think that it is a good idea to appoint a DPO for your organisation. This person can keep data protection high on the organisation’s agenda and ensure that GPDR compliance is achieved and then maintained.
Have a ‘Right to be Forgotten’ process (also known as Right of Erasure)
Have good default privacy settings
If your website captures any sort of user data or details, such as an eCommerce website or one that allows the user to have an account with some sort of profile that identifies them, make sure the website is set to the highest level of privacy for the user by default and that there are settings the user can choose to downgrade their settings if they wish – a bit like your privacy settings in your social media apps (although many of them don’t!). DPOs should be checking that only data that is absolutely essential be captured.
Improve data encryption and work towards storing user profiles as pseudonyms
Basically, if you’re storing personally identifiable data on your website (user accounts that have their names, email, shipping/billing addresses etc) you need to be working towards getting that data stored so that it is stored encrypted. Peudonymisation is also something that should be considered. This basically means that account profiles have usernames or login methods that are not visibly connected to the actual individual – usually this is done by having two databases for the website – one for the pseudonym and that database connects to the actual account details so that the whole profile does exist in one place. This reduces the exposure of PII (personally identifiable information) becoming exposed in the event of a data breach or hack.
The first step is having an SSL (secure sockets layer) certificate on your website that encrypts all the data entered into a website through form fields (like when you set up an account, buy something online or sign up to a newsletter etc. However, the data is most likely not stored encrypted. Most CMS systems, like WordPress, Drupal and Joomla don’t do this and you’ll need to have some customisation done to your site to make the data get stored encrypted so that in the event of a breach, the data is useless and cannot show identifiable information to individuals.
Compliant connected systems: Google, Mailchimp, Salesforce, Mizmoz, Facebook etc
The GDPR rules call these ‘third party data processors’. They are processing the organisation’s data on their behalf. Most of these sites and systems are based on the US. Although they have a requirement to become GDPR compliant they will be compliant with the US-equivalent called Privacy Shield.
You need to make sure that your processes and policy clearly states what third party data processors you use and where a subject’s data is passed to.
A note about Privacy Shield:
Under EU GDPR (article 45), international adequacy decision has not been granted to the USA. Albeit that EU-US agreed Privacy Shield v.2.0 (formerly “safe harbour”) was being adopted in July 2016, this infographic explains quite well that it does not meet GDPR standards https://www.trustarc.com/resources/privacy-research/privacy-shield-vs-gdpr-infographic/.
Other articles also state that the Article 29 Working Party has delayed ratification of Privacy Shield because of these inadequacies, furthermore it is now due to be rejected and nullified by the European Courts of Justice. Final result = think twice about using a US-based service if you want to be GDPR compliant!
Take a data audit
I mentioned this earlier but this is really where it all starts. List all the places where you know you capture data and what sort of information that contains. Then mark each one with either with a 1 or a 3 to help you track which are first (your organisation) and which are third party data processors.
For each data processor consider the following:
- What are you using the data for?
- Where is the data being stored?
- Do you still need to hold the data?
If they aren’t GDPR or Privacy Shield compliant, you’ll need to find out when they will become compliant or find another provider.
The website GDPR compliance checklist:
First and foremost, as an organisation you need to make sure you are registered on the ICO (Information Commissioner’s Office) website as a data controller (you may also be a data processor, too). Go to https://ico.org.uk/for-organisations/
There are 14 points in the checklist:
This leads us on to the infamous ‘cookie pop up’…
2. Cookie & privacy popup notice
If you want to read more about the detail of cookies and how consent will control their usage you can read more on this at the end of this article ‘Cookies – footnote’.
4. SSL certificate
Secure Sockets Layer certificate – it’s the encryption code process that sits on the hosting space of your website. It the thing that makes the browser bar display a secure notice and sometimes go green and show a padlock symbol. The purpose is to securely encrypt all the details that are entered into any forms or fields on a website. They can be purchased and installed from £99 per year. A variety of SSL certificates are available, all encrypting the data to the same level (256 bit – 2048) but some have further protection and insurances. There are free ones being offered as part of a project called ‘Let’s Encrypt’ but it’s doubtful this offer will last long and doesn’t come with any assurances like those offered by the branded ones, such as GeoTrust and VeriSign.
5. Pseudonymisation or anonymisation
– This one’s harder to resolve.
Most websites that have user accounts and store information about its users (like your Amazon account storing your name, address, date of birth etc) store the data in an SQL database. This is a web-based database that the website calls to, queries and delivers your details when you sign in. In most instances, unless it’s online banking, these details will not be stored encrypted and so if the SQL file was accessed the content could be clearly read.
It’s very hard to both store and retrieve data in an encrypted way and is why most sites don’t. However, as part of GDPR, ‘pseudonymisation’ means that websites will need to start moving towards the users being identified by a username only and that the rest of the data is encrypted so that there is no possible connection between the user and the stored details. You will need to speak to your website developer and host about planning this change as it will take time, planning and require a budget.
6. Newsletter signups
7. User account creation
If your website is an eCommerce one or allows a user to set up an account for access to services behind a login area, you will need to ensure that you have both the SSL installed (as referred to in point 6) and also work towards the data being stored using pseudonyms. Recent headline examples (Uber, TalkTalk, Experian) have shown that even major internet giants aren’t doing this so better to talk to your web developer about how you can move towards this process.
8. Payment gateways
9. Enquiry & contact form
If your website has an enquiry form for people to send you messages, you need to ensure the following are adhered to:
- The website has an SSL
- The details are not stored in the website’s SQL database unless stored encrypted
- If they are sent to you by email, your email service provider adheres to GDPR rules and that the email is stored and sent according to GDPR secure methods. Many email service providers, like Googlemail and Outlook 365 are updating their terms of service in accordance with GDPR – it’s worth checking their policies to make sure your email provider complies. Email is one of the most common places private data gets abused and lost or misused.
- Do you print out the email with the enquiry details on? If you do, this is also a data risk. Ensure you have a shredding process in place to make sure that emails with user’s private details aren’t just put in the bin!
- No pre-ticked boxes to automatically sign the enquirer up to a newsletter.
The enquiry is explicit to that instance. You cannot then add the user’s details to your marketing database unless they have explicitly agreed to it using a separate tick box.
10. Live chats
11. Connected email
Whilst not strictly website-related, all email services and the storage of email from all with whom you are connected, must be stored in accordance with DPA (Data Protection Act) & GDPR guidelines. In short, make sure you store your email data securely, use good anti-virus applications and archive and delete unnecessary email completely. And have a Data Retention policy – a statement by which your organisation follows in terms of how you store data and for how long before it is deleted. Typical business data retention policies are 2 years – anything older than that is usually out of date anyway. The exception to the rule here are regulated industries – financial services, medical, Governmental, HMRC etc – these guys may require you to keep data records longer, particularly when it comes to accounting and finance. You’ll need to check with your regulated body if you fall into this bracket.
12. Social media account connection
Using social media sites for your organisation also falls under GDPR. Whilst you do not need to seek permission from each person who ‘likes’ your page or ‘follows’ you, you do need to ensure that any information gathered directly from people with whom you interact on these sites is handled in accordance with the GDPR privacy guidelines. If you’ve had a chat using Facebook Messenger with someone about an enquiry, make sure the chat history is completely deleted when it’s done. Get the person to email you so that you can hold the formal connection outside of a social media channel.
13. Google Analytics (and other user tracking systems)
You must enable the anonymisation option in Google Analytics to properly conform to GDPR. Google Analytics records user’s IP addresses in visitor reports and this is deemed as ‘identifiable information’. You don’t really need it so turn it off. What’s not fully clear right now is how this will affect geographic reports. We’ll update on this in the coming months.
14. CRM connection
The Information Commissioner’s Office (ICO) has actually launched a dedicated advice line to help small organisations prepare for the new data protection laws (GDPR). The service is aimed at people running small businesses or charities and recognises the particular problems they face getting ready for the new law.
You can Find out more here: https://ico.org.uk/for-organisations/resources-and-support/getting-ready-for-the-gdpr-resources/
Cookies – footnote
Implied consent is not compliant because the GDPR requires the user to make a ‘positive action’ to indicate their consent. Just because you visit a site for the first time would not qualify.
Changes to your browser settings won’t be enough. GDPR states that it must be as easy to withdraw consent as it is to grant it. Block cookies if they don’t consent would not meet this criteria as it doesn’t provide the user with enough granular choice.
‘By using this site, you accept cookies’ notices are no longer compliant. If a user cannot genuinely choose, then there is no valid consent. People who don’t consent also cannot be compromised in not being able to visit the site. They must still be able to use the site, albeit with perhaps limited functionality, without fear of compromise of their rights.
Which also means…
The simplest way to handle this for most website owners is to provide a simple explanation that users can clear and block cookies on their browser.
This article was prepared by Aubergine as non-authoritative guidance. Neither Aubergine or the author accepts any responsibility or liability that might occur directly or indirectly as a consequence of the use, application or reliance on this material.