Sooner or later, one of your processors adds or relocates a subprocessor outside the European Economic Area (EEA). Sometimes the notice arrives by email with a deadline attached; sometimes a line quietly changes on a subprocessor page. Either way, the same fact now exists: personal data you are responsible for is flowing to a third country along a leg you have not assessed, and Chapter V of the General Data Protection Regulation (GDPR) applies to that leg just as it applies to transfers you make yourself.
This article walks through the controller's side of that moment: why the onward leg is your problem at all, how these changes tend to surface, the assessment sequence to run when one does, the contract mechanics that carry it, the UK parallel, and what the resulting decision record should contain.
Why the onward leg is the controller's problem
Article 44 GDPR states the general principle: any transfer of personal data to a third country, including onward transfers from that country to another, may take place only if the conditions of Chapter V are complied with by the controller and the processor, and all of the chapter's provisions apply so that the level of protection guaranteed by the regulation is not undermined. The chain does not dilute responsibility; it extends it. Articles 45 to 49 then supply the available tools: adequacy decisions, appropriate safeguards such as Standard Contractual Clauses (SCCs), and, for occasional situations, the narrow derogations.
Article 28 reinforces the same point from the contract side. Under Article 28(4), a processor that engages another processor must impose the same data protection obligations on it by contract, including on transfers. And under Article 28(2), where you granted a general written authorization for subprocessing, the processor must inform you of intended additions or replacements, giving you the opportunity to object. The mechanics of your Data Processing Agreement (DPA) determine how much warning you get; Chapter V determines what you must be satisfied of, warned or not.
How these changes surface, often quietly
In a well-run relationship, the change arrives as a notification with a notice period, because the DPA requires exactly that. In practice, surfacing is uneven. Some vendors email only the addresses subscribed to a notification list, which may belong to someone who left the company. Some update the subprocessor page and consider that notice given. Some revise the DPA annex at renewal and mention it nowhere else. A few operate a changelog or news feed where subprocessor entries appear between feature announcements. How subprocessor change notifications work, and fail is a topic of its own; the operational conclusion is that relying on inbound email alone means learning about some transfers late.
The reliable pattern is watching the disclosure surfaces themselves, the subprocessor list and the DPA pages, on a schedule, so that silent edits become dated events. The distinction matters legally as well as operationally: objection windows in DPAs run from notice, and a change you only discover after the window has closed leaves you managing a fact instead of exercising a choice.
The assessment sequence when it happens
When a subprocessor change moves data outside the EEA, the questions come in a fixed order.
- Identify the destination and the data. Which country is involved, which services and data categories are affected, and whether personal data will be stored there or accessed remotely from there. The vendor's notice rarely states all of this; the DPA annexes and a direct question to the vendor usually complete the picture.
- Identify the transfer tool for the new leg. If your processor is established in the EEA, it acts as the exporter for this leg and needs its own Chapter V tool with the subprocessor, typically SCCs. If your vendor is already outside the EEA and processes under SCCs signed with you, the onward-transfer obligations in those clauses govern how it may engage the subprocessor. Either way, the leg needs a named tool, and you are entitled to ask which one it is.
- Check your Transfer Impact Assessment (TIA) coverage. Does an existing assessment cover this destination, for these data categories and access patterns? If yes, record that conclusion and move on. If not, the six-step method of the European Data Protection Board's (EDPB) Recommendations 01/2020 applies to the new leg, from mapping through supplementary measures to re-evaluation; a practical TIA walkthrough covers the steps in detail.
- Evaluate supplementary measures for the leg. What actually protects the data in the destination: encryption in transit and at rest, who holds the keys, pseudonymization, and access controls at the subprocessor. Measures the vendor asserts should be verifiable in its technical documentation rather than taken on faith.
- Decide, inside the window. Either accept the change and document why it is acceptable, or object through the DPA's mechanism under your Article 28(2) authorization terms. Objection consequences vary by contract; many DPAs resolve a sustained objection through termination rights for the affected service, so the realistic decision is often between accepting with measures and planning an exit.
The sequence is deliberately front-loaded: identification and tooling questions come before the legal analysis, because the answers determine whether any analysis is needed at all. A subprocessor added inside the EEA changes your inventory but not your transfer position. A subprocessor added in a third country already covered by an adequacy decision changes the record but usually not the risk. The expensive case is the genuinely new destination, and the sequence isolates it quickly. Throughout, the deadline is contractual, and silence typically operates as acceptance in practice.
Cases that look different but follow the same sequence
Three variants come up often enough to name.
- Remote access rather than storage. A subprocessor that only accesses EEA-hosted data from a third country, for support or engineering purposes, is still on the receiving end of a transfer for Chapter V purposes; the EDPB's recommendations treat remote access from a third country as a transfer like any other. The sequence applies unchanged, with access patterns and the controls around them at the center of the analysis.
- A destination already covered by an adequacy decision. The leg still needs to be identified and recorded, but the tool question resolves immediately and no TIA is required for it. Track the adequacy decision's status over time rather than treating the entry as closed forever.
- A relocation inside the same subprocessor. No new entity appears on the list, but a region change, for example a workload moved between the subprocessor's hosting locations, creates a new leg all the same. These are the changes most likely to surface only as a quiet edit to a location column, which is precisely why location details deserve the same attention as entity names.
None of the variants changes the order of the questions; they change how quickly the questions resolve. What they share is that each starts with noticing a factual change that the vendor may not have flagged as significant.
Contract mechanics in the SCC world
The 2021 SCCs, Implementing Decision (EU) 2021/914, are modular. Module Two covers controller-to-processor transfers, and Module Three covers processor-to-processor transfers, which is the form an EEA processor typically signs with a third-country subprocessor. Clause 9 mirrors the GDPR's authorization mechanics, general or specific authorization with an agreed notice period, and requires the subprocessor to be bound by obligations that in substance match the clauses. Clause 14 places the transfer assessment duty on the parties to that leg, and it requires them to document the assessment and produce it to the competent supervisory authority on request.
Two consequences follow for the controller. First, there is paper you can legitimately ask for: which mechanism covers the new leg, and the conclusions of the assessment behind it. A processor that cannot summarize its analysis for a customer is telling you something useful about the chain you are relying on. Second, your own accountability does not travel away with the paperwork: the Article 44 chain principle means you need to be satisfied that the chain holds as a whole, which is why the post-Schrems II transfer toolbox matters to you even when the two transferring parties are other companies. In the cleanest setups, your DPA obliges the vendor to maintain valid onward tools and to evidence them on request, so the chain is inspectable from your seat.
Annex hygiene matters too. The subprocessor annexes to the DPA and to the SCCs are where the agreed state of the chain formally lives, so a change accepted in an email exchange but never reflected in the annex leaves the contract asserting an outdated chain. When you accept a change, part of the acceptance is confirming where and when the annex gets updated, and keeping the superseded version, since the question of what was agreed at a past date has a way of returning.
The UK parallel, briefly
The UK General Data Protection Regulation (UK GDPR) applies the same chain logic to data within its scope. Transfers from the UK rely on UK adequacy regulations or UK transfer tools, the International Data Transfer Agreement (IDTA) or the EU SCCs combined with the UK Addendum, together with a UK-style transfer risk assessment. When a vendor serves both your EU and UK processing, a subprocessor change outside the EEA usually needs the check under both regimes. The facts are identical; the paperwork and the applicable instruments differ, so the decision record should state both outcomes.
Documenting the decision
The output of the whole sequence is a decision record, and it earns its keep long after the moment passes. It should state what changed and when you learned of it; the destination analysis or the TIA version relied on; the transfer tool identified for the leg; the supplementary measures in place; the decision, acceptance or objection, with its owner and date; and the follow-ups it triggered, such as DPA annex updates or corrections to your records of processing.
Kept per change, these records accumulate into the account an auditor or supervisory authority actually asks for. The question is rarely whether your vendors ever changed anything; it is whether you noticed, assessed, and decided each time they did. A dated trail of subprocessor decisions answers that in minutes. Its absence converts every historical change into an open question about your oversight.
Where DPAFlow fits in
The failure mode in all of this is rarely the legal analysis; it is finding out late. DPAFlow monitors vendor subprocessor lists and DPA pages on a scheduled, recurring basis, detects changes, records them with dated evidence including captured page text and change diffs, and alerts the team by email. Detected changes enter a review workflow where the accept-or-object decision can be assessed and documented next to the evidence that prompted it.
For the assessment side, the Transfer Impact Assessment module helps keep the TIA versions those decisions rely on current and exportable. The judgment about the transfer stays with you; the moment it should happen stops depending on luck.