Client data flows across borders and regulatory regimes

A custody dispute involving a Frankfurt-based manufacturing subsidiary lands on a London partner's desk on a Monday. By Wednesday, HR files, employee emails, and board minutes have moved from a German server to a London matter team's document management system, then out again to a New York e-discovery vendor for processing. Nobody in that chain necessarily broke the law. But nobody necessarily checked either, and that gap is where firms get exposed.

This lesson traces that exact data path and shows where the legal transfer mechanisms live, where they commonly fail, and what a data audit at each hop should look for.

The route: three jurisdictions, three regimes

Frankfurt (origin): Personal data of employees, executives, or customers sits under the EU's General Data Protection Regulation (GDPR), enforced in Germany by state-level data protection authorities (Datenschutzbehörden). GDPR treats any export of personal data outside the European Economic Area (EEA) as a "restricted transfer" requiring a legal basis.

London (matter team): Since Brexit, the UK runs its own near-identical regime, UK GDPR, overseen by the Information Commissioner's Office (ICO). A transfer from Germany to London is EU-to-UK, an international transfer under EU law even though both sides have "adequacy" recognition from the European Commission (a formal finding that UK law offers equivalent protection). Adequacy is currently in place but was only renewed with a sunset clause; the European Commission extended UK adequacy to June 2025 and then again, and firms should treat it as a standing item to monitor, not a permanent fact.

New York (e-discovery vendor): The UK-to-US leg is the dangerous one. The US has no single comprehensive federal privacy law. Instead there's a patchwork: California's CCPA/CPRA (California Consumer Privacy Act, amended by the California Privacy Rights Act), plus separate state laws in Virginia, Colorado, Connecticut, Utah, and a growing list of others, each with different thresholds and consumer rights. None of these give the US "adequacy" under GDPR. Every transfer of EU or UK personal data into the US needs its own legal justification.

Where the transfer mechanism actually lives

GDPR Articles 44 to 49 govern this. In practice, three mechanisms matter for law firms:

1. Standard Contractual Clauses (SCCs): European Commission-approved contract templates that bind the data importer (the US vendor) to EU-level protections. Updated versions were issued in 2021. These are the workhorse mechanism.
2. UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs, issued by the ICO for the UK leg.
3. Adequacy decisions, which remove the need for contractual fixes entirely, but only cover a short list of countries (not including the US as a whole).

The Schrems II problem

In July 2020, the Court of Justice of the European Union (CJEU) issued the *Schrems II* ruling (Case C-311/18), striking down the EU-US Privacy Shield framework and, critically, holding that SCCs alone aren't automatically sufficient. Data exporters must also assess whether the destination country's surveillance laws (in the US, this means FISA Section 702 and Executive Order 12333) could let government agencies access the data regardless of the contract.

This created the Transfer Impact Assessment (TIA), now a standard due diligence document: before sending data to a US vendor, the exporter must document the surveillance risk, the sensitivity of the data, and any supplementary measures (encryption, pseudonymization, access controls) that mitigate it.

The EU-US Data Privacy Framework (DPF), adopted by the European Commission in July 2023, restored a form of adequacy for US companies that self-certify with the US Department of Commerce. It has already faced legal challenges echoing Schrems I and II. Firms relying on DPF-certified vendors should confirm certification status directly on the Data Privacy Framework registry rather than taking a vendor's word for it, and should still keep an SCC fallback in the contract.

Why e-discovery vendors are the highest-risk hop

E-discovery (the identification, collection, and review of electronic documents for litigation) routinely involves bulk transfer of unreviewed data, meaning privileged material, special category data (health, union membership, biometric data under GDPR Article 9), and irrelevant personal data all move together before anyone filters it.

Practical failure points:

• Vendor subprocessors: The New York vendor may host on cloud infrastructure with data centers in multiple regions, or use offshore review teams in a fourth country never mentioned in the original contract.
• No TIA on file: Firms assume the vendor's SCCs cover them, without documenting the Schrems II surveillance assessment.
• Data minimization skipped: GDPR Article 5(1)(c) requires transferring only what's necessary. Sending the full Frankfurt HR drive instead of a filtered, relevance-tagged subset multiplies exposure.
• Retention drift: Once litigation closes, data sits on vendor servers indefinitely because no one owns the deletion instruction.

A minimal transfer audit checklist

For each cross-border data flow, verify:
[ ] Legal basis for processing (GDPR Art. 6, plus Art. 9 if special category)
[ ] Transfer mechanism identified (SCCs / IDTA / adequacy / DPF)
[ ] Transfer Impact Assessment on file, dated, and matter-specific
[ ] Subprocessor list obtained and geographic locations confirmed
[ ] Data minimization applied before export (filter, not full dump)
[ ] Retention/deletion schedule agreed and calendared
[ ] US state law scope check (does CCPA/CPRA or another state law apply
    to the vendor's handling, independent of GDPR?)

This isn't a one-time form. Matter teams should run it per matter, because the data set, vendor, and jurisdictions change every time.

US state laws add a second, separate layer

Even once GDPR transfer mechanics are sorted, the New York vendor's handling of the data may independently trigger US state law obligations, because CCPA/CPRA applies based on the personal information of California residents, regardless of where processing happens. A New York vendor processing a Frankfurt subsidiary's US-resident employee data for a California-linked corporate parent can be in scope for CCPA even though the "transfer" conversation was all about GDPR.

This means law firms need two parallel compliance tracks, not one: GDPR/UK GDPR transfer legality, and US state privacy law applicability. Treating US privacy as "no GDPR, so no problem" is the most common silent breach risk in this whole chain.

For a firm-level view of enforcement trends, the International Association of Privacy Professionals (IAPP) publishes free tracking resources on both EU enforcement actions and the expanding US state law mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition →, useful for a periodic scan rather than a one-off read.

🎬 [VIDEO: "Schrems II Explained: EU-US Data Transfers" — youtube.com — a short explainer on the CJEU ruling and its practical effect on standard contractual clauses, useful as a plain-language primer before reading the full judgment]

Key Takeaways

• Every hop in a cross-border matter (Frankfurt to London to New York) is a separate legal transfer event under GDPR, each needing its own mechanism (SCCs, UK IDTA, adequacy, or DPF), not one blanket assumption covering the whole chain.
• Schrems II (2020) means SCCs alone are not enough for EU-to-US transfers; a documented Transfer Impact Assessment covering US surveillance law exposure is now expected practice.
• E-discovery vendors are the highest-risk link because they receive bulk, unfiltered, unreviewed personal data, often including special category data, before minimization happens.
• US state privacy laws (CCPA/CPRA and others) apply on their own terms and can create exposure independent of any GDPR transfer question, so both tracks need separate checks.
• Run a per-matter transfer audit (legal basis, mechanism, TIA, subprocessor list, minimization, retention) rather than relying on a firm-wide policy document that nobody revisits.