Unless you have been implementing an 18-month media and digital detox, you will have doubtless heard of the General Data Protection Regulation (GDPR) coming into force on 25 May 2018, replacing the Data Protection Act 1998.
If like me, you have also been receiving multiple daily emails from consultants promising to remove the compliance tasks from your to-do list you will also probably hate it but, believe it or not, GDPR is a good thing!
We are sure you value your personal privacy – your name, address, date of birth, place you were born, your favourite pizza order or even all your cab trips from A to B.
To avoid these situations, we all have to play our part with GDPR compliance and your corporate website is one communication channel that must not be overlooked. Whilst you may not be in the business of selling to consumers or requesting application data there are still a number of fundamental areas for consideration.
Whilst the clock is ticking and we are now in final countdown, for many corporates, getting your website GDPR ready is not overly onerous so here is generic checklist that could help you in the final GDPR sprint. Use these tips as you will but (...here comes the small print) please remember each site is different, the regulation itself is still evolving and this is not an exclusive list and nor is it a substitute for receiving legally qualified advice.
Not all cookies are used in a way that could identify users, but some are and under the GDPR users should be provided with information on how these are going to be used. The best practice would be to list all cookies in tables and clearly explain what they are used for, where they come from (provider), when they expire and the cookie type.
2. Cookie disclaimer
The majority of cookie disclaimers are based on a soft opt-in, in fact we are all familiar with the text ‘by using this site, you accept cookies’. Under GDPR if there’s no valid consent option, it does not count as consent at all.
Some websites seem to have found a way around this by selecting all cookies as ‘on by default’ and asking users to change their browser settings by ‘blocking all cookies’ if they wish to. We believe this is not acceptable. GDPR states that it must be as easy to withdraw consent, as it is to grant it. Users must be given the information and granularity to block individual cookies to not degrade the user experience and to ensure clarity around how cookies are being used on a site.
4. SSL certificate
GDPR is all about personal data protection and trust. Sites with online contact forms, a sign up to RNS, newsletter or sites with a career section where candidates can apply for jobs would most certainly collect personal data and therefore must be secured with an SSL certificate. However, in general, it is good practice to use an SSL certificate even if you don’t collect personal data as it is a good way to inform your web visitors that you care about their data and your websites provide a good trusted online connection. You can learn more about SSL in another one of our other recent posts.
5. Newsletter/RNS signups, enquiry and application forms
At the point of collecting personal data, the website must:
- Inform users why personal data has been collected and what you intend to do with it.
- Prompt users to OPT-IN (and not opt-out) in processing and/or collecting personal data. You must have a separate OPT-IN option if personal data is going to be shared with another party or for each intended use if different from the main one. For example, the contact page of your site has an enquiry form. It is obvious that users will be using this to request a call back or to ask a specific question. On this basis, you can’t also use the information provided to automatically signup them up to a monthly newsletter.
The website should also avoid storing personal data on the database or server unless this is encrypted. However, in most cases, websites do not need to store personal data as this should be immediately sent to the data processor.
Another important part of GDPR is to consider what information you are collecting and the lawful basis for doing so. You should only be requesting absolutely necessary data for the task in hand. If you are offering sign-up to a monthly news email, there is no immediately obvious need to request date of birth, physical address details or similarly broad personal information.
‘Pseudonymisation’ means that websites will need to start moving towards the removal of personal emails for identification, unless there are strong reasons for not doing so, and instead utilising a generic ‘category’ email address. For example, if you have to provide an email address on the careers section so that candidates can apply for jobs you may want to consider a generic email address like firstname.lastname@example.org instead of email@example.com. Similarly, where individual offices may wish to provide the name of a local staff member to appear more personal, we would still advise a more generic contact email is used, for example firstname.lastname@example.org for the Hong Kong office contact.
7. IP Masking
By default, Analytics use the entire IP address of website users to provide general geographic reporting. When IP masking is enabled, Analytics removes the last octet of the user's IP address prior to its use and storage. This does slightly reduce the accuracy of geographic reporting but not a lot and it’s a price worth paying especially if you are not using that information.
The hosting and its security also plays a big part in the protection of personal data. The cloud provider of your choice must also be GDPR ready and you must assure that server updates are periodically applied so any discovered vulnerabilities are patched. When appropriate you should also enable encryption at rest. If you are trusting SampsonMay with this, our fully managed hosting will have this covered for you. SampsonMay hosting data resides within a Microsoft Azure Europe region and AWS Europe region. It inherits the policies and protections afforded by this residency. Data is stored using Local Redundant Storage which means every request made against data in your storage account is replicated three times within the region. The three replicas are spread across domains to ensure that data is available even if hardware failure impacts a single rack and when nodes are upgraded during a rollout. Updates are applied on two levels, the physical servers and the guest virtual machines (VMs) that run the App Service resources. Both are updated monthly and automatically, in a way that guarantees the high-availability SLA.
10. CMS security
CMS updates are also important for the security of your website data. You must periodically apply these updates. Some updates are very smooth to apply and are intended to fix bugs or improve the CMS overall security. However, others are designed to change the way the CMS works and so they require parts of the code to be reworked. This has obvious cost implications but it is worth considering in the light of the upcoming 25th May GDPR launch. Also, from both a housekeeping and security perspective, user admins should frequently check authorised CMS users to make sure that only approved users have access to your account, helping to keep your information in the right hands.
11. Vulnerability tests
Article 32 of the GDPR requires organisations to implement technical measures to ensure data security. Although Article 32 gives examples of security measures, it does not provide a comprehensive list. It motivates organisations to find, implement and revise effective security measures in light of the dangerous and rapidly changing information security threat landscape. We recommend vulnerability testing to be completed every year. This test aims to determine whether and how an attacker can gain unauthorised access to assets that affect the fundamental security of your system. It provides real-world security testing of the security controls you believe are in place and functioning effectively.
As referenced at the start of this article, this is not an exclusive list and nor is it a substitute for receiving legally qualified advice or examining your own procedures and methods in depth but hopefully it serves to provide some initial insights into the areas you need to consider in order to ensure website compliance under GDPR.
If you would like to chat further around the above then please do not hesitate to get in contact with us.