What is a subprocessor in GDPR terms?

A subprocessor is a third party that a processor (typically the SaaS vendor) engages to help process personal data on behalf of the controller (typically the vendor's customer). Examples include cloud hosting, email delivery, and AI model providers.

Who needs to authorize a new subprocessor — the vendor or the customer?

The processor (vendor) needs authorization from the controller (customer) before engaging a subprocessor, either specific or general. This direction is easy to get backwards but is the core of Article 28's subprocessor rules.

Is the vendor still liable if a subprocessor causes a data breach?

Yes. Under GDPR Article 28, the original processor remains fully liable to the controller for the subprocessor's performance of its data protection obligations — engaging a subprocessor doesn't transfer that accountability away.

How much notice does a vendor have to give before adding a subprocessor?

GDPR requires a genuine opportunity to object before the change takes effect, but doesn't mandate a specific number of days. Many vendor DPAs specify a notice window, commonly around 30 days, though this varies — check the actual DPA.

Should AI or LLM providers be listed as subprocessors?

If customer personal data is routed through a third-party AI model to power a product feature, that model provider is functioning as a subprocessor and should be disclosed, ideally along with whether the data is used for model training.

What is a subprocessor list? A practical definition

Glossary · enterprise · 4 min read · last verified 2026-07-21

Reviewed before publication Editorial board Independent commercial review

In shortA subprocessor list documents the third parties a vendor (processor) engages to help process customer (controller) data. Under GDPR Article 28, the processor needs authorization and remains liable for subprocessor performance.

The short definition

A subprocessor list is a published record of the third-party vendors a company engages to help process personal data on behalf of its customers — common examples include cloud infrastructure providers (AWS, GCP, Azure), email and communications tools (Twilio, SendGrid), analytics platforms, customer support tooling, and increasingly, AI or LLM providers used to power product features. If your SaaS product touches your customers' personal data and you rely on other companies to help deliver the service, those companies are your subprocessors, and enterprise buyers will expect a documented, current list of them.

Getting the roles right — this is where people get it backwards

Under the EU GDPR framework (and similar structures in UK GDPR and various other data protection regimes), there are two core roles:

The controller determines the purposes and means of processing personal data. For a typical B2B SaaS relationship, the customer is usually the controller — they decide what data goes into your product and why.
The processor processes personal data on behalf of, and under the instructions of, the controller. As the SaaS vendor, you are typically the processor with respect to your customer's data.
A subprocessor is a third party the processor engages to help carry out that processing — you (the processor) hiring your own vendors to help deliver your service to your customer.

The obligation runs in a specific direction: the processor (you, the vendor) needs authorization from the controller (your customer) before engaging a subprocessor — not the other way around. This direction is easy to invert when writing about it casually, but it's the whole basis of why subprocessor lists exist and why customers care about them.

What GDPR Article 28 actually requires

Article 28 of the GDPR governs the processor relationship, and it specifically addresses subprocessors:

A processor must not engage another processor (a subprocessor) without the controller's prior specific or general written authorization.
If the controller gives general authorization — the more common and scalable approach for SaaS vendors with many customers — the processor must inform the controller of any intended changes concerning the addition or replacement of subprocessors, giving the controller an opportunity to object before the change takes effect.
Where a subprocessor is engaged, the same data protection obligations that apply to the processor under its contract with the controller must be imposed on the subprocessor via contract (or another legal act) — commonly through the subprocessor's own data processing agreement.
Critically, the original processor remains fully liable to the controller for the subprocessor's performance of its data protection obligations. Engaging a subprocessor doesn't transfer or dilute the processor's responsibility — it adds a layer without removing accountability.

This is why a maintained, accessible subprocessor list matters operationally, not just as a compliance formality: it's how a vendor fulfills the "keep the controller informed" obligation at scale, instead of negotiating individual notices with every customer for every vendor change.

What a usable subprocessor list looks like

A subprocessor list that actually helps a customer's security or legal team review it typically includes:

Subprocessor name and the entity operating it.
What the subprocessor does (hosting, email delivery, analytics, support ticketing, AI/ML processing, etc.) �� the function matters as much as the name.
What categories of data it may touch.
Where it processes data (relevant to data residency and cross-border transfer questions).
A change notification mechanism — commonly a subscribe-to-updates option or an email notice — so customers who've given general authorization actually get the "opportunity to object" the regulation contemplates, rather than a list that's silently amended with no notice trail.

The notice period, and why it's negotiated

GDPR doesn't mandate a specific number of days of advance notice for subprocessor changes — it requires that the controller get a genuine opportunity to object before the change takes effect. In practice, vendor data processing agreements commonly specify a notice window, and 30 days shows up frequently as a negotiated or offered standard, though shorter and longer periods both appear depending on the vendor and the customer's leverage. Buyers with strict internal review requirements should confirm the actual notice period in the DPA rather than assume a default.

Why this has gotten more scrutiny lately

Two trends have pushed subprocessor lists from a compliance checkbox to an active review item in enterprise deals:

AI features built on third-party model providers. If a SaaS product routes customer data through an LLM API to power a feature, that model provider is a subprocessor, and increasingly a specific point of scrutiny — buyers want to know whether their data is used to train the underlying model, not just that it's processed.
Growing subprocessor chains. Modern SaaS stacks routinely depend on a dozen-plus third parties, each of which may have its own subprocessors, creating a multi-layer chain that's harder to fully audit than a single-vendor relationship.

What buyers should actually check

Is the subprocessor list current, dated, and easy to find — not buried or stale?
Is there a working notification mechanism for changes, not just a static page?
Does the DPA specify a clear notice period and objection right?
Are AI/LLM providers disclosed if the product has AI-powered features?
Does the contract confirm the vendor remains liable for subprocessor performance, consistent with Article 28?

This is general information about how subprocessor obligations commonly work under GDPR-style frameworks, not legal advice — specific obligations depend on your data flows, roles, and applicable law, so confirm details with counsel and the vendor's actual DPA.