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.

So…

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)
An organisation must have a Privacy Policy statement on their website. This statement, amongst other things, must include what data is captured about the user, what it is used for, how long it is stored, whether it will be shared with anyone (and detailing who), and the process for a user to request to be provided with a full exposure of what data is held about the user and the process for them to request it is completely removed from the organisation’s system – aka ‘the Right to be Forgotten’.

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?

For each of the third-party processors you need to check their respective privacy policies to make sure they are GDPR compliant. Any US-based third-party processors should be Privacy Shield compliant. For each of your third-party processors you need to hold a copy of their privacy policy.

If they aren’t GDPR or Privacy Shield compliant, you’ll need to find out when they will become compliant or find another provider.

Make sure you have a Privacy Policy that clearly states what data and how you’re storing and using it, the third-party processors you share the data with and the process of subjects to request sight of the data and to have it completely deleted if they request. If you get a request for this, you must comply within 30 days.

 

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:

 1. Cookie policy

A page on your website that states what cookies are used on the site, both yours and from third parties and what data you capture with them and what you do with it. An example of typical compliant cookie policy can be seen here on our website: https://www.aubergine262.com/privacy-cookies/

This leads us on to the infamous ‘cookie pop up’…

 

 2. Cookie & privacy popup notice

You don’t need to have one but you do need to state what cookies are used and what the privacy policy is at the first point of arriving at the website – so a pop up is the most logical and well-established solution. It needs to state that cookies are used on the site and that the user needs to agree to the use of the data as set out in the privacy and cookie policy. The policy pages state what cookies are used (both yours and third-party ones) and that you have to agree to the terms in order to fully use the site. It is very possible that, as some cookies are purely functional and not data gathering tools, that the site won’t work properly for you. You will, of course, have the right to request to the website owner to disclose what information you hold about the user and it be permanently deleted.

The use of the website must not be limited to those who accept the use of the cookies. The user must be given the option to use the site without the use of cookies and decline the use of cookies for their session. It must be explained to them the cookie notice that if they decline the cookies the site may lose some functionality.

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’.

 

 3. Privacy policy

A privacy policy is a more thorough document that states the website owner’s full statement of what data is captured, when it was captured, what the data is used for, the third party’s details and the process, including the DPO’s details as well as the process of requesting the user’s details and request that they be permanently deleted.

 

 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

If you have the facility for users to sign up on your website to receive a newsletter from you, whether you send that out one at a time from your desktop email app or from a system like Mailchimp, Mizmoz, e-Shot, Communigator etc, you need to make sure the tick box that handles this subscription is set to the user has to OPT-IN and not opt out. You need to seek consent for each method you plan to email them, indicating how it is to be used and how you can unsubscribe. You cannot roll into your website’s standard terms of use/business the automatic sign up and agreement to the newsletter service. They must be separate opt-in tick boxes for each place you gather the data on the site. E.g If a user signs up to a service they buy on your website, they will have to tick a box to accept the terms of that service. If you offer a monthly marketing newsletter there will need to be a separate tick box for them to select. It cannot be a ‘required’ field. You’ll also need to provide another separate tick box if you also give the user’s details to another party. Make sure that the emails you send out all have an unsubscribe link, too.

 

 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

If you have an eCommerce website and use one of the popular payment gateways, such as PayPal, Sagepay, Worldpay or Stripe, you need to make sure that (as well as ensuring the processes are followed in line with the above points) the payment gateway privacy policies are checked and referenced in your own privacy policy. If they are UK (or European) based, they will need to be GDPR compliant, if US-based, Privacy Shield compliant. The storage of actual payment details on a website falls under and are regulated by PCI compliance.

 

 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

If you have a live chat service on your website, you need to make sure that you refer to this third-party service in your cookie policy and privacy policy and that you review their GDPR/Privacy Shield policy. You may think the data isn’t being stored anywhere, but it is – very often the transcript of the chat is emailed to both parties once completed. The above principles to storage and use apply here, too.

 

 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.

You also need to make sure that your privacy policy refers to these third-party data controllers, especially as people use SSO (Single Sign-on) for logging into sites also using their social media account logins for convenience. You also need to ensure that, if you use the details of your customers or connections on your social media page to promote your business that you have their consent to do so.

 

 13. Google Analytics (and other user tracking systems)

If you run Google Analytics on your site (or any other tracking service) you will need to make sure that it is referred to in the cookie policy and the privacy policy and that you ensure you check the third party’s own privacy policy to ensure they comply. Whilst we know that Google Analytics will be both GDPR and Privacy Shield compliant, other, lesser-known tracking services may not be.

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

Related to points 6, 7, 8, 9 & 10. If your website captures user’s data and then writes it into a CRM, such as Salesforce or Pardot, you need to make sure that the data collection process is secure, as previously referred, and that you refer to the third-party service in your privacy policy. Additionally, if your website automatically sends the enquiry directly into the CRM, the date, time, reason for capture and consent details are also captured. As a user, they have the legal right to ask you where you captured their details, when, was it explicit how the data will be used and how the details can be permanently deleted (also known as ‘request to be forgotten’).

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…

Sites will need an always available opt-out when it comes to cookies. Even after granting consent, there must be a process for users to change their mind and stop. The site’s privacy policy needs to state the process to begin a SAR ‘Subject Access Request’ for full disclosure of data held by the site. Additionally, the user must have the ability to withdraw the consent. Whilst this relates more specifically to data stored, the user can simply clear their browser’s cache of cookies and when revisiting the site, reject acceptance.

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.

………………………
DISCLAIMER
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.