Using Standard Contractual Clauses to Move EU Data to the US

The current SCCs come in different modules depending on the relationship between the parties, controller to controller, controller to processor, processor to processor, and using the wrong module for your actual relationship undermines the whole point of having a legally valid transfer mechanism. A company sending employee data to a US-based EOR is typically in a different module relationship than a company sending customer data to a US-based analytics vendor.

Work with counsel to identify the correct module for each specific data flow, since a single company often has multiple different transfer relationships that need different modules, not one blanket agreement covering everything.

Using SCCs isn't sufficient on its own; you also need to assess whether the destination country's laws, US government surveillance access in particular, could undermine the protections the SCCs promise, and implement supplementary measures if they do. This assessment needs to be documented, not just asserted, since it's exactly what a regulator would ask to see.

Common supplementary measures include encryption in transit and at rest with keys held outside US government reach, and minimizing what data actually needs to transfer in the first place rather than transferring everything by default.

The simplest way to reduce transfer risk is transferring less data. Before setting up a new cross-border data flow, ask whether the full dataset actually needs to move, or whether a smaller subset, or an aggregated version, would serve the actual business purpose. This isn't just a compliance nicety, it also reduces the scope of what needs to be covered by SCCs and supplementary measures in the first place.

This is particularly relevant for employee data moving into US-based HR or payroll systems, where sensitive categories like health information sometimes get transferred by default even when the US system doesn't actually need them.

A few patterns that show up repeatedly:

• Signing SCCs once at vendor onboarding and never revisiting them as the data flow or the legal landscape changes
• Using the wrong module for the actual relationship between the parties
• Treating the transfer impact assessment as a checkbox rather than a documented, substantive analysis
• Transferring more data than the receiving system actually needs, widening the risk surface unnecessarily

Each of these is a reason to review your current cross-border data flows specifically, rather than assuming an SCC signed years ago still reflects your current setup.

For example, a company that signs SCCs with its US HR platform in the first year may later add a US analytics vendor that receives customer email addresses. That second flow is a different relationship and may need a different module. A short data-flow register helps: list each vendor, the categories of data they receive, the module in use, the date the transfer assessment was done and the next review date. When a new vendor appears, adding a row prompts the module and assessment questions before any data moves.

SCCs, transfer impact assessments, and any supplementary measures documentation need to be stored somewhere retrievable, since a regulator inquiry, a customer's own vendor due diligence, or an internal audit can all ask for it with limited notice. Foxit eSign is useful for executing SCCs and related agreements with multiple vendors and signatories efficiently, and Process Street can standardize the transfer impact assessment process so it's actually completed consistently rather than skipped under time pressure.

Check with EU data protection counsel on your specific transfer flows, since the right module and supplementary measures depend on the actual relationship and data involved in each case, and a generic template rarely fits every vendor relationship equally well.