A marketing automation SaaS signs a EUR 180K deal with a European bank. Six months in, a user in Germany files a Subject Access Request. The SaaS thinks: "We are just a vendor - the bank handles that." The bank thinks: "The data is on their platform - it is theirs." Six weeks later, both are staring at a joint liability problem because neither had a DPA clarifying responsibilities. That conversation - "wait, who is the controller here?" - is the most common reason GDPR programmes break at scale.
The Three GDPR Roles
GDPR Article 4 defines three distinct roles. The distinction is not administrative - it determines legal liability, contractual obligations, user-facing responsibilities, and regulator-facing accountability.
The Controller - Who Decides
A controller determines the purposes and means of processing. If you run a SaaS product, you are the controller for: user account data, website visitor data, employee data, and prospect data in your CRM. The controller carries the heaviest legal burden - lawful basis, privacy notice, all eight user rights, RoPA, 72-hour breach notification, and primary liability.
The Processor - Who Executes
A processor processes data on behalf of the controller, on documented instructions. Examples: your email provider (Mailchimp), cloud host (AWS), payroll platform, support tool (Zendesk). Obligations: process only on instructions, confidentiality, security measures, assist with SARs and breaches, no sub-processors without authorisation, delete or return data at contract end.
The Sub-Processor - The Third Layer
A sub-processor is engaged by a processor to process data on behalf of the controller. If your SaaS (processor) uses AWS for hosting, AWS is a sub-processor. Under GDPR Article 28(4), the processor must have controller authorisation, flow down the same obligations in writing, and remains fully liable for the sub-processor performance.
Side by Side - What Each Role Owes
| Aspect | Controller | Processor | Sub-Processor |
|---|---|---|---|
| Decides purposes | Yes | No | No |
| Needs lawful basis | Yes | No | No |
| Signs DPA with | Each processor | Controller + sub-processors | The engaging processor |
| Responds to SARs | Directly | Assists controller | Assists via processor |
| Breach notification | 72 hours to DPA | Notify controller ASAP | Notify processor ASAP |
| Maximum fine | 4% global turnover | 2% global turnover | Via processor liability |
| Writes privacy notice | Yes | No | No |
The Dual-Role Reality
Most SaaS companies are both controller and processor simultaneously - controller for their own user data, processor for enterprise customers data flowing through the product. This is normal and expected. The key: classify per processing activity, not per company. For each data flow, ask: "Did we decide why this data is processed, or did our customer?"
Practical Steps - Get Classification Right
- Map every data flow and label the role: controller, processor, or sub-processor.
- Sign a DPA with every processor before data flows, not afterwards.
- Keep a current sub-processor list and make it available to enterprise customers.
- Test your breach-notification chain - the processor-to-controller 72-hour handoff must work when rehearsed.
- Classify per activity, not per company - you will often be both roles within the same product.
For the full GDPR guide, see GDPR Explained for Startups. For the India DPDP equivalent, see Data Principal vs Fiduciary vs Processor.
Frequently Asked Questions
Yes - this is extremely common. Most SaaS companies are controllers for their own user account data, marketing data, and employee data, while simultaneously being processors for enterprise customers whose data flows through the product. The classification must be done per processing activity, not per company.
No. The processor relies on the controller lawful basis. The processor obligation is to process only on documented instructions from the controller, as specified in the Data Processing Agreement. If a processor starts processing data for its own purposes, it becomes a controller for that processing.
This is a breach of GDPR Article 28. The processor can face regulatory action and fines of up to EUR 10M or 2% of global turnover. The controller may also terminate the DPA and seek damages. This is why enterprise contracts routinely demand sub-processor lists and change-notification clauses.
The controller notifies the regulator within 72 hours. The processor role is to notify the controller without undue delay upon becoming aware of a breach and provide all information needed for the controller to make its regulatory notification. The processor does not typically notify the regulator directly.
Yes. Under GDPR Article 28, any tool that processes personal data on your behalf - email provider, analytics, CRM, cloud host, support tool, payment processor - requires a Data Processing Agreement. This is a legal requirement, not best practice. Most major SaaS vendors offer standard DPAs.