Subprocessors, and the facts that go stale
A subprocessor list is the part of a client's documentation most likely to be wrong, and the part most likely to be read by somebody who will check. It is also the part that nobody is reminded to revisit: a vendor changes its contracting entity on its own schedule, and every document naming the old one stays quietly untrue until a prospect notices.
The writing collected here is about the three fields that carry the weight — the legal entity, the country, the transfer mechanism — and about the discipline of being able to say when you last checked.
Guides
Long-form, written for a practitioner.
- Subprocessor lists: what changes when a vendor updates its DPA
Which vendor changes require a client update, which only need a note on file, and how to track them across a portfolio.
- How to scale a privacy practice past 20 clients
What breaks between 10 and 40 clients, and the operating habits that keep documentation current without hiring for every new engagement.
Notes
Shorter pieces on one thing that changed.
- A vendor changed its entity: which documents are now wrong
One contracting entity moves and the blast radius runs through four document types, every client using that vendor, and whatever you already sent out.
- Article 25(1) and the moment your client becomes the provider
How an SME that buys a model and fine-tunes it takes on the provider's obligations, the questions that surface it, and what changes in the file.
- The brand is not the counterparty
A subprocessor annex naming Heroku or SendGrid names a product, not the legal person your client contracts with, and often not the right country either.
- When a vendor has no public data processing agreement
What to ask for, what a customer-specific DPA changes about the annex, and how to record "asked, no response" so the file stays honest.
Doing this work
What the product does with it.
- Subprocessor lists
Keep a current subprocessor list for every client: legal entity, country, transfer mechanism and DPA link for each vendor, from a registry we verify, with changes tracked.
- Data processing agreements
Draft an Article 28 data processing agreement for each client from the facts you confirmed once: the processing described, the sub-processors named, transfers and their mechanisms, in your firm's wording.
- Vendor changes
Vendor pages are checked daily and every change is read by a person before it reaches you, with the clients affected and the documents to regenerate.
- Records of processing
Build an Article 30 record of processing for each client from facts you confirmed once: purposes, categories, recipients, transfers and retention, with the vendor rows filled from a verified registry.
Reference
The pages the facts come from.
See what changed since your clients' policies were written
Enter up to ten client websites. Free, no sign-up, the first report in about a minute.