The importance of data protection roles in product development

Summary

Correctly choosing whether you are a controller, a joint controller, or a processor is important not only from a compliance perspective. It should take into consideration the future needs for data for your product and will largely direct its development. 

Intro

The traditional division between the controller and the processor historically relied on a distinction between a party connected to the data subject (for example a customer) and an invisible service provider taking over some specific task that would facilitate delivery.

This division is gradually becoming outdated and we can question if it is still fit for purpose. Yet, they are the roles that are given to us, unless you are in Australia, where the data protection law does not include the concepts of controllers and processors. Hence the need to master the strategic choice between the two and navigate them for your benefit.

While relying on this division we recognise two main roles:

• the controller: held accountable for the data and able to define the purpose and means of processing;
• the processor: who serves the controller with the fulfilment of specific tasks on its behalf. 

There are also two-subgenres of those roles: 

• the sub-processor: being tasked by the processor to fulfil a part of its work for the controller. This effectively creates a chain of controller – processor – sub-processor;
• joint controllers: where the purpose of processing is jointly decided by two entities which consequently become jointly responsible for the data.

The legal shift from processorship to (joint) controllership 

There is a developing trend of shifting the role of processor towards the domain of controllership or joint controllership caused by the fact that the service entity in some way benefits from the data processing. This is driven by authorities with the overarching thought that entities that directly or indirectly draw benefits from the data processing should be co-responsible for the data and that more controllership means more protection for the data subjects, more overall accountability and ultimately enhanced data protection.

One could of course argue against the position that more controllers equal better data protection. To date we have seen little enforcement against controllers making the contractual responsibility of the processor towards the controller a more effective mechanism working in parallel with the obligations of the processor under GDPR.

An example: Product improvement. Personal data (even when ultimately anonymised or aggregated) typically fuels the development of the product. Valuable insights are often gained by assessing the way users use the product, or errors they encounter. That development is essential for long term success even when the app is not provided directly to consumers but as a white label product or to businesses that provide it to their own employees. Authorities consider that the service or app provider that traditionally was considered a processor should now be seen more in the controller role – due to the provider’s separate use of data for product development. 

One of the first instances where this was brought up was the question of the role of Microsoft when offering its cloud services, where Microsoft historically positioned itself contractually as a processor. The Dutch authorities questioned whether Microsoft was solely a processor in this b2b context for a subset of data.

In response, Microsoft changed its stance and is now a controller when they “process data for specified administrative and operational purposes incident to providing the cloud services covered by this contractual framework, such as Azure, Office 365, Dynamics and Intune. This subset of data processing serves administrative or operational purposes such as account management; financial reporting; combatting cyberattacks on any Microsoft product or service, and complying with our legal obligations.”

Also, the CJEU has touched on the topic of roles and analysed the division of roles between Facebook and the companies who use it to promote themselves (in the Wirtschaftsakademie case). One of the important points raised: defining the criteria for drawing of statistics, or designating categories of persons whose data should be collected, are some of the aspects that tare decisive in becoming a controller. It seems that legally speaking, impacting the extent of the collection is one of the decisive aspects that makes an entity a controller.

Positives and negatives of each position

Is there a “better” position to be in? Should you try to become a controller at all cost? Not necessarily. Below are some of the most important particularities of the controller position, The positives have mostly to do with deciding how to use the data and include:

• Defining the purpose (so what is done with data) and accordingly re-purposing the data and using it for your own legitimate interest or research 
• The ability to anonymise the data and then using it freely (or possibly marketing the insights gained through this process)

The negatives have to do with the ultimate responsibility for data and responsibilities towards the data subject:

• Assessing and documenting the appropriate legal basis, and when appropriate, performing the DPIA
• Handling the communication with data subjects for transparency’s sake, and with data subjects and authorities in case of breaches
• Fulfilling on data subject rights, including informing the data subject 

So, can I freely choose my processing roles? 

Yes and no. According to CJEU, whether one is a controller or a processor is FACTUAL and cannot be changed contractually. That means that if you are a controller you cannot become a processor simply by signing a DPA. You will remain a controller with the wrong contract. However, that does not exclude designing your product so that you are more likely to be a processor, or a controller, depending on which of those roles is more suitable. 

In practice, that requires considering how you plan to develop your product in the long-term and what your future data requirements are likely to be. 

Again, an example to illustrate this point:

A b2b platform that facilitates food deliveries (and feel free to exchange this with just about any platform that works b2b2c – Apps? Tickets? You name it.) 

1. When designing this the first question would be who your customer really is– is this only the business, and do they merely pass the data to you, or through your service?

Or rather, is it that your facilitation has some sort of direct contact with the data subject, which is not necessary but welcome? Could you argue that you deliver value to the data subject that is separate and apparent to the individual?

On the one hand you could say that you are a processor of each of the restaurants on your platform because you offer them a specific service that facilitates the ordering of the food and management of the order. But you could also say that you are providing the service to the individual and aggregating the different restaurants for them. They order via your webpage and may then even sign up with an account with you.

2. Who decides what will be done with the data? The businesses for whom you work? Or maybe you do so with them jointly?

Legally there is a distinction of the so-called essential elements of processing and the essential technical aspects. If you decide on the essential elements and are the driving force for which data is collected and why it is collected, you are likely to be the controller. On the other hand, if you decide how to technically perform even the essential tasks, but don’t affect how the why and what elements are collected, you typically would be the processor.

Are the decisions about which data is collected done at the singular business level with whom you collaborate, or is it that you largely drive that process and decide what data and about whom it is collected?

3. Is there any data that you collect for your own sake and don’t share with the controller? (and for which the controller would not have any use)?

Are you doing advanced analytics and product improvement for your own sake? Or maybe you look at trends on a larger scale that reaches beyond what the restaurants might have need for? That would indicate you are working on your own behalf instead of just delivering specific task to the restaurant as a controller.

As you will notice, both of those models are potentially available, and you can make the decision in the direction of each of them. The distinctions here are not always very clear and some margin for interpretation is left in the hands of the company. Practically, that might mean that you have a degree of freedom to arrive at the doorsteps of the businesses with whom you cooperate with just the right agreement – for you and your product. If you will have no clarity on this point you are likely to end up as a processor. It might be the right option, but it may also end up limiting you in the future.

P.S. If you require any help understanding whether you are a processor or a controller we offer face to face online conversations and data protection courses (which are fun and engaging) to help you make the right strategic choices.