Subprocessor
A vendor your vendor uses. Your email tool runs on AWS, so AWS handles your users' data too, and you have to disclose it.
See it
What it is
A subprocessor is anyone your processor hands the data to in order to do their job. Your support tool is your processor; the cloud it runs on, the transcription API it calls, and the offshore support team it staffs are its subprocessors, and therefore yours by inheritance. Data does not stay where you put it, it flows down a chain, and the controller stays responsible for the whole chain.
What GDPR actually requires is narrower than the artifact everyone builds: prior written authorization from the controller, either specific or general, plus notice of intended additions or replacements so the controller can object. The common way to deliver that at scale is a subprocessor list, a public page naming each downstream vendor, what it does, and where it processes data, plus an email subscription for change notices. That page and any fixed notice window are contractual choices, not statutory ones. Enterprise buyers read the page during procurement anyway, and adding a new region or AI vendor to it is a change your customers may have a contractual right to object to.
Gotcha: most teams under-count. The obvious ones (AWS, Stripe, Twilio) make the list, while the session replay script, the error tracker, and the AI feature someone shipped last sprint quietly do not. If personal data leaves your systems to reach a vendor working on your instructions, it belongs on the list, and 'it's just analytics' is not an exemption. The reverse error costs you too: dumping every recipient on the page, including independent controllers and your own staff, makes the list unreadable and quietly overpromises what you will give notice about.
Ask AI for it
Build a public subprocessor page for our product. First inventory every third party that touches customer personal data (hosting, database, email, payments, support, analytics, error tracking, AI APIs, and any contractor teams), then classify each recipient before publishing anything: our own processor, a subprocessor engaged by one of those processors, an independent controller receiving data for its own purposes, or personnel acting under our authority. Only actual subprocessors belong on the page. Output them as a table with: vendor name, service provided, categories of personal data reached, processing location or region, and link to their DPA or privacy terms, and list the other categories separately so nobody mistakes them for subprocessors. Add a short intro explaining what a subprocessor is in plain language, plus a change-notice block that states the advance notice period our DPA already promises; if you cannot find that commitment in the DPA, insert a bracketed TODO rather than inventing a number.