How To Become GDPR Compliant

What Is The GDPR?

GDPR stands for the General Data Protection Regulation and is a new EU regulation designed to increase data protection for EU citizens.  Its purpose is to make companies protect the personal data of their customers with hefty fines of up to 20 million (or 4% of annual turnover, whichever is greater) for companies that don’t comply with the laws.

Anyone who is what is defined as a data controller – someone who collects and processes personal data will have to comply with the new regulations, as well as companies who run websites or apps.  This also includes any organisations that use internal databases, CRMs or even just plain email.  This new regulation will be coming into effect on the 25th of May 2018.

Help Your Website To Become GDPR Compliant

Here we will talk about a few steps to help you on the way to becoming GDPR compliant.

1) Data Protection Officer

A DPO is an individual or individuals designated by the Data Controller to be responsible for monitoring the internal compliance of the GDPR within the organisation. This could be a specifically trained employee within the data controller’s organisation or a position that is outsourced. Unless you are carrying out large scale processing of personal data a suitably informed in-house member of staff should be perfectly sufficient for this role.

2) Fair And Private Policies

You will probably have to update your fair processing and privacy policies that are listed on your site. Review whether the information that you provide is explicitly clear. If something is happening with peoples data that they cannot clearly ascertain from the information that you provide, then you will need to make some changes and let them know.

Be sure to put in place a process for regularly reviewing and updating your fair processing information. It must reflect what you’re doing now, not five years ago.

3) Strengthen Your Weakest Areas

During your personal data audit, any weaker parts of your website should come to light. Examples could be insecure (unencrypted) email accounts or website traffic. Another example might be contact form submissions that have been saved to your website’s database. These have likely long since been acted on or replied to so they no longer need to be kept. Whatever the weak links are you should aim to strengthen or remove them.

4) Requests For Data Deletion

The right to be forgotten (Article 17) is perhaps the new data subject right causing most discussion. It’s easy for organisations to collect data about individuals but how will you go about forgetting someone? If you are required to action a request for data removal under this right, you must be able to remove the data from all sources where you hold it. This includes backups. It is wise to develop a process now to ensure you can action such requests

5) Pseudonymization^* Of Data

If you are storing personally identifiable data on your website then you really need to be working towards pseudonymising this data. This is quite a technical undertaking and as mentioned underneath, a lot of the CMS developers seem to be arriving late to the party.

^*The GDPR refers to something called pseudonymization. Put simply, this is a process to transform data in a way that stops it from being attributed to a data subject (an individual) without the use of additional information. An example of this might be using a unique reference ID for someone rather than their name when storing their data in a database. The second table of names and corresponding IDs stored on a separate system would then be used to join the tables together and recreate the data. In this way, if a data breach occurred and the personal data was stolen, the data wouldn’t expose actual names just the additional data.

This is the most ambiguous part of the GDPR as it relies (to a certain degree) on how you interpret pseudonymization. An often mentioned example of pseudonymization is encryption whereby data is held in an encrypted fashion and requires a key (stored separately) to decrypt it. Websites that use HTTPS send data over an encrypted connection so you could say that if your website has an SSL certificate you’re on your way to GDPR compliance but the data in the database itself is likely stored unencrypted so if the database was breached the personal data would still be exposed. No CMSs that we’ve ever used have stored personal data in a truly pseudonymous way. We wait to see how WordPress and the other major CMS players address this.