How to make your website GDPR compliant
GDPR was the topic on everybody’s to-do list in the lead up to the enforcement date of the 25th May 2018. All businesses needed to review how they collect, store, use and delete personal data.
Whilst it hasn’t impacted the community perhaps as much as the scaremongers would have foretold, it is still very much worth making sure your website is compliant. If nothing else, it’s good to care about your customer’s data.
Your website is affected by GDPR as it:
- Collects personal data from individuals (e.g. contact forms)
- Tracks individuals (e.g. cookies)
- Sends personal data to data processors (e.g. your email marketing list)
GDPR does not mean you need to stop using your website to grow your business. The law is not trying to prevent growth or even marketing.
It is aiming to bring our data protection laws up to date with current technology and practices. Ultimately, we should embrace the new legislation and take the opportunity to be open with our customers and prospects.
As a digital marketer, website designer, and having worked with software businesses that have had to adapt early, I am often asked about GDPR for websites. As this question has been asked so frequently, I have put together this guide.
Please note that I am not providing legal advice. However, this practical guidance can be used to help you do exactly what the Information Commissioners Office is asking: demonstrate compliance.
Before the first legal cases appear in court, nobody can be completely sure of what bullet-proof compliance looks like. But we can take reasonable steps to show that we have tried.
The most obvious way to achieve compliance would be to get legal advice.
This blog is divided into chapters:
Privacy policies, cookies and the requirements of a Privacy Notice
The Privacy Notice
Within the UK, our enforcing body for the GDPR is the Information Commissioner’s Office. Their website provides extensive guidance on the requirements of a privacy notice, and the extra requirements under the GDPR.
A privacy notice can be supplied in writing, through signage, orally or electronically. This makes the point that a privacy notice is not just one web page.
It is recommended to have a privacy notice on your website to contain the full details, but you must also display relevant privacy information at the data collection point.
A good example would be a clear notice on your contact form briefly describing what you will do with the data a user is about to enter.
Extra requirements for privacy notices are placed on businesses by the GDPR. The most important of which is the necessary clarity for the website visitor to be able to understand it.
It is exactly this form of legalese writing and attempts to hide how an individual’s data is used that the GDPR has been designed to tackle.
Your privacy notice should be concise, transparent, intelligible and easily accessible. And it should not be a copy-and-paste job. It needs to be relevant to how your business uses personal data.
UX of Privacy Notices
The ICO do make recommendations on the user experience to assist users in understanding your privacy notice.
Layers are a brilliant way to lay out a lot of information in a skimmable and mobile-friendly design, as shown in their example:
This allows you to provide headline titles, with the option to click for more information. Finally, they also include a link to the full privacy notice for more information.
Just-in-time notices are also recommended, providing the website visitor with information about why that specific data is being collected and how it will be used.
What should you include in your Privacy Notice?
Now we have identified that a privacy notice should be:
- Easy to understand
- No longer than is necessary
- Widely accessible
- Delivered, in part, at the point of data collection
We can move on to identifying what should be included. Unfortunately, in our opinion it is not possible to download a simple template due to the specific and concise nature of a Privacy Notice. However, Article 13 of the GDPR does specify exactly what you must include.
I have interpreted the requirement in a less technical/easier to understand language as follows:
- The identity and contact details of the controller, and where applicable the data protection officer
- The purpose and legal basis for the processing
- If the legal basis is legitimate interest, the legitimate interest must be defined
- Any recipient, or categories of recipients, of the personal data
- Details of any transfer to a third country, and of the safeguards in place
- The retention periods, or criteria used to determine the retention periods, of the personal data
- Details of the rights to access, and to rectification or deletion of personal data, as well as rights to object to processing and the right to data portability
- The right to withdraw consent at any time, if processing is based on the legal basis of consent
- The right to lodge a complaint with a supervisory authority
- If automated decision making exists, including profiling, then this must be made clear including how decisions are made, the significance and the consequences
You can refer to the original specification in Article 13 on pages 40 and 41 of the GDPR here.
It is also suggested that you date, or version, your privacy notice and keep a copy of each version.
The GDPR does suggest you inform data subjects of changes to your processes, however it appears from the widespread practices of larger firms to date that the general consensus is to date a policy and expect website visitors to be able to find it.
As previously mentioned this is not legal advice, but a logical collection of what is being interpreted to date. Only a court judgement could define the accuracy of this suggestion.
How we wrote our Privacy Notice: Step-by-step guide
With the continuous notice that this is not legal advice, we are happy to share how we’ve tackled the problem.
We’ve broken down our process into this step-by-step guide to help you do the same.
Take it with a pinch of salt – it’s our interpretation, not a lawyer’s view!
Step 1 – The identity and contact details of the controller, and how to complain
- #1 The identity and contact details of the controller, and where applicable the data protection officer
- #9 The right to lodge a complaint with a supervisory authority
This is pretty self-explanatory. Put the details of the data controller under a clear heading in your privacy notice.
We chose to also include the required information about the way for an individual to complain to the ICO should they be unhappy in this section.
Step 2 – What you process, under what basis and how long for
- #2 The purpose and legal basis for the processing
- #3 If the legal basis is legitimate interest, the legitimate interest must be defined
- #4 Any recipient, or categories of recipients, of the personal data
- #5 Details of any transfer to a third country, and of the safeguards in place
- #6 The retention periods, or criteria used to determine the retention periods, of the personal data
To tackle this point, you need to determine exactly what data you process, where it comes from and which legal basis you will use to process it. It’s the meatier part of GDPR, but it must be completed.
There are six lawful basis for processing data under the GDPR. You need to take a moment to understand them and the implications that come with using them. The available basis are [text has been copied directly from the ICO’s website for clarity]:
- Consent: the individual has given clear consent for you to process their personal data for a specific purpose.
- Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract.
- Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations).
- Vital interests: the processing is necessary to protect someone’s life.
- Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law.
- Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.)
We found the easiest way to complete this section is to use the example spreadsheet from the ICO themselves. Scroll down to the ‘Is there a template we can use?’ section and download the ‘Documentation template for controllers’.
Once you have worked through the template you will have a complete document containing:
- the data you process
- what category
- who it is shared with
- the legal basis
- how long you store the data for
It will take a while, but it’s the only way to secure your business for GDPR and to be able to create a privacy notice that is compliant.
If you decide on legitimate interest as the lawful basis to process any data, you must complete a legitimate interest assessment (LIA). You can find an LIA template document on the ICO’s website.
Now you can create the relevant headings in your privacy notice.
Step 3: Individual’s rights
- #7 – Details of the rights to access, and to rectification or deletion of personal data, as well as rights to object to processing and the right to data portability
- #8 – The right to withdraw consent at any time, if processing is based on the legal basis of consent
You must describe the rights that individual’s have under the GDPR. This includes their right to withdraw consent. We chose to create a section that listed out these rights, and where applicable, how to enforce them.
Step 4: Sense check
If you are writing your privacy notice yourself, I found it helpful to work through the points above and then refer to other companies that have done privacy notices well. It can help you to make sense of the technical language used in the GDPR specification.
I think there is some irony there – in the need to reduce legalese language, we first need to interpret legalese language ourselves!
Some privacy notices that we are a fan of:
- Microsoft, who have made use of the Layers concept. Try the ‘Learn More’ options to see additional information on each section.
- Simply Business has a clean UX with all headers visible when you hit the page, and a simple drop down for further information. They’ve clearly hit the key areas defined by the GDPR.
- M&S have an in-depth policy with clear headers. Their description of their legitimate interests and legal basis is particularly useful.
- Obsequio Software have all the right sections but have really managed to keep it concise.
- Slack have a larger (read longer) policy, which is not necessarily a good thing. However, they do keep an archive of old policies and have taken a strong approach at tackling the multiple international regulations at play.
Cookies and the GDPR
The GDPR only refers to cookies once in Recital 30, which states:
“Natural persons may be associated with online identifiers…such as internet protocol addresses, cookie identifiers or other identifiers…this may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.”
Essentially this means that if a cookie can be used to uniquely identify an individual, then it is processing personal data and GDPR applies.
Cookies, PECR and the ePrivacy Regulation
PECR has been adopted as UK law from the EU ePrivacy Directive. An EU Directive is used locally by individual countries to create their own laws. An EU Regulation applies, as is, across EU member states and citizens.
The ePrivacy Regulation is currently being drafted which will replace the ePrivacy Directive, and therefore PECR.
As this law is still in draft form, we cannot take action to comply with it. On the day the GDPR hits, you need to comply with GDPR for data processing and PECR for electronic marketing.
If you have a cookie notice on your site, and you specify the essential (required for the website to operate) and non-essential (such as retargeting cookies like the Facebook Pixel) cookies, you are meeting PECR regulations at least.
There is a lot of conflicting information across the internet, with some suggesting you must gain explicit consent under GDPR before placing a single non-essential cookie on a website visitor. Whilst others suggest that the upcoming ePrivacy Regulation will force internet browsers to allow users to manage their cookie preferences themselves, removing the need for the cookie pop-up that shows on websites today.
What does the ICO have to say about cookies?
All of the ICO’s guidance on cookies sits within the PECR section of their website with no reference to GDPR at all. It seems the ICO haven’t called this yet. They may be waiting for the final version of the new ePrivacy Regulation before providing guidance.
We decided to try and get further clarification.
Any organisation relying on consent to process data will need to ensure it’s ‘GDPR compatible’. In general, GDPR requires a ‘higher level’ of consent than DPA, so is advisable to look at any current notices & check whether they are likely to be compliant with GDPR
— ICO (@ICOnews) March 27, 2018
The issue as we see it:
- Cookies officially sit under PECR, soon to be replaced with the ePrivacy Regulation
- GDPR places more stringent requirements on consent
- The ICO are waiting for the ePrivacy Regulation before providing us with concrete guidance on what we, as website owners, need to do
We don’t blame them, the ICO cannot give us guidance on something which does not yet exist.
Our best guess at meeting cookie requirements under PECR and GDPR
Here at Kabo we’ve decided to continue as normal until we receive formal guidance from the ICO. We assume, hopefully correctly, that until their guidance is updated they are unlikely to prosecute.
- A table containing:
- A list of all the cookies we could identify
- The name of the product/service that creates the cookie
- A description of the purpose, written as clearly as possible without legalese language
- Whether the cookie is placed from our website domain (first party) or from a different website domain (third party)
- The duration that the cookie will remain on the website visitor’s device
- Guidance on how to manage cookies using popular browsers
- Links wherever possible to third parties that place cookies on our website for further information
- A date to show when the policy was last updated
How to carry out a Cookie Audit
Skip this part and revisit your practices after the ePrivacy Regulation has been released.
Personally, for non-developers, I am a fan of the Attacat Cookie Audit Tool. Set up an incognito browser window, install the chrome extension, and run a cookie audit by crawling your website. Fill out some forms, leave a comment, use the LiveChat, share a post on social media, etc.
You’ll be provided with a list of cookies the tool picked up on. Then you can get googling [other search engines are available] until you identify them.
The best method is to use the developer tools in your browser to identify the actual cookies that appear as you navigate your website.
Using Chrome’s Developer Tools to run a Cookie Audit
Open up Chrome and select a new incognito window [CTRL+SHIFT+N on a Windows machine]
Right click and select the ‘Inspect’ option from the menu.
Select Application from the top menu, and then select Cookies from the left hand menu. You should end up with a blank window showing ‘cookies’. This means the web page has not set any cookies at this point.
Next, navigate to your website in this browser window. You should notice the Cookies option in the left hand menu display a drop down icon at this point. Click on it to open it, then click on the first option. Your window should now show a list of cookies.
Create a table to list all of the cookies you find. You want to gather the cookie, name, purpose, type and duration.
Now you can fill out the table with the cookies that have shown up on your home page. Using the screenshot above:
- The Cookie field in your table should be filled out with the cookie name. Our first example is _cfduid
- The Name field in your table should be filled out with the product or service that creates the cookie. Our first example is Cloudflare, which is easy to guess from the domain. The third cookie in the list, _ga is served from our website domain. In order to identify which product or service is creating it the easiest thing to do is a quick internet search. _ga is in fact a Google Analytics cookie.
- The Purpose field requires a little more digging. If you do not know exactly why cookies are being used by a product or service on your website, you need to find out and then describe it in easy-to-understand language. The best way to do this is searching online.
- The Type field is asking if the cookies is first party or third party. A first party cookie is served by your domain, while a third party cookie is served by a third party domain. In our examples in the screenshot above, _fr is third party while _ga is first party.
- The Duration field should list how long a cookie will remain on a website visitor’s device. Look at the expires/max age field to determine how long that is. Work out the number of minutes/days/months/years from the time you carried out the action which caused the cookie to be placed, and you have your duration.
Once you have gathered all of the home page cookies, you should navigate through your website and check if any additional cookies appear. Record any that do in your table.
Things that may create cookies include:
- Comment forms on blog posts
- Contact or sign up forms
- Live chat
- Social share buttons
- Embedded video such as youtube
Click on each page type and interact with all the different kinds of functionality you have on your website.
Bonus hints and tips
Whilst working on our own GDPR compliance, we came across some common products or services.
This chapter contains useful tips for Microsoft email, Google Analytics and information on SSL certificates for secure data transfers.
Have Microsoft email?
An obvious one, but easy to set up. If you use Microsoft as your email provider, make sure you set up an alert to help you delete data past it’s retention point. Navigate to Data Privacy > GDPR Dashboard and then ‘Create a label’ to set up an alert that will either:
- Delete all data after a certain amount of time, or
- Alert you when data passes a certain age so you can decide whether it should be deleted
Use Google Analytics?
If you’ve used Google Analytics for a long time, you may still be running their ‘classic’ version. This was replaced by Universal Analytics a few years ago.
Universal analytics anonymises IP addresses, meaning the IP addresses collected are no longer counted as personal information. If you aren’t sure, it is worth checking and upgrading before the 25th May. Here’s a great article that goes in to more detail by Ryte.
If you are using Google Tag Manager to implement Analytics on your site, it’s slightly more complex. You need to set the ‘anonymizeIp’ variable to ‘true’ yourself.
Why SSL matters
Very simply, an SSL certificate enables data to be transferred securely from the point of data entry (e.g. a form on a website) to wherever it is going (i.e. to be saved on your website hosting server). If you don’t have an SSL certificate, which gives a website the ‘S’ in HTTPS, then you have no secure method of transferring this data.
There is no specific mention of SSL/TLS in the GDPR. However, article 32 does state:
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
the pseudonymisation and encryption of personal data;
the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
SSL/TLS certificates have been around for a long time, are relatively simple to implement and are used widely. Considering these points, I personally would not run a website without an SSL certificate once GDPR comes in to force unless the site did not have any data collection points.
You can get SSL certificates free now from Let’s Encrypt through good hosting providers, and they are relatively painless to implement for a small website.
WordPress GDPR compliance
Version 4.9.6 is currently forecast to release on the 17th May (although this could change). There’s been a huge effort to get GDPR-related functionality in to WordPress core before the 25th May.
It will not automatically make you website compliant, before you take a deep breath of relief and give up on this GDPR thing. However, it should be a great help in meeting some of the essential functionality you will require under GDPR.
Some of the highlights:
- Plugin authors will get guidance on how to make their plugins GDPR compliant, which will help all of us website owners to use plugins that don’t cause us headaches
- A ‘postbox’ idea is being considered, which collects all information from individual plugins on the data the collect and the cookies they store, to help website owners create informed privacy notices
- Tools will be added to export or delete personal information on request (but the action will be completed manually by the website owner to ensure nothing is carried out incorrectly)
- Documentation will be created to help website owners to understand how these tools work, and how to make use of them
The 17th May is not a guaranteed release date however, and is cutting it a little close to the 25th May. It would be worth carrying out your website review and creating your privacy notice before this date, and then reviewing the new tools once they are released.
WordPress plugin compliance
WordPress has a never ending list of plugins. Many of them will process website visitor data in some form.
You need to identify any that collect personal information, such as name, phone, email address or IP address. Obvious ones to check include:
- Contact forms
- Anything related to blog comments
- Live chat
- Membership plugins
- Security plugins
- Statistics and logging
If you can’t work out where they store the data, if it is compliant with GDPR when taking data outside of the EU, or how long the data is stored for you might want to consider finding a replacement.
For example, we will not use Akismet or Jetpack as Automattic have not satisfied GDPR requirements in our view. There’s extensive discussion on Akismet here.
At Kabo Creative we develop websites using Caldera Forms. They are a great team, and are on the forefront of all new developments, be that Gutenburg, forcing users to stop using insecure versions of PHP, and they are pushing forward on GDPR.
Many blogs I’ve read suggest that you stop contact forms from storing data on your web hosting server and just send to email instead.
Whilst that will assist with GDPR compliance, it’s no help at all if an email fails to send. You’ve lost that form for good, which means you have permanently lost a potential lead for your business.
Caldera have confirmed that their plugin will allow you to delete data after a set number of days before the 25th May and will integrate with WordPress core GDPR functionality for data requests. That’s good enough for us, and we’re looking forward to the release of version 1.7.
We are big fans of Drift as a free and easy to use live chat plugin for WordPress. There’s a few key points to help you use this plugin in a compliant way:
- Turn off clearbit.
- If you decide consent is your lawful basis for live chat, Drift now offer the option to add a consent form before a chat begins.
- You can get request a Data Processing Agreement.
- You will be able to request and delete personal data by the 25th
Wordfence is a strong contender in the security plugin market for WordPress. The team have made an announcement that they will be compliant before the 25th May. What we know so far:
- A Data Processing Agreement will be available for customers.
- They have applied for the Privacy Shield Certification.
- We do not yet know if they will be anonymising IP addresses, but they have promised to respond to that question soon.
The latest blog post lists out what they have done so far towards GDPR compliance, and is worth monitoring if you use Wordfence.
Need help with your WordPress website?
We hope this guide to making your website GDPR compliant has helped. For a final time, this is not legal advice, but hopefully it will help you on your journey to compliance.
If your next step is to get a website that works, we’d love to get involved. Fill out the form and we’ll be in touch.