Privacy Law in Practice – An Insight into Data Protection Law as an In-House IT Lawyer – Madeleine Weber

Welcome to Privacy Law in Practice, our series at TPP demystifying what it is like to practice in privacy law.

Have you ever wondered which data protection law issues come up in practice? It obviously depends on the industry and area you work in, but data protection law might be more prevalent than you think.

I completed an English LLB law degree in 2016, and an LLM in 2017. Back then, there were few options to study data protection law modules. Little did we know that data protection would become a very important area of law (and one I wish I had learned about a lot sooner!)

Back in February 2018, I started working in the in-house legal team of a software company. Coincidentally, the EU General Data Protection Regulation (the “GDPR”) came into effect in May 2018. Suddenly, I was drowning in data processing agreements – negotiating, drafting, debating data protection issues that I had little (or no) clue of.

To give you a bit more background, I work for software vendors that sell software as a service (“SaaS”) to other businesses. SaaS is software that is hosted, managed and run online by the software provider. A bit like Netflix, which is a subscription service hosted online that provides you access to films and series – you don’t need to do anything other than pay for the subscription fee to access it. SaaS providers rely on the same business model – for example, my current employer sells security software as a service. It basically sells subscriptions to companies which enable their employees to use the internet and access their internal applications securely.

With SaaS, often it is the case that any personal data inputted into the software by a customer can be said to be processed by the software provider. Where usernames and personal details are uploaded to the SaaS to create user profiles, for example, these are personal data that are controlled by our customers (the data controllers – as they are the ones who control which data will be inputted into the software) and deemed to be processed by software providers (the data processor – as they process any personal data uploaded to the SaaS).

Under Article 28 of the GDPR, it is a legal requirement for data controllers to have a contract in place with data processors, containing certain matters, such as a contractual requirement that appropriate security measures apply. Therefore, customers of SaaS often require their software suppliers to enter into a data processing agreement (“DPA”).

Therefore, in my role as in-house counsel of a software vendor, I work on DPAs and data protection matters on an almost daily basis. Over the years, I noticed that the issues that arise tend to repeat themselves.

Here is a little rundown of data protection issues that come up frequently in my day-to-day work:

1) Whose standard applies

Many organisations are policy-driven and insist on having their standard DPA apply, to enable them to tick the “our standard DPA” applies. However, as a software vendor with thousands of customers for which we process personal data in the same way, adapting customer standards to ours is a tedious process. The thing with data processing is that it is quite factual. Which security measures apply, what happens when a data security incident happens, in what timeframes certain actions are taken etc. are all set processes which cannot be adapted for individual customers.

Customers can adhere to their legal obligation by simply having a GDPR-compliant data processing agreement in place – there are more ways than one to comply with the obligation. By contrast a software supplier cannot have a bespoke process for each customer. Therefore, the starting point should always be the supplier standard. This is, however, often a debate and requires convincing from the supplier side that it makes more sense to start with the supplier standard DPA.

2) What to include

The GDPR sets out in Article 28(3) what needs to be included in a DPA. As with many things in the GDPR, there is room for interpretation. Some people insist on including every single technical detail into a DPA, whilst others don’t mind more or less copying and pasting the provisions of Article 28 and signing that. There is a degree of subjectivity involved as to how detailed a DPA should be. For data processors, it is important to ensure that the agreed DPA is not so restrictive, that it is impossible to change or add a process, without negotiating an amendment.

For example, if the following measure is included into a DPA:

“Anyone having access to the personal data will be required to set a password containing no less than 12 characters, including a capital letter, a number and a symbol.”

it would require an amendment if the password policy should ever change within the processor’s organisation (which it very well could do.) Therefore, it is wiser to maintain a degree of flexibility with these things and agree, for example:

“Anyone having access to the personal data will be required to set a strong password in accordance with the then applicable password policy.”

3) Where is personal data transferred

Another issue that is almost always discussed is where the personal data will be transferred to. Under the GDPR, if personal data is transferred to a jurisdiction that is not recognised as an adequate jurisdiction by the European Commission, organisations need to rely on transfer mechanism recognised by the GDPR. Many organisations are concerned with data transfers into certain jurisdictions (especially after the Schrems II case ), and often ask for personal data to be kept within the EEA. Often, this is not practicable, for organisations which operate internationally. Many software vendors, in particular, are not able to provide a service which is limited to just the EEA, because for example, their support personnel might be based around the globe.

Where customers are concerned about data transfers, it is important to reassure them that the same security measures apply regardless of where the personal data is transferred to. It is also important to have adequate GDPR-compliant transfer mechanisms in place, such as standard contractual clauses. With these reassurances, it should be difficult for the customer to argue why their personal data can’t be transferred internationally.

4) Liability

Liability is a common sticking point between processors and controllers. In the event there is a data breach caused by the processor, and subsequent damages arise (for example, in the form of fines or data subject compensation requests), these can be substantial. Controllers are keen to be protected in such cases and have the ability to obtain damages from a processor in such a situation.

On the other hand, processors need to limit their exposure in the event something happens and they have multiple claims on their hands that they are unable to meet. Therefore, most processors will fight heavily to ensure their liability is limited to a certain amount.

Particularly, as a SaaS vendor where all customers sit on the same online solution – the risk is very concentrated (an incident might not just affect one customer, but several customers simultaneously). It is important to make controllers understand that limiting liability is often a necessity for processors to protect their business from going bust in future (which is also in the interest of the controller).

5) Alternative legal frameworks

It is important to remember that the GDPR isn’t the only data protection legislation that needs to be complied with. In some cases, other legislation needs to be considered. For example, a customer with multiple affiliates in the EU and South Africa will be subject to not just the GDPR, but also the South African Protection of Personal Information Act. The DPA will need to reflect both jurisdictions’ requirements.

Many data protection laws are similar to the GDPR, but some are also quite different. Therefore, it is important to do research where necessary, and add contractual provisions as required by applicable laws.

There are many ways in which data protection can arise in practice, especially when working in-house (be that on the supplier, or the customer side). It is important to have a basic understanding of data protection law. Doing the Certified Information Privacy Professional Exam/Europe (the “CIPP/E”) was very helpful to consolidate my GDPR knowledge, and is one very good way of obtaining a foundation in data protection law.

The CIPP/E is a multiple-choice exam and provided by the International Association of Privacy Professionals (see iapp.org). If you are interested in sitting the exam, I have a number of free and paid resources to help you prepare for it at inhousew.com

Additionally, it also helps to have a certain amount of technical knowledge to ensure you understand what personal data is collected and why, and how it is handled, etc. This is something that can only really be obtained within the organisation you work by talking to the engineers, coders, IT security experts, etc. It is very easy to focus purely on the law and forget about the technology that requires the processing of personal data.

However, there is no point in being a legal expert who does not know of the technical realities that make the law applicable. You need to know a certain amount about both the law and the relevant technology to be a successful data protection lawyer.

If you are a privacy law practitioner and would like to share your insight into practice in this series, please contact us at TPP.

2 thoughts on “Privacy Law in Practice – An Insight into Data Protection Law as an In-House IT Lawyer – Madeleine Weber

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s