Beyond Legal #30: The cloud infrastructure engineer who asked where the data actually lives

She asked where personal data actually lives. First time in ten years anyone asked me that. — Abdi C., Cloud Infrastructure Engineer

Most data protection programmes have a transfer policy. Most of those policies describe a mechanism — standard contractual clauses, binding corporate rules, an adequacy decision. Almost none of them have been validated against the actual infrastructure that determines where personal data physically sits. The policy describes the legal framework. The infrastructure determines whether the legal framework is doing any work.

Abdi’s story #

Abdi is a cloud infrastructure engineer at a pan-European professional services firm. He manages the architecture that determines where the organisation’s data is processed and stored — which cloud regions are used, how data is replicated, which services sit in which jurisdictions, and what configuration decisions were made during migrations that may not be visible to anyone outside his team.

He had never been involved in a data protection discussion, though he had been involved in a great many infrastructure decisions.

The Data Protection Leader — let’s call her Isadora — was carrying out an audit of the company’s international transfer position following a regulatory inquiry at a peer firm in the same sector. She was working through the company’s records of processing activities (RoPA), checking the transfer entries against the documented mechanisms. She noticed that several entries referenced cloud storage but did not specify the cloud region. She went to ask the infrastructure team which regions were actually in use.

Abdi answered her question precisely, because as an infrastructure engineer, this was his bread and butter. The company was running workloads on a cloud provider whose EU region had a service dependency on nodes in a country without an adequacy decision. Personal data processed through those workloads was being transiently routed through a jurisdiction where the data protection protections under EU law did not apply, and for which no transfer mechanism had been documented. Nobody in the data protection function had known this, because nobody had ever asked which regions the workloads actually ran in.

It was the first time in Abdi’s ten years of infrastructure work that anyone from data protection or a compliance function had asked him that question.

What the audit revealed #

The routing issue was not intentional. It had emerged from a default configuration applied during a cloud migration two years earlier. The infrastructure team had selected the configuration for performance and cost reasons, without any awareness that it created a transfer implication under the GDPR. Nobody had told them to check. Nobody had thought to ask.

The remediation required a joint effort between Abdi and Isadora: identifying the affected workloads, assessing which categories of personal data were involved, documenting the scope of the transfer, conducting a transfer impact assessment (TIA) for the destination jurisdiction, and either reconfiguring the routing or implementing appropriate supplementary measures before the transfers could continue.

The work took four months. It also revealed three further infrastructure configurations that had similar implications. By the end, the company had a transfer register that had been validated against the actual infrastructure for the first time.

Both Abdi and Isadora were retained and promoted into a jointly accountable data governance function. The regulatory inquiry at the peer firm resulted in a formal finding. The company’s own compliance position, now documented and governed, was significantly stronger.

Under Articles 44 to 46 of the GDPR, transfers of personal data to third countries — countries outside the EU/EEA without an adequacy decision from the European Commission — require an appropriate safeguard before the transfer takes place. This requirement applies regardless of whether the transfer is intentional. A cloud configuration that routes personal data through a non-adequate jurisdiction is a transfer under the GDPR whether or not it was planned, disclosed, or documented. The controller is responsible for ensuring that the transfer mechanism is in place and that the mechanism provides genuine protection — not simply that a legal document exists.

Two recent enforcement decisions make this clear from an operational perspective.

In August 2024, the Dutch Data Protection Authority fined Uber €290 million for transferring the personal data of European drivers to the US without adequate safeguards for a period of over two years, after ceasing to use standard contractual clauses and failing to implement an alternative mechanism. The transferred data included GPS location, payment details, photos, and in some cases medical and criminal records. The Dutch DPA’s finding was straightforward: the absence of an operative transfer mechanism means the transfer is unlawful, regardless of the company’s intentions or its subsequent compliance steps.

In May 2025, the Irish Data Protection Commission fined TikTok €530 million for failing to verify, guarantee, and demonstrate that EEA user data remotely accessed by staff in China was afforded a level of protection essentially equivalent to that guaranteed within the EU — and compounded the violation by providing inaccurate information to the inquiry, having told the DPC throughout the investigation that it did not store EEA data on servers located in China.

In both cases, the company had technical infrastructure teams who knew what the systems were doing. The failure was not technical ignorance — it was the absence of a conversation between the infrastructure function and the data protection function.

Article 46(1) of the GDPR requires that transfers to third countries without an adequacy decision are subject to appropriate safeguards and that enforceable rights and effective legal remedies are available for data subjects. Standard contractual clauses provide the contractual framework. But following the Schrems II judgment, controllers must also assess whether the law and practices of the destination country allow the recipient to honour the obligations the SCCs impose — and implement supplementary measures where they do not. For cloud infrastructure specifically, this means knowing which regions workloads run in, which services have cross-region dependencies, and whether any of those dependencies touch a non-adequate jurisdiction. That knowledge sits with the infrastructure team. A data protection programme that has never asked the infrastructure team those questions is not governing its transfer position — it is describing one.

The challenge for today: Ask your cloud infrastructure or IT team one question: are there any workloads involving personal data that run in, route through, or have service dependencies on cloud regions outside the EEA? If they need time to find out, you have found the gap.

For more on how infrastructure decisions carry data protection consequences that compliance functions often cannot see, see Beyond Legal #21 and Beyond Legal #22. For the legal framework that governs transfer mechanisms, see Beyond Legal #29.

Article references: Article 5(2) (accountability), Article 30 (records of processing activities), Article 44 (general principle for transfers), Article 45 (adequacy decisions), Article 46 (transfers subject to appropriate safeguards), Article 83(5) (fines for transfer violations).

Series: This is post 30 in the Beyond Legal series — 20 roles, 20 days, real consequences. Abdi, Isadora and the actual story is fictitious, the two cases are real.