GDPR for US Businesses: When It Actually Applies

Last updated: 09/17/2026
Compliance
GDPR for US Businesses: When It Actually Applies

GDPR applies to a US business when it has an EU establishment, offers goods or services to people in the EU, or monitors their behavior. Where the person sits decides it, not where your company does.

Your headquarters isn't the trigger. It's where the person is standing when you collect their data, and whether you went looking for them. That distinction decides whether this turns into real compliance readiness work or a two-page memo you file and forget.

A support inbox gets an email from a Berlin address. The sender wants a copy of everything you hold on them, and they've cited an article number. Your company has no office in Europe, no European customers anyone can name, and nobody on staff who has ever read Article 15.

So does it apply?

Sometimes. GDPR for US businesses isn't a company-level question. The honest answer depends far less on your business than on which specific things you do with data, and that's where most US companies start in the wrong place. They go looking for a yes or no verdict on the entire operation. The regulation was never written to give one.

Does GDPR Apply to US Businesses?

Data flowing from a US server to a person located in the European Union

Yes, if you have an EU establishment, offer goods or services to people in the EU, or monitor their behavior online. No, if none of the three is true. Citizenship is irrelevant.

Article 3 sets the territorial scope, and it uses one phrase that does most of the work. Data subjects who are in the Union. Not EU citizens. Not EU nationals. People physically located there at the moment the processing happens. Physical location. That's it.

Flip it around and the rule gets easier to hold onto. A French citizen who moved to Cleveland and buys from your online store is outside Article 3(2), because they aren't in the Union. An American expat living in Lisbon who buys the same thing is inside it. Same product, same transaction, same server in Virginia. Different answer, because the two people are standing in different places. Same company either way.

That's the part that catches finance and legal teams off guard, because every other compliance framework they've dealt with keys off the company. SOC 2 looks at your controls. PCI DSS looks at your cardholder data environment. CMMC looks at your contract. GDPR looks at a stranger's physical location, which is not a thing you control and often not a thing you know. If you're working through which standards apply to you, this one belongs in a separate column from the rest.

Worth saying plainly, since the overlap confuses people. GDPR and California's rules are separate regimes with separate triggers, and being ready for one does not get you the other. We've covered where CCPA and GDPR overlap elsewhere.

The Two Doors GDPR Comes Through

There are exactly two. Article 3(1) catches you through an establishment in the EU. Article 3(2) catches you through what you do to people who are there.

US companies tend to assume door one means a registered subsidiary with an office lease and a local tax ID. It doesn't. The test is whether you have stable arrangements in a member state, and a single salesperson working from an apartment in Munich with a company laptop and a quota can satisfy it. One person. No lease, no entity, no VAT number.

Table comparing GDPR Article 3(1) establishment and Article 3(2) targeting triggers

Door two splits into offering and monitoring, and the second one is where US companies get surprised. Selling nothing in Europe is not a defense against the monitoring limb. An ad pixel can do it on its own. No sale required.

When GDPR Does Not Apply to Your Company

Paragraph 42 of the European Data Protection Board's Guidelines 3/2018 on territorial scope draws the boundary from the other side.

the mere accessibility of the controller's, processor's or an intermediary's website in the Union, the mention on the website of its e-mail or geographical address, or of its telephone number without an international code, does not, of itself, provide sufficient evidence to demonstrate the controller or processor's intention to offer goods or a services to a data subject located in the Union.

Read that twice. Your website being reachable from Portugal is not targeting. Publishing your phone number is not targeting. Someone in Amsterdam finding you through organic search, filling out a form, and buying something once is not, by itself, targeting either. The test in Recital 23 is whether you envisaged offering to people in the Union, and the factors that show intent are concrete. Currency. Language. Shipping options. Paid referencing aimed at Union consumers. A top-level domain that isn't yours. None of that is accidental.

So take a 140-person metal finishing shop in Ohio that sells to US defense primes. English-only site, .com domain, USD invoicing, no EU shipping, no ad platform pixels beyond a pageview counter. GDPR almost certainly does not apply to that company, and it should spend its compliance budget on CMMC instead. Telling them otherwise would be a waste of their money.

Analytics deserve a caveat. Paragraph 56 of the same guidance says monitoring requires that the controller has a specific purpose in mind for collecting and reusing data about someone's behavior in the EU. Counting pageviews in aggregate is a weak fit for that. Building a profile that follows an individual across sessions to decide what ad they see is a strong fit. The gap between those two sits inside your tag manager, not inside your business model, and most companies have never looked. Not once.

GDPR Applies to Activities, Not to Companies

Paragraph 7 of the EDPB guidance quietly rescopes this entire project. A controller or processor, it says, "may be subject to the GDPR in relation to some of its processing activities but not subject to the GDPR in relation to other processing activities."

Your company is not in scope. Specific things you do are.

That matters on a practical level, because it's the difference between a remediation plan that touches every system you own and one that touches four. A US manufacturer with a German distributor relationship might be in scope for the contact data of that distributor's staff and out of scope for its entire US payroll, its shop floor systems, and its customer list. Same company. Two answers. The work is to draw the line accurately, which starts with knowing what data you hold and where it sits, and most organizations discover they've never actually mapped it.

What About Your EU Employees and B2B Contacts?

One employee in the EU puts that employee's data in scope. Not your whole HR system necessarily, but their record, their reviews, their monitoring, and anything you collect about them.

Send one engineer to work out of Lyon for a year and you've created a processing activity governed by European law, run by an HR team in Dallas that has never heard of a lawful basis. The record gets stored in Workday. Somebody runs a background check. Somebody else enables device monitoring on the laptop. Each of those is a processing activity that now needs a legal footing under Article 6, documented before the fact rather than reconstructed after a complaint. Three activities. One employee.

And the obvious lawful basis, the one every US company reaches for first, is the one you can't use. Consent requires a free choice. European regulators have held for years that an employee can't freely refuse their employer, so consent obtained in an employment relationship is usually invalid on its face. You're left with contractual necessity, legal obligation, or legitimate interest, and legitimate interest requires a documented balancing test that somebody has to sit down and write.

B2B contact data trips people the same way. A work email at a company domain is still personal data if it identifies a person, and there's no B2B carve-out in the GDPR the way US state laws have carved one out at various points. Your sales team's prospecting list of named contacts at EU firms is personal data. It always was.

Do You Need an EU Representative?

Yes, when Article 3(2) applies and you have no EU establishment. Article 27 makes it mandatory, in writing, with only two narrow exemptions. Most US companies in scope have never done it.

Read the exemptions closely rather than assuming you fit one. Article 27(2) lets you skip the representative if the processing is occasional, isn't large-scale special category or criminal conviction data, and is unlikely to result in a risk to people's rights and freedoms. All three conditions, together. Not any one of them. Ongoing ecommerce sales to EU consumers are not occasional. The second exemption covers public authorities, which you aren't.

Where the representative sits is also specified, and this catches companies that appoint one in Ireland out of habit because that's where their SaaS vendors are. Article 27(3) says the representative must be established in a member state where your data subjects actually are. Selling into Germany and Spain and appointing a rep in Dublin doesn't follow the text. Convenient, but wrong.

Search for the Article 27 penalty and you'll be told EUR 20 million or 4% of global turnover. That's the wrong tier. Article 83(4) covers breaches of Articles 25 through 39, and Article 27 sits inside that range, which puts the ceiling at EUR 10 million or 2% of worldwide annual turnover, whichever is higher. Still a serious number. Half the one you were quoted, though, so check it against the regulation text before it lands in a board deck.

A representative is also not a liability shield. Not a buffer, either. Appointing one doesn't transfer your obligations to them, and it doesn't stop a regulator from coming after you directly. What it does is give data subjects and supervisory authorities somebody in their own jurisdiction to write to, which is also why appointing one is a fairly reliable way to start receiving requests you weren't getting before. Treat it the way you'd treat any other outside party with access to your processes, which is to say inside a real vendor risk program rather than as a line item somebody renews by email.

How EU Regulators Actually Reach a US Company

A regulatory decision travelling from a European authority to a US company

Through fines that block deals, through your EU customers' own regulators, and occasionally through assets. Distance helps less than US executives assume, and the assumption is usually the whole risk model.

Clearview AI is the case to know, because it removes every excuse at once. US company. No EU office. Never sold its facial recognition service to a European customer. The Dutch data protection authority fined it EUR 30.5 million in a decision announced in September 2024, with periodic penalty payments on top that could exceed EUR 5 million more. The jurisdictional hook wasn't sales or establishment. As Pinsent Masons noted in its analysis, the authority found the processing fell within territorial scope because it amounted to monitoring the behavior of people in the EU. Scraping was the activity. That was enough.

Enforcement stopped being theoretical a while ago. CMS's Enforcement Tracker Report for 2025/2026 records about EUR 6.11 billion in fully documented fines across 2,685 cases, which is 440 more fines and EUR 487.6 million more money than the edition before it. Roughly EUR 1.2 billion of that landed in the most recent twelve months. The pace is no longer climbing toward something. It arrived.

Collection is the part people ask about, and it's a fair question. A Dutch regulator cannot send a marshal to Torrance. True enough. What it can do is register the fine, publish the decision, and let the practical consequences accumulate. An unpaid GDPR penalty is a procurement problem the first time an EU enterprise buyer's vendor questionnaire asks about regulatory actions. It's a diligence finding in your next funding round or acquisition. And if you ever open that Munich sales office, the liability is waiting for you when you get there.

What's Changing in 2026, and What Isn't Yet

Two things are genuinely in motion. Neither has changed the law you have to follow today, and the distinction matters because a lot of the coverage reads as though both are settled.

Start with the EU-US Data Privacy Framework. It survived its opening court challenge when the General Court dismissed the Latombe case on September 3, 2025 and upheld the Commission's adequacy decision. Then it got appealed to the Court of Justice on October 31, 2025, docketed as Case C-703/25 P, with no hearing date announced as of this writing. Two previous transatlantic transfer frameworks have already been struck down at that court. Two for two so far. If you're relying on DPF self-certification as your only transfer mechanism, keeping standard contractual clauses drafted and ready is the cheap insurance, and it costs you nothing if the appeal fails.

The second is the Digital Omnibus package the Commission put forward on November 19, 2025. For a mid-market US company the interesting pieces are the proposal to raise the record-keeping exemption from 250 employees to 750, which the EDPB and EDPS broadly welcomed, and a proposal to stretch the breach notification window from 72 hours to 96. As of September 2026 the GDPR pieces are still being negotiated in Council and Parliament. Not law. Meanwhile California keeps tightening its own rules on a separate clock, so a US company with exposure on both sides is tracking two moving targets rather than one. Don't plan against either set of proposals, and specifically don't let anyone tell your team the breach clock is 96 hours, because Article 33 still says 72.

What to Actually Do in the First 30 Days

Nobody needs a 40-page gap assessment to answer the threshold question. You need to know which of four situations you're in, and each one has a different first move.

Table of four US company scenarios and the first GDPR step for each

Nothing on that list is a software purchase. No platform. No scanner. No portal. The first 30 days of this work is people reading contracts, reading tag configurations, and writing down what they find, and software doesn't do any of that for you. It's the same unglamorous groundwork that sits under any information security compliance program, regardless of which framework put you there. Where outside help earns its keep is in scoping, because a privacy advisor who has drawn these lines before will get to the right answer in days rather than the months an internal team spends circling it. That's the work behind a virtual Chief Privacy Officer engagement, and it's advisory. Nobody certifies you GDPR compliant, and any provider who offers to should be your last call rather than your first.

Before You Spend Anything

Consilien is a security-first managed IT and compliance readiness firm working with companies between 20 and 1000 users, nationwide, across manufacturing, distribution, professional services, and real estate. Compliance readiness is a standalone offering here rather than something bundled into a managed IT contract, which matters on a topic like this one, because the scoping question in front of you is a governance question and not a helpdesk ticket.

If you can't answer which of those four rows you're in, that's the thing to fix this month, and it's a conversation rather than a project.

What US Companies Keep Asking About GDPR

We have zero European customers. Can we stop reading?
Probably, but check the pixel first. Offering goods and services is only one of the two triggers in Article 3(2). Behavioral tracking of people in the EU is the other, and it doesn't require you to sell them anything. Clearview AI had no EU customers at all and still collected a fine of EUR 30.5 million on the monitoring limb. Run through your ad platforms and tag manager before you file this away. Whether you're clear rides on what those are doing, not on the customer list.
Does GDPR cover EU citizens who live in the United States?
No. Article 3(2) is written around data subjects who are in the Union, which is a geography test rather than a nationality test. A German citizen who lives in Austin and shops on your US site is outside it. Their cousin in Hamburg buying the same thing is inside it.
One remote employee in Portugal. Are we in scope?
For that employee's data, almost certainly. A person working regularly from a member state can amount to a stable arrangement under Article 3(1), and the arrangement doesn't need a legal entity or an office behind it. What surprises US HR teams is the lawful basis problem rather than the scope question. You can't lean on consent, because European regulators treat consent between employer and employee as compromised by the power imbalance, so you're documenting contractual necessity or legitimate interest instead. That's a form somebody has to fill out before the processing starts, not after.
Isn't an EU representative just a mailbox we can buy for a few hundred dollars?
The service is commoditized, sure. The obligation isn't. Article 27 requires the designation in writing, requires it in a member state where your data subjects actually are, and doesn't shift any liability off you when you make it. Appointing one also tends to increase the volume of data subject requests you receive, because you've just published a contact point in the reader's own country. Budget for handling those, not only for the retainer.
72 hours or 96 for a breach?
72. Article 33 hasn't moved. The 96-hour figure comes from the Digital Omnibus proposal the Commission published in November 2025, which was still in negotiation between Council and Parliament as of September 2026. Proposals aren't law, and building an incident response runbook around one is how a team ends up two days late on a real notification, which is its own line item in what a breach ends up costing.
If we're already SOC 2, how much of GDPR do we get for free?
Some of the security controls, almost none of the privacy obligations. SOC 2 asks whether you protect data well. GDPR asks whether you had a lawful reason to collect it, whether you told the person, whether you can hand it back within a month, and whether you can delete it on request. Those are different questions with different evidence, and the overlap sits mostly in access control, encryption, and vendor management. A clean SOC 2 report is genuinely useful here. It just isn't a shortcut to the parts of GDPR that trip US companies up.

Related Articles

Stay ahead with expert tips, industry trends, and actionable strategies.