A vendor's sub-processor list is the most useful document it publishes, and the one buyers read least carefully. It tells you who else will touch your data, where they sit, and how honestly the supplier describes its own supply chain. Reading it properly before signature costs an hour and prevents a category of surprise that is expensive to unwind later.
This article covers what to look for, what the common gaps mean, and how to turn the list into something you can rely on. If the list has already changed and you are deciding what to do about it, our article on monitoring sub-processor changes picks up from there.
Find the list first
Start by establishing that a list exists and where it lives. Suppliers publish them in several places, and the location tells you something:
- A dedicated sub-processor page linked from the trust center or the Data Processing Agreement.
- An annex inside the Data Processing Agreement itself.
- A section of a general privacy or security page.
- On request only, under a non-disclosure obligation.
- Nowhere.
A published, dedicated page is the best signal. It means the supplier expects scrutiny and has committed to maintaining the disclosure. A list available only on request is workable but adds friction to every future check. No list at all, for a supplier that plainly uses infrastructure providers, means the disclosure duty in Article 28(2) of the General Data Protection Regulation (GDPR) is unlikely to be operating well either.
What a complete entry looks like
Assess each entry, not just the list as a whole. A useful entry identifies:
- The legal entity name, not merely a brand or product name.
- The processing it performs, described specifically enough to be meaningful.
- The country or countries where processing takes place.
- Where relevant, the group relationship, since affiliates in third countries are frequently the real transfer.
Entries that say only "cloud hosting provider" or "communications infrastructure" without naming the entity are not disclosures. They prevent you from doing the transfer analysis you are responsible for, and they should be raised before signature rather than accepted as normal.
Six things worth checking
1. Categories used in place of entities
Some lists mix named entities with unnamed categories. Categories are sometimes legitimate, for example where a supplier uses one of several regional carriers depending on routing. More often they are a way to preserve flexibility without accepting the disclosure duty. Ask which entities sit behind each category.
2. Affiliates treated as invisible
A supplier's own group companies are frequently sub-processors in substance: a development team in one country, a support function in another. Lists that name only third-party vendors and omit intra-group processing understate the chain, and intra-group arrangements are where a surprising share of third-country access actually lives.
3. Location described as a region
"Global", "EU/US", or "various" is not a location. Transfer analysis requires a destination. If a supplier cannot say where a sub-processor processes, it cannot support the assessment you owe, and our international data transfer checklist sets out what you need instead.
4. Support and administrative access
Storage location and access location are different questions. A supplier can store data in an EU region while support staff elsewhere can read it. Ask explicitly where administrative and support access originates, because it rarely appears on the list and it is a transfer.
5. Whether the list is dated and versioned
A list with a "last updated" date and an archive of previous versions is a supplier that understands what customers need. A list with neither leaves you unable to say what the position was when you signed, which is exactly what you will need to show later.
6. How changes are announced
Find the notification mechanism before you need it: a subscription, an email to a named contact, or nothing. This determines whether your objection right under a general authorization is real or theoretical, as our comparison of general and specific authorization sets out.
Turning the list into evidence
Whatever the list says, capture it as it stands on the date you assess it. A hyperlink is not evidence: the page it points at can change without notice, and the version you relied on disappears when it does.
Keep a dated capture of the page content alongside the assessment, and record the entities, locations, and mechanisms in your own records rather than only in the vendor's format. That is what allows you to answer, two years later, what the chain looked like when you made the decision. Our article on audit-ready vendor evidence covers the standard, and building a sub-processor inventory covers the structure to keep it in.
What to do when the list is inadequate
Escalate before signature, when you still have leverage. In order of preference:
- Ask for the missing entity names and locations directly. Many suppliers will provide them even when the public page is vague.
- Ask for a contractual commitment that the published list is complete and will be maintained.
- Ask for notice terms that push notifications to you rather than requiring you to poll a page.
- Where the supplier will not improve the disclosure, record that as a finding in the assessment and factor it into the risk decision.
A supplier that resists identifying its chain before signature will not become more transparent afterwards, and that is itself a useful piece of diligence.
Frequently asked questions
Is a supplier legally required to publish a sub-processor list?
The GDPR does not require publication as such. Article 28(2) requires authorization and, under a general authorization, that the processor informs the controller of intended changes. In practice publication is how most suppliers discharge that duty, and its absence makes the duty harder to satisfy.
Do we need to assess every sub-processor individually?
No. You contract with the vendor, which remains fully liable to you under Article 28(4) for its sub-processors' performance. What you need is enough visibility to run the transfer analysis and to notice material changes.
What if the list is very long?
Length is not itself a problem. Concentrate on entries that involve third countries, that can read rather than merely store data, and that are new since your last review.
How often does a list change?
Often enough that annual review misses things. The drivers are covered in our article on why sub-processor lists change.
Where DPAFlow fits in
Reading the list once is diligence. Knowing when it changes is the harder problem, because the change happens on the supplier's website and generates no signal in your systems. DPAFlow checks vendor sub-processor lists, Data Processing Agreement pages, and trust-center pages on a scheduled, recurring basis, records what changed with dated evidence including captured page text and change differences, and sends email alerts. Detected changes enter a review workflow where your team assesses materiality and documents its decision.
DPAFlow does not judge whether a sub-processor is acceptable and does not provide legal advice. It preserves the version you relied on and surfaces the difference when it moves. The evidence model is described on the evidence page.
This article is guidance for evaluating a disclosure. It is not legal advice, and the assessment calls belong to your privacy function and counsel.