SaaS agreement: controller or processor?

A SaaS agreement does not determine the data protection role merely by using a label. The relevant question is who decides on the purpose and the essential means of each processing activity. A provider may therefore act as a processor for customer data while also being a controller for billing, platform security or its own product analytics.

This distinction matters in practice. It determines whether an Article 28 GDPR agreement is required, who handles data subject requests, how subprocessors are approved and which data the provider may use for its own purposes. For the broader legal framework, see the German-language core guide on GDPR processing agreements for SMEs. The agreement should reflect the SaaS service as it is actually used, rather than applying one blanket label to the entire relationship.

Article 4(7) GDPR defines the controller as the party that, alone or jointly with others, determines the purposes and means of processing. Under Article 4(8), a processor processes personal data on behalf of the controller. These terms describe actual decision-making for a particular processing activity.

A SaaS agreement can support the assessment if it reflects reality. It cannot allocate responsibility freely. If the agreement calls the provider a processor but the provider decides an independent purpose in practice, the contractual label cannot settle that activity by itself.

Start with a processing map rather than a template. Which data is used in which module? Who decides why it is processed, how long it is kept and who can access it? Only then can the appropriate agreement structure be selected.

A business usually uses a SaaS system for its own process, such as customer management, human resources, support or appointment scheduling. The business normally sets the purpose and essential parameters for the personal data involved. The provider supplies the platform and processes the data on instructions. In that area, a processor role is often likely. The page on processors and service providers explains the wider framework.

The provider may also handle other data. This can include contract and billing data, login details, system security logs or information used to prevent abuse. Whether the provider is a processor or controller depends on the purpose and actual decision-making for that activity. One role statement for the entire commercial relationship can hide these differences.

A single data set may also feed several processing activities. A name may be processed on behalf of the customer for the customer’s service, while being processed for the provider’s own invoicing purpose. The records, privacy information, agreement and product settings should tell the same story.

Purpose answers why the processing takes place. In a human resources platform, the purpose may be the employer’s payroll administration. In a ticketing platform, it may be handling customer requests. Those purposes usually come from the business using the SaaS solution.

Means require a distinction between essential and non-essential decisions. Data types, data subject groups, access categories and retention are closely connected with lawfulness, necessity and proportionality. Within the instructions, a processor may often choose technical details such as particular software or the internal distribution of access rights.

The boundary is not determined by whether the provider can read the content. A business can remain a controller even without direct access if it determines purpose and essential means. Conversely, a provider does not become a controller merely because it selects the technical infrastructure.

If the SaaS provider processes personal data for the customer’s purposes, an agreement or other legal act under Article 28 GDPR is required. It must describe the subject matter and duration, nature and purpose, types of personal data, categories of data subjects and the controller’s rights and obligations.

The agreement must cover documented instructions, confidentiality, appropriate technical and organisational measures and rules for subprocessors. The processor agreement check helps organise these points at an early stage. The provider must also assist the controller with data subject rights, security and breach duties and data protection impact assessments where this is required by the nature of the processing.

At the end of the service, deletion or return at the controller’s choice should be addressed unless storage is required by law. The provider should also supply information needed to demonstrate compliance and allow appropriate audits and inspections. A link to general standard terms does not automatically prove that these points are covered.

A provider may process personal data to deliver the commissioned service and pursue separate purposes at the same time. Examples include its own invoicing, platform security and abuse prevention. For each purpose, ask whether the provider decides independently and which legal basis and information are required.

Product improvement, usage analytics, advertising and profiling need particular care. A broad clause allowing the provider to use all customer data to optimise its services does not by itself show that the use is compatible with the original engagement. Purpose, data scope, recipients, retention and available choices need a specific assessment.

Where the same provider is a controller for one activity and processor for another, the data flows and operational responsibilities should be separable. The privacy governance topic page places these organisational responsibilities in context. This makes it easier to handle access, erasure, security reviews and questions from data subjects.

SaaS providers often use hosting, support, analytics or security services. Where they use those services to process data on behalf of the customer, the service providers will commonly be further processors. The customer needs a traceable authorisation and information process and a practical way to assess material changes.

The list should contain more than company names. Check the function, processing location, data involved and whether a transfer to a third country occurs. Transfers outside the European Economic Area require a separate assessment under Chapter V GDPR. A certification or location label does not replace that assessment.

The chain must also work for support access, remote maintenance and disaster recovery. The processor assessment checklist supports a practical review. Agree how incidents are reported, how data subject requests are supported and how data is deleted or returned at the end. Recheck the information when the product or its subprocessors change.

Processing map: Record modules, data types, data subject groups, purposes, systems and retention periods. Separate service delivery from billing, security and own analytics.

Role matrix: Allocate controller, processor or, where appropriate, joint controller for each activity. Explain the allocation by reference to actual decisions on purpose and essential means.

Instructions: Set out who directs settings, access, deletion, export and retention. Document how new instructions are issued and changes approved.

Subprocessors: Check the list, functions, locations, authorisation model, third-country links and response options when the list changes.

Evidence: Keep security measures, audit information, incident procedures, deletion evidence and the return format in a form that can actually be found and used inside the business.

The contract heading decides everything: An “Article 28 agreement” does not turn every provider processing activity into processing on behalf of the customer. The provider’s own purposes require a separate assessment.

The customer is treated as controller for everything: Choosing a SaaS product does not mean that the customer decides the provider’s own purposes. The provider’s independent processing remains a separate area.

Standard terms are accepted without review: A product may contain settings, data flows or subprocessors that are not described adequately in the data processing schedule.

Subprocessors remain invisible: General permission without a list, change notice and workable response option makes the chain difficult to control.

Product configuration is not documented: Roles and risks can change when new modules, analytics functions or integrations are activated. Contract review must remain connected to actual use.

Cloud storage: The business decides which customer data is stored for which business process. The standardised provider stores it for that purpose and on instructions. That storage is commonly processing on behalf of the customer. If the provider uses usage data for an independent purpose, that part must be assessed separately.

Support platform: The customer determines which requests are handled and which groups of people are recorded. The provider may choose the technical implementation while remaining bound by instructions for customer data. Billing, account management and platform protection may involve additional own processing.

Joint campaign: Two businesses jointly decide the target group, purpose and means of a customer campaign. Joint controllership may then be closer to the facts than processing on behalf of one business. Their responsibilities for information and data subject rights should be agreed transparently.

Is a SaaS provider always a processor? No. It may be a processor for customer data handled on instructions and a controller for own purposes such as invoicing or some security activities. The answer is given for each processing activity.

Is an Article 28 agreement attached to standard terms enough? It can be embedded in standard terms, but it must satisfy Article 28 GDPR and fit the actual service. A blanket label without purposes, data types, instructions and controls is not a reliable solution.

Who is liable when a SaaS provider makes a mistake? The answer depends on the role, processing activity and breach. The agreement should allocate assistance, notification, evidence and cooperation, but it does not remove the need to examine the actual incident.

In SaaS arrangements, the decisive issue often lies in the interaction between the product, its settings, subprocessors and actual use rather than in one clause. We review the processing activities, allocate the roles and identify which contractual terms and evidence your business still needs. Contact us with the agreement, product description, data flow and intended modules so that the next steps can be defined clearly.