Does GDPR Apply to US Companies? Article 3 Explained (2026)

GDPR applies to US companies that offer goods or services to people in the EU or monitor their behaviour there, under Article 3(2) of Regulation (EU) 2016/679. No EU office, employees, or establishment is required. This guide covers every trigger, obligation, and fine exposure a US company needs to understand.

For a full overview of what GDPR requires, including the seven data-processing principles and the six lawful bases, see the companion explainer.

Does GDPR Really Apply to a US Company With No EU Presence?

Yes. Article 3(2) of Regulation (EU) 2016/679 extends GDPR's reach beyond the EU's borders. The provision applies to any controller or processor not established in the Union when its processing of personal data relates to: (a) the offering of goods or services, irrespective of whether a payment is required, to data subjects who are in the Union; or (b) the monitoring of the behaviour of data subjects as far as their behaviour takes place within the Union.

The operative phrase is "not established in the Union." Article 3(2) was written specifically to capture non-EU entities. A software company in Austin, a media publisher in Chicago, and an e-commerce retailer in Phoenix can each fall within GDPR's scope based entirely on how they process information about people who are physically in the EU at the time of that processing. This is the central insight US companies frequently miss: GDPR's jurisdictional hook is based on the location of the data subject at the time of processing, not the location of the company or its servers.

There is a second route into GDPR that applies regardless of Article 3(2). Article 3(1) captures controllers and processors who are established in the EU. This matters for US companies that have opened a branch office, a subsidiary, or even a stable sales arrangement in an EU Member State. If that EU establishment is involved in processing personal data, even if the actual data processing happens on US servers, Article 3(1) applies to that processing in the context of the EU establishment's activities. A US company with a German sales office, a French distribution subsidiary, or a Dutch customer-service team is likely to be covered under Article 3(1) for its EU operations independently of the Article 3(2) analysis.

The Article 3(1) establishment test comes from the CJEU's pre-GDPR jurisprudence in Google Spain v AEPD (Case C-131/12, 2014), which held that a US parent company's Spanish subsidiary constituted an EU establishment, bringing the parent's data processing activities under EU data protection law. The same logic applies under GDPR's Article 3(1).

The Two Article 3(2) Triggers: Targeting and Monitoring

Trigger 1: The Targeting Test Under Article 3(2)(a)

The first trigger applies when a US company is offering goods or services to data subjects who are in the Union. "Offering" requires an element of deliberate targeting. Recital 23 of GDPR draws the line explicitly: "The mere accessibility of the controller's, processor's or an intermediary's website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention."

In plain terms: a US company whose website is in English does not automatically target EU residents because English is widely spoken in Europe. The EDPB's Guidelines 3/2018 on Territorial Scope (Version 2.0, adopted 12 November 2019) elaborate on this boundary in detail. The EDPB identifies a non-exhaustive list of factors that, taken together or individually, indicate an intention to offer goods or services to EU data subjects.

Factors that indicate targeting under Recital 23 and EDPB Guidelines 3/2018:

• Using a language or currency generally used in one or more EU Member States alongside the ability to order goods or services in that language (for example, a product page in German with a shopping cart that accepts euros).
• Directly mentioning customers or users from the EU or specific Member States.
• Offering delivery options to EU Member State addresses.
• Using a country-code top-level domain for an EU Member State (for example, .de, .fr, .nl).
• Running paid advertising campaigns geo-targeted to EU Member States.
• Including EU-specific VAT information or displaying tax-inclusive pricing for EU jurisdictions.
• Providing a customer support pathway in an EU language or time zone.

Each of these factors is evidence of intent; none is automatically decisive on its own. The EDPB Guidelines acknowledge that a combination of factors increases the weight of the analysis. A US company that ships to EU addresses, accepts euros, and runs French-language Google Ads has accumulated three strong indicators of targeting.

Concrete examples where targeting almost certainly applies:

The key distinction is intent plus capability. Accessibility without targeting intent falls outside Article 3(2)(a). Targeted outreach or infrastructure built to serve EU users crosses the line.

Trigger 2: The Monitoring Test Under Article 3(2)(b)

The second trigger is behavioural monitoring. Recital 24 of GDPR explains that this covers tracking EU residents online, particularly the use of profiling techniques to analyse or predict personal preferences, behaviours, and attitudes. The monitoring trigger is broader than it first appears: it does not require intentional targeting of EU users. If your technical infrastructure collects individual-level data from people who happen to be in the EU and uses that data to make decisions about them, the monitoring trigger may apply independently of the targeting analysis.

The EDPB Guidelines 3/2018 emphasise that "monitoring" requires an element of tracking or following an individual's behaviour over time. A one-time collection of an IP address in an access log, without any profiling or follow-on use, is less likely to constitute monitoring. Persistent tracking through cookies, pixels, device fingerprinting, or cross-site tracking technologies typically does.

Activities that commonly trigger the monitoring test for US companies:

• Installing third-party advertising or retargeting pixels (Google Ads conversion tags, Meta Pixel, LinkedIn Insight Tag) on a website visited by EU users, where those pixels collect IP addresses and browsing behaviour to build audience segments.
• Running web analytics (including self-hosted analytics) configured to capture and retain individual-level IP addresses or device identifiers from EU visitors over time.
• Using a customer data platform (CDP) that stitches together EU users' browsing history, purchase patterns, and email-open data into a behavioural profile for downstream targeting or personalisation.
• Operating a mobile application that logs EU users' location data or in-app behaviour over time.
• Running a rewards or loyalty programme that tracks EU members' purchase history and sends targeted offers based on that history.
• Using a CRM enrichment tool that combines EU individual contact data with third-party behavioural signals.

A US company does not need to know that a specific user is in the EU for the monitoring trigger to apply. If the technology used collects individual-level data from EU residents and that data is processed to make decisions about them, the trigger is met. The EDPB explicitly notes that tracking the behaviour of data subjects "as far as their behaviour takes place within the Union" focuses on the location where the tracked behaviour occurs, not where the processing takes place.

The Scenario Table: Does GDPR Apply?

Article 27: The EU Representative Requirement

Once Article 3(2) pulls a US company into GDPR's scope, Article 27(1) imposes a structural obligation: the company must designate, in writing, a representative established in one of the EU Member States where the company's data subjects are located.

The EU representative's role is substantive, not ceremonial. The representative serves as the company's local point of contact for both data subjects and supervisory authorities. EU residents can exercise their GDPR rights (access, rectification, erasure, portability, objection) directly through the representative. Any EU data protection authority (DPA) may direct enforcement correspondence, administrative orders, and proceedings to the representative. Under Article 27(4), the designation does not relieve the controller or processor of any liability under the GDPR; the representative acts in addition to, not instead of, the US company.

The representative must be established (have a real presence, not just a registered address) in an EU Member State, not merely the EEA. This distinction matters: Norway, Iceland, and Liechtenstein have adopted GDPR as EEA states, and an EEA-only presence (for example, a representative in Norway) does not satisfy Article 27 for EU supervisory authority purposes, though the EDPB has noted in practice that EEA-based representatives are generally acceptable given EEA GDPR implementation. US companies should confirm with their legal counsel whether an EEA state qualifies for their specific situation.

The identity and contact details of the Article 27 representative must be disclosed in the company's privacy notice. Data subjects must be able to reach the representative. Commercial representative services exist in all major EU Member States specifically for this purpose; the cost is typically a few hundred to a few thousand euros per year, well below the fine exposure for missing the requirement.

The Article 27(2) Narrow Exception

Not every US company meeting Article 3(2) must appoint a representative. Article 27(2)(a) carves out processing that is simultaneously: (a) occasional (not routine or ongoing); (b) does not include large-scale processing of special-category data under Article 9(1) (health data, biometric data, genetic data, racial or ethnic origin, religious or philosophical beliefs, political opinions, trade union membership, sexual orientation, or criminal convictions); and (c) unlikely to result in a risk to the rights and freedoms of natural persons, taking into account the nature, context, scope, and purposes of the processing. Public authorities are also exempt under Article 27(2)(b).

This exception is narrow in practice. Most US companies running a website with advertising cookies, a marketing email list, a mobile app, or behavioural analytics will not qualify. Their processing is ongoing (not occasional) and involves persistent individual-level tracking. A US academic researcher who conducted a one-time anonymous survey of EU participants might qualify; a US SaaS company with a recurring EU customer base will not.

Failure to appoint a required Article 27 representative is a Tier 1 (Article 83(4)) fine violation, exposing the company to up to EUR 10 million or 2% of global annual turnover, whichever is higher.

GDPR and US State Privacy Laws: How They Interact

Many US companies subject to GDPR are also covered by US state privacy laws, principally California's Consumer Privacy Act (CCPA), as amended and strengthened by the California Privacy Rights Act (CPRA, effective 1 January 2023). The CCPA/CPRA regime and GDPR share conceptual DNA (both require privacy notices, data subject rights, and data-flow governance) but differ in several important ways that require distinct compliance work rather than a single unified programme.

Lawful basis vs. opt-out model. GDPR requires a lawful basis for every processing activity before processing begins (opt-in as the default). CCPA/CPRA uses a different model: processing is generally permitted but consumers have the right to opt out of the sale or sharing of their personal information. GDPR's consent standard under Article 7 requires freely given, specific, informed, and unambiguous indication of agreement; CCPA consent for sensitive data requires opt-in, but the general "sale/share" mechanism uses a prominent opt-out. A US company cannot satisfy GDPR's lawful-basis requirement simply by providing a CCPA opt-out mechanism.

Data subject rights scope. Both regimes grant rights of access, deletion, and portability. GDPR additionally provides the right to object under Article 21 and the right to restrict processing under Article 18, which have no direct CCPA/CPRA equivalent. GDPR also grants automated decision-making rights under Article 22 that go beyond CCPA's profiling opt-out.

Sensitive data definitions. CPRA added a category of "sensitive personal information" (SPI) with opt-in consent requirements for certain uses. GDPR's Article 9 special categories are similar but not identical. For example, CPRA includes government ID numbers, precise geolocation, and union membership as SPI; GDPR includes racial/ethnic origin, religious beliefs, and health data. A company must map its data types against both definitions separately.

Scope thresholds. CCPA/CPRA applies to for-profit businesses that meet one of three thresholds: annual gross revenues over USD 25 million; annually buying, selling, or sharing personal information of 100,000 or more consumers or households; or deriving 50% or more of annual revenues from selling or sharing personal information. GDPR has no revenue or volume threshold; any company that meets the Article 3(2) tests is covered regardless of size, subject to narrower obligations for smaller processors under certain articles.

Processor vs. service provider. GDPR's Article 28 uses the term "processor" for vendors who process data on a controller's behalf. CCPA/CPRA uses "service provider." Both require a written contract specifying the processing scope, but the contract terms required differ. A combined data processing agreement / service provider agreement that satisfies both is achievable but requires careful drafting.

Practical implication. A mid-size US company with EU users and California-based customers or employees should treat GDPR and CCPA/CPRA as two parallel compliance programmes with a shared data-mapping and vendor-management backbone, not as a single exercise. The audit steps overlap (data inventory, vendor contracts, privacy notice update, subject-rights workflow) but the substantive legal standards diverge at the lawful-basis and consent layers.

For the full comparison, see the GDPR vs. CCPA comparison guide.

EU-US Data Transfers: The DPF and the 2021 SCCs

When a US company receives personal data from an EU entity (a customer, partner, or vendor), a separate legal question arises: Chapter V of GDPR (Articles 44 through 49) requires a lawful transfer mechanism for personal data flowing from the EU to a third country, including the United States. The CJEU's Schrems II judgment (Data Protection Commissioner v. Facebook Ireland, Case C-311/18, 16 July 2020) invalidated the predecessor Privacy Shield mechanism, leaving a gap until the current DPF was adopted.

Two primary tools are now available.

The EU-US Data Privacy Framework (DPF)

On 10 July 2023, the European Commission adopted its adequacy decision for the EU-US Data Privacy Framework as Commission Implementing Decision (EU) 2023/1795, under GDPR Article 45(3). The adequacy decision concludes that the United States ensures an adequate level of protection for personal data transferred to DPF-certified US organisations. This means EU companies and individuals can transfer personal data to a certified US company without executing a separate transfer contract or conducting a Transfer Impact Assessment for that specific transfer.

The DPF is administered by the US Department of Commerce. A US company self-certifies annually to the Department of Commerce, committing to the seven DPF Principles: Notice, Choice, Accountability for Onward Transfer, Security, Data Integrity and Purpose Limitation, Access, and Recourse Enforcement and Liability. The certification is public: the Department of Commerce maintains a searchable list of certified organisations at dataprivacyframework.gov that EU companies can consult to verify a US partner's status.

Eligibility for DPF certification is limited to US organisations subject to the jurisdiction of the Federal Trade Commission or the US Department of Transportation. This covers most private-sector US companies. However, financial institutions regulated exclusively under the GLBA, telecommunications carriers subject to FCC jurisdiction, and certain non-profit organisations may not qualify. Any company that is unsure of its eligibility should confirm with the Department of Commerce or legal counsel before committing to DPF as its transfer mechanism.

Under the DPF adequacy decision, EU individuals whose data is transferred to a DPF-certified US company have four tiers of redress: (1) direct complaint to the certified organisation (which must respond within 45 days); (2) independent dispute resolution through one of the DPF-approved bodies; (3) binding arbitration through the DPF Panel for unresolved residual claims; and (4) the Privacy and Civil Liberties Oversight Board (PCLOB) for complaints about US government access to transferred data, a mechanism inserted specifically to address the national-security concerns that caused the CJEU to invalidate Privacy Shield.

The DPF's long-term stability faces ongoing legal scrutiny. The French data protection authority (CNIL) and others have noted that the structural differences between EU and US surveillance law remain, and future CJEU challenges are possible. The adequacy decision is subject to periodic review by the European Commission. US companies that want a transfer mechanism less dependent on a single adequacy decision's political durability should also execute 2021 SCCs as a belt-and-suspenders measure.

For detailed coverage of the DPF's litigation risk and the PCLOB mechanism, see the GDPR international data transfers guide.

2021 Standard Contractual Clauses

US companies that are not DPF-certified, or that prefer a contractual transfer mechanism, use the 2021 Standard Contractual Clauses established by Commission Implementing Decision (EU) 2021/914 of 4 June 2021. The 2021 SCCs replace the pre-GDPR 2001 and 2010 SCC decisions; those old clauses may no longer be used for new transfers.

The 2021 SCCs use a four-module structure that maps to different transfer relationships:

• Module 1 (Controller to Controller): The US company receives EU personal data from an EU controller and processes it for its own purposes. Example: a US data analytics firm receiving customer-segmentation data from an EU brand for independent analysis.
• Module 2 (Controller to Processor): The US company processes EU personal data strictly on behalf of an EU controller. Example: a US cloud hosting provider, email delivery platform, or marketing automation tool acting as a processor for an EU business.
• Module 3 (Processor to Sub-Processor): The US company acts as a sub-processor engaged by an EU processor. Example: a US data centre used by an EU cloud provider.
• Module 4 (Processor to Controller): The US company, acting as a processor, sends data back to its EU controller. This is the least common scenario.

Getting the module selection wrong is itself a compliance failure. A US company that receives EU data from an EU business partner must correctly characterise whether it is acting as a controller or a processor for that processing activity before executing the SCCs.

The 2021 SCCs also require the parties to complete a Transfer Impact Assessment (TIA), in which the US data importer assesses whether US law (including national security authorities such as FISA Section 702 and Executive Order 12333) conflicts with its SCC obligations. The importer must notify the EU exporter if it cannot comply with the SCCs and must agree to supplementary measures (encryption, pseudonymisation, contractual access restrictions) where US law creates a gap. Data subjects are third-party beneficiaries of the SCCs and can enforce the clauses against either party.

Binding Corporate Rules for Multinational Groups

A third transfer mechanism, Binding Corporate Rules (BCRs), is available to multinational corporate groups transferring data internally across borders. BCRs require approval from a lead DPA and take months to obtain. They are practical only for large multinationals with substantial ongoing intra-group cross-border transfers. For most US companies, DPF self-certification or 2021 SCCs are the operative choice.

GDPR Enforcement Against US Companies: Real Examples

GDPR Article 83 fines apply to non-EU companies on the same terms as EU-established entities. Several landmark enforcement actions directly involved US-headquartered or US-origin firms.

Meta Platforms (Ireland DPC, May 2023): The Irish Data Protection Commission (DPC) imposed a EUR 1.2 billion fine on Meta Platforms Ireland for transferring EU user data to Meta's US servers under SCCs, without adequate supplementary measures to address the US surveillance law gap identified in Schrems II. This is the largest single GDPR fine on record as of mid-2026 and involved a US-origin company with an EU establishment (Article 3(1) applied via the Irish subsidiary). The DPC also ordered Meta to suspend EU-US data transfers.

WhatsApp Ireland (Ireland DPC, September 2021): The DPC fined WhatsApp EUR 225 million for transparency violations, specifically for failing to provide EU users with sufficiently clear information about how their data was shared between WhatsApp and other Meta companies. This case was pursued under the one-stop-shop mechanism with Meta's EU establishment as the lead controller.

Amazon Europe (Luxembourg CNPD, July 2021): The Luxembourg National Commission for Data Protection fined Amazon EUR 746 million for processing EU users' behavioural advertising data without a valid lawful basis, specifically for the advertising targeting built around users' browsing and purchase histories. Amazon is a US company operating through EU entities; the CNPD acted as lead authority given Amazon's EU headquarters in Luxembourg.

Google LLC (France CNIL, January 2022): The CNIL fined Google LLC (the US parent entity) EUR 150 million for placing advertising cookies on users' devices without valid consent and for making the cookie refusal process more difficult than the opt-in process. This fine targeted the US parent company, not merely its EU subsidiary.

Google Ireland (Ireland DPC, multiple): The DPC has pursued multiple investigations against Google Ireland, covering analytics data retention and targeted advertising practices.

These enforcement actions demonstrate several points that US companies need to internalise. First, fines are assessed against the company as a whole, including US parent entities. Second, the mechanisms for enforcement against non-EU entities include directing enforcement through EU representatives and applying commercial pressure by ordering EU entities to suspend transfers to non-compliant US partners. Third, the one-stop-shop mechanism means that a US company's choice of EU establishment location determines which DPA leads cross-border investigations, and the Irish DPC and Luxembourg CNPD have become particularly active lead authorities for large tech companies.

The Full GDPR Compliance Checklist for US Companies

Establishing that GDPR applies is the gateway, not the finish line. A US company within Article 3(2)'s scope must satisfy the full stack of GDPR controller obligations:

Step 1: Appoint an Article 27 EU representative. Written designation, EU Member State presence, identity disclosed in the privacy notice. Exception: only if Art 27(2) narrow carve-out genuinely applies.

Step 2: Conduct a data mapping exercise. Identify every category of EU personal data processed, the purpose of each processing activity, the lawful basis relied upon, the retention period, and any third-party processors or recipients. This feeds the Article 30 records of processing activities.

Step 3: Establish lawful bases for every processing activity. Under Article 6(1), each processing activity must rest on one of six lawful bases: consent, contract, legal obligation, vital interests, public task, or legitimate interests (which requires a balancing test). Marketing activities typically require consent. Contract performance lawful basis applies when processing is necessary to perform a contract with the data subject. Legitimate interests requires a documented three-part test: the interest is legitimate, processing is necessary for it, and the data subject's interests and rights do not override.

Step 4: Update the privacy notice. The Article 13/14 information notice must disclose: identity and contact details of the controller and (if applicable) the EU representative; the purposes and legal bases for each processing activity; any third-country transfers and the mechanism used; retention periods; and the data subject's rights (access, rectification, erasure, restriction, portability, objection, and the right to lodge a complaint with a supervisory authority).

Step 5: Build a data subject rights (DSR) workflow. GDPR grants EU residents the right to access their data (Art 15), correct it (Art 16), erase it (Art 17), restrict processing (Art 18), receive a portable copy (Art 20), and object to processing (Art 21). Requests must generally be answered within one calendar month, with a possible two-month extension for complex requests. No charge is permitted for the first request each year.

Step 6: Conduct a cookie and consent audit. Most US company websites deploy advertising and analytics cookies that require valid GDPR consent (freely given, specific, informed, unambiguous, and as easy to withdraw as to give) before activation. The EDPB and multiple DPAs have confirmed that pre-ticked boxes, bundled consent, and "consent walls" (requiring consent to access the site) do not satisfy GDPR consent. A compliant consent management approach requires a layered notice with granular opt-ins and a mechanism to withdraw consent at any time.

Step 7: Execute Article 28 processor agreements. Every vendor or sub-contractor that processes EU personal data on the company's behalf (cloud storage, email delivery, CRM, analytics, support tools) requires a written data processing agreement under Article 28(3) specifying the processing scope, instructions, security obligations, sub-processor rules, audit rights, and return-or-delete obligations at contract end.

Step 8: Choose a data transfer mechanism. If the company receives EU personal data from EU entities or individuals, verify whether the company is DPF-certified or whether 2021 SCCs are in place for each relevant transfer relationship.

Step 9: Establish a breach notification procedure. Article 33 requires notification to the competent supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to natural persons. The 72-hour clock begins when the company's internal team becomes aware of the breach, not when the forensic investigation is complete. A preliminary notification can be submitted within 72 hours with further details to follow.

Step 10: Assess whether a Data Protection Officer (DPO) is required. GDPR Article 37 requires a DPO for: public authorities; companies whose core activities require large-scale, regular, and systematic monitoring of individuals; and companies whose core activities involve large-scale processing of special-category data (health, biometric, genetic, criminal). Most US companies engaged in standard SaaS, e-commerce, or professional services will not meet the DPO threshold, but companies operating large-scale ad-tech, health tech, or HR analytics platforms should assess carefully.

Step 11: Conduct Data Protection Impact Assessments (DPIAs) where required. Article 35 requires a DPIA before commencing any processing likely to result in high risk to natural persons, including large-scale profiling, systematic monitoring of publicly accessible areas, and processing of special-category data at scale.

Step 12: Maintain Article 30 records of processing activities. Controllers must maintain a written record of all processing activities, available to supervisory authorities on request. The Article 30(5) exception for companies with fewer than 250 employees is narrow and does not apply if processing is ongoing, poses risks to data subjects, or involves special-category data.

Disclaimer: This article presents general legal information about GDPR's territorial scope and its application to US-based companies. It is not legal advice and does not create a lawyer-client relationship. GDPR compliance determinations are fact-specific and depend on how your organisation processes personal data. Consult a lawyer or data protection professional licensed in your jurisdiction for advice on your specific situation. Information verified as of June 2026.