GDPR and the expected implications

GDPR and the expected implications


By now, most companies who do any business in the EU are aware of the General Data Protection Regulation (GDPR), which was approved by the EU Parliament on April 14, 2016, and goes into effect on May 25, 2018.

The GDPR replaces the Data Protection Directive 95/46/EC. Organisations found in non-compliance will face heavy fines: €20 million or 4 percent of global revenue per infraction. This could mean millions, or even billions of dollars in fines for large companies.

Anyone who collects and processes personal data (defined by the GDPR as a Data Controller) will be required to comply with the new regulations to a certain degree.


This includes websites and apps, and also internal databases, CRMs or email.


In many ways, those that are following best practices from a Data Protection are well covered. You may need to include more information in your privacy notices, but we believe that if you follow good practice recommendations already you will be well placed to comply with the GDPR regime.


There is still discretion for data controllers to consider where the information required by GDPR should be displayed in different layers of a notice. This is probably the key message here.

It will be essential to adopt innovative technical means for delivering privacy information such as layered and just in time notices – in order to be effective and to comply. In other words, before any information is collected from Cookies to Brochure Requests to Purchase. Data collection needs to be inactive before consent is given.

Effective User testing will help you to comply with the new provisions of the GDPR, as well as the current requirements of the DPA.


The GDPR says that the information you provide to people about how you process their personal data must be:

  1. concise, transparent, intelligible and easily accessible;
  2. written in clear and plain language, particularly if addressed to a child; and
  3. free of charge

These requirements are about ensuring that privacy information is clear and understandable for all data subjects. GDPR requires you to state what data is being processed and why (essential).

Additionally, you are required to inform data subjects for how long the data will be stored. You must also state who the subject should contact regards to any part of your data processing actions. That is a significant amount of information that should vary and not be a blanket notice


The explicit emphasis on adapting privacy notices for children goes beyond what is currently required by the DPA.

Those that process children’s data will need to take account of the level of comprehension of the age groups involved and tailor their notices accordingly. The code seeks to address this in relation to making privacy notices accessible.


By default, privacy settings should be set to their highest level with a user given options to downgrade this if they choose to. As many social media users know, social networks often work in the opposite way to this! Data controllers should also be ensuring that data is only being processed when absolutely necessary.


Under the GPDR a data subject has the right to erasure of their data. This means that if an individual asks you to remove their data from your systems you have to comply. All backups, all references to and so on. Everything.


The GDPR includes a longer and more detailed list of information that must be provided in a privacy notice than the DPA does. There are also some differences in what you are required to provide, depending on whether you are collecting the information directly from data subjects or from a third party.

This distinction is key.


From a database perspective, the GDPR makes reference to something called pseudonimisation.

In other words, this is a process to transform data that stops it from being attributed to a data subject (an individual) without the use of additional information.

An example of this could be using a unique reference ID for someone rather than their name when storing their data in a database. A 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 possible the most ambiguous part of the GDPR as it relies (to a certain degree) on how you interpret it.

An often-mentioned aspect of pseudonimisation is encryption. Data is encrypted and requires a key (stored separately) to decrypt it. Sites that use HTTPS send data over an encrypted connection so you could argue that if your website has an SSL certificate you’re on your way to GDPR compliance.

In our view though, the data in the database itself needs to be encrypted too. This applies to CMS too.


The GDPR requires you to have suitable processes defined 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.


All public authorities and any organisation that processes personal data (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 in to this category we think that it is a good idea to appoint a DPO. This person can keep data protection high on the organisation’s agenda and ensure that GPDR compliance is achieved and then maintained.


  • Clearer explanations of what data and why is collected
  • Before any data is collected
  • Information layering at the point of collection is key
  • Say it in plain English
  • Write it for the audience, especially children
  • The default is the highest-level setting of privacy
  • Don’t forget your 3rd party data collection
  • Right to be forgotten functionality needed
  • Encrypt your database and design it properly
  • Have a process in before anything happens
  • DPO needed


Leave a reply

Your email address will not be published. Required fields are marked *