3

Assume the following situation:

There is a cloud-software (SAAS) which is used by a school for basically three things:

Edit: The SAAS was designed with children facilities in mind: Nurseries, daycare-centres, schools, children sport-clubs.

  1. The administrative users of the school manage the school's base-data with it, meaning children, teachers, parents, classrooms, and the relationships between those
  2. Teachers may log in, an post homework, pictures to a timeline, and log absence or presence information of children
  3. Parents may log in to see what teachers posted about their children, report an excused absence, send messages to the teachers, or see any other information shared by the administrative users or the teachers

The SAAS-provider stores the data on servers in the EU, and uses a EU-based transactional mail provider. A DPA is available from both, and the SAAS has signed them.

As to my understanding the company providing the SAAS-software (provider) in this case is the processor.

The controller would be the client of the company (the school) because they decide which data it puts into the system.

There is no relationship between the SAAS-provider and the teachers or parents. They are managed (and their access rights are controlled) by the school administration.

Based on this, the following questions arise for me:

  1. Am I right in assuming that in this case the school is the controller, and the SAAS-provider is the processor?

  2. This would mean that, under GDPR-law, the SAAS-provider needs to provide a DPA and sign it with the school?

  3. The responsibility of having the DPA signed lies with the school, and not with the SAAS-provider? The provider must provide it, and sign it if requested by the school?

2
  1. Under GDPR the Controller is the party which has defined "purpose" and "scope", meaning what the Processor is supposed to do while Processing Personal Data within the scope of a Service being rendered by the Controller.

So, if the Controller has defined what the Software does and the other company has developed the software "tailor-made" as per the Controller's request and now makes it available for the Controller to use it as a Service, then YES, the SaaS Company is the Processor and the School the Controller.

However, most likelly, the SaaS company has developed a Software on its own that addresses "most common needs" of schools, and that makes them also a controller, for they has defined WHAT the SW does... so on that case: - the School is a Controller under that Service Scope - the SaaS company is both a Co-controller and a Processor (since it enables the tool as a Service).

  1. Controllers, being the ones that define "purpose" and "scope" should also be the ones enabling their own DPA for the Processor to sign... if the SW was "tailor-made" at the request of the School, then the School must provide the DPA for the SaaS company to sign. On the other hand if the SW already existed, hence both act as Co-Controllers and since the SW scope is the one that bears most relevancy within the "relationship" and Shared Services, the SaaS Company should provide the DPA for the School to sign (similar to what happens with Cloud hosting companies line AWS or Azure).

  2. It's not a matter of "responsibility" but of "risk mitigation" for the Controller since under GDPR the Controller becomes liable for any non-compliance points on the Processor's side. Again, if the School is the Controller and the SaaS company the Processor, then it is of the utmost interest of the School to have a DPA ratified between both. Nevertheless, and since it is most likely that both act as Co-controllers, it is most relevant for both to have the DPA in order.

  • 1
    I don't think it matters how the software was developed, only how data is processed within the scope of the contract. It is completely normal for SaaS providers to act as a controller in a B2C context and as a processor in a B2B context. – amon Jun 17 at 9:43
  • 1
    A common mistake Amon... If the SW was "tailor-made" the School was the one that exclusively defined "purpose" and "scope", therefore the single Controller. On the other hand if the SaaS Company has pre-defined SW functionalities, it is also a Co-Controller for it defined "purpose" and "scope". – Rui Freitas Serrano Jun 17 at 10:05
  • 1
    Thanks for the comments to far. I tend to disagree with Rui about the fact that the SAAS-provider is a co-controller. The decision which data is actually put into the system is not taken by the provider, and not enforced by the fact that certain data-fields (e.g. "Allergies", "Hobbies") exist. Anyway a controller could "abuse" field named "comment" and store different data (like weight, religious beliefs) which the software never "asked" for. – yglodt Jun 17 at 13:01
  • 1
    yglodt, you are right about the decision about which Data will be input in the tool... however the tool has specific configured "data fields" (name; alergies; age; etc...) and even tough some are "comnon sense" driven, they have either been configured by the SaaS decision or the School decision... making the Saas company a Co-Controller in the first case either we "like it or not" :) – Rui Freitas Serrano Jun 17 at 13:17
  • After reading more about the topic I come closer the opinion that the SAAS-provider might be in a joint-controller relationship with the school. But anyway the SAAS-provider is still also the processor. Opinions? – yglodt Jun 18 at 11:22
1

By default, both the school and the SaaS provider are Controllers. However, the SaaS provider is likely eligible to act as a Processor in this relationship. Processor status is not automatic but requires a DPA to be signed.

A provider might insist on Processor status because it simplifies their compliance, or might refuse this status because they lose flexibility: they cannot unilaterally take on new subprocessors or change the scope of the service, but must act only on the Controller's instructions.

The school should insist on the SaaS provider's Processor status because otherwise the school would need a legal basis that allows the personal data to be shared with another Controller.

So if either side wants the SaaS provider to be a Processor, this should be negotiated clearly. The provider has no obligation to take on a Processor role if they don't want to.

  • You are one step ahead Amon... foreseen problems on the DPA discussion/ negotiation :) they are both controllers only if the SaaS company already had the SW functionalities pre-defined as their offering portfolio and had not developed it per the School-specific requirements. – Rui Freitas Serrano Jun 17 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.