The GDPR overlay on US-EU contracts

If you are a U.S. company and your contract touches anyone in the European Union — customers, employees, users of a website, attendees at an event — the General Data Protection Regulation may apply to that relationship even if every other word in your agreement is written under U.S. law. GDPR does not replace the contract. It overlays it.

This article is a plain-language map of when a U.S. contract needs GDPR-aware language, what the basic roles and obligations are, and what the current transfer mechanisms look like after the Schrems II decision. It is not a substitute for reading the regulation or speaking with privacy counsel — GDPR is fact-specific and the details matter.

When GDPR reaches across the Atlantic

GDPR applies to the processing of personal data in two main scenarios relevant to U.S. contracts:

• Establishment in the EU. If you have an office, branch, or other stable presence in the EU, and the processing happens "in the context of the activities of that establishment," GDPR applies.
• Targeting EU data subjects. Even without a presence in the EU, GDPR applies when you offer goods or services to people in the EU, or monitor their behavior. A U.S. SaaS company with EU customers is a standard example. A U.S. website that happens to load for a European visitor is usually not, on its own, enough.

The practical test is less about geography and more about intent. If your contract contemplates handling personal data that originates with, or relates to, people in the EU, GDPR is probably in the room.

Controller vs. processor: the role that changes everything

GDPR divides parties into two main categories and gives them different obligations.

• Controller. The party that decides the "purposes and means" of the processing. The controller is the one who chose to collect the data, what to do with it, and how long to keep it. The controller carries the primary compliance burden: lawful basis, transparency, data subject rights, security, and accountability.
• Processor. A party that processes personal data on behalf of the controller, following the controller's instructions. Processors have their own direct obligations under GDPR — security, notification of breaches, limitations on sub-processors — but they cannot decide to use the data for their own purposes without becoming a controller themselves.

The role depends on what the party actually does with the data, not on what the contract calls them. A vendor labeled a "processor" who decides to enrich the data with their own analytics for their own benefit has, probably, become a controller for that processing.

When two parties are both controllers of the same data for a joint purpose, they are "joint controllers," and Article 26 of GDPR requires a written arrangement allocating responsibility between them. This is common in co-marketing, shared platform, and integration scenarios.

The Data Processing Agreement (DPA)

When a controller engages a processor, Article 28 of GDPR requires a written contract — a Data Processing Agreement — with specific terms. The required content includes:

• The subject matter, duration, nature, and purpose of the processing
• The types of personal data and categories of data subjects
• A requirement that the processor only process data on documented instructions
• Confidentiality obligations on personnel handling the data
• Appropriate technical and organizational security measures
• Rules on engaging sub-processors, including prior authorization
• Assistance to the controller in responding to data subject requests
• Assistance with security, breach notification, and impact assessments
• Return or deletion of personal data at the end of the engagement
• Audit and information rights for the controller

A U.S. commercial contract without a DPA attached — or with DPA language integrated into the main body — is missing the overlay. A vendor processing EU personal data on your behalf without one is a compliance gap for both parties.

Transfers out of the EU: the Schrems II problem

GDPR restricts transfers of personal data from the EU to countries that do not offer an "adequate level of protection." The European Commission maintains a list of jurisdictions it considers adequate. The United States is currently handled through a specific framework, and the landscape has shifted repeatedly over the last decade.

The 2020 Schrems II decision by the Court of Justice of the European Union invalidated the then-current Privacy Shield framework. Since then, the most common transfer mechanisms in practice have been:

• Standard Contractual Clauses (SCCs). Template clauses published by the European Commission that the exporter and importer incorporate into their contract. These are the workhorse mechanism for most transfers and require a transfer impact assessment to evaluate whether the destination country's laws provide sufficient protection.
• EU–U.S. Data Privacy Framework. A successor framework to Privacy Shield that provides an adequacy basis for transfers to certified U.S. organizations. Whether this is the right mechanism depends on whether the specific U.S. recipient is certified and whether the framework is currently in force — both of which can change.
• Binding Corporate Rules (BCRs). Internal policies approved by EU data protection authorities for transfers within a corporate group. These take significant time to put in place and are mostly used by large multinationals.

Because the specific transfer mechanism in force, and the supplementary measures required, change over time and depend on the facts, this is one of the areas where contract language should be drafted with current counsel input rather than copied from an older agreement.

A practical checklist

When you are drafting or reviewing a U.S. contract that touches EU personal data, ask:

• Who is the controller and who is the processor for each processing activity?
• Is there a DPA in place with the Article 28 required terms?
• Is personal data crossing the EU border to the U.S.? Under what transfer mechanism?
• Have sub-processors been listed and authorized?
• Does the contract describe how data subject requests will be handled between the parties?
• Is there a breach-notification timeline that meets GDPR's 72-hour clock?

GDPR-aware drafting does not have to make a contract unreadable. It usually means attaching a clean DPA, referencing the current transfer mechanism, and being precise about roles. The underlying commercial terms can stay in U.S. style.

This article is for general information only and is not legal advice.