Subprocessor lists: what changes when a vendor updates its DPA

Legal entity, location and transfer mechanism: the three fields that matter

The vendor registry behind this site has a deliberately short header:

name, legal_entity, country, category, transfer_mechanism,
dpa_url, subprocessor_list_url, verified_at

Eight columns for 157 vendors. The argument for each one is the same: it is a fact you may have to defend in a document that goes out under your name. Nothing else earned a column — there is no reliability rating and no vendor score, because a number nobody can source is worse than an empty cell.

The name is not the counterparty

name is what your client's engineers call the thing. legal_entity is who is on the other side of the contract, and in the current export those two strings differ on every row. Some of the differences are cosmetic — "AgileBits Inc. dba 1Password", "Formagrid Inc dba Airtable". Some are not:

Vendor as the client names it	Contracting entity	Country
Heroku	SFDC Ireland Limited	IE
Salesforce	SFDC Ireland Limited	IE
SendGrid	Twilio Ireland Limited	IE
Twilio	Twilio Ireland Limited	IE
Amazon Web Services	Amazon Web Services EMEA SARL	LU

Two consequences for portfolio work. A subprocessor list that says "Heroku" and another that says "Salesforce" may be naming one counterparty, and the corporate customer reviewing the list will ask which contract governs. And because an entity change is an entity change, it lands on every product that entity contracts for at once — the unit of change is the legal person, not the brand.

Country is about the contract, not about the data

country records where the contracting entity sits. Where the data is processed is a different fact, and the registry keeps it in a different field. Collapsing the two gives you a document that is confidently wrong: an Irish contracting entity tells you nothing on its own about which regions a service runs in.

The field earns its place because it decides whether a transfer question arises at all, and because it is the field that moves when a vendor restructures. In the current export, 80 of 157 contracting entities are recorded in the US, 21 in Ireland, 14 in France.

The mechanism belongs to a document, not to a company

transfer_mechanism is a closed set — SCC, DPF, adequacy, none, n/a — because free text in this column is unusable the moment you have more than a handful of clients. Two rows from the same registry:

Service	Contracting entity	Mechanism recorded
Microsoft 365	Microsoft Ireland Operations Limited	DPF
Microsoft Azure	Microsoft Ireland Operations Limited	SCC

Same entity, different mechanism, because the mechanism is a property of the document you actually read, not of the company that published it. Track it per service and you can answer a questionnaire. Track it per company and you will eventually answer one wrongly.

The distribution matters for how you prioritise work: 83 rows in the current export record DPF, 62 standard contractual clauses, 5 adequacy and 7 not applicable. The registry's own country data notes that the US entry on the Commission's adequacy list covers only organisations participating in the EU-US Data Privacy Framework. A DPF row is therefore a statement about one organisation's participation, not about a country — which is why it can change without anything visible happening to the product.

Two URLs and the honest blank

dpa_url and subprocessor_list_url are the evidence. They are also the two fields most likely to be empty: 27 rows in the current export have no DPA link, 37 have no subprocessor list. That blank is itself a recorded fact. When a document is generated from a record with an empty dpa_url, the right output is a gap marker asking the consultant to supply the link — not a plausible-looking URL that returns 404 in front of your client's customer.

Changes that trigger notification duties

Article 28(2) is the mechanism that makes any of this operational. A processor may not engage another processor without the controller's prior specific or general written authorisation; where the authorisation is general, the processor must inform the controller of intended additions or replacements and give it the opportunity to object. Article 28(4) then requires the same data protection obligations to be imposed on the further processor by contract, and leaves the first processor fully liable for its performance.

Almost every vendor DPA your clients sign runs on the general-authorisation branch. That has a practical consequence people under-appreciate: the objection window starts from the vendor's notice, not from the day you read it. A notice that sat unread in a shared inbox for three weeks has consumed the client's window, and the only way to know is to be watching the list yourself.

Here is the taxonomy the monitoring behind this registry actually distinguishes, with the severity attached to each:

Detected change	Severity
Contracting legal entity no longer on the page	critical
Transfer mechanism appeared or disappeared	critical
DPA or subprocessor page removed	critical
Subprocessor added, entry names a country without adequacy	critical
Subprocessor added, adequacy or DPF covered	notable
New dated version of the DPA, or DPA text changed	notable
Subprocessor list changed, no recognised name in the diff	notable
Subprocessor removed	minor
Trust page updated	minor

The four criticals are the ones that put a letter in your outbox this week.

The contracting entity changed. The client's DPA names a party. If that party is no longer the one contracting, the paperwork has stopped describing reality, and the transfer analysis usually moves with it — an EEA entity replaced by a US one changes the mechanism question, not just the name on page one. Every document built from that vendor record goes stale: the subprocessor list, the ROPA, the DPA schedule and the privacy policy.

The transfer mechanism changed. A page that used to mention standard contractual clauses and now mentions the Data Privacy Framework, or the reverse, invalidates the transfer column of the ROPA and, where the client publishes one, the transfer paragraph of its privacy notice. Note what the detection actually is: mentions on a page appeared or disappeared. That is a signal, not a legal conclusion. You read the document and decide what it means; a tool that decides for you is handing you a professional risk dressed as a convenience.

The DPA or the subprocessor page is gone. A 404 or a redirect to the home page means the citation in a package you have already delivered now points at nothing, and the discovery path is usually a corporate reviewer clicking it. Treat this as urgent — but only when the server actually says so. A 403, a 429, a 5xx or a timeout is a failed fetch, not a withdrawal: vendor sites block automated readers routinely. If you run your own link checks, encode that distinction or you will send a client a panicked email about a page that is perfectly fine.

A subprocessor was added. This is the change the article is written about. The severity turns on geography: an added entry that names a country outside the EEA, the UK and the Commission's adequacy list changes the client's transfer position, and the analysis has to be redone before the objection window closes. An addition covered by adequacy or by a framework participation is still a notification, still an update to the published list, but it is next week's work rather than today's.

Changes that only need a file note

The rest of the taxonomy is real and worth recording, and almost none of it justifies an email to a client.

A subprocessor was removed. A removal narrows the processing. No new recipient, no new transfer, nothing for the client to object to. It does make the client's published subprocessor list inaccurate, so it belongs in the next regeneration — not in a letter. It is also the change most likely to be an artefact: a well-built diff only counts a name as removed when the new text does not mention it anywhere, because a reformatted table row is not a departure.

A new dated version, with no entity or mechanism signal. Read the diff, note the version and the date, and check one specific thing before you file it: does the client's own DPA incorporate the vendor terms by reference? If it does, a version bump has changed the client's contract, and that is worth a line in the next report even when the substance is neutral.

The list changed but no known name appears in the diff. Usually reordering, re-categorisation or a wording change. Read it, note it, move on.

The trust page changed. Nothing downstream is built from it. No document goes stale. This is the clearest case in the taxonomy for a note and nothing more.

Two operational rules keep this half of the list from filling up with noise. First, normalise before you compare: strip navigation, headers, footers and scripts, and mask the things that change on every render — dates, times, the copyright year, long cache identifiers. A page that reprints today's date at the bottom is not a page that changed. Second, a failed fetch is never a change, and the first successful fetch after a run of failures has no baseline to compare against. That gap is not a clean bill of health; it is a prompt to look at the page yourself.

If you want one test to apply to a change landing in your inbox, ask three questions:

1. Does it change who the counterparty is?
2. Does it change where the data can go?
3. Does it change something the client has already published or told people?

Any yes is a client communication. Three noes is a file note.

Keeping evidence of when you checked

The registry gives every record a verified_at and a verified_by. Both columns exist for the same reason: the defensible claim is never "this is true", it is "this is what the page said on this date, and this is who read it". Records older than twelve months get flagged for re-verification rather than quietly ageing, because an unreviewed fact looks exactly like a reviewed one in a generated document.

Batch verification is fine — every row in the current export carries the same checked date, because they were checked together. What is not fine is a checked date that was copied forward without anyone opening the page.

Underneath the registry sit two separate trails, and the separation is the point.

• Snapshots. For each URL, each fetch stores the HTTP status, the final URL after redirects, the normalised text and its hash, and the "last updated" date printed on the page. That is enough to reconstruct a diff months later without depending on a third-party archive, and enough to answer the only question that ever gets asked in a dispute: what did this page say when you wrote the document?
• Record revisions. Every change to a vendor record writes the previous state, the list of fields that changed, and the source of the change — a monitor, a manual edit or an import. In an audit that last column is the one that matters. "The field changed because the page changed on this date" and "the field changed because a colleague edited it" are different stories, and you cannot reconstruct which one applied if you only keep the current value.

Compare both the hash and the vendor's own "last updated" line, not one or the other. A vendor can revise text without touching the date, and can touch the date without revising anything. The date is a claim; the hash is an observation.

One more discipline, borrowed from how the registry itself is maintained: a detected change is not published until a human confirms it. Publishing a false positive sends wrong information about a vendor to everyone downstream, and a correction email does not undo it. The rule scales down to a one-person practice — never forward a raw monitor alert to a client. Open the page, confirm what changed, then write.

Communicating changes to clients

Match the cadence to the severity, and say so in the engagement terms so nobody is surprised. Critical changes go out on their own, immediately. Everything else goes into a periodic digest: three vendor changes this week, seven clients affected, twelve documents to regenerate. A consultant who emails on every trust_page_updated trains clients to ignore the emails that matter.

Batch by client, never by vendor. One client with forty vendors gets one message covering everything that touched it. The same vendor change can reach a dozen clients with entirely different consequences — one publishes that vendor in its subprocessor list, another uses it for something that never touched personal data — so the letter goes only to the clients where the vendor is actually linked to a purpose.

A client-facing change notice needs six things and nothing else:

1. The vendor, by contracting entity, not just the brand name.
2. What changed, in one sentence, taken from the diff.
3. The date you observed it, and the date the vendor gave, if it gave one.
4. Which of the client's documents are now out of date.
5. What you will do, and by when.
6. What requires the client's decision, with the deadline if one is running.

Do not attach the diff. Do not send the objection decision as though it were yours: under Article 28(2) the objection belongs to the controller. State the change, state the window, give your recommendation with the reason behind it, and let the client decide. The same restraint applies to every legal qualification in the chain — controller or processor, in scope or out. You propose and explain the trigger; the client confirms.

Keep the per-client change log. At renewal, a list of the vendor changes you caught, the dates you caught them and the documents you refreshed is the most concrete description of the retainer that exists. The work is invisible when nothing goes wrong, which is precisely when clients ask what they are paying for.

Clausebench maintains this registry, watches the vendor pages behind it and shows which clients' documents a confirmed change has made out of date; those notifications are free and are not truncated. However you track it, the thing to get right is the split above — the difference between a change that starts a clock and a change that starts a paragraph in a file.