Support-Model Change and a Missing Transfer Addendum
A EU-based online retailer processes data for 14 million customers. It runs its e-commerce stack on a US-headquartered IaaS provider's EU region; the provider's support engineers in the US have "break-glass" access to customer environments for troubleshooting. The retailer's DPO approved SCCs (2021 modules) and a transfer impact assessment (TIA) completed in 2022. In 2023 the provider changed its support model so that 30% of tickets are handled by a new team in India. The retailer also uses a US-based analytics SaaS for clickstream data that includes IP addresses and hashed customer IDs, with no DPA addendum covering international transfers. A supervisory authority inquiry asks for evidence of transfer safeguards. The privacy team proposes pseudonymizing the clickstream data before it leaves the EU.
1. Assess whether the existing TIA remains valid after the support model change.
Read the worked answer
It does not. A TIA is a point-in-time assessment tied to a specific transfer, recipient, and legal context. Two things have changed: a new support team in a third country, and a corresponding change in who can reach EU customer data. The 2022 TIA cannot speak to Indian legal access, to the new team's access paths, or to whether break-glass access from the US has changed.
Steps:
- Refresh the data map: which data categories, volumes, and access paths now reach India; whether the new team has break-glass rights or only sanitized tickets.
- Confirm the SCC module and whether the provider's subprocessor list was updated and notified per the contract. The retailer should exercise, or at least consider, its right to object.
- Conduct a new TIA for India: assess local surveillance and government-access law, the practical likelihood of access, and the supplementary measures available. India has no EU adequacy decision, so SCCs plus effective supplementary measures are required.
- Re-verify the US position, since US personnel retain break-glass access and the legal analysis there is not static.
Judgement: the SCCs remain the transfer mechanism, but the TIA supporting them is stale. Relying on it in a supervisory authority inquiry would be indefensible. The reassessment should be documented before the inquiry response is drafted, with a remediation plan if the new transfer cannot be adequately safeguarded.
2. Evaluate the proposed pseudonymization of the clickstream data as a supplementary measure.
Read the worked answer
It depends entirely on who holds the key and what the recipient can do with the data.
Where it works: if the retailer replaces customer IDs with tokens and keeps the re-identification key in the EU, and the US analytics vendor receives only tokens plus IP addresses it cannot link to an identity, the practical risk of the recipient identifying individuals drops materially. That is a genuine supplementary measure and should be documented as such in the TIA.
Where it does not:
- Hashed customer IDs are not automatically pseudonymous. If the hash is unsalted, deterministic, or reversible against the retailer's customer table, and the vendor has any way to correlate, the protection is thin. IP addresses remain personal data under EU law and are themselves an identifier.
- If the recipient can re-identify via other datasets or via the retailer's own systems, the measure does not change the transfer analysis.
- The measure must be technically enforced, not contractual only.
Judgement: treat pseudonymization as one mitigation among several - data minimization, aggregation, retention limits, EU-only processing for sensitive fields - not a silver bullet. The larger defect is the missing DPA addendum for the analytics vendor. That is a straightforward compliance gap that should be closed first, since no transfer mechanism is in place at all. Fix the mechanism, then optimize the measures, and document the reasoning in the TIA refresh.
3. What should the retailer include in its response to the supervisory authority, and what should it do first?
Read the worked answer
First, remediate before replying where feasible. The missing transfer addendum for the analytics vendor is an identifiable gap. Executing the DPA with SCCs before responding converts a live violation into a documented remediation with a date. Responding with a known, unaddressed gap is worse than responding with a credible plan.
Response content:
- Data map and categories of data transferred, with recipients and countries.
- The transfer mechanism for each flow: SCC module, plus the TIA for each third country.
- Subprocessor list and the notification trail for the India support change.
- Supplementary measures actually implemented, described technically - encryption, key custody, pseudonymization, access controls, break-glass logging.
- Records of processing, retention rules, and the governance around transfer approvals.
- The refreshed TIA and the remediation plan with owners and dates.
What not to include: speculation, unverified assurances from the vendor, or claims that a stale TIA covers a changed model. Accuracy matters more than completeness of reassurance.
Ongoing: add a trigger to the privacy governance process so that any change in support location, subprocessor, or access model automatically re-opens the TIA. The lesson from this inquiry is that transfer documentation decayed silently, and the control that failed was change detection, not the original assessment.