Are You Making Any Cross-Border Data Transfers Under GDPR?

If your product or service is subject to the GDPR, then GDPR Chapter V regulates any transfers you make of EU personal data to "third countries," meaning any country outside the European Economic Area (EEA) where GDPR applies.

The basic thrust of these restrictions (as interpreted by the CJEU in the consequential Schrems II decision) is that EU personal data transferred outside the EEA must receive "essentially equivalent" protections as personal data processed within the EEA. If the "third country" to which the data is transferred does not have data privacy laws equivalent to the GDPR, then protections can be added on via contract, technical measures, and other means to bring the level of protection up to GDPR standards.

Before transferring data to a third country that hasn't been deemed by the European Commission to have "adequate" (GDPR-equivalent) data privacy protections, the exporter of the data must perform a "transfer impact assessment" to determine whether the laws of the target country provide GDPR-equivalent protections and, if not, what additional measures should be taken to meet that standard. It must then implement those measures.

For transfers to the United States, the equivalency standard is most often met either by participating in the EU-US Data Privacy Framework (DPF), or (especially for smaller services) by using European Commission-approved Standard Contractual Clauses (SCCs) in conjunction with data minimization, encryption, or other technical measures to limit the risk that EU personal data will be misused or fall into the hands of US surveillance agencies.

Collecting data directly from an EU data subject is not a "transfer" without more

Just because your US product or service has users in the EU doesn't mean it's necessarily "transferring" any EU personal data. That's because only transfers of data from a controller or processor to another controller or processor are considered "transfers" under GDPR Chapter V.

Thus, if a user in the EU signs on to your US-hosted service and you store their data on your US-based servers, no transfer has taken place.

This means that a US-based service that keeps all of its data in-house can generally falls outside of Chapter V entirely (for that data flow, anyway).

Watch out for intra-US transfers, and transfers by another name

However, if you provide that user's data to a third party—including an affiliate—in a third country, you must comply with Chapter V. Since the US is itself a "third country," this means most US-based services with EU users are still making Chapter V transfers, including to hosting providers and other service providers in the US. (Movement of EU personal data to other offices, employees, or integrated contractors of your company is not likely to be considered "transfers" however.)

European regulators also interpret "transfer" quite broadly. For example, data may be deemed "transferred" even when it's merely made available in the third country, e.g. if a service provider in a third country can access EU user data via a CRM interface or user support tool like Zendesk.

Having an EU subsidiary doesn't necessarily make this easier, it just creates another transfer

Your company may be tempted to set up an affiliate or office in the EU, or to store EU data primarily or exclusively in the EU, but this alone won't solve the problem—and it may make it worse.

Meta provided Facebook to EU users via an Irish subsidiary. It nonetheless stored and processed user data primarily in the US. The European Data Protection Board (EDPB) found that Meta IE transferred Facebook's EU users' data to its US affiliates and therefore was subject to GDPR Chapter V's transfer restrictions.

Storing EU user data with a hosting provider in the EEA doesn't get you out of Chapter V either: when your US staff access that data, the EEA hosting provider is making the data available to you in the US—itself a transfer (though the least-onerous kind, typically papered by 'Module 4' SCCs built into the host's standard Data Protection Addendum). And where the access runs between group companies, it's a transfer full-stop: The Irish Data Protection Commission found that TikTok, even though it segregated EU user data on servers hosted in the EU, "transferred" that data to China by virtue of remote access to the data by staff of its (separate) China entities.

Can US-based services avoid GDPR transfer requirements?

A US-based service provider can only avoid GDPR's third country-transfer restrictions under very narrow circumstances:

• There is no EU affiliate in the contracting chain with the EU users;
• The EU user data is not transferred—or accessible in identifiable form—to any third party in a third country; and
• The EU user data is stored either (a) on your own infrastructure (i.e. not on the servers of a hosting provider like AWS); (b) with a provider based in the EEA (contracting through its EEA entity); or, (c) with a third-country provider that receives only data that is encrypted or pseudonymized such that the provider cannot access identified personal data.

That's a pretty narrow set of circumstances—most US service providers with EU users are therefore likely making Chapter V transfers of one kind or another. In practice, Chapter V enforcement has focused on companies with no transfer tool in place (Uber's €290M fine), or assessments that didn't hold up (TikTok's €530M)—not on companies with documented, proportionate, good-faith transfer programs.

Compliance with GDPR Chapter V transfer restrictions

The full scope of Chapter V compliance will be covered in a later post, but here's a short summary of what US service providers must do to ensure third-country transfers of EU personal data are compliant:

1. Perform a transfer impact assessment to determine whether the third-country has GDPR-equivalent protections and, if not, what measures are necessary to bring the transfer up to par. If the European Commission has issued an adequacy decision for the third country under GDPR Art. 45, that ends the analysis, but the service provider is required to keep tabs on whether the decision is revoked. (Transfer impact assessments are not specifically mentioned in the GDPR, but the EDPB has made it clear that they are required "in practice.")
2. Subject the transfer to "appropriate safeguards" in the form of contractual terms (either SCCs or ad hoc terms), binding corporate rules (for transfers to affiliates), "an approved code of conduct" together with binding commitments from the transferee, or "an approved certification mechanism."
3. If the safeguards are not adequate under the circumstances, including if there is a significant risk that EU personal data will be subject to FISA Section 702 directives or national security letters, take additional technical measures to neutralize those risks.

Where that leaves us

In practice, avoiding US warrantless surveillance with technical measures is nearly impossible for US service providers. Even encryption at rest in the EU is likely inadequate if the US entity retains, or has the right to obtain, the key—basically a foregone conclusion under the US CLOUD Act.

For most US service providers, then, the question comes down to the surveillance value of the data. B2B services whose EU personal data extends only to user accounts, billing data, and the like probably don't need to move heaven and earth to create a technological fortress around the data. On the other hand, service providers handling private communications of EU consumers should think carefully about whether contractual clauses and encryption-at-rest are sufficient to meet GDPR's standard.

Service providers processing EU personal data with a higher surveillance value should consider taking the additional measure of achieving and certifying DPF compliance. The DPF is undergirded by a 2022 executive order (EO 14086) that added surveillance safeguards and a redress mechanism for EU individuals; on that basis, the European Commission issued an adequacy decision covering DPF-certified US providers.

Alas, a dark cloud hangs over the DPF. The CJEU previously invalidated the two previous EU-US frameworks blessed by the EC (the EU-US Privacy Shield and the International Safe Harbor Privacy Principles). A case challenging DPF—Latombe v Commission, on appeal to the CJEU—may succeed: actions of the Trump administration (including removals of oversight-board members, and a Supreme Court ruling confirming the President's power to make them) have called into question the legal sufficiency of the executive order on which the EC based its determination.

For now, DPF compliance is likely the safest path for US providers offering communications platforms to EU users. But in case it's invalidated, DPF participants should be prepared to fall back to Art. 46 appropriate safeguards by including SCCs in their contracts with transferees and keeping TIAs for those transfers up to date.

Perfect protection against US surveillance isn't realistic, including for DPF participants. Recognizing this, EU regulators focus their Chapter V enforcement analysis on whether transfers are documented and proportionate.

Taking action

This week, list every vendor that touches EU user data, identify where each is located (physically and legally), and check whether each is subject to an EC adequacy decision—for US entities, check them against the DPF participant list. That will give you a solid start on mapping your transfers.