When a vendor has no public data processing agreement

Start with how common the blank is

Before deciding what an empty DPA field means, it helps to know how much of the file it covers. In the current export of our vendor registry there are 157 rows. Of those, 27 have no DPA URL recorded and 37 have no subprocessor list URL. The two sets overlap only partly: 15 rows have neither, 22 have a DPA on file but no published subprocessor list, and 12 have a published subprocessor list but no DPA link.

So the blank is not an edge case you meet twice a year. On a portfolio where each client runs twenty or thirty tools, the question is not how to avoid blanks but how to work through them in a way that survives being read by somebody else.

The blanks also cluster. In the current export, 5 of the 10 finance rows and 4 of the 10 payments rows have no DPA URL — Qonto, Wise, Revolut Business, QuickBooks and Expensify on one side, Adyen, GoCardless, Klarna and PayPal on the other. That clustering is itself information, and it points at the first question to ask, which is not "where is their DPA".

An empty field is not automatically a failing

There are at least four reasons a vendor publishes no data processing agreement, and they call for different work.

The vendor is not acting as a processor for this data. Banks and payment institutions frequently determine their own purposes for the personal data they handle, because regulation obliges them to. A vendor that is a controller in its own right has nothing to publish under Article 28 for that processing, and the right artefact is a controller-to-controller description in the ROPA, not a processor agreement you failed to obtain.

The agreement exists but is not public. It sits behind the enterprise contract, is issued on request, or is stitched into terms of service that never use the word "addendum". Brevo's DPA link in our export points at its terms of use page, which is exactly this case.

The agreement exists on a group page rather than the product's own. Worth checking before you write to anyone, because in the current export the DPA link is hosted somewhere other than the product's own domain in 14 rows.

The vendor genuinely has nothing. Small tools, newly founded companies, products sold to individuals that ended up in a business stack.

Only the fourth is a finding. The other three are lookups you have not finished yet, and the difference between them and a finding is the whole point of the method below.

What to ask the vendor for

Write to the vendor once, in one message, asking for everything you will need, because a second round trip costs another two weeks:

• The executable data processing agreement, in the version they would actually sign with a customer in your client's position.
• The name of the contracting legal entity and its registered seat, which decides both the annex line and the transfer analysis, and is frequently not the brand.
• The current list of subprocessors, with the entity and country for each, and the address where changes to it are published or notified.
• The transfer mechanism they rely on for flows out of the EEA, and where you can verify it — for a US entity relying on the framework, the participating entity name as listed.
• Their notification route and objection window for subprocessor changes, if the agreement does not already set one.
• Whether they act as processor or controller for this processing, in their own view. You are not bound by their answer; the qualification is your client's and yours. But an answer that says "controller" explains the missing DPA and changes what you document.

Date the message and keep it. That date is a fact about the engagement even when the reply never arrives.

What a customer-specific DPA changes about the annex

If the vendor comes back with a signed, customer-specific agreement, one thing quietly changes and it is easy to miss.

The annex is no longer a snapshot of a public page. It is a list attached to a signed contract, and the authorisation under Article 28 runs to that list — not to whatever the vendor's website shows next quarter. The notification route becomes whatever the agreement says: a named contact, a defined period, an objection window that either exists or does not.

Practically, three things follow. The source you cite in the annex is the agreement and its date, not a URL. The subprocessor list you render is the one annexed to that agreement, and where it differs from the public page, the public page is not your source. And monitoring that page becomes an early warning at best, never sufficient on its own to update a document you built from a contract.

The reverse is the more common direction: where you are relying on a published DPA, the annex should say which page, in which version, read on which date. Every row in the current export carries a verification date; all 157 were checked on 2026-09-16. A cited page without a date asserts the present tense of something that changes without telling you.

Recording "asked, no response"

Here is where most files go soft. The consultant writes to the vendor, hears nothing, and the field stays empty — indistinguishable, three months later, from a field nobody ever looked at.

Record the attempt, not the absence. The registry row keeps the blank, and the notes carry what happened: asked on this date, through this channel, no response by this date. In the client-facing document the cell does not go blank and does not go missing. It says the vendor publishes no agreement and that a request was made, with the date, and the gap stays marked as a gap.

This is the same shape we use everywhere a required fact is absent: an unanswered question renders as "Not confirmed" with an explicit gap marker underneath, never as a silent omission and never as an assumed "No". The two are different claims. "We asked and they did not answer" is a fact about diligence. "There is no agreement" is a fact about the vendor. Only one of them is supported by an unanswered email.

When you do reach a conclusion — that the vendor is a controller here, that no processor agreement applies — write the conclusion and whose it is. The qualification belongs to the consultant, and a file that shows who decided what, and when, survives a corporate customer's review of your client.

Why a plausible link is worse than a blank

The temptation with an empty DPA field is to fill it with something that looks right: the vendor's privacy policy, a group company's addendum, a page that turns up first for the product name plus "dpa".

A blank is loud. It stops the document from being finished, it renders as a gap, and the reviewer sees exactly what is missing. A plausible link is silent, and it fails later, in front of someone else — during a questionnaire response, during a customer's diligence, during an incident when the annex turns out to describe a different company's obligations.

There is a mechanical reason too. A URL in a file is a monitoring target: the change detector fetches it on a schedule and reports diffs against it, so a wrong link produces a stream of confident, irrelevant change notices about a document that never governed your client's processing. Ours is deliberately conservative about the opposite error — a 403, a 429 or a 5xx counts as a failed fetch rather than a change, because vendor sites block crawlers and that is not news. Nothing protects you from a link that was never the right one.

An empty field costs one line of explanation in the document. A wrong one costs the reputation of every other line in it. Clausebench leaves the field empty and marks the gap for exactly that reason, and the registry's verification dates exist so that a blank can be read as "checked, not published" rather than "never looked".

The short version: ask once and ask fully, write down that you asked, and let the blank stay a blank until a fact fills it.