The payload contained user identifiers, event timestamps, and behavioral metadata. The analytics vendor was US-based. The users whose data was in the payload were in Germany. The payload crossed an ocean in milliseconds. Nobody in the engineering team thought of it as an international data transfer. Nobody in the legal team knew it was happening. The GDPR obligation for cross-border transfer — including a valid transfer mechanism, a transfer impact assessment, and a data processing agreement with the vendor — had been triggered before the first payload arrived.
Why Engineering Teams Don't Think in Transfer Terms
Engineering teams who build API integrations think in technical terms: endpoints, authentication, payload schemas, rate limits, error handling. The concept of a data transfer in the legal sense — the movement of personal data from a jurisdiction with one legal framework to a jurisdiction with a different legal framework, triggering specific compliance obligations — is not part of the technical vocabulary in which API integrations are designed and built.
This is not a failure of the engineering team. It is a consequence of the fact that data protection law was written in a vocabulary of processing, controllers, processors, and transfers that does not map naturally to the technical vocabulary of APIs, microservices, and cloud infrastructure. The law describes the legal reality. The engineering process operates in the technical reality. The connection between them requires a deliberate translation layer that most organizations have not built into their development processes.
An API call is a data transfer. A data transfer that sends personal data from an EU user to a US server is an international data transfer under GDPR. The law applies to the data movement, not to the developer's mental model of what they were building.
What the API Call Triggered
The Transfer Mechanism Requirement
GDPR Article 44 requires that personal data transferred to a third country is only transferred if the transfer is covered by a valid transfer mechanism: an adequacy decision for the recipient country, standard contractual clauses with the recipient, binding corporate rules, or another mechanism specified in Articles 46 or 49. The US-based analytics vendor is in a country without a blanket adequacy decision for GDPR purposes — the EU-US Data Privacy Framework covers specific certified organizations, and the analytics vendor may or may not be certified. SCCs with the vendor are a viable mechanism. They need to exist before the transfer begins, not after it is discovered.
The Transfer Impact Assessment
The post-Schrems II requirement for a transfer impact assessment when using SCCs for EU-to-US transfers requires the organization to assess whether the protection available to the data in the US is essentially equivalent to EU protection, considering US surveillance law. This assessment must be conducted before the SCCs are relied upon as the transfer mechanism. The integration that went live before the TIA was conducted has been transferring data under an unvalidated mechanism since launch.
The Data Processing Agreement
GDPR Article 28 requires that processing of personal data by a processor on behalf of a controller is governed by a contract that specifies the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. The analytics vendor that receives event data containing personal data is processing that data as a processor. The DPA must be in place before processing begins. A DPA that is executed after the integration is live covers processing from the DPA's execution date, not from the integration's launch date.
Building the Translation Layer
The gap between engineering's technical vocabulary and the legal vocabulary of data transfers requires a translation layer in the development process. Privacy engineering reviews that assess whether new integrations create international data transfers, built into the feature design process before development begins, provide the translation layer that catches transfer obligations before the integration is live rather than after.
The screening question is simple: does this integration send personal data about EU users to a server or service outside the EU? If yes, the integration requires a transfer mechanism, potentially a TIA, and a DPA before it goes live. The engineering team answers the factual question about the integration's technical design. The legal or privacy team assesses the compliance implications of the answer. The process is lightweight and occurs at the design stage where the compliance requirements can be addressed before the code is written.
Organizations that have built this translation layer have found that the population of integrations that create cross-border transfer obligations is significantly larger than what their formal vendor onboarding process was catching. Most of the additional integrations are with analytics vendors, monitoring tools, and third-party services that engineering teams integrate directly without going through formal vendor management.
Build the transfer question into the integration design process. The API call is a data transfer. Treat it as one before it goes live.
The API call crosses the border before the lawyer knows it exists. Build the process that tells the lawyer before the API call is written.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.