← All guides
GDPR7 min read11 May 2026

What is a Sub-processor Under GDPR? A Plain-English Guide for SaaS Founders

Every SaaS company has sub-processors — but many founders don't know it. Here's what a sub-processor is under GDPR, why it matters, what your DPA must say about them, and how to build a compliant sub-processor list.

The one-line answer

A sub-processor is any third party that your SaaS engages to process personal data on behalf of your customers. If you use AWS to host your database, Sentry to track errors, Intercom for support, or OpenAI for AI features — and any of those systems can access or process your customers' personal data — those vendors are your sub-processors under GDPR.

The controller–processor–sub-processor chain

GDPR creates a clear hierarchy:

  • Controller: Your business customer — the company that signed up for your SaaS and determines why and how personal data is processed. They're responsible for having a lawful basis for processing.
  • Processor: Your SaaS company — you process personal data on behalf of the controller (your customer). You need a Data Processing Agreement (DPA) with them.
  • Sub-processor: Any third-party service you use that, in turn, processes personal data it received from you (which originated from the controller). You need a DPA with each sub-processor too.

The chain matters because liability flows down it. If your sub-processor has a breach or GDPR violation, it's your problem as the processor. And through you, the controller's problem. GDPR Article 28(4) makes this explicit: the processor remains fully liable to the controller for any sub-processor's compliance failures.

Common SaaS sub-processors (and which ones most people miss)

Obvious ones: AWS, Google Cloud, Azure (your infrastructure). Most founders know about these.

Frequently missed:

  • Error tracking: Sentry, Bugsnag, Rollbar — these often receive stack traces with user IDs, email addresses, and request payloads. That's personal data.
  • Analytics: Mixpanel, Segment, Amplitude — behavioral data tied to user identities is personal data.
  • Email: SendGrid, Postmark, Resend — you're sending emails containing user data through these services.
  • Customer support: Intercom, Zendesk — support tickets contain user-identifying information.
  • Monitoring and logging: Datadog, New Relic, Loggly — logs often contain IP addresses, user IDs, and sometimes more. IP addresses are personal data under GDPR.
  • AI services: OpenAI, Anthropic — if you pass customer data to these APIs (even indirectly), they're sub-processors. This is the fastest-growing compliance gap in 2026.
  • Auth: Clerk, Auth0, Okta — user account data flows through these.
  • CRM: HubSpot, Salesforce — if your CRM stores customer contact data that came from your SaaS users, check whether it's being used for your own purposes (not a sub-processor) or processing on behalf of your customers (potentially a sub-processor).

What GDPR requires for sub-processors

GDPR Article 28(2) requires that a processor (you) must not engage a sub-processor without prior specific or general written authorisation from the controller (your customer).

In practice, almost all DPAs use general authorisation — meaning your customer agrees upfront that you can use sub-processors, as long as you:

  • Maintain and publish a list of your sub-processors
  • Give prior notice (typically 10-30 days) before adding or changing a sub-processor
  • Give the customer the right to object to new sub-processors
  • Enter into a DPA with each sub-processor imposing the same data protection obligations

The sub-processor DPA chain

Article 28(4) says: when a processor engages a sub-processor, the same data protection obligations as set out in the controller-processor contract shall be imposed on that sub-processor. Specifically, you must ensure your sub-processor agreements include all the Art. 28(3) mandatory clauses.

In practice: AWS, Google Cloud, Microsoft Azure, Stripe, Intercom, HubSpot, Datadog, and most enterprise SaaS vendors have published DPAs. You typically need to accept their DPA in your account settings or sign their standard agreement. For smaller vendors without a published DPA, you need to negotiate one.

Building your sub-processor list

Your DPA with your customer should include an Annex listing your current sub-processors. At minimum, list:

  • Sub-processor name (legal entity name)
  • Country of processing (or data center location)
  • Purpose of processing
  • Link to their privacy/DPA documentation

Keep this list updated. If you add a new sub-processor, notify your customers in advance (per the notice period in your DPA) and give them the right to object. If a customer objects and you can't accommodate the objection, they have the right to terminate without penalty.

International transfers and sub-processors

Many popular sub-processors are US-based (AWS, Stripe, OpenAI, etc.). Transferring EU personal data to US sub-processors requires a legal mechanism under GDPR Chapter V:

  • Standard Contractual Clauses (SCCs): Most US vendors use these. The 2021 updated SCCs (Commission Decision 2021/914) are the current standard.
  • EU-US Data Privacy Framework: US companies certified under the DPF can receive EU data without SCCs. Check the DPF list at dataprivacyframework.gov.
  • Adequacy decisions: Countries with EU adequacy decisions (UK under the UK GDPR bridge, Canada, Japan, etc.) don't need additional safeguards.

If your sub-processors are transferring EU data to the US and none of the above apply, you have a GDPR violation on your hands. Audit your vendor list and check their compliance documentation.

AI sub-processors: the compliance gap of 2026

Adding an AI feature powered by OpenAI or Anthropic? If you pass any personal data from your users into the API — even as part of a prompt — those AI vendors become sub-processors. You need to:

  • Sign OpenAI's or Anthropic's Data Processing Agreement (available in their account settings)
  • Add them to your sub-processor list
  • Update your privacy policy to disclose AI model usage
  • Notify your customers with the contractual notice period
  • Review whether the AI vendor's data retention policies are compatible with your customers' requirements

OpenAI has published a DPA for API customers. Anthropic similarly offers data processing terms. Accepting these should be your first step before processing any customer personal data through their APIs.

Practical checklist

  • ✅ Audit all third-party services in your infrastructure — identify which ones touch personal data
  • ✅ Classify each as sub-processor (processes on behalf of your customers) vs. independent controller (processes for their own purposes)
  • ✅ Confirm a DPA is in place with each sub-processor (accept theirs or negotiate yours)
  • ✅ Check that US sub-processors have a GDPR Chapter V transfer mechanism (SCCs or DPF)
  • ✅ Publish your sub-processor list (link from your DPA and privacy policy)
  • ✅ Add a sub-processor notice clause to your customer DPA (advance notice + right to object)
  • ✅ Review and update the list quarterly

Bottom line

Sub-processors are everywhere in modern SaaS — your infrastructure, email, analytics, error tracking, support tools, and AI features are all candidates. The obligations aren't optional: Article 28(4) makes you liable for your sub-processors' GDPR compliance. Audit your stack, sign the DPAs, publish your list, and give your customers proper notice.

If you need to generate a DPA with a proper sub-processor clause and Annex, our free GDPR DPA generator covers this end-to-end — including the sub-processor table and notification rights clause.

More guides