To answer all those questions and provide an easy path for US companies to follow, we put together the following practical checklist. In order, it explains if and when the GDPR applies, what type of role - Controller, Processor or both - the company takes and what each one requires and, last but certainly not least, how to move personal data from the EU to the US, and whether to rely on the EU-US Data Privacy Framework, standard contractual clauses or both.
For a more personalised analysis, Book a LEGALFLY demo. We will walk you through the US-GDPR Compliance Checklist using contracts relevant to your portfolio.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
GDPR Compliance Checklist for US Companies
Step 1: Does the GDPR apply to your company?
Article 3 establishes the territorial scope: there are three statutory and one contractual (and the most common in practice) clauses that bind a US company to GDPR.
Article 3(1): The enterprise has an establishment in the EU. Whether it is a subsidiary, a branch, an office or even a small stable team in the EU, the GDPR applies to processing carried out in the context of that establishment's activities. It does not matter where the servers are, the EDPB's Guidelines 3/2018 on territorial scope read "establishment" broadly: a stable arrangement can be enough, even without a registered entity.
Article 3(2)(a): The enterprise offers goods or services to customers in the EU. It is not enough to have an exclusively European website, as Recital 23 points to signals such as EU languages or currencies, delivery to EU countries, EU domain names, or marketing aimed at EU audiences - and it does not exempt free services.
Article 3(2)(b): The enterprise monitors the behaviour of people in the EU. Tracking and profiling individuals in the EU, through behavioural advertising, cross-site tracking, location data or analytics used to predict preferences, among others, brings that processing within the GDPR (Recital 24).
Article 27 dictates which enterprise may need an EU representative. A US company caught by Article 3(2) without an EU establishment must appoint a representative in a member state where its data subjects are, which, in turn, holds a copy of the records of processing (under Article 30) and must be named in the US company’s privacy notice. Exceptions are far and few: occasional processes that do not involve large-scale special categories or criminal data, and are unlikely to create a risk, are exempt. Most companies with an ongoing EU customer base do not qualify.
Keep in mind:
Many US B2B companies are not directly caught by Article 3 for their customer data, as they process personal data on behalf of European customers, who themselves are the controllers subject to the GDPR. They, the customers, are the ones responsible for enforcing GDPR legal obligations through audit rights, indemnities and termination, rather than by a regulator. Therefore, they must bind you by an Article 28 contract and a valid transfer mechanism before sending you any data.
It is also of note that, although the EDPB states that a non-EU processor is not subject to the GDPR under Article 3(2) merely because it processes data for an EU controller, the same duties will still be imposed onto the processor by the DPA they sign.
Step 2: Controller or Processor? Most US companies are both
The split between controller and processor decides which half of this checklist applies, and it is where most US teams get confused. The role is set by the facts, not by the label in the contract:
You are a controller when you decide why and how personal data is processed. Your own marketing lists, website analytics, EU employees, sales prospects and customer account contacts usually fall here.
You are a processor when you process personal data only on a customer's documented instructions and for the customer's purposes. A SaaS platform hosting customer records, a payroll provider or a support tool usually sits here for the data customers load into it.
Keep in mind:
A typical US SaaS company is a controller for its own business data and a processor for its customers' data, at the same time. The danger zone is the middle.
If your terms let you use customer data for "product improvement", analytics or model training, you are deciding a purpose of your own and, for that use, you become a controller, which the customer's DPA almost certainly prohibits. As such, you must map each data flow to one role before signing anything.
The two checklists below follow that split:
Step 3a: What applies if you are a controller
If you are caught by Article 3 as a Controller, the full GDPR applies to that processing. For a US company, these are the obligations that matter most.
Checklist: Controller obligations
☑️ Lawful basis (Art. 6) - Each processing purpose has a documented legal basis, either a contract, a legitimate interest (with a balancing test on file), a consent or a legal obligation. US-style "notice and opt-out" is not a legal basis.
☑️ Transparency (Arts. 13 and 14) - An EU-facing privacy notice must include your company, your EU representative, purposes, legal bases, recipients, transfers, retention and individual rights.
☑️ Individual rights (Arts. 15 to 22) - You can handle access, rectification, erasure, restriction, portability and objection requests within one month, including requests that reach your processors.
☑️ Records of processing (Art. 30) - You keep a written record of processing activities. The exemption for organisations under 250 employees rarely applies, because it falls away for regular processing.
☑️ Security (Art. 32) - Technical and organisational measures are proportionate to the risk, and must be documented.
☑️ Breach notification (Arts. 33 and 34)- You can notify the lead supervisory authority within 72 hours of becoming aware of a breach, and affected individuals without undue delay where the risk is high. US state breach laws run separately and on different triggers.
☑️ DPIAs (Art. 35) - High-risk processing, such as large-scale profiling, systematic monitoring or new AI uses, has a data protection impact assessment before it starts.
☑️ Privacy by design and default (Art. 25) - New products and features collect only what they need by default.
☑️ DPO (Art. 37) - You have assessed whether you need a data protection officer, which in itself is required where core activities involve large-scale regular monitoring or large-scale special category data.
☑️ EU representative (Art. 27) - Appointed in writing, unless you have an EU establishment or meet the narrow exception.
☑️ Your own vendors (Art. 28) - Every processor you use for EU personal data, including US cloud and SaaS providers, is bound by a compliant DPA.
☑️ Transfers (Chapter V) - Every transfer of EU personal data to the US or elsewhere is covered by the DPF, SCCs or another mechanism (see Step 4).
☑️ Cookies and tracking - Non-essential cookies and trackers on EU-facing sites have prior consent under the ePrivacy rules, which sit alongside the GDPR.
Step 3b: What applies if you are a Processor
As a Processor, most of your GDPR obligations arrive through the customer's DPA. Article 28(3) dictates its minimum content, so the clauses themselves are rarely negotiable. You can, however, negotiate how they are written: notice periods, audit mechanics, liability and the scope of what you are allowed to do with the data.
European customers tend to review DPAs against the same checks, which the LEGALFLY DPA review checklist groups into 7 areas and 21 questions and that you can find below. Reading those checks from the processor's side tells you what will be asked and where to hold your position.
Review area | What the EU customer will check | Your position as the US processor |
|---|---|---|
1. Scope of processing | Subject matter, duration, purpose, data types and data subject categories are specific and tied to the services | Accept specificity. Make sure the annex matches what your product actually does, including support and logging |
2. Instructions and confidentiality | You act only on documented instructions, including for transfers; staff are bound by confidentiality | Accept. Define instructions to include use of product features, and remove any "service improvement" use of customer data you cannot defend |
3. Security and breach notification | Appropriate technical and organisational measures; breach notice without undue delay, ideally within 48 hours; notice covers nature, scope, consequences and remediation | Keep a current security annex. Commit to a fixed window you can meet, with phased information allowed |
4. Sub-processors | Prior specific or general written authorisation; advance notice with a right to object; you stay fully liable | Use general authorisation with a published list and email notice. Agree to a defined remedy for unresolved objections |
5. Assistance | Prompt help with individual rights requests, DPIAs and prior consultation | Accept, with help throughout product tooling first and reasonable cost recovery for bespoke work |
6. International transfers | A valid mechanism, such as the latest SCCs, covers any transfer to a third country | Offer DPF certification plus SCCs (Module 2 or 3) as a fallback (see Step 4) |
7. Exit, audit and liability | Audits beyond certificates; return or deletion with copies deleted; capped liability with data protection carve-outs; governing law and jurisdiction | Offer SOC 2 or ISO 27001 reports first and audits after incidents. Set backup deletion timelines. Negotiate a defined super-cap, not unlimited liability |
Your direct obligations as a Processor:
Whenever the GDPR applies to you directly, some duties become your responsibility regardless of the contract, and you can be fined directly by supervisory authorities when failing to follow through:
Records of processing for processors (Art. 30(2)), security (Art. 32)
Notifying the controller of breaches (Art. 33(2))
Sub-processor rules in Article 28
Appointing an EU representative where Article 3(2) applies.
Please, keep in mind that three clauses come up most often:
A "service improvement" or AI training right in your standard terms that contradicts the DPA.
A sub-processor list that leaves out your AI model provider or offshore support teams.
A liability clause in your master agreement that silently caps data protection claims at 12 months of fees, which the customer's DPA will try to override.
Step 4: Transfers. DPF, SCCs, or both
This is the part of the checklist that carries the most risk for US companies.
Every time personal data moves from the EU to the US, Chapter V of the GDPR requires a transfer mechanism, and there are two that do almost all the work, regardless if you are a controller receiving data from EU affiliates or a processor receiving it from EU customers.
The EU-US Data Privacy Framework
The DPF is an adequacy decision the European Commission adopted in July 2023.
US companies self-certify with the Department of Commerce and commit to the DPF Principles, enforced by the FTC or the Department of Transportation. Once certified, EU exporters can send you personal data without SCCs or a transfer impact assessment for that transfer - HR data, however, needs a separate HR certification.
Only certified organisations benefit, so it covers you but not your uncertified US sub-processors.
Standard contractual clauses
The 2021 SCCs are contract terms adopted by the Commission:
For a US processor receiving data from an EU controller, Module 2 applies.
For a US sub-processor receiving data from an EU processor, Module 3 applies.
SCCs need a transfer impact assessment that looks at US law in practice, which is currently easier than it was before 2023 due to the safeguards introduced by Executive Order 14086, including the Data Protection Review Court.
There are, however, risks you must consider:
The DPF is valid today (upheld on 3 September 2025 by the General Court in Latombe v Commission (T-553/23)) but Philippe Latombe appealed to the Court of Justice on October 31st, 2025 which, in turn, struck down both predecessor frameworks - Safe Harbor in 2015 and Privacy Shield in 2020. No hearing date has been reported (Interlegal, October 2026).
A second risk emerged in June 2026, when the US Supreme Court's ruling in Trump v. Slaughter allowed FTC commissioners to be removed without cause. NOYB, the European Center for Digital Rights, argued that this undercuts the FTC independence the adequacy decision relies on, and announced its own challenge. For now, the Commission has said it continues to implement the DPF but, if the Court of Justice annuls the adequacy decision with little or no transition period, every transfer that rests on the DPF alone loses its legal basis at once. That is what happened to Privacy Shield users in July 2020.
Transfer posture | Exposure if the DPF falls | What to do now |
|---|---|---|
DPF only | Every affected transfer is left without a mechanism | Put SCCs in place now, as a fallback, before a ruling forces a rushed migration |
DPF plus SCCs | Low. The SCCs take over | Keep TIAs current so the fallback holds on its own |
SCCs only | Not affected by a DPF ruling | Keep TIAs rigorous. SCCs carry their own enforcement risk when the assessment is weak |
Checklist: Transfers
Every EU-to-US data flow is mapped to a mechanism: DPF, SCCs, binding corporate rules or a derogation.
If you rely on the DPF, your certification is active, covers the right data (including HR data) and lists the correct entities.
Customer DPAs include signed SCCs (Module 2 or 3) as a fallback that applies automatically if the DPF ceases to be valid, even where the DPF is the primary mechanism.
A transfer impact assessment supports every SCC transfer, with a review date.
Onward transfers to your own sub-processors are covered, either by their DPF certification or by SCCs you sign with them.
Supplementary measures you rely on (encryption, access controls, EU hosting options) are described in the security annex.
You have a process to challenge or notify on government access requests, as required by SCC Clause 15.
UK transfers use the UK Extension to the DPF or the UK Addendum, and Swiss transfers the Swiss-US DPF or adapted SCCs.
Keep in Mind:
The 2021 SCCs were drafted for importers that are not subject to the GDPR. If you are directly subject under Article 3(2), they fit awkwardly, and the Commission has been working on an additional set for that case.
US state privacy laws are a separate regime, not a substitute
Comprehensive privacy laws implemented in around twenty states, including California's CCPA, are often treated as "the US version of GDPR", but they are not interchangeable.
Complying with them does not satisfy the GDPR, and GDPR compliance does not automatically satisfy them.
The differences that matter in practice:
State Laws | GDPR | |
Scope | Apply based on thresholds such as revenue or the number of state residents' records. | Applies based on establishment, targeting or monitoring, with no size threshold. |
Legal Basis | Notice and opt-out. | Requires a legal basis before processing starts. |
Contracts | Require service provider or processor contracts with their own required terms. | DPA usually covers most of them, but not all. Check for state-specific terms, such as the CCPA's restrictions on selling or sharing. |
Transfers | No equivalent to Chapter V. | Nothing in US state law helps you justify a transfer from the EU. |
The practical approach is to build one privacy programme with a GDPR baseline and state-specific layers on top, and to keep the contract templates for each regime clearly separated.
What else is moving in 2026
Two EU developments are worth tracking, though neither changes today's checklist:
The Digital Omnibus - The European Commission proposed it on 19 November 2025 to amend parts of the GDPR and the ePrivacy rules, and the former is still a proposal. Among other things, it would make the definition of personal data relative to who holds it, which matters for US vendors that only see pseudonymised data. It would also move breach notification to 96 hours for high-risk breaches only. Until a final text is adopted, current GDPR rules apply in full. You can read more about it in our own GDPR Compliance Checklist.
The EU AI Act - It applies to US companies that place AI systems on the EU market or whose AI output is used in the EU. The separate AI omnibus was adopted as Regulation (EU) 2026/1744, and delayed the obligations for high-risk systems listed in Annex III to 2 December 2027 (PPC Land). For US processors, the more immediate effect is contractual. European customers now ask whether you train on their data and where your models run, and expect the answer in the DPA.
Handling customer DPAs at scale with LEGALFLY
For a US company selling into Europe, the bottleneck is not the GDPR checklist but its volume. Every European deal brings a customer DPA, and each one lands in Legal's queue while Sales waits. LEGALFLY, the legal operating system for in-house teams, moves that work from request to outcome, inside the guardrails legal sets.
Agent Studio
The customer DPA becomes one workflow, as LEGALFLY's Sales workflow chain adapts directly to inbound DPAs:
A customer DPA arrives from sales by email, Slack or Teams.
A triage agent identifies whether it is the customer's paper or your own template, and routes it.
The Review agent checks it against your own DPA playbook: scope, instructions, security and breach windows, sub-processors, assistance, transfers, audit, exit and liability.
Terms inside your positions pass while deviations are routed to Legal with the flagged clause, the reason and a suggested redraft in your approved fallback wording.
Legal approves and the requester in sales is notified automatically.
Sales stops waiting on Legal for routine data terms, and the latter stays in control of every exception. This is a legal workflow automation that reaches beyond the Legal team, which is where most of the DPA volume starts.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
Anonymisation
Customer DPAs, annexes and sub-processor lists contain names, signatories and contact details, often of EU individuals, and sending them through a generic AI tool creates the very transfer question this checklist is about.
LEGALFLY anonymises documents at import, before any analysis begins, so personally identifiable data does not leave your environment. LEGALFLY is the only legal AI that anonymises documents before analysis. It runs as SaaS, single tenant, or single tenant with on-premise anonymisation, and is ISO 27001 certified and SOC 2 Type II compliant.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
Contract Intelligence
It is crucial to know which contracts depend on the DPF, particularly if the Court of Justice rules against it.
Contract Intelligence provides full visibility across the contract lifecycle, including obligations and key dates after signature.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
FAQs About GDPR Compliance Checklist for US Companies
Does GDPR apply to US companies with no office in the EU?
It can. Under Article 3(2), the GDPR applies to a US company that offers goods or services to people in the EU or monitors their behaviour there, even with no EU presence. US B2B companies are also bound in practice through the DPAs their EU customers ask them to sign.
Do US companies need an EU representative?
Yes, if they are subject to the GDPR under Article 3(2) and have no EU establishment, unless their processing is occasional, excludes large-scale special category data and is unlikely to create a risk. Most companies with ongoing EU customers do not meet that exception.
Is the EU-US Data Privacy Framework still valid in 2026?
Yes. The General Court upheld it in September 2025. An appeal (Case C-703/25 P) is pending before the Court of Justice, which struck down both earlier frameworks. Keeping SCCs as a fallback is the safest contract position.
If we are DPF-certified, do we still need SCCs?
Not legally, for transfers covered by your certification. Practically, yes. SCCs in your customer DPAs mean a ruling against the DPF does not leave every EU contract without a transfer mechanism overnight.
Does CCPA compliance cover GDPR requirements?
No. US state privacy laws are separate regimes with different scope, legal bases and contract terms, and they say nothing about transfers out of the EU.
What is the most common reason a US company needs a GDPR compliance checklist?
An EU customer asking it to sign a data processing agreement. That one document brings in Article 28 obligations, transfer clauses, breach windows, audit rights and liability terms.
