Subprocessor List: What Must Be On It and How to Spot Gaps

A usable subprocessor list answers three questions for every row: who is the entity, what do they do with the data, and where do they process it. When any of those fields is missing, vague or collapsed into “various”, the list stops being something a privacy team can act on.

This post is about how to read that page and spot the gaps. For the legal definition of a subprocessor and why vendors publish lists at all, start with our guide on what a subprocessor is. Here we stay on the artefact itself.

What practice expects on a usable list

Article 28 of the GDPR requires prior authorisation before another processor is engaged, and most SaaS contracts handle that with general authorisation plus a current list. The Regulation does not itself prescribe a three-column table. The Commission’s own templates do: Annex III of the 2021 standard contractual clauses (Decision (EU) 2021/914) and Annex IV of the Article 28(7) standard contractual clauses (Decision (EU) 2021/915) ask for name, address, contact details and a description of the processing. The EDPB Guidelines 07/2020 on the concepts of controller and processor likewise treat the identity of other processors, and the controller’s ability to object to changes, as part of operable general authorisation.

In day-to-day review, that practice collapses to three fields on every entry: legal name, purpose of the processing, and location (at least country or region). Data categories help when published. A row that cannot supply name, purpose and location is incomplete for an Article 28-style review, even if the rest of the trust centre looks polished.

How real lists look when the fields are filled in

Concrete rows make the standard clearer. As of our check on 25 September 2026, Stripe’s list of subprocessors includes Amazon Web Services, Inc. as a cloud service provider in the United States, with business-user, representative and end-customer data named as categories. Twilio, Inc. appears for cloud communications (including two-factor authentication and user support), also in the United States. Microsoft Corporation appears with an explicit AI purpose: technology to improve the quality of user support operations, processing information from support queries in the United States.

As of the same day’s check, Atlassian’s list of subprocessors names OpenAI, L.L.C. as a generative AI services provider for intelligence product features and for support, in the United States, against customer personal data stored in applicable cloud products or shared during support. Mailgun Technologies, Inc. is listed for product-notification communications, with locations in the USA and the EEA. Those rows give a reviewer something to accept, object to or escalate.

You do not need every vendor to match Stripe’s or Atlassian’s wording. You do need the same three answers. If a row cannot supply them, mark it as incomplete before you debate residual risk scores.

How to spot gaps on a subprocessor list

Reading a subprocessor list for gaps is a pattern-matching skill. Gaps cluster into a few patterns. Train your eye on them.

Category labels instead of entities. Stripe’s list (25 September 2026 check) includes rows titled “User and Sales support service providers” and “Verification service providers”, both with location “Various”. Those may be honest summaries of a changing bench of providers, but they are not entities you can diligence, map for transfers or put in a record of processing activities. Treat a category row as a finding: ask for the named parties, or accept the opacity with a recorded decision.

Purpose stated once for a whole section (and separate product tables). On Atlassian’s own page (read 26 September 2026), Crowdstrike, Okta and Tenable sit in a separate “Atlassian Government Cloud Sub-processors” table whose columns are name and location of processing, not a purpose column per row. Separately, Atlassian group companies (Atlassian B.V., Atlassian Pty. Ltd., Atlassian US, Inc. and others) sit under a section sentence that states their purpose: technical and operational support to customers. Our directory extract can show empty purpose cells for those rows because the purpose sits at section level, or because a Government Cloud table never carried a purpose column. That is a documentation shape to understand, not proof that the vendor stated “no purpose”. When you review, read section headers and scoped tables, not only the per-row cells.

Location too broad to use. Cloudflare, Ltd. on Atlassian’s list (same check) describes location as customer traffic processed globally at the data centre closest to the end user. That may be accurate for a CDN, and still fail a transfer or residency review that needs countries. Stripe’s “Various” rows have the same problem in shorter form.

Tables without a data-categories column. Stripe’s affiliate table (25 September 2026 check) carries name, region, entity country and purpose. It has no data-categories column at all, and it opens with a sentence on which affiliates apply. Describe that as a table without that column, not as blank cells next to filled ones. Open the linked terms or ask the vendor if you need categories for those affiliates.

AI providers buried as ordinary tooling. Atlassian lists Amazon Web Services, Inc. (AWS Bedrock), Google Vertex AI and OpenAI for generative AI features. Stripe lists Microsoft for AI in support. Those purposes change the risk conversation. A list that only says “cloud hosting” for a model provider is a different kind of gap: the name is there, the role is understated.

What “not stated” means in our directory

When ClauseTrail shows a purpose, location or data category as missing, we mean the vendor’s published list did not give that field for that row on the day we read it. We do not infer purpose from the company brand, fill a country from a headquarters address, or copy categories from another product line. Section-level prose and separate product tables (as with Atlassian’s group companies and Government Cloud table) can also leave a per-row extract empty even when the page states something nearby: always open the source page before treating emptiness as a vendor gap.

That honesty rule matters for reviews. A blank in the directory is evidence about the document extract, not evidence that processing is safe. Your follow-up is still to the vendor: update the list, point to another annex, or confirm in writing. For transfer questions that sit beside the list (standard contractual clauses versus the Data Privacy Framework, for example), use the DPA and our comparison of standard contractual clauses versus the Data Privacy Framework.

Pair the list with the DPA notice mechanics

A complete list is only half the control. The data processing agreement should say how you hear about additions, how long you have to object, and which list URL is authoritative. Reading gaps on today’s page without knowing the notice channel leaves you unable to act when the page changes tomorrow. Keep the list URL, the subscription email and the objection window in the same vendor file.

Also watch product-scoped lists. Atlassian’s rows often bound data to “Applicable Cloud Products”, DX, Forge or Loom support. A gap can be product-specific: the entity is fine for one cloud product and undeclared for another you actually use. Scope the review to the products on your order form.

The one check worth making this week

Open the live subprocessor list for one high-data vendor you already rely on. For the first ten rows, fill a three-column grid: name, purpose, location. Mark any cell that is blank, “various”, “global”, a category label, or only a link to another document. Also mark purposes that live only in a section header, and tables that omit a column entirely. Those marks are your gap list. Escalate the AI and support rows first; then the section-level affiliate purposes; then the vague location lines.

When you want the same structured read across vendors, browse the ClauseTrail directory of published subprocessor lists. Each vendor page shows the current list as published and when we last checked it.

ClauseTrail monitors vendor lists of subprocessors, DPAs, privacy policies, terms of service and AI-usage terms, and alerts compliance teams when rows or wording change. See the public directory of subprocessor lists and pricing.

Frequently Asked Questions

What should appear on a subprocessor list?

In practice: the subprocessor’s legal name, the purpose of the processing and the location where it happens. The Commission’s SCC Annex III and Article 28(7) Annex IV templates also ask for address, contact details and a description of the processing. Data categories help when the vendor publishes them. A row missing name, purpose or location is incomplete for an Article 28-style review.

What does “not stated” mean on ClauseTrail?

It means the vendor’s published subprocessor list did not include that field for that entry on the day we read it, or the field sat outside the per-row cells (for example in a section sentence). We do not invent a purpose from the company name or a country from a headquarters address. A “not stated” value is a prompt to open the source page, ask the vendor or record an accepted gap.

Is a location of “global” or “various” acceptable?

It is common for CDNs and pooled support benches, and it is usually too coarse for transfer, residency or record-of-processing work. Treat it as a gap unless the vendor can name countries or regions for the processing that touches your data.

What should I do if a subprocessor list says “various”?

Treat “various” as incomplete for diligence, transfers and your record of processing activities. Ask the vendor for the named entities and countries that apply to your products, or accept the opacity with a recorded risk decision and a date to revisit.

Should affiliates of the vendor appear on the list?

Often yes, when they process customer personal data. Many lists name group companies with a country and a section-level purpose rather than a per-row purpose cell. Read the section prose before treating the affiliate rows as silent on purpose.