"Are you a controller or a processor?" is one of the first questions in an enterprise privacy review. The honest answer for most SaaS companies is "both, for different processing". The answer customers want is a clear statement of which role applies to which data, backed by contracts and records that agree with it.
The role is not a label you choose. Under GDPR it follows from what you actually decide about the processing. Getting it wrong has consequences in both directions: a processor that acts like a controller takes on controller obligations it has not met, and a controller that calls itself a processor has probably skipped steps such as choosing a lawful basis.
This article explains the test, applies it to the processing a typical SaaS company does, and lists what each role requires.
The legal definitions, and the test behind them
GDPR Article 4(7) defines a controller as the body that, alone or jointly with others, determines the purposes and means of processing personal data. Article 4(8) defines a processor as a body that processes personal data on behalf of the controller.
The European Data Protection Board's guidelines on the concepts of controller and processor explain how to apply this. The key distinction is between two kinds of decisions:
Purposes: why the data is processed at all.
Essential means: which data is processed, for how long, whose data it is, and who receives it. These are closely tied to purpose and belong to the controller.
Non-essential means: practical choices such as which hosting provider, database or security tooling to use. A processor can make these without becoming a controller.
So a processor can have real discretion over how the work is done. What it cannot do is decide why the processing happens or what data it covers.
The role is assessed per processing activity, not per company. You can be a controller for one activity and a processor for another on the same day, often in the same database.
Applying the test to a typical SaaS company
Here is how the roles usually fall for a B2B SaaS product. These are common patterns, not rules. Your contracts and actual behavior decide.
| Processing activity | Usual role | Why |
|---|---|---|
| Customer content uploaded into the product | Processor | The customer decides what to upload and why |
| Customer user accounts used to deliver the service | Varies | Often processed for the customer, though some providers treat account administration as their own purpose |
| Your own billing and contract records | Controller | You decide to process them for your own business |
| Marketing leads and website analytics | Controller | Your purposes, your choice of data |
| Your employees' HR records | Controller | Your purposes |
| Security logs about use of your platform | Often controller | Kept to protect your own service |
| Product analytics on how customers use features | Depends | Controller if you decide to analyze it for your own purposes |
| Using customer data to train shared models | Likely controller for that purpose | You decided a new purpose |
The last two rows are where disputes start. A processor may only process on the controller's documented instructions, under Article 28(3)(a). If you use customer data for a purpose the customer did not instruct, such as improving a model offered to all customers, you are deciding a purpose. Article 28(10) is explicit: a processor that determines purposes and means is treated as a controller for that processing.
That does not make such processing forbidden. It means you need a lawful basis of your own, transparency toward the individuals, and a contract that allows it. Whether a particular product analytics or model training use is controller or processor processing is a judgment worth confirming with counsel.
Joint controllers, and when you are one
Article 26 covers joint controllers: two or more parties that jointly determine purposes and means. Joint control does not require equal responsibility. It requires that both parties shape why and how the processing happens.
Joint controllers must have an arrangement that sets out their respective responsibilities, in particular for transparency and individual rights, and the essence of it must be made available to individuals.
In SaaS, joint control is less common than people fear. It tends to arise in co-marketing campaigns, shared data products, and integrations where two companies pool data for a purpose they designed together. If you find yourself negotiating what both sides may do with a shared dataset, check whether you have drifted into joint control.
What each role obliges you to do
As a processor
Act only on documented instructions (Article 28(3)(a)), and tell the controller immediately if you think an instruction infringes data protection law.
Sign a contract that meets Article 28(3). The detail is covered in what belongs in a GDPR data processing agreement.
Get authorization before using sub-processors (Article 28(2)), and flow the same obligations down to them (Article 28(4)).
Keep your own record of processing under Article 30(2), listing the controllers you act for and the categories of processing.
Implement appropriate security under Article 32.
Notify the controller of a personal data breach without undue delay under Article 33(2). The controller then decides about notifying the authority.
Assist the controller with individual rights requests, security, breach notification and DPIAs, taking into account the nature of the processing.
As a controller
Choose and document a lawful basis for each purpose; see the six GDPR lawful bases.
Provide privacy information to individuals under Articles 13 and 14.
Handle individual rights requests directly and on time.
Keep a record of processing under Article 30(1).
Carry out DPIAs where processing is likely to result in high risk.
Notify the supervisory authority of qualifying breaches within 72 hours, and affected individuals where the risk is high.
Use processors that give sufficient guarantees (Article 28(1)), with a contract in place.
Liability also differs. Under Article 82, a processor is liable for damage only where it has not complied with obligations specifically directed at processors, or where it acted outside or contrary to the controller's lawful instructions. A controller involved in processing is liable for damage caused by processing that infringes the regulation.
Common mistakes in role allocation
Declaring one role for the whole company. A privacy notice that says "we act only as a processor" is almost never true for a company with a website, a sales team and employees.
Letting the contract and the product disagree. If the data processing agreement says you process only on instructions, but your product terms allow you to use customer data for "any business purpose", the contract set is inconsistent. Customers' legal teams will spot it.
Forgetting the processor record. Processors often assume Article 30 applies only to controllers. Article 30(2) applies to processors directly.
Treating "processor" as lower risk. Processors carry fewer obligations, not none. Supervisory authorities can and do act against processors for their own failures, such as inadequate security.
Copying US terminology. Under the CCPA, the closest equivalents are "business" and "service provider". The concepts overlap but are not identical, so map each law's roles separately.
How to document your roles
Customers and auditors ask for evidence, not assertions. A defensible set of documents looks like this:
A role register. One row per processing activity, with the role you hold, the reasoning, and the customer or internal owner.
A record of processing in both forms. Article 30(1) entries for controller activities and Article 30(2) entries for processor activities; see how to build an Article 30 record of processing.
Contracts that match. A processor DPA for customer data, and privacy notices for controller processing.
A review trigger. Revisit roles when you launch a feature that uses customer data for a new purpose.
If you are pursuing ISO 27701, it separates controls for controllers and processors, so this register feeds directly into scoping; see ISO 27701 controller and processor controls. The GDPR framework page summarizes the wider obligations.
How TrustLynce helps
TrustLynce keeps records of processing for controller and processor activities in its data privacy workflows, alongside DPIAs and data subject requests. Commitments you make in DPAs can be tracked against the controls that meet them through customer commitments.