Discussion point: Does processing of SaaS login credentials make you a data controller?

While drafting and negotiating technology agreements, this Kat increasingly comes across an inconsistent interpretation of General Data Protection Regulation as it pertains to the determination of data processing roles when personal data is limited to login credentials, such as person’s name, login identifier and email address, which are necessary to access a SaaS platform. It is not yet clear who acts and on what basis as a data controller and who assumes a processor role within such engagement.

GDPR interpretation alternatives

Processor position

According to what seems the more prevalent understanding, the determination of a data processing role solely rests on answering who hands over the data to whom. For instance, one entity purchases access to a SaaS platform from another entity and, in order to make this access possible for its employees, conveys the names and email addresses of such employees to the SaaS provider. In this case, the  employer is deemed to be the data controller, while the SaaS vendor acts as a processor that processes the personal data to provide certain services to users’ employer.

Furthermore, if the individual users set up their own accounts by directly providing their name and email to the platform (even if they are acting within their professional capacity, e.g. they register with their work email and employer pays for the services), this determination shifts the respective roles by 180 degrees: the SaaS provider becomes a controller and the employer is out of the picture altogether.

Controller position

The GDPR, however, does not expressly focus on who gives data to whom and emphasises instead the decisive element of the relationship of the parties with regards to personal data at stake. According to Art.4(7), the “Controller" means the party, which alone or jointly with others, determines the purposes and means of the processing of personal data, i.e. decides how and why a data subject’s personal data are processed.

In search of a common ground

Advocates of an alternative approach focus on the GDPR requirement set out in Art.4(8), whereby a processor is defined as a party who processes personal data on behalf of a controller. Administrative login credentials are deemed to be separate from the concept of service/product delivery, and are considered necessary for the provider’s own verification purposes. Hence the processing is undertaken on behalf of the supplier and not the customer, thus making the supplier the controller of the data. Notably, the purpose of data processing in the scenario at stake is always the same – to utilise access to a SaaS platform – and is solely determined and driven by the SaaS provider.

ICO guidance

The UK data protection authority - The Information Commissioner's Office (ICO) - has provided checklists setting out  indicia  for determining whether a party is a controller or a processor. Even though these indicia  are not  self-explanatory, the “Controller position”, as described above, seems to be more aligned with the  ICO’s interpretation.

This conclusion may also be supported by the following example that the ICO has shared to help distinguish between controllers and processors.

A mail delivery service is contracted by a local hospital to deliver envelopes containing patients’ medical records to other health service institutions. The delivery service is in physical possession of the envelopes,  but may not open them to access any of the personal data or other content they contain. […] 
The delivery service will not process the personal data in the envelopes and packages it handles. It is in possession of the envelopes and packages but, as it cannot access their content, it cannot be said to be processing (it is not even ‘holding’) the personal data they contain. Indeed, the delivery service will have no idea as to whether the items they deliver contain personal data or simply other information.
This means that, regarding the content of the envelopes and packages it delivers, the delivery service is neither a controller in its own right nor a processor for the clients that use its services, because: 

• it does not exercise any control over the purpose for which the personal data enclosed in the items of mail entrusted to it is used; and 

• it has no control over the content of the personal data entrusted to it. 

The controller (the hospital) that chooses to use the delivery service to transfer personal data is the party responsible for the data. If the delivery service loses a parcel containing highly sensitive personal data, the controller that sent the data is responsible for the loss. So the controller will need to think carefully about the type of service that is most appropriate in the circumstances.
However, the delivery service will be a controller in its own right regarding any data it holds in connection with its provision of the delivery service. […] In addition, to the extent that it records details of the delivery addresses of individuals (the name-and-address information on the items to be delivered), it will be a controller regarding that personal data. If the service arranges timed deliveries or tracking, then any personal data, such as individual senders’ and recipients’ names and addresses it records for that purpose, will be personal data for which the service is the controller.

What are the implications?

If the SaaS provider is indeed deemed to be a controller, then data processing agreement (DPA), required by Art. 28(3), becomes unnecessary. This Kat has seen companies entering into a Controller-Controller DPA, which to her seems redundant (unless there is a joint-controllership scenario), because individual controllers do not need to take instructions from the other party and they can solely decide how and why the data is processed.

It would be sufficient to simply include a contractual representation from a SaaS supplier that such data will only be used for verification purposes and that the vendor warrants compliance with applicable data protection laws. A SaaS business, in turn, should seek a warranty from its customer that all data is collected and provided in compliance with the applicable data protection law.

Since this aspect of the construction of the GDPR has yet to be clarified by the data protection authorities and the judiciary, it would be great to hear what insights other data protection enthusiasts might have!

Image Credits: GlobalP