May a SaaS provider qualify itself as a processor in its terms and conditions?

May the provider of an online identification service position itself as a processor in its general terms and conditions when it has designed the entire set-up of that service itself? No, rules the Data Protection Authority (DPA) Litigation Chamber in decision 103/2026 of May 12, 2026. Isabel SA is fined 120,000 euros for its TruliUs identification service for violating the principle of responsibility under Art. 5(2) General Data Protection Regulation (GDPR), plus a reprimand for the transparency, access and minimization violations that result from that misclassification. The reasoning extends beyond this one case and affects every B2B SaaS provider that positions itself as a processor through its terms and conditions.

The facts

The plaintiff is manager of a company that uses an external accountant for its accounting. That accountant in turn works with an online accounting platform on which customers can upload their documents. In order to identify himself on that platform on behalf of his company, the complainant had to use the TruliUs service - an identification and authentication solution for companies developed by Isabel SA, similar to itsme but specifically designed to prove that a natural person can legally act on behalf of a legal entity. TruliUs relies on itsme as the underlying identity verifier for this purpose.

On March 29, 2021, the complainant files a complaint with the DPA. He raises two objections. First, he notes that the privacy statement on the TruliUs website reflects only a fraction of the data effectively accessed through itsme - more than ten data points, including nationality, eID photo, place and date of birth, eID number. He then notes that his access requests of March 11 and 19, 2021, went unanswered.

The Inspectorate formulated four findings: defective prior information (Articles 5(1)(a), 12(1) and 13 GDPR), disregard of the right of access (Articles 5(1)(a), 12(1) and 15(1) GDPR), violation of the minimization principle and of protection by default (Articles 5(1)(c) and 25(2) GDPR), and violation of the principle of responsibility (Article 5(2) GDPR). Isabel defends itself by arguing that it is only a processor for the authentication and identification activity and that all these obligations fall on the customer - the plaintiff's company.

The decision

The Litigation Chamber first answers the question whether Isabel is a processor or a data controller within the meaning of Art. 4, 7) GDPR for the authentication and identification activity within TruliUs. It qualifies Isabel as a processor and builds that qualification on four pillars.

First, the Litigation Chamber examines the purpose. Isabel itself conceived, developed and marketed TruliUs in October 2020. Its purpose - to provide a solution that allows natural persons to identify themselves on behalf of a legal entity - was determined unilaterally by Isabel prior to any contractual relationship with a customer. Relying on the ruling of the Court of Justice in IAB Europe (ECJ March 7, 2024, C-604/22), the Chamber points out that whoever drafts and controls the rules of a data-sharing system thereby already becomes a data controller - never mind that Isabel here went far beyond mere rule-making.

Next, the Chamber analyzes the essential means of processing. Isabel unilaterally defined what data would be accessed through itsme, what categories of individuals would have access, how long accounts would be kept (a 13-month deletion period for inactive accounts), what partners data could be shared with, and the entire technical architecture. That the customer could theoretically choose which data to collect remains “highly theoretical,” according to the Litigation Chamber - in practice, all data points defined by Isabel were collected by default, including those the accounting platform did not need.

The Chamber then rejects Isabel's analogy to a standardized cloud service from the EDPB Guidelines 07/2020. A cloud provider provides a neutral technical infrastructure in which the customer decides what data to store, why and for how long. With TruliUs, this is fundamentally different: Isabel determined not only the infrastructure, but also the purpose, data categories, retention periods and recipients. The customer was merely using a service whose parameters were completely pre-filled.

Finally, the Litigation Chamber points out the absurd implications of Isabel's contention: if the plaintiff's company were a data controller, the plaintiff would have had to provide himself - as the manager of that company - with information about the data collected by Isabel, and exercise his right of access against his own company for data held by a third party. That would be contrary to the useful effect of the GDPR.

The Litigation Chamber concludes that Isabel is a data controller, and that the other three violations (lack of information, refusal of access, excessive data collection) derive directly from this misclassification. It therefore imposes a single fine of 120,000 euros for the violation of Art. 5(2) GDPR - the breach from which all the others stem - with a reprimand for the derivative violations. This choice finds support in Art. 58(2)(i) GDPR and Recital 148 GDPR.

Legal analysis and interpretation

No artificial division of roles within one cohesive service

Isabel had carefully constructed its defense: for the search of the Crossroads Bank for Enterprises, the creation of accounts, billing and web statistics, it saw itself as a data controller, for the authentication and identification activity as a processor. The Litigation Chamber sharply punctures this construction. Authentication and identification within TruliUs are inseparable from the other processing operations: all steps contribute to a single goal - allowing natural persons to act on behalf of a company - and rely on a single technical architecture designed by Isabel.

The Court recognizes that the case law of the Court of Justice - including Fashion ID (ECJ July 29, 2019, C-40/17) - imposes a processing-by-processing approach, but adds an important caveat: that disaggregation presupposes that the processing operations can actually be considered separately. When that is not possible - when they are processing operations that logically and technically presuppose each other - the principle of effectiveness prohibits labeling one as a processor and the other as a controller.

This is a clear refinement of the Fashion ID doctrine and an important signal for SaaS providers looking to fine-tune their role allocation by submodule. The message is that a functional whole is also legally judged as a whole.

The limits of the “standardized cloud service” argument

The cloud example from EDPB Guidance 07/2020 is eagerly cited by SaaS providers: a vendor that provides a standardized technical infrastructure without defining the purpose or content of the processing itself can act as a processor.

First substantively: once the provider itself defines the purpose, data categories, retention period and recipients, the cloud analogy is no longer applicable. The comparison only holds when the provider is truly neutral - providing a storage container, not a precooked process.

Next, procedurally: even assuming the service is standardized, the EDPB adds an additional condition, according to the Chamber. The customer must receive a detailed description of the service and actively consent to how the processing is done. In this case, those elements were missing. It is an interpretation that significantly raises the threshold for qualifying as a processor, and requires SaaS providers to thoroughly document their pre-contractual disclosures - otherwise the cloud argument will remain a hollow phrase.

One fine for the principal violation, one reprimand for the derivative violations

Methodologically interesting is the choice to impose a fine for one central infringement - art. 5, paragraph 2 GDPR - and to deal with the other infringements via a reprimand. The Litigation Chamber substantiates this choice with three elements: the structural and inseparable nature of the infringements, the formal pedagogical value of a reprimand and the principle of proportionality.

This technique has its own logic when violations really stem from the same fault, but it also raises questions. By fining only Art. 5(2) GDPR, the fine is capped at the ceiling amounts of Art. 83(5) GDPR through the violation of the responsibility principle - resulting in a significant maximum amount in this case. In other cases, a company that commits multiple separate violations without common cause can be fined cumulatively - albeit within the limits of the concurrence rule from Art. 83(3) GDPR. Moreover, the Litigation Chamber expressly points out that its previous decisions do not constitute a precedent by which it is bound when assessing subsequent cases, relying on a judgment of the Market Court (Market Court Jan. 27, 2021, 2020/AR/1333). As a result, those who wish to dispute the amount of a DPA fine by reference to lower fines in previous cases find little audience.

Specifically, what does this mean?

For providers of B2B SaaS services. A contractual self-qualification as a processor provides no shield when in reality you are determining the purpose and essential means of processing. The analysis must be done on a per-processing activity basis, but when activities are functionally inseparable, they are assessed as a whole. Those who want to invoke the “standardized cloud service” example must actually provide a neutral infrastructure without defining data fields, retention periods or recipients themselves - AND must be able to prove that the customer has received and actively approved a detailed description of the processing pre-contractually. General terms and conditions, DPIAs and processing logs that assume incorrect qualification offer no excuse: the Litigation Chamber reads them as evidence of an implemented, but erroneous, compliance policy.

For buyers of SaaS services. A counterparty that declares itself a processor in its terms and conditions is passing on the GDPR obligations to you without this being factually correct. For authentication services, identity solutions, scoring engines and similar platforms, it is advisable to map the actual decision-making power over purpose, data categories, retention periods and recipients both contractually and operationally before entering into a contract. A DPIA in which you designate yourself as a data controller while not actually performing that role does not protect you from complaints from your customers or employees - on the contrary, it increases your liability.

For digital identity and authentication providers. The Litigation Chamber explicitly draws the parallel between Isabel and itsme: whoever identifies end users and shares their data with partners is a data controller for that activity. It is not enough to hide behind the B2B nature of the service.

Frequently asked questions (FAQ)

Can I freely choose in my terms and conditions whether I am a processor or a controller?
No. The Litigation Chamber expressly points out that the qualification is based on a factual assessment, not on the contractual self-declaration. Whoever determines the purpose and essential means of processing is a controller, regardless of what the terms and conditions say.

What are the risks of incorrect self-qualification as a processor?
Misclassification is in itself a violation of the principle of responsibility under Art. 5(2) GDPR and can result in a fine of up to €20 million or 4% of global turnover. Moreover, the underlying obligations (transparency, right of access, minimization) continue to apply and can lead to additional sanctions - in this case, a reprimand.

May I be a processor for some parts of my service and a controller for others?
In principle, yes, because qualification must be done per processing activity. But when the various processing operations are functionally inseparable within one service - which is typically the case with authentication services - the Litigation Chamber prohibits artificial splitting.

Conclusion

In this decision, the Litigation Chamber takes a strict factual approach to the concepts of processor and data controller. Those who design a SaaS service from A to Z, unilaterally defining the purpose, data fields, retention periods and recipients, cannot qualify as processors - even when their general terms and conditions, DPIA and processing register tell that opposite story for years. The decision forces B2B SaaS providers, and in particular players in digital identity and authentication, to thoroughly reassess their roles under the GDPR.