What to check in a payment provider's sub-processor list (GDPR checklist, 2026)

Start with the provider's role: is it your processor, or an independent controller, as many merchants of record are? Then check each entry's legal entity, country and purpose, and which entries are US companies under which transfer tool. If the provider is your processor, the EDPB's 2024 opinion says you should have every sub-processor's identity readily available, at every level, whatever the risk.

Step zero: decide whether the provider is your processor

A sub-processor list is a processor's disclosure. Under Article 28(2) GDPR, a processor needs your prior written authorisation, specific or general, to engage another processor. Under a general authorisation, it must tell you in advance about intended additions or replacements, so you can object. That right exists only for data the provider processes on your behalf. If the provider decides on its own why and how it uses the data, it is an independent controller (deciding jointly with you makes it a joint controller), and its list describes its own vendors.

Roles are assessed for each processing operation, and they follow what the provider actually does, not the label in its contract. Payment providers usually fit one of these patterns:

• Processor: the provider handles data only on your instructions. Its list is your sub-processor chain, and Article 28 applies in full.

• Independent controller: the buyer contracts with the provider, which sets its own purposes. Many merchants of record work this way. Paddle's terms (6 October 2026) say each party acts as an independent controller, and its Data Sharing Addendum shares buyer data with sellers controller to controller, with SCC Module 1 for restricted transfers. Paddle also publishes a processor DPA (1 February 2023) that points to ProfitWell pages, which is one reason the two get mixed up.

• Mixed: one company plays both roles. Stripe's DPA (28 September 2026) makes Stripe a processor when it services the platform and provides its products for you, and a controller for its own purposes, such as choosing banks, preventing fraud, AML checks and improving its products. Adyen's current terms say it may act as processor or controller depending on the service, and its privacy statement covers shopper card and transaction data as controller processing.

We sit in the second group for the buyer data we use to sell, charge for and account for your product. Our Data Protection Addendum (section 2.3) records that we do not act as your processor. It also says (section 2.2) that we are not joint controllers, but if you help decide how buyer data is collected or used, that part could still be joint control under Article 26.

An independent controller is still a recipient of your data, so some duties stay with you. You need a lawful basis for any personal data you send it yourself. Your privacy notice should name it as a recipient, and your records of processing should cover it among your categories of recipients. Our DPA (section 5.2) asks sellers to name us in their privacy notice as merchant of record and independent controller.

The role question trips up AI assistants too. In 121 AI answers to a sub-processor prompt that we tracked between 9 October and 2 November 2026, 41 named Paddle. In 35 of them, the answer framed Paddle, next to Stripe and Adyen, as a processor whose vendors are your Article 28 sub-processors, and none of the 121 mentioned merchants of record. If you are deciding how a merchant of record fits your GDPR records, start with our guide to merchant-of-record data roles.

The 12-point checklist

Items 1 to 4, 6 to 8, 10 and 11 rest on Article 28, Chapter V or the EDPB's opinion, and they apply where the provider is your processor. Items 5, 9 and 12 are good practice. For a provider that acts as an independent controller, use the whole list as due diligence: Article 28 gives you none of it as a right.

1. A full legal entity name, address, country and contact point for every entry, not a brand.

2. What each entry does with the data and, as good practice, which data categories it receives.

3. Chain depth: every processor further down the chain, hosting included.

4. A transfer tool for every transfer outside the EEA, including remote access and onward transfers, and, for SCCs, which module.

5. US parents, including EU subsidiaries and EU-hosted services of US groups.

6. The notice period before a new entry takes effect.

7. Your right to object and, as good practice, what happens if you do.

8. How you hear about changes. A processor has to flag them to you, so an edited page on its own is weak.

9. AI and LLM providers, and what data reaches them.

10. Affiliates named one by one, with their countries.

11. The DPA's wording on legal demands, and a duty to tell you about them.

12. The date the list was last updated.

On item 4, the SCC module has to match the real roles. The Dutch data protection authority fined MLU B.V., the Dutch company behind the Yango taxi app, EUR 100 million over transfers of Norwegian and Finnish users' data to Russia, in a decision dated 1 April 2026 and announced on 8 May. According to Alston & Bird's summary, Ridetech International, a former MLU subsidiary whose obligations MLU took over, had used controller-to-processor clauses for a Russian group company that the regulator treated as a joint controller, so the clauses did not fit the transfer. Encryption keys held in Russia added to the finding, and MLU said it would challenge the decision.

Adequacy decisions include the EU-US Data Privacy Framework, which covers only US companies certified under it. It is valid as of this update: the EU General Court dismissed a challenge to it on 3 September 2025 (Latombe v Commission, T-553/23), and an appeal (C-703/25 P) is pending at the Court of Justice. One gap remains open: the Commission says it is still developing separate SCCs for importers whose processing is itself subject to the GDPR under Article 3(2).

On item 5, server location does not settle US access. Under the CLOUD Act (18 U.S.C. 2713), a provider of electronic communication or remote computing services must comply with US legal process for data in its "possession, custody, or control", whether the data is stored inside or outside the US. A US cloud company running an EU data centre is inside that rule. An EU subsidiary of a US group is a harder call: it turns on whether the subsidiary is itself subject to US jurisdiction and whether the US parent controls its data. The statutory route for challenging an order that conflicts with foreign law (18 U.S.C. 2703(h)) applies only to countries with a CLOUD Act agreement, and no EU member state has one as of this update. The list should name the parent so you can weigh this when you assess the provider.

On item 11, the wording matters most where data leaves the EEA. The EDPB calls the Article 28(3)(a) phrase "unless required to do so by Union or Member State law to which the processor is subject" highly recommended but not strictly required (paragraph 108). The contract must still oblige the processor to tell you when a law requires it to process data outside your instructions. A broader "law or binding order of a governmental body" clause does not breach Article 28(3)(a) on its own (paragraph 124), but it releases neither party from the duty to inform you or from the transfer rules. Where data is processed outside the EEA, the EDPB says those words alone are "highly unlikely to suffice" (paragraph 116): the parties should assess the third country's law and deal with it in the contract.

Stripe, Adyen, Paddle and tiun lists compared

Stripe and Adyen give you about 30 days to object to a new entry, and silence counts as acceptance at both. Paddle and we act as independent controllers for buyer data, so neither list carries an Article 28 objection right. All rows checked on 4 November 2026.

Limits of EDPB Opinion 22/2024

The opinion, adopted on 7 October 2024, sets a fixed bar for knowing who is in the chain and a risk-based one for checking them. Controllers should have the name, address and contact person of every processor and sub-processor "readily available at all times", whatever the risk, and the processor should supply and update that information without being asked (paragraphs 22, 31 and 32).

On the checking side:

• You have no duty to ask systematically for sub-processing contracts. Decide case by case, ask when you doubt compliance or a regulator asks, and run an audit process that checks a sample of them (paragraphs 69 and 70).

• You must verify that your processors give sufficient guarantees, whatever the risk. You can rely on what your processor tells you if it shows compliance, ask for more when it looks incomplete or wrong, and check harder as the risk rises (paragraphs 47, 48, 52, 59 and 60).

• The opinion covers processors acting for a controller and does not deal with independent controllers; it expressly leaves data sent to separate controllers out of one of its questions (paragraph 76). An independent controller answers for its own processors under Article 28, which is why step zero comes first.

Worked example: our own list

Our list is dated 2 September 2026 on the web page (the PDF shows version 2026.9) and has 12 entries. These are the processors we use for our own processing as merchant of record, so they are not sub-processors in your chain. Our DPA calls them sub-processors because they process data for us.

Nine of the 12 are US companies or European subsidiaries of US groups. Our DPA (section 8.1) says we process data primarily in Switzerland and the EEA, and the table shows which flows leave. Card and PayPal data can reach the US for backup, operations and clearing. Google and Microsoft are listed as "EEA / Global". Sign-in codes, transactional email, error logs, product analytics and our AI tools, including support workflows, are processed in the US. Stripe's DPA also makes Stripe a controller for its own purposes, such as fraud and AML checks, which our list does not show.

Buyers give their data to us directly at checkout, so that is not a transfer by you. If you send us personal data yourself, the EU's adequacy decision for Switzerland covers it. Our privacy policy applies the GDPR where buyers are in the EEA and names rivacy GmbH in Hamburg as our EU representative where Article 27 requires one.

Run against the checklist, the list dates itself (item 12), gives a purpose for every entry and names a transfer tool wherever the list says data reaches the US. It points to a change subscription in the Supplier Dashboard (item 8). Items 7 and 11 have no equivalent for an independent controller like us, and the list names no affiliates (item 10). It falls short elsewhere:

• Some names do not match the vendor's own legal entity. Loops is run by Astrodon Corporation, Quaderno by Recrea Systems, SL, and Ipregistry by Elaunira SARL, and Statsig's site now shows Statsig, LLC, with its product and customers at Amplitude (item 1).

• No addresses or contact points (item 1).

• No data categories per entry; our DPA (section 4.1) lists categories only for our processing as a whole (item 2).

• Where the list names hosting, it sits in brackets rather than as entities, so AWS appears under seven entries without a row of its own (item 3). Ipregistry's own provider page also lists US cloud providers that our entry does not mention.

• Several tools are Swiss ones, such as the Swiss-US DPF, and for those entries the list does not say which tool covers EU buyers' data under the GDPR. It names no SCC module and gives Google and Microsoft a tool only for the US although both are listed as "EEA / Global" (item 4).

• No parent companies; the last column above is our addition (item 5).

• "Reasonable advance notification" with no fixed number of days (item 6).

• OpenAI is listed for internal operations, product development and support, but the list does not say which model provider, if any, powers AI Analytics (item 9).

One future change matters for your records. Our DPA (section 2.4) says that when we switch on a planned feature that lets you push your own data into our systems, for example from your own MCP server or an integration, including for AI Analytics, we will act as your processor for that data under an annex we publish first. The processors we use for that data would then be sub-processors in your chain, with your Article 28 rights.

Red flags

• Entries that give a brand with no legal entity or country.

• "Affiliates" as a single line with no names.

• Changes announced only by editing the page, with no email or feed.

• AI features that send personal data to an outside model provider missing from the list.

• No date on the list.

• "EU-hosted" next to a US group, with nothing on access from outside the EEA or on government requests.

• A provider that calls itself your processor in one document and a controller in another, without saying which data falls under which.

FAQ

Does Stripe's sub-processor list cover my customers' data?

Partly. Stripe's DPA makes Stripe your processor when it services the platform and provides its products for you, and a controller for its own purposes, such as fraud prevention and AML checks. The service-provider list and your objection right cover the processor part. If you subscribe, Stripe emails you at least 30 days before it adds a sub-processor. Its DPA says you transfer personal data to Stripe, LLC in the United States.

Do I need to list my merchant of record in my own sub-processor list?

Usually not. Your sub-processor list covers parties that process your customers' data for them, and a merchant of record acting as an independent controller does not. That changes in some cases. If you send it personal data you hold as a processor, such as user lists for seat billing, you need your customers' authorisation first. If it becomes your processor for some data, as we would under the annex our DPA (section 2.4) describes, it is a sub-processor for any customer data you put through that feature. Either way, name it as a recipient in your privacy notice.

How often should I re-check a sub-processor list?

Subscribe to change notices and review each one inside the objection window, which is about 30 days at Stripe and Adyen. Re-read the whole list when you renew the contract, when the provider adds AI features, and when one of its vendors changes owner. Twilio bought Stytch in November 2025, and Statsig's product and customers moved from OpenAI to Amplitude in May 2026; both kept their names.

Does EU hosting by a US provider avoid the CLOUD Act?

Not by itself. The CLOUD Act lets US legal process reach data that a communications or cloud provider subject to US jurisdiction holds or controls, wherever it is stored. For an EU subsidiary of a US group, the answer depends on jurisdiction and control, so weigh it when you assess the provider.

Is the EU-US Data Privacy Framework still valid?

Yes, as of 4 November 2026, for US companies certified under it. The EU General Court dismissed a challenge on 3 September 2025 (T-553/23), and an appeal (C-703/25 P) is pending at the Court of Justice. If the Court annuls the adequacy decision, US entries that rely on it alone would need another tool, usually SCCs backed by a transfer impact assessment. Transfers from Switzerland to the US rely on a separate Swiss-US framework.

This is general information, not legal advice. Check your own set-up with your DPO or counsel.