Subprocessor lists are the single most volatile component of vendor privacy posture. A privacy policy might change once a year. A DPA might change once every two. A subprocessor list will change on average every few months — and for some vendors, every few weeks.
This is the operational problem subprocessor management has to solve: how to track changes across a portfolio, evaluate which ones matter, and respond within the contractual notice window before it expires.
What you're actually tracking
For each vendor, the subprocessor list answers two questions:
- Which third parties have access to the personal data the vendor processes for you?
- Where is each one located?
Modern lists also tend to disclose:
- Service category (cloud hosting, email delivery, support).
- Data accessed (which categories, sometimes specific fields).
- Whether they're located in adequate or non-adequate jurisdictions.
A well-maintained subprocessor list is a structured table on a stable URL. A poorly-maintained one is a buried PDF, a paragraph in the privacy policy, or — worst case — "available on request." The third case is a yellow flag during vendor selection.
What changes look like
In practice, subprocessor list changes fall into four buckets:
Bucket 1 — New entity added. The most common change. A new subprocessor is added, typically with a small note ("Effective from October 1st").
What to evaluate:
- Where are they?
- What category of data do they touch?
- Do they replace an existing subprocessor or add to the chain?
- Does their location change your transfer landscape?
Bucket 2 — Entity removed. Less common but worth noticing. The vendor stopped using a subprocessor. Usually low-risk; occasionally a sign that the relationship ended unexpectedly.
Bucket 3 — Entity changed. Same name, different details. Region change is the important case here — a US subprocessor switching to an EU region, or vice versa, has compliance implications.
Bucket 4 — Reformat. The list was rewritten or restructured with no semantic change. Adds noise to monitoring; can usually be acknowledged without deeper review.
A working triage rubric
The same change has different significance depending on the vendor's tier and the data they handle. A practical rubric:
| Change | Tier 1 vendor | Tier 2 vendor | Tier 3 vendor | | --- | --- | --- | --- | | New subprocessor in adequate country | Document, no further action | Document | Acknowledge | | New subprocessor in non-adequate country | Review TIA, possibly object | Review TIA | Document | | Subprocessor in non-adequate country added without notice period | Object, escalate | Object | Document and escalate | | New subprocessor handling special-category data | Review TIA, escalate to DPO | Review TIA | Review TIA | | Subprocessor removed | Document | Acknowledge | Acknowledge | | Reformat with no semantic change | Acknowledge | Acknowledge | Acknowledge |
The rubric is not the final word — judgment still matters — but having one written down makes the audit trail consistent and answers the auditor's question of "how do you decide what's material."
Responding within the notice window
Most DPAs grant a window — commonly 14 to 30 days — to object to a new subprocessor. If you don't notice the change in that window, the right of objection is functionally lost.
The mechanics of objection:
- Read the DPA's objection clause. It will specify how to object (email, portal, contact channel) and what happens next.
- State the grounds. Most clauses don't require detailed grounds, but a clear statement of the issue helps. ("We object to [Subprocessor] in [Location] on the basis that the resulting transfer to [Country] is not currently supported by our TIA.")
- Understand the consequences. Most DPAs give the vendor a choice: refrain from using the subprocessor for the objecting customer, or treat the objection as a notice of termination. The second is a significant lever — sometimes the only one.
In practice, objections are rare because the consequences are inconvenient (you lose the vendor or accept the change). But the existence of the right matters: an auditor who sees that you reviewed every change, evaluated it against your TIA, and accepted it on documented grounds is satisfied even if no objection was raised.
Capturing the audit trail
Every subprocessor change review should produce a record:
- Date the change was detected.
- Vendor and document.
- What changed (specific entities, locations).
- Risk evaluation.
- Decision.
- Reviewer.
Tooling like Thorgate stores this automatically. Without tooling, a shared spreadsheet is the minimum viable substitute. An inbox full of emails ("FYI we're adding a new processor next month") is not, in audit terms, a record.
Where this fits in the broader picture
Subprocessor management is one slice of vendor monitoring, not the whole thing. Privacy policies, DPAs, ToS, and security pages are also moving targets. But subprocessor lists are the slice that:
- Changes most frequently.
- Has the shortest notice windows.
- Most directly affects the transfer landscape.
- Most often gets missed in manual review.
Getting subprocessor monitoring right tends to drag the rest of the vendor program along behind it.