Controller processor roles for a SAAS for schools

Question

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?

Answer 1

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).

2. 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).

3. 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.

Answer 2

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.