Somewhere on your website there is a subprocessor list. It was written when you signed your first enterprise contract, it has three entries, and it is wrong.
Since then you added an error tracker, a support tool, a transcription service, an analytics platform, and a model provider your product calls on every request. Each one receives customer data. Each one is a subprocessor. Most of your data processing agreements commit you to publishing them and notifying customers before you add one.
This post is what actually counts, how the list drifts, and how to keep it current without a committee. For whoever signs the DPAs, which at a company under a few hundred people is usually whoever signs everything.
What counts
A subprocessor is any third party that processes personal data on your behalf in the course of delivering your service. The test is access, not intent, and not whether they store it.
So these count:
- Cloud and hosting providers.
- Anything that receives application data: error tracking, log aggregation, APM, session replay.
- Support tooling, where tickets contain customer content.
- Email and messaging providers.
- Payment processors, usually, depending on the flow.
- Model and AI providers, if customer data reaches them. This is the one most lists are missing today.
- Any vendor whose support staff can access your production systems.
These usually do not: tools processing only your employees' data, a vendor handling exclusively aggregated and genuinely anonymous data, and anything where the customer contracts directly rather than through you.
The frequent error is thinking transient means exempt. A service that receives data, acts on it and retains nothing is still processing it. Ephemerality affects risk, not classification.
Why the list goes stale
The drift is structural, not careless.
Procurement is decentralised. An engineer adds an error tracker with a credit card in an afternoon. Nothing in that path touches the person who maintains the subprocessor list.
Existing vendors add features. A tool you already use ships an AI summarisation feature, enabled by default, which sends content to a provider you have never listed. Your vendor changed their subprocessors, and your obligation to your customers did not change with it.
Nobody owns the list. It lives on the website, it was written by someone in a legal conversation, and it has no update trigger.
Trials become production. A tool adopted for an experiment quietly becomes load-bearing without ever being formally adopted.
The contractual consequence
This is not documentation hygiene. Most enterprise DPAs contain:
An obligation to maintain an accurate list, usually published at a stable URL.
Advance notice before adding one, commonly 30 days, sometimes with a mechanism for the customer to object and, if unresolved, to terminate.
Flow-down terms, requiring you to bind each subprocessor to obligations at least as protective as yours, and making you liable for their failures as if they were your own.
So an unlisted subprocessor is a breach of contract with every customer on that DPA, independent of whether anything bad happened to the data. It is also exactly the kind of thing that surfaces during a security review or an audit, at the worst moment, and the discovery undermines everything else you have told that customer about your controls.
Finding the ones you have
Three sources, and the union is closer to the truth than any one of them.
Finance. Every recurring payment to a software vendor. This is the most complete list you have of what the company uses, and the only one nobody can forget to update.
Egress. What your production systems actually connect to.
# from your egress logs or firewall, over a week
sort -u destinations.log | grep -vE '\.(internal|local)$' | head -50
A destination your team cannot name is the finding. This catches the vendor whose feature started calling a new endpoint after an update.
Integrations. OAuth grants in your identity provider, installed apps in your source host, webhooks registered on your repositories, and anything holding an API key to your systems.
Run all three, reconcile, and expect the result to be considerably longer than your published list.
Keeping it current
Hook the list to procurement. Any new tool that will touch customer data requires a line in the subprocessor register before it is paid for. If the register is a file in a repository, it is a pull request, which is reviewable and dated.
Review quarterly against finance. A short cycle, driven by the payments list rather than by memory.
Watch your vendors' own lists. Most publish theirs and offer notification. Subscribe. Their additions can become yours.
Publish at a stable URL with a changelog. Dated entries showing what was added and when. This is the artifact that satisfies both the notification obligation and the auditor, and it takes one page.
Notify before, not after. The notice period is a contractual term with a number in it. Adding a vendor and updating the page afterwards fails the obligation even when the page ends up correct.
The AI provider question, specifically
Worth separating because it is where most lists are currently wrong, and because customers are asking about it directly.
If your product sends customer data to a model provider, that provider is a subprocessor. List it. Expect follow-up questions about retention, whether data is used for training, and which region processes it, and be able to answer all three by reference to the provider's terms rather than by assurance.
If you switch providers, that is a subprocessor change with a notice period attached. This matters because model providers get switched on engineering timescales, for cost or quality reasons, by people who have never read a DPA.
The concession
Maintaining this perfectly is genuinely hard at a company shipping quickly, and a maximalist reading of "any third party that could touch personal data" produces a list so long it stops being informative to customers.
The defensible position is to be complete about anything that receives customer content or has production access, be explicit about the boundary you drew, and review on a fixed cycle. A list with a stated scope and a recent date is trusted. A short list with no date is not, and it invites exactly the question you do not want.
The implication
Your subprocessor list is a claim about where customer data goes, published under contract. If it disagrees with your egress logs, the logs are right.
Reconcile the two once, put the list under version control, and hook it to the one process nobody can bypass, which is paying for things.
