The brand is not the counterparty

The line that looks finished but is not

A subprocessor annex with a line reading "Heroku — hosting — United States" looks finished. It has a name, a purpose and a country, which is roughly the shape Article 28 expects when the controller authorises a subprocessor. It is still wrong in the way that is hardest to catch on review, because nothing about it looks uncertain.

"Heroku" is a product. The legal person that contracts with an EU customer is a company with a registered name, a seat, and a position in a corporate group. In the current export of our vendor registry, the entity recorded against Heroku is SFDC Ireland Limited, seated in Ireland. The annex line above names neither the company nor the country. It names the thing your client's engineer says in standup.

This is not pedantry about naming. Three separate outputs change when you swap the brand for the entity: the annex, the ROPA and the transfer analysis. And of every field we keep on a vendor, this is the one that goes stale fastest, silently, without the product ever changing.

How often the two diverge

In the current export the registry holds 157 vendor rows. In 38 of them, the product name does not appear anywhere inside the recorded legal entity string — a plain substring test after stripping case and punctuation, so it catches Auth0 sitting under Okta, Inc. and misses nothing subtler than that.

Roughly a quarter of the file, then, is a name that will not match if you search a contract database, a DPF participant list or a company register for the brand.

The relationship also runs the other way. Those 157 rows resolve to 147 distinct legal entities, because seven entities in the current export carry more than one product:

• Content Square SAS is recorded for Contentsquare, Heap and Hotjar.
• Microsoft Ireland Operations Limited is recorded for Microsoft 365, Microsoft Azure and Microsoft Clarity.
• Google Cloud EMEA Limited is recorded for Google Cloud, Google Workspace and the Gemini API.
• SFDC Ireland Limited is recorded for both Heroku and Salesforce.
• Twilio Ireland Limited is recorded for SendGrid and Twilio.
• Atlassian Pty Ltd is recorded for Atlassian and Bitbucket.
• Amplitude, Inc. is recorded for Amplitude and Statsig.

The Twilio family is the useful one to sit with, because it splits both ways in the same export. SendGrid and Twilio resolve to Twilio Ireland Limited, seated in Ireland. Segment resolves to Twilio Inc., seated in the United States. Same brand family, two counterparties, two seats. An annex that lists all three as "Twilio, US" is wrong twice, and an annex that lists all three as "Twilio, Ireland" is wrong once.

What changes in the annex

Article 28 gives you the mechanism the annex is actually doing work for: the controller authorises subprocessors, and is told about intended changes so it can object. An authorisation runs to a legal person. "Heroku" cannot be a party to anything, cannot be notified, and cannot be objected to.

So the annex line grows a column. Not a longer sentence — a column, because the brand still has to appear or nobody at the client will recognise the row:

Service	Contracting entity	Seat
Heroku	SFDC Ireland Limited	Ireland
Segment	Twilio Inc.	United States
SendGrid	Twilio Ireland Limited	Ireland

The second consequence is deduplication. If your client uses Heap and Hotjar, the honest annex has one counterparty with two services, not two counterparties. When a corporate customer of your client counts parties with access, one entity is a materially different answer from two, and it is the answer they can verify.

What changes in the ROPA

The ROPA asks where the data goes, which is a question about entities and their seats, not about logos. Two things tighten when you fill it from the entity.

Recipients stop being a list of tools and become a list of companies. The duplicate collapse above is the same collapse here, and it is the first thing a reviewer notices when they cross-read the annex against the ROPA: if the two documents disagree about how many recipients exist, they were assembled from different fields.

Group structure becomes visible rather than implied. A row that reads Google Cloud EMEA Limited, Ireland says something specific about the counterparty. A row that reads Google, US says something vague about a company that has many.

What changes in the transfer analysis

This is the part where using the brand is not merely untidy. The adequacy data we keep for country pages records that the United States has an EU adequacy decision scoped to "only organisations participating in the EU-US Data Privacy Framework", and that Canada's is scoped to "commercial organisations only".

Participation in that framework attaches to a named legal entity. It is not a property of a product, a domain or a logo. If you check the brand and the contract is signed by a different company, you checked the wrong participant and the answer you wrote down is unsupported — whichever way it came out.

In the current export, 80 of the 157 rows are seated in the United States, with 59 recorded as relying on the framework and 21 on standard contractual clauses. Every one of those 59 is a claim about a specific company name, and that name is the one in the legal entity column, not the one in the product column.

The same discipline changes the answer in the other direction too. Matomo Cloud resolves to InnoCraft Ltd, seated in New Zealand, and the export records the transfer basis as adequacy. Fathom Analytics resolves to Conva Ventures Inc., seated in Canada, also adequacy — with the "commercial organisations only" scope attached, which is a qualifier to confirm rather than assume. If you had filed either under a generic assumption about small analytics vendors, you would have drafted clauses nobody needed.

Why this field dates fastest

A product name is a marketing asset and it survives almost everything. The contracting entity survives nothing: acquisitions, group reorganisations, the creation of a regional subsidiary to contract with EU customers. None of those events change the login page, the invoice branding or the URL your client types.

You can see the aftershocks in the export without reading a single press release. Neon is recorded against Databricks, Inc. Statsig against Amplitude, Inc. Auth0 against Okta, Inc. Lever against Employ, Inc. Close against Elastic Inc. And in 14 rows, the DPA we have on file is published on a host that is not the product's own — Heroku's on salesforce.com, Slack's on salesforce.com, Pusher's on bird.com, Loom's on atlassian.com, Mailgun's on sinch.com. That mismatch between where the product lives and where its contract lives is usually the first visible trace of an entity that has already moved.

Which is why our change monitoring treats legal_entity_changed and transfer_mechanism_changed as their own change types rather than as edits to a page, and why every registry row carries a verification date — in the current export, all 157 were checked on 2026-09-16. A field that can change without any observable signal on the vendor's product needs a date next to it, so the question is never "is this right" but "when was this last true".

If you maintain annexes for twenty or two hundred clients, the practical form of this is a single rule: the registry holds the entity, the documents render the entity, and the brand is a label for humans. That is how clausebench stores it, and it is the reason a vendor's acquisition becomes one registry edit rather than an afternoon of grep across client packs.

The line "Heroku — hosting — United States" is not a small inaccuracy. It names no counterparty, and the transfer conclusion it implies was never checked against a company that exists.