Happy 4th Birthday GDPR!

Let’s join hands and sing a merry tune;

It’s time to blow up a balloon;

For today we celebrate the four years we’ve spent;

Processing data and getting consent!

Happy birthday, GDPR!

I remember the first time I heard about the General Data Protection Regulation. It was described as ‘revolutionary’, as well as the biggest shake-up of data laws the world had ever seen. To be honest, it left me quaking in my paralegal boots. Now, I often describe the GDPR as the ‘gold standard of data protection’, because that is exactly what it represents. It’s the tough, fine-imposing, fear-inducing privacy standard that every individual who uses the internet wants fighting in their corner, a shining beacon of hope in an age characterised by what can only be described as data abuse – breaches and monetisation without any kind of individual awareness, consent or recourse. 

When the European GDPR came into force back in 2018, its far-reaching impact, together with a distinct lack of specifics made compliance a daunting prospect – particularly for SMEs. Businesses were suddenly being advised to get to know their data flows and establish whether they were ‘data controllers’ or ‘data processors’, the need for privacy policies being at the forefront of every wary business owner’s mind. However, the more we understood, the more we benefited. Trust between organisations and consumers drastically improved, as individuals were finally able to gain back control over their data. 

It’s all about compliance (it ain’t rocket science)

As somebody who has witnessed such a monumental transformation to the data protection landscape, it is important to recognise all that we’ve achieved in light of this regulatory ‘blueprint’ that is now being replicated on a global scale. GDPR compliance is such a significant part of my role, that I’ve been asked to give you an insight into my day-to-day. While I can’t delve into the specifics, I can offer a general summary in the only way I know how – by using the ‘GDPR’ as a different kind of acronym, each letter representing a common compliance consideration cropping up in my everyday working life.

‘G’ is for global

The GDPR is somewhat peculiar, in that it applies to organisations that have nothing to do with the UK. When the GDPR came into force across Europe, its effect was intended to be ‘extra-territorial’; that is, it served to protect personal data belonging to EU citizens, whether the organisations handling that data were EU-based organisations or not. This means that if you are based outside of the EU or UK and offer goods or services to EU/UK citizens or monitor their behaviour (eg track their IP addresses on your website), then the GDPR applies, in particular, the bit on ‘restricted transfers‘. 

In short, the GDPR forbids transfers to what it calls ‘third countries’ unless extra protections are put in place. The United States of America is a classic example of a third country, meaning that any transfer of personal data belonging to UK/EU citizens to the USA would be deemed a restricted transfer requiring additional protection.

The GDPR sets out a number of potential protections you can adopt when making such transfers, one being the (now infamous) Standard Contractual Clauses (SCCs). Interestingly, the UK now has its own set of Standard Contractual Clauses, which came into effect in March 2022. If you transfer personal data belonging to UK citizens to third countries like the USA, then I highly recommend that you explore these further, or Ask a lawyer.

‘D’ is for data processing agreements

When data processing of any kind is going on in an organisation, a Data processing agreement (or ‘DPA’) needs to be in place. Over the years, I’ve come to appreciate how wide the concept of ‘processing’ really is under the GDPR, for it encompasses everything ‘done’ to data, such as recording and storing it. DPAs are important documents governing the relationship between data controllers and data processors, and oblige data processors to do certain things, like ensuring any data transferred to them by the data controller is safe and secure. To spice things up a bit, a DPA must also be in place between data processors and any data processors they engage (known as ‘sub-processors’). 

Allow me to illustrate:

  • Company A determines the types of personal data which are to be processed and the purposes of the processing. As Company A also decided to collect personal data in the first place, it is a data controller. 
  • Company A wants to store its customers’ personal data in the cloud, and so engages Company B (a UK-based cloud provider) to carry out this processing on its behalf, making Company B a data processor. 
  • To be GDPR-compliant, Company A and Company B must enter into a DPA. As both companies are UK-based, there is no need for any extra protections, which are reserved for ‘restricted transfers’ only.
  • Company B decides to engage a data processor of its own – Company C – to help with the processing of Company A’s data. This means Company C is a ‘sub-processor’, and so must enter into a DPA with Company B. Further, Company C is based in the USA, making the transfer of personal data to it from Company B a ‘restricted transfer.’ Company B must, therefore, ensure one of the protections (eg the SCCs) is in place before making the transfer. Before engaging Company C, it is also important that Company B gets permission from Company A (for it’s Company A’s data after all).

‘P’ is for policy

The GDPR is renowned for obliging data controllers to provide certain policies and notices, not just to its customers, but internally also. Some of the main ones include:

  • A Privacy policy, which is a crucial document if you are collecting personal data (for example) via a website.  
  • A Data protection and security policy sets out how an organisation protects personal data. Such a policy explains to staff what the requirements are under the GDPR, demonstrating its commitment to compliance.
  • A Privacy notice (for employees) and one for consultants, a document that is essential for compliance, serving to promote transparency and provide individuals with more control over the way their data is used.

‘R’ is for risk 

The very nature of the GDPR dictates a risk-based approach to compliance, meaning organisations should implement protective measures corresponding to the level of risk of their data processing activities. For example, if you find yourself needing to process ‘special category’ data (such as biometric data), you’ll need to ensure you carry out a risk assessment in the form of a Data Protection Impact Assessment (or ‘DPIA’). Special category data warrants a much higher level of protection under the GDPR, the reason being, that any processing may affect the rights and freedoms of individuals. Therefore, it is important to establish what the risks are, and figure out ways how to minimise them. 

A [privacy] design for life

Whenever you start something new, it is important to adopt what is known affectionately in these circles as a ‘privacy by design and default’ approach – ensuring data privacy and security are ‘baked in’ right from the very outset, and all the way through the lifecycle of a project. The compliance considerations I’ve mentioned are just the tip of the iceberg, so it’s important to get some lawyerly assistance to help you navigate it all.

 

Lauren Delin

RELATED POSTS