← All guides
GDPR7 min read18 May 2026

Sub-Processor List for GDPR Compliance: What It Is, What It Must Contain, and How to Build One

GDPR Art. 28 requires processors to notify controllers of sub-processor changes. Your sub-processor list is part of your sales and compliance stack — here's what to include and how to maintain it.

What is a sub-processor under GDPR?

Under GDPR, a sub-processor is any third party that a processor engages to process personal data on behalf of the original controller. The processing chain works like this:

  • Controller: the entity that determines the purposes and means of processing (your customer);
  • Processor: the entity that processes data on behalf of the controller (typically your SaaS company);
  • Sub-processor: any third party your SaaS engages to help process that customer data (your cloud provider, database, email service, monitoring tools, etc.).

Article 28(2) requires that processors obtain prior specific or general written authorisation from the controller before engaging sub-processors. Article 28(4) requires that the same data protection obligations imposed on the processor (via the DPA with the controller) are also imposed on each sub-processor via a written contract.

In practice, most B2B SaaS companies use a "general written authorisation" model: their DPA or Terms of Service states that the customer gives general consent to the use of sub-processors, with a notification mechanism (typically email or an updated webpage) for any changes. The customer retains the right to object.

Why your sub-processor list matters commercially

Beyond the legal requirement, your sub-processor list is now a standard part of enterprise sales due diligence. Security questionnaires routinely ask: "Please provide a list of sub-processors that may access or process our data." A well-maintained, publicly accessible sub-processor list:

  • Speeds up enterprise procurement processes;
  • Signals operational maturity to security-conscious buyers;
  • Reduces back-and-forth in DPA negotiations (your sub-processor obligations are pre-documented);
  • Reduces GDPR compliance risk for your customers (they can't demonstrate their own DPA compliance without knowing who you sub-process through).

Companies like Stripe, Notion, and Intercom publish their sub-processor lists publicly. Doing the same positions you in the same category of trustworthy vendors — a meaningful advantage when competing against alternatives.

What must a sub-processor list contain?

GDPR doesn't prescribe a specific format, but regulators and enterprise buyers expect to see at minimum:

  • Sub-processor name — the legal entity name, not just the product name;
  • Purpose / activities — what data processing this sub-processor performs on your behalf;
  • Data categories processed — which categories of personal data they receive (e.g. names, email addresses, IP addresses, usage data);
  • Country of processing — where the data is processed (important for international transfer compliance);
  • Transfer mechanism — if data is processed outside the EEA, the legal basis for the transfer (EU Standard Contractual Clauses, UK IDTA, adequacy decision, etc.);
  • DPA / privacy page link — a link to the sub-processor's own DPA or privacy documentation, so your customers can audit the chain.

Some organisations also include: the sub-processor's DPA certification status (ISO 27001, SOC 2), the date of last review, and the notification date (when you started using them).

Which tools are sub-processors vs mere tools?

One of the most common points of confusion is distinguishing which third-party tools are sub-processors under GDPR vs which are just tools your company uses for its own purposes. The test is whether the tool processes personal data about your customers' users as part of delivering your service.

Typically sub-processors (process your customers' user data):

  • Cloud infrastructure (AWS, GCP, Azure) — stores your database;
  • Database-as-a-service (Supabase, PlanetScale, Neon) — hosts your data;
  • Transactional email (SendGrid, Resend, Postmark) — sends emails to your customers' users;
  • Error monitoring (Sentry) — captures stack traces that may include user IDs or email addresses;
  • Application observability (Datadog, New Relic) — logs that may include user identifiers;
  • AI/ML inference (OpenAI, Anthropic) — if you send user-provided content to these APIs for processing;
  • Customer support (Intercom, Zendesk) — support tickets contain user data;
  • Search (Algolia, Typesense) — if your search index includes user-generated content.

Usually not sub-processors (internal tools):

  • Your internal project management tools (Linear, Jira) — unless engineers paste customer data into them;
  • Your company CRM (HubSpot, Salesforce) — unless you're importing customer user data into it;
  • Your internal HR tools — no contact with customer data;
  • Domain registrar, DNS provider — infrastructure that doesn't see your data content.

When in doubt, ask: does this vendor receive or could they access personal data about your customers' end users in the course of providing their service to you? If yes, they're a sub-processor.

The AI sub-processor challenge

AI inference providers (OpenAI, Anthropic, Google Gemini, etc.) are now one of the most frequently questioned items in DPA negotiations. Key issues:

  • Do they use your data to train models? Most enterprise API tiers explicitly do not. Verify this in their data processing addendum and make it visible on your sub-processor list — this is a top-of-mind concern for buyers.
  • Where is processing occurring? US-based AI providers processing EU personal data require SCCs as the transfer mechanism. Check that your DPA with the AI provider includes SCCs.
  • What data categories are you sending? If your AI features process user-submitted content that could include special category data (health information, financial details, etc.), document this specifically.

Notification obligations and the change process

Under the general authorisation model, you must notify controllers "in advance" of any intended change to sub-processors (Art. 28(2)). Your DPA should specify:

  • The notification mechanism (typically email to a designated address, or posting to a public webpage with an RSS feed or changelog);
  • The notification period — how far in advance you'll notify before adding or changing a sub-processor;
  • The objection period — how long the controller has to object (30 days is standard, though some enterprise customers negotiate for longer);
  • What happens if the controller objects (typically: either party may terminate the affected service if the objection cannot be resolved).

Maintain a changelog of your sub-processor list with dates of additions and removals. This is what controllers need to audit their own GDPR compliance, and what regulators will ask for in an investigation.

International transfers and your sub-processor list

Post-Schrems II, every sub-processor in a non-EEA country needs a valid transfer mechanism. For US sub-processors, the most common options are:

  • EU-US Data Privacy Framework (DPF): if the sub-processor is DPF-certified (check the DPF list at dataprivacyframework.gov), this is the simplest mechanism;
  • Standard Contractual Clauses (SCCs): the 2021 SCCs issued by the European Commission are the fallback for non-DPF-certified providers. These must be in your DPA with the sub-processor;
  • UK IDTA or UK Addendum: for UK personal data transfers.

Include the transfer mechanism in your sub-processor list column. Enterprise buyers will check this.

Where to host your sub-processor list

Common approaches:

  • Public webpage: a dedicated page (e.g. /sub-processors or /legal/sub-processors) that is updated when the list changes. Include a "Last Updated" date prominently. This is the most common approach for B2B SaaS.
  • Linked from your DPA: your Data Processing Agreement should include a clause that points to your sub-processor list URL and grants general authorisation subject to the notification procedure.
  • Trust centre: if you have a trust centre (e.g. on TrustArc, Vanta, or a custom page), include the sub-processor list there alongside your certifications and policies.

Generate your GDPR DPA with sub-processor provisions

ComplyKit's GDPR Data Processing Agreement Generator generates a complete Article 28 DPA including a sub-processor authorisation clause, notification procedure, and a populated sub-processor table based on the common SaaS tools you select. This gives you a starting point that covers the legal structure — pair it with a public sub-processor list page for complete compliance.

For the full compliance picture, also review our guide on what is a sub-processor under GDPR and our GDPR DPA explained post.