GDPR Subprocessors: What Controllers Must Check

What GDPR subprocessors mean for the controller

Under the GDPR, a SaaS vendor that processes personal data for you is a processor. The companies that vendor engages to help (cloud hosts, support platforms, email providers) are subprocessors. The phrase GDPR subprocessors is usually searched by controllers who need to know what they must do about that chain, not what the processor must put in its contract.

That distinction matters. Article 28 of the GDPR sets duties on both sides. The processor must not engage another processor without your authorisation, must flow down the same obligations, and remains liable if a subprocessor fails. You, as controller, must use only processors that provide sufficient guarantees, keep records that reflect who receives the data, and stay able to demonstrate accountability when a list changes.

This post is written from the customer side. For the dictionary definition of a subprocessor, see our learn guide on what a subprocessor is. For the Article 28 checklist a processor must meet in the DPA itself, treat that as a separate reading of the contract text.

What the GDPR actually expects of you

Three controller-facing rules shape how you handle GDPR subprocessors in practice.

Sufficient guarantees. Article 28(1) requires the controller to use only processors that provide sufficient guarantees to implement appropriate technical and organisational measures so that processing meets the Regulation and protects data subjects’ rights. Choosing a vendor without checking who sits behind it is not enough. The guarantee assessment covers the processor and, through Article 28(4), the chain it builds under it.

Authorisation and the chance to object. Article 28(2) says the processor shall not engage another processor without prior specific or general written authorisation. With general authorisation (the usual SaaS model), the processor must inform you of intended additions or replacements “thereby giving the controller the opportunity to object to such changes.” Your DPA is where that notice period and objection process live. The statute does not invent a 30-day window; the contract does.

Accountability and records. Article 5(2) makes the controller responsible for, and able to demonstrate, compliance with the principles. Article 30(1) requires a record of processing activities that includes “the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or international organisations.” When a vendor adds a subprocessor in India or the United States, your record of processing activities and any transfer documentation need to stay accurate.

None of this turns you into the subprocessor’s customer. You rarely have a direct contract with Amazon Web Services or Twilio. Your leverage sits with the vendor you hired, through the DPA and the authorisation you gave.

How vendor lists look in practice

Public lists make the chain visible. As of our check on 25 September 2026, Stripe’s subprocessor list names Amazon Web Services, Inc. for cloud hosting (United States), Twilio, Inc. for communications and two-factor authentication (United States), and Salesforce, Inc. for customer-service interactions (United States), among others, with support partners in Ireland, Colombia, Malaysia, the Philippines and India. Atlassian’s list , as of the same check, includes Amazon Web Services across multiple regions, plus providers such as Databricks, MongoDB, Snowflake and Mailgun for hosting, analytics, databases and product notifications.

Those names are not abstract. Each one is a recipient for Article 30 purposes, and each location outside the EEA can trigger transfer questions. Controllers who treat the list as optional reading usually discover the gap when a customer, auditor or supervisory authority asks who else touches the data.

The notice mechanics matter as much as the names. As of our checks on 25 September 2026, Stripe’s DPA commits to email notice at least 30 days before adding a subprocessor; HubSpot’s DPA gives a 30-day objection window on reasonable grounds relating to protection of customer personal data; Atlassian’s DPA likewise gives at least 30 days’ notice to subscribed emails before a new subprocessor may process customer personal data. The GDPR requires the opportunity to object under general authorisation. The DPA is where the clock is set.

Transfers hitch a ride on the list

GDPR subprocessors often sit outside the EEA. When they do, Chapter V of the GDPR applies to the transfer. Controllers need to know whether the vendor relies on an adequacy decision, the EU–US Data Privacy Framework, standard contractual clauses, or binding corporate rules, and whether a transfer impact assessment is needed for a particular destination.

As of 25 September 2026, Stripe’s DPA cites Modules 1 and 2 of the Commission SCCs (Implementing Decision (EU) 2021/914) and participation in the Data Privacy Framework. HubSpot’s DPA cites SCCs, DPF certification and BCR authorisation. Atlassian’s DPA cites SCCs, DPF participation and adequacy decisions. Those clauses sit next to the subprocessor list: a new US or Indian entity on the list is not only a new recipient, it can change which transfer tool and which assessment you need on file.

For the difference between SCCs and the Framework in plain terms, see our guide on standard contractual clauses versus the Data Privacy Framework.

What to do when you are the controller

Translate the articles into a weekly operating rhythm.

1. Map which vendors process personal data for you. Controllers, not processors, own the purpose. If the vendor decides means on your documented instructions, it is a processor and its list matters.
2. Locate each vendor’s current subprocessor list and DPA. Prefer the list the vendor publishes over a PDF annexed years ago. Record the URL and the date you last read it.
3. Check authorisation terms. Confirm you gave general or specific authorisation, what notice you are owed, and how you object. If the DPA is silent on notice, that is a negotiation point, not a GDPR number the vendor somehow omitted.
4. Update your records when the list moves. Article 30 recipients, privacy notices that name categories of recipients, and any transfer documentation should track material additions, removals and location changes.
5. Decide whether to object. Objection rights under general authorisation are real but commercial. Use them when the new entity’s purpose, location or security posture creates a risk you cannot accept, and document the decision either way.

Procurement, security and the data protection officer often split these steps. The DPO cares about the ROPA and transfers. Security cares about the new entity’s controls. Procurement cares whether an objection is workable. Align them before the notice window closes.

The one check worth making this week

Pick one production SaaS vendor. Open its published subprocessor list and its DPA’s subprocessor clause. Confirm three things: the list URL still resolves, the notice period matches what you think you signed, and at least one non-EEA location on the list is reflected in your transfer documentation. If any of those three fails, fix that vendor before you expand the exercise.

ClauseTrail reads vendors’ subprocessor lists and related contract documents every day and surfaces what changed, with links to the versions it compared. Browse the vendor directory or a page such as Stripe’s to see a current list as we extracted it. Plans and limits are on pricing.

Frequently Asked Questions

What are GDPR subprocessors from a controller’s point of view?

They are the companies your processor engages to help process personal data on your behalf. Under Article 28 you must authorise that engagement (specifically or generally), and under Article 30 you must be able to account for those recipients in your records. You usually have no direct contract with them; your rights and duties run through the processor’s DPA.

Does the GDPR require vendors to publish a public subprocessor list?

No. Article 28(2) requires prior authorisation and, for general authorisation, information about intended changes so you can object. A public HTML list is a common way vendors meet that transparency expectation, but a private portal, email annex or DPA schedule can also satisfy the duty if you actually receive timely notice.

How much notice must I get before a new subprocessor is added?

The GDPR does not set a fixed number of days. It requires that general authorisation come with information about intended changes and an opportunity to object. The notice period (often 10, 14 or 30 days in SaaS DPAs) is a contractual term. As of 25 September 2026, Stripe, HubSpot and Atlassian each commit to a 30-day window in the DPAs we have read.

Do I need a transfer impact assessment for every subprocessor outside the EEA?

Not automatically for every name on every list. You need an appropriate Chapter V mechanism for restricted transfers, and where you rely on SCCs you must assess whether the destination country’s law and practice allow the importer to honour them. Material new locations or novel processing (for example an AI provider receiving customer content) are the usual triggers to refresh that assessment.

What if I object to a new subprocessor and the vendor will not change course?

Your objection rights are contractual. Many DPAs let the vendor terminate the affected service if it cannot accommodate the objection. Document the risk, escalate commercially, and decide whether to accept, migrate or stop using that feature. The accountability principle still requires you to record why you continued or stopped.

How do GDPR subprocessors relate to my privacy notice?

Articles 13 and 14 require information about recipients or categories of recipients. Controllers often disclose categories (“cloud hosting providers”, “customer support tools”) rather than every legal entity. When a change introduces a new category or a sensitive destination, revisit whether the notice still matches reality.