Does GDPR apply to US businesses that don’t sell to Europe?

A US business may need to consider GDPR even if it does not sell to Europe—but a visit from Europe does not automatically put the whole business in scope. The useful questions concern your establishment, whom you offer services to, and whether you monitor people's behavior in the EU.

The website scenarios and consent demo use fictional examples. They can help plan a review, but do not determine any business's legal obligations. Sources were checked on October 22, 2026.

Does GDPR apply to US companies without EU sales?

The European Commission's application guidance identifies two main routes relevant here: processing connected to an EU establishment, and certain processing by a business outside the EU that offers goods or services to people there or monitors their behavior there. Services can be free; a completed European sale is not the threshold.

GDPR Article 3 ties the non-EU targeting route to the relevant processing of people in the Union. It is not a citizenship checklist. For Article 3(2), an EU passport holder in California is outside the Union; a US visitor in France is in it. Location alone still does not establish an offer or monitoring trigger.

An EU visit count does not settle scope. Review what the processing is for and whether it leads to profiling; sales location alone is not enough. Monitoring does not require an intention to target the EU. EDPB territorial-scope guidance.

Europe is not one legal jurisdiction. The GDPR also applies in the EEA countries Iceland, Liechtenstein and Norway; include them in the scope review. The examples below use EU locations. EDPB small-business scope guidance.

Four website scenarios to assess

1. Someone abroad reads a local US contractor’s website

A California contractor advertises local jobs, has no EU establishment, offers its service only in its US service area, and does not profile people in the EU. Someone traveling in France reads its public pages.

Availability alone does not establish targeting. Review the offer and tracking facts. EDPB guidance.

2. A free US webinar is marketed to people in France

A US training company runs ads aimed at people in France and invites them to register for a free webinar. Its registration form collects names and email addresses. There is no shopping cart and no European revenue.

The deliberate offer of a free service is a reason to assess GDPR scope for the registration and follow-up processing. Check campaign targeting, landing-page wording, registration destinations and email-list segmentation. Charging nothing does not resolve the question.

3. A US-only store profiles EU visitors

A store ships only within the US, but its site records identified visitors' product views across sessions to infer interests and build retargeting audiences. Those flows monitor people’s behavior while they are in the EU.

Assess the monitoring route: checkout restrictions do not settle profiling or subsequent analysis. “Analytics” alone does not identify the activity. EDPB monitoring guidance.

4. A US company has an EU operation

A US firm opens a stable EU operation that generates leads, and its US CRM processes those leads in connection with that operation. Hosting the CRM in the US does not remove the establishment question.

Review how the processing relates to the EU operation; an employee’s location alone does not settle that connection. EDPB establishment analysis.

GDPR and cookie consent are related, but separate questions

GDPR governs relevant personal-data processing. Cookies, local storage, pixels and other access to a person's device also need a review under applicable ePrivacy and national rules. Calling everything “GDPR cookies” can hide that distinction.

France's CNIL explains the national device-access rule and consent exceptions; its audience-measurement guidance describes a narrowly conditioned exemption. That is not a worldwide exemption for anything labelled analytics. A vendor's configuration, reuse of data and cross-site tracking can matter.

GDPR has several possible legal bases. Where consent is the chosen basis, it needs a valid choice and a usable way to withdraw; a blanket “I accept the privacy policy” checkbox is not a substitute for deciding the purpose and basis of each activity. GDPR Articles 6 and 7, EDPB consent guidance.

UK GDPR and the UK's PECR rules need separate assessment. The EU answer should not be copied into a UK or US-state policy without reviewing those rules. ICO storage and access guidance.

A real technical example: the banner looks right, but the request already ran

We built a local consent-check demo source download for the fictional Northstar Garden Supply shop. Both versions show privacy choices. The difference is what the code permits.

In the before version, the optional sample request starts during page initialization before a choice. Pressing Reject changes the displayed choice, but another test action still sends a request. A reassuring banner is not evidence that a tag is controlled.

View full-size screenshot

In the after version, an undecided or rejected state blocks the request. Accepting changes the permission state; it does not itself send an event. A subsequent test action reads the sample. Withdrawal blocks future requests again.

View full-size screenshot

These are actual browser captures from runnable code. Requests read a bundled JSON file on the same loopback server, using fixed synthetic values and no credentials. The demo uses no real analytics provider, cookie, identifier, persistent consent record or personal value. It demonstrates request gating; it is not a complete consent platform or evidence of how a live vendor behaves.

Make the permission check part of the request path

The repaired view's request handler checks consent before constructing or fetching the local sample:

if (!controller.canSendOptional()) {
  return; // Block before starting the optional request.
}
await fetch(sampleEventUrl(), { credentials: 'omit', redirect: 'error' });

The complete request handler validates the same-origin response and fixed JSON. In production, identify every loading and sending path: a tag-manager trigger, a hardcoded script, an app embed and a server-side event can bypass a check that exists in only one place.

Withdrawal cannot recall a request already sent. It also needs production work beyond this in-memory example: stop applicable future processing, update vendor state, and handle stored identifiers and records according to the applicable requirements. The demo has no identifier to delete and resets when reloaded. EDPB consent guidance.

What to check on your actual website

Start with the business facts

Record any EU establishment, intended service areas, shipping destinations and country-targeted campaigns. Include free downloads, courses, newsletters and account services. Review what the offer and campaigns do together rather than treating one translated page or currency setting as a complete answer.

Then identify the processing: which information is collected, from whom, for which purpose, by which system and in which role. The establishment, targeting and monitoring questions should be reviewed against those facts before a developer is asked to implement a jurisdiction policy.

Inspect loading, requests and storage

Start a fresh test session and open the browser's Network and Application panels before interacting with the page. Chrome's Network documentation explains request inspection; the Application panel shows cookies and other browser storage.

Run a defined test sequence:

• Load the site without choosing. Record the vendor endpoints and storage created.
• Reject optional categories. Navigate to another page and perform a representative action.
• Start a fresh session, accept a category, and repeat the action.
• Withdraw that permission and repeat it again.
• Check important variants: product pages, signup forms, video/maps, checkout handoffs and app embeds.

Compare observed behavior with the policy that applies to each purpose and region. If the policy requires a tag to wait, verify that it actually waits. Check cookies and non-cookie requests/storage; no cookie in the list does not prove that nothing was disclosed. Record endpoint, trigger, category, owner and evidence for each unexpected flow.

Browser inspection cannot expose every server-to-server event or a vendor's downstream processing. Add tag-manager/server configuration, app settings and vendor documentation to the review. A location override in a browser is not a full substitute for testing a real regional configuration.

Follow forms past the submit button

Take a sample inquiry or signup through its destinations: mailbox, CRM, newsletter platform, support desk and any app connection. Use authorized synthetic test data, not a real customer record. Check who can access it, which fields are needed, how long it is retained and what happens when a correction or deletion request is received.

For in-scope processing, purpose, data minimization and storage limitation are part of the review. GDPR Article 5. In practice, ask whether a general contact form really needs a birth date or full street address, and whether a requested reply is being silently turned into an unrelated marketing signup. Removing a field from the page is incomplete if an integration still copies the same information elsewhere.

Match the notice to the implementation

Compare the privacy and cookie disclosures with the actual system inventory. A notice mentioning one analytics tool is incomplete as an operational record if the current template or app loads additional advertising, video or chat services. Assign an owner to approve changes when a vendor or purpose changes.

A US provider processing for an in-scope controller may need Article 28 contract terms. That contract alone does not put every provider activity directly in territorial scope. Review each role and activity. Commission role guidance, EDPB guidance.

What should the first review deliver?

A first review should leave you with a processing inventory, unresolved applicability questions, a vendor/tag map, and evidence from before a choice, after rejection, after acceptance and after withdrawal. Give each issue an owner, a proposed change and a retest method.

“We don't sell to Europe” is one business fact, not the full assessment. A single foreign visit does not answer the establishment, targeting, or monitoring questions either. Assess those facts before choosing a site-wide policy, then test whether the website and connected systems enforce it.

dirango provides cookie-consent implementation and monthly audits and website governance for technical setup and ongoing ownership. Use the project form to share the business, intended markets, site platform and systems for review.

For US-state opt-out controls, see California, state cookie requirements and Global Privacy Control, with a separate working GPC demonstration.