A software-as-a-service company —a CRM, an ERP, an email marketing platform, a project management tool, an HR software, a product analytics tool— processes personal data every day that does not belong to it, but to the companies that use it. That particular position, being a critical piece in the operations of hundreds or thousands of customer companies, makes the SaaS one of the actors with the highest GDPR exposure in the digital ecosystem. And, at the same time, one where regulatory compliance can best be turned into a commercial advantage.
This guide explains how a SaaS company regulates its role under the GDPR (Regulation (EU) 2016/679) and the LOPDGDD (Spain's Organic Law 3/2018): when it is a processor, what document it must offer its business customers (DPA), how it manages sub-processors, where the boundary between processor and independent controller lies and what to watch when training models or integrating artificial intelligence.
The typical role distribution in SaaS
When a business customer contracts a SaaS, at least two planes of personal data processing coexist with different roles:
- Data the customer uploads to the platform (end customers in the CRM, employees in HR software, subscribers in the email platform): the customer is the controller of that processing; the SaaS is the processor executing what the customer instructs. The art. 28 GDPR regime applies here.
- Data of the customer itself as a user of the SaaS (administrator account, billing data, access logs, commercial contact): the SaaS is the controller of that processing. Here the art. 6 GDPR regime applies, typically based on the performance of the contract under art. 6(1)(b) GDPR.
In well-structured SaaS companies, this duality is clearly reflected in two distinct documents: the privacy policy of the public website (covering commercial acquisition, product use and billing, where the SaaS is the controller) and the DPA (Data Processing Agreement) that the business customer signs or accepts when contracting (covering the art. 28 GDPR regime for the data the customer will upload).
The DPA: the document every professional SaaS offers its customers
Art. 28(3) GDPR requires the controller and the processor to regulate their relationship by means of a contract or other legally binding act with specific minimum content. In the SaaS world, this instrument is universally called the Data Processing Agreement (DPA) and is usually offered as an addendum incorporated into the terms of service.
A professional SaaS makes the DPA available to the customer without it having to ask, ideally accessible from the admin panel, downloadable as a signed PDF or acceptable via a consent check that creates a record. The DPA must cover:
| Clause | What it should say in a SaaS context |
|---|---|
| Subject matter and duration | Provision of the service described in the contracting terms during the term of the customer's subscription. |
| Nature and purpose | Storing, processing, analysing and displaying the data the customer uploads in line with the product's functionalities, without using it for distinct purposes of the SaaS in its role as processor. |
| Types of data and data subjects | Identifiers, contact details, commercial data and, where applicable, special categories if the product allows. Data subjects: end customers, employees, suppliers of the customer. |
| SaaS personnel | Contractual confidentiality, joiner/leaver controls, least-privilege principle for access to customer data. |
| Security measures | Encryption in transit and at rest, multi-factor access control, logical tenant segregation, activity logging, backups, vulnerability management, certifications (ISO 27001, SOC 2) where applicable. |
| Sub-processors | Accessible, up-to-date list (hosting, CDN, monitoring, external support if any), general authorisation in the DPA and a mechanism for notifying changes. |
| International transfers | Identification of countries outside the EEA, the basis for the transfer (adequacy decision, Data Privacy Framework for the US, standard contractual clauses) and an impact assessment where appropriate. |
| Assistance with rights | In-product tools so the customer can handle data subject rights (export, deletion, rectification) and a support procedure when technical intervention is required. |
| Breach notification | Specific timeframe for notifying the customer of any breach affecting its data (typically 24-48 hours), minimum information set and collaboration procedure. |
| Return and deletion | On subscription termination, the customer can export the data in a structured format (CSV, JSON, API). Subsequent retention period, typically 30-90 days, and confirmed secure deletion. |
Sub-processors: the chain every SaaS must document
Almost no SaaS operates alone: behind it there is usually a cloud provider (AWS, Google Cloud, Azure), a CDN (Cloudflare, Fastly), a monitoring service (Sentry, Datadog), a payment gateway (Stripe), a support tool (Intercom, Zendesk), a transactional email provider (SendGrid, Postmark) and, increasingly, external AI models.
Each of these providers processes data of the SaaS's customers and is therefore a sub-processor within the meaning of art. 28(2) GDPR. The SaaS must:
- Maintain a public and up-to-date list of all sub-processors it uses, accessible from the website (typically on a page titled "Subprocessors").
- Sign with each sub-processor an art. 28 GDPR contract with guarantees equivalent to those of the main DPA.
- Notify customers with reasonable advance notice (14 to 30 days is the standard) of any significant change: addition of a new sub-processor, replacement of an existing one, broadening of the processing scope.
- Allow the customer to object to the change within that period. If the objection is justified and blocks service continuity, the customer should be entitled to terminate its subscription.
Processor vs. independent controller: the most difficult line to draw
The most subtle data protection mistake in SaaS is to assume that all operations on customer data are governed by the processor regime. In reality, there are three areas where the SaaS frequently acts as an independent controller and where the applicable regime changes entirely:
- Aggregated product analytics: if the SaaS combines usage data from all its customers to improve the product, generate sector benchmarks or train recommendation models, that purpose belongs to the SaaS, not to the customer. The SaaS becomes a controller and needs an autonomous legal basis (typically legitimate interest under art. 6(1)(f) GDPR, with a documented balancing test), to inform end data subjects contractually through its corporate customers, or to anonymise the data before the combination.
- AI model training: using customer data to train general models that will serve all future customers is clearly a purpose of the SaaS itself. Without the customer's explicit consent or irreversible anonymisation, this processing is not covered by the processor role.
- Commercial marketing to product users: if the SaaS sends newsletters, upsell offers or product communications to individual users belonging to customer companies, it is acting as a controller over the data of those specific users, not as a processor over the data of their companies.
The professional way to manage this area is:
- Map clearly which processing operations are as processor and which as independent controller.
- Regulate each with its own legal basis and documentation.
- Explicitly mention in the DPA which processing operations fall outside the processor role and which require additional consent or prior anonymisation.
- Offer the customer mechanisms to authorise or block optional processing (clearly differentiated opt-in / opt-out).
"In SaaS, complying with art. 28 GDPR is not paperwork: it is product. An accessible DPA, a public sub-processor list and clear tenant segregation are three signals that enterprise customers check before signing. Doing it well accelerates sales; doing it poorly blocks them."
Mario P. Talamillo · Managing Partner, Certix®
Multi-tenant and segregation: the structural security measure
A SaaS serves multiple customers (tenants) on the same infrastructure. The way the architecture segregates data between tenants is a structural security measure under art. 32 GDPR and, accordingly, a point the DPA must describe with technical honesty:
- Logical multi-tenant with application-level segregation (each record carries a tenant identifier and filtering is applied across all queries). The most widespread model. Requires extreme care in testing so no bug allows tenant leakage.
- Physical multi-tenant with a separate database per customer. Higher operational cost but better segregation. Common in high-end SaaS or heavily regulated sectors.
- Isolated single-tenant with a dedicated instance per customer. The opposite extreme, reserved for very large or regulated customers.
The mature enterprise customer asks about this before signing. A professional SaaS documents it in the DPA and in its public security documentation.
Breaches: the SaaS is the natural notification channel
When a security breach occurs at the SaaS, the art. 33 GDPR regime obliges the customer (controller) to notify the AEPD (the Spanish Data Protection Authority) within 72 hours. For this to be technically possible, the SaaS (processor) must alert the customer as quickly as possible. The DPA must regulate this:
- Customer notification timeframe: typically 24-48 hours from the moment the SaaS becomes aware.
- Minimum information in the first communication: nature of the incident, systems and categories of data affected, estimated scope, immediate measures adopted.
- Technical collaboration: the SaaS provides the customer with what it needs to prepare the notification to the AEPD and, where appropriate, communication to data subjects.
- Follow-up communication: root-cause analysis, improvement plan, lessons learned.
Minimum checklist for a responsible SaaS
- Standard DPA published, accessible and signable, aligned with the content of art. 28(3) GDPR.
- Public sub-processor list with name, function, country and URL of each provider's own DPA.
- Mechanism for notifying customers of sub-processor changes with a reasonable objection period.
- Clear mapping between processor and independent-controller processing, with distinct legal bases.
- AI usage and training policy: which data is used to improve the model and under which customer authorisation.
- Public security documentation: encryption, tenant segregation, certifications, recovery point objective.
- Breach notification procedure to customers with an explicit timeframe.
- Product functionalities for export, deletion and rectification that help the customer handle data subject rights.
- Public privacy page for product users (public website, free trial) clearly separated from the enterprise DPA.
Frequently asked questions
Is a SaaS company a controller or a processor with respect to the data its customers handle?
The general rule is processor (art. 28 GDPR) over the data the customer uploads to the platform. However, the SaaS also acts as an independent controller in other layers: administrator account, billing, aggregated usage analytics, improvement of its own service. This duality must be clearly regulated in the terms of service and, above all, in the art. 28 GDPR DPA the SaaS signs with each customer.
What must a SaaS offer its customers to comply with art. 28 GDPR?
A Data Processing Agreement (DPA) containing the minimum content of art. 28(3) GDPR: subject matter, duration, nature and purpose, types of data, obligations, confidentiality, security measures, sub-processors, assistance with rights, breach notification and data return. It is usually offered as an addendum incorporated into the terms of service or expressly signed.
When does a SaaS stop being a processor and become an independent controller?
When it decides on its own new purposes that the customer has not instructed: combining data from multiple customers for its own analytics, training general AI models, reusing data to improve the commercial product beyond the contracted service, or marketing to individual users. In those cases an autonomous legal basis is required, data subjects must be informed and all other controller duties must be met.
Must a SaaS offer its customers guarantees regarding the sub-processors it uses?
Yes (art. 28(2) GDPR). The SaaS must maintain an accessible, up-to-date list of sub-processors (AWS, Google Cloud, Cloudflare, Stripe, etc.), sign an art. 28 GDPR contract with each one with equivalent guarantees, notify customers of significant changes with reasonable advance notice and allow them to object. The major cloud platforms offer their own standard DPAs that must be reviewed.
This content is for informational purposes only and does not constitute legal advice. The application of regulations to each specific case requires individual analysis. Spanish regional sectoral regulations may extend or modify deadlines and requirements.
Does your SaaS have a solid DPA that withstands enterprise client due diligence?
At Certix we assign you a compliance expert from the technology sector. No commercial intermediaries, no generic templates.
Speak to a specialist