Is GDPR Applicable in the US? What the Evidence Shows

"Is GDPR Applicable in the US" gets answered badly from both directions. One camp treats any US company with a website as caught by GDPR because the internet is global. The other treats a US-incorporated company with US servers as automatically outside EU law. Article 3 of the Regulation settles this more narrowly than either camp allows: it applies to a US company's processing when that company offers goods or services to people in the EU, or monitors their behaviour, regardless of where the company is based or where its servers sit. This article works through what Article 3 actually requires, then checks what US vendors publish, Data Privacy Framework enrollment, EU representative disclosures and data processing agreements, to see which ones evidence that reach rather than just asserting it either way.

What Article 3 actually says about reach beyond the EU

Article 3(1) covers the easy case: a controller or processor established in the EU is bound by the Regulation for processing carried out in the context of that establishment, full stop. Article 3(2) is the part that catches US companies with no EU office at all. It applies the Regulation to a controller or processor not established in the Union when the processing relates to either of two things: offering goods or services to data subjects in the Union, or monitoring the behaviour of data subjects in the Union, as long as that behaviour takes place within the Union. Nothing in Article 3(2) asks where the company is incorporated, where its servers are, or whether it has ever signed a contract with an EU entity.

This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the monitoring of their behaviour as far as such behaviour takes place within the Union.
— Regulation (EU) 2016/679, Article 3(2)

The two triggers that catch a US vendor

The offering test does not require a sale. A free tier, a waitlist form or a marketing page aimed at an EU audience can count if the company shows an intention to target that market. Guidance from supervisory authorities points to practical signals rather than a single bright line: pricing in euros, a domain like .de or .fr, languages other than the vendor's home market, testimonials from EU customers, or shipping and support that explicitly reach EU countries. The monitoring test is separate and catches a different group of vendors, mostly ones running analytics, advertising, fraud scoring or behavioural profiling on visitors physically located in the EU, whether or not those visitors ever become paying customers.

A US SaaS company with a localised pricing page in euros and testimonials from Berlin or Dublin customers
A US ad-tech or analytics vendor running cookies, pixels or device fingerprinting on EU visitors
A US company with an app store listing translated into French or German and support hours covering CET
A US vendor whose free tier signup form collects an EU billing address without blocking it
A US company running A/B tests or behavioural scoring on traffic it knows originates in the EU

Flowchart showing the two Article 3(2) triggers, offering goods or services and monitoring behaviour, that bring a US vendor inside GDPR's territorial scope — Two separate tests decide reach: targeting an EU market, or watching EU behaviour.

Being in scope of Article 3(2) is not the same as having a seal, a badge or a certificate to show for it. The phrase "GDPR certified" is wrong in the same way "SOC 2 certified" is wrong: there is no accreditation body issuing certificates against the whole Regulation, and Article 42's certification mechanisms, where they exist at all, cover narrow processing operations, not a company-wide status. A vendor that is correctly in scope under Article 3(2) can still have no public evidence of how it handles that scope, and a vendor with glossy "we take privacy seriously" copy can still be in breach of obligations it has never evidenced anywhere. What the Regulation actually asks of a vendor and what a vendor can actually show you are two different documents worth separating before a buyer takes a claim at face value.

The evidence a US vendor can actually publish

Three artifacts show up in public vendor pages and trust centres and each does a different job. The first is enrollment in the EU-US Data Privacy Framework, the US Department of Commerce programme that lets a company self-certify adherence to a set of privacy principles recognised under the European Commission's adequacy decision for transfers. How the framework fits into a vendor review matters because DPF enrollment is a transfer mechanism and an FTC-enforceable commitment, not a substitute for the vendor's underlying GDPR obligations as a controller or processor.

The second artifact is an EU representative, required under Article 27 for any non-EU company that falls within Article 3(2) scope and has no EU establishment. The representative is a named contact, acting on the company's behalf for supervisory authorities and data subjects, and its absence on a privacy page is itself a data point: either the company has decided Article 3(2) does not apply to it, or it has not got round to the paperwork.

The third artifact is the data processing agreement, usually paired with Standard Contractual Clauses for the transfer leg, and the subprocessor list sitting underneath it. Checking a vendor's subprocessor list tells a buyer which downstream companies actually touch the personal data the main vendor collects, which matters more than the headline claim once a contract is signed.

Evidence type	What it shows	What it does not show
DPF enrollment (active)	A Commerce Department self-certification against listed privacy principles, FTC-enforceable	That the company's internal GDPR controller or processor obligations are met
EU representative named (Art. 27)	The company has acknowledged Article 3(2) scope and appointed a contact	Any record of how the company actually handles data subject requests
Public DPA with SCCs	Contractual terms for a transfer mechanism, usually downloadable without a sales call	A signed version specific to a given buyer's contract
Subprocessor list	Which downstream vendors handle the data and for what purpose	That every subprocessor itself holds equivalent evidence

None of these artifacts alone proves compliance, but each narrows what a buyer still has to ask.

Comparison graphic of DPF enrollment, EU representative disclosure and data processing agreement as three distinct pieces of GDPR evidence — Three artifacts, three different jobs: a transfer mechanism, a contact, and a contract.

Checking the registry, not the homepage

A vendor's own marketing page is the worst place to check DPF status, because enrollment can lapse, go inactive or never have existed in the form the copy implies. The Data Privacy Framework registry mirror tracks what the Department of Commerce's own list actually says, which is the only authoritative source for whether a given company's participation is current. A row that shows active enrollment next to a current EU representative and a downloadable DPA is a materially different claim from a homepage sentence that says "we comply with GDPR" and stops there.

2
Article 3(2) triggers: offering goods or services to EU data subjects, or monitoring their behaviour in the Union; 0
GDPR certification schemes company-wide: Article 42 certification covers narrow processing operations, not a blanket seal; 3,000+
vendor pages cross-referenced against registries: DPF, FedRAMP, CSA STAR and Visa PCI mirrors checked against public claims, in the CertReports index on 2026-10-02

What this looks like on one vendor's page

Notion is a useful case because its public record shows a DPF listing sitting alongside a published DPA and a long subprocessor list, so a buyer can compare a registry status against the contractual artifacts it is meant to support rather than against a single marketing line. Look at whether the DPF row and the DPA date line up, and whether the subprocessor list is specific enough to name the companies actually handling the data.

Notion · Trust report

Collaboration · Public evidence as of 12 Oct 2026

Visit trust centre Full evidence

Framework overview

CertReports state for each framework with public evidence: 11 vendor-stated, 1 expired.

3 more frameworks on the evidence page

3Documents and agreements

Legal and review documents Notion publishes or offers, as of 12 Oct 2026.

26Subprocessors

Named on Notion's public subprocessor list, last seen 12 Oct 2026.

Amplitude
Anthropic
AWS
BABaseten
CSCerebras Systems Inc.
Cloudflare
Confluent
Customer
and 18 more on the evidence page

A DPF status row sitting next to a public DPA and subprocessor list, not next to a marketing claim. Every line is a dated public record from Notion's trust centre and the Data Privacy Framework list. A framework not shown means no public evidence was found, not that Notion lacks it.CertReports

A seven-step check a buyer can run in ten minutes

1
Map the vendor's own EU exposure
List whether the vendor sells, markets, or runs analytics against EU-based users, including free tiers and trial signups.
2
Search the DPF registry mirror
Check the vendor's current status directly rather than trusting a badge on their own site.
3
Look for a named EU representative
Check the privacy or legal page for an Article 27 representative, not just a generic contact form.
4
Pull the DPA without a sales call
A DPA that requires a call to see is a weaker signal than one posted as a PDF.
5
Read the subprocessor list for specificity
Named companies and purposes are stronger evidence than a generic reference to service providers.
6
Compare dates across artifacts
A DPF listing, a DPA version date and a subprocessor list update should not be years apart from each other.
7
Treat silence as a finding
No EU representative and no DPA on a vendor that clearly targets EU users is itself a data point worth raising in a review, not a gap to fill in with assumption.

Common misreadings worth correcting

"GDPR is only for companies based in Europe": wrong, Article 3(2) exists specifically to catch non-EU companies
"Our company has no EU office, so GDPR cannot apply": wrong for the same reason, establishment is irrelevant under 3(2)
"DPF enrollment proves GDPR compliance": wrong, DPF is a transfer mechanism recognised under an adequacy decision, its legal status has itself been litigated and appealed, and it says nothing about a company's wider controller obligations
"If we don't have an EU representative, we must be out of scope": backwards, Article 27 is a consequence of being in scope, not a gate that determines it

Is GDPR Applicable in the US? What the Evidence Shows

What Article 3 actually says about reach beyond the EU

The two triggers that catch a US vendor

The evidence a US vendor can actually publish

Checking the registry, not the homepage