A vendor changed its entity: which documents are now wrong

One line on a legal page

A vendor you have in eleven client stacks moves its EU contracting entity. The announcement, if there is one, is a changed paragraph on a legal page. Nobody emails you. The service works exactly as it did yesterday.

What has actually happened is that a named counterparty in a set of documents that went out under your signature is now the wrong named counterparty. The question is not whether that matters. It is: which documents, for which clients, and which of those have already left the building.

The taxonomy, and why severity is not a feeling

Detection compares two snapshots of one vendor page and emits typed changes. The page types are the data processing agreement, the subprocessor list, the legal page and the trust page. The change types are legal_entity_changed, transfer_mechanism_changed, subprocessor_added, subprocessor_removed, subprocessors_changed, dpa_updated, new_version, page_removed and trust_page_updated. Each carries a severity: critical, notable or minor.

The severities are assigned by rule, not by impression:

• legal_entity_changed is critical. It fires when the contracting entity recorded in the registry stops appearing on the vendor's own DPA or legal page. That is the case in this post.
• transfer_mechanism_changed is critical. Standard contractual clauses, the EU-US Data Privacy Framework, an adequacy decision, binding corporate rules — any of these appearing or disappearing from the page changes what a transfer section in a client document is allowed to say.
• subprocessor_added is critical when the new entries mention a country without an EU adequacy decision, and notable otherwise. The same event, two severities, decided by what is in the added lines.
• page_removed is critical for a DPA or subprocessor list, notable for the others. A document you cite by URL that now returns 404 is a broken citation in every package that cites it.
• subprocessor_removed is minor. A name leaving a list narrows what you claim; it does not put a false statement into circulation.
• trust_page_updated is minor and affects nothing. It maps to an empty document list on purpose.

Two negative rules do as much work as the positive ones. A failed fetch is not a change: a 403, a 429, a 5xx or a timeout means the vendor's site blocked a bot or fell over, and emitting page_removed on those would fill your inbox with fiction. A page is gone only when the server says 404 or 410, or when it redirects a deep link to the home page. And volatile text — rendering dates and similar — is masked before the diff, so a page that reprints today's date at the bottom does not announce itself as changed every single night.

Nothing publishes automatically. A detected change sits in a moderation queue until a person confirms it, adjusts the one-line summary and, if the registry field itself was wrong, corrects it. A false positive broadcast to every consultant using that vendor is not an incident you apologise for; it is the reputational hit that ends the product.

The fan-out, step by step

Approval is where the chain runs. Take the entity move.

Step one: which document types. A confirmed legal_entity_changed maps to four types — subprocessor list, records of processing, data processing agreement, privacy policy. The mapping is per change type, not per vendor. Subprocessor list changes touch three of the four and leave the privacy policy alone; a trust page update touches none.

Step two: which clients. Every client linked to that vendor, across every firm, excluding archived clients. Not the clients you happen to remember using it. This is the part that is physically impossible by hand: nobody is opening forty vendors' legal pages for forty clients each week, so in practice that work simply does not get done.

Step three: which rows. For each of those clients, the documents that exist in the affected types get status = 'stale', and an impact row is written with the list of documents it actually touched for that client — open until you acknowledge or resolve it. The list is per client, because two clients using the same vendor may not have generated the same documents.

There is a second path into the same staleness, worth naming because it is the mirror image. When a client fact changes — not a vendor page — the documents to invalidate are derived from which sections declare that slot as required. Confirm a new value for the vendors slot and the privacy policy, cookie policy, DPA, subprocessor list, records of processing and vendor management policy are the ones that referenced it. Same outcome, computed from the document definitions rather than from a change taxonomy.

Which changes oblige you to tell the client

This is the distinction that decides whether your monitoring is useful or just noisy.

A critical change generates an immediate email, per firm, with the full count of affected clients. Entity moves, a vanished DPA, a transfer mechanism change, a subprocessor added in a jurisdiction without adequacy — these are the four, and they are the ones where a document already in someone's hands now contains a statement you would not make today.

Everything else goes into a weekly digest: the approved changes of the last seven days, each with the number of your clients it touches. Three changes, seven clients, twelve documents. That is a line in a file and a task for Thursday, not a phone call.

The design rule underneath is that the notification is never truncated. You see every affected client and what changed, whether or not you pay for anything. The paid part is regenerating the documents, because a notification that blurs the client list to sell you an upgrade teaches you to distrust the notifications, and then the whole mechanism is worthless.

What has already been sent

Staleness inside your workspace is recoverable. Staleness outside it is the actual exposure, and it has three exits worth checking by name.

The trust page. If the client has one published, it is serving sections built from these same facts and document bodies right now, to whoever has the link. A stale subprocessor list is not sitting in a drawer; it is live.

Approved document requests. When a corporate customer requested the DPA or the subprocessor list through that trust page, there is a row recording who asked, from which company, for which document types, when it was approved, and when the one-time link was downloaded. That row is your distribution list. It is the difference between "somebody out there may have the old version" and a named contact at a named company who took a specific document on a specific date.

Questionnaire answers. Answers marked confirmed carry a pointer to the document and section they were drawn from. When that document goes stale, the answers sourced from it are candidates for the same review — and unlike the document, those answers are already inside somebody else's vendor management system.

"When was this register last true?"

The auditor's question is rarely "is this correct". It is "as of when".

A shrug is the wrong answer, and so is a document with no date on it. The dated answers available here are specific: the vendor registry row carries a verified timestamp, moved when a moderator checked the field against the source, with the correction recorded as a revision rather than an overwrite. Each client fact carries who confirmed it and when. Each document carries when it was generated, its revision number, and a revision history that records what each version came from — a generation, a chat edit, a manual edit, a template, a rollback.

Chain those and the question has an answer with dates in it: this register was built on the twelfth from facts confirmed in March and registry rows verified in August, the vendor's entity changed on the second, we were told the same day, and here is the regenerated version. That is a defensible answer. It is not a claim that nothing ever goes out of date; it is a claim that you know when each part stopped being checked, which is the only version of the claim anybody should believe.

Monitoring this way is the part of clausebench that turns a one-off document package into something with a maintained expiry date, and the chain above is what you are actually buying when you buy it.