Who Is Subject to GDPR?

Who Is Subject to GDPR?

Here's a common misconception worth clearing up first: just having a website that EU visitors can access doesn't put you under GDPR. Regulators have said this explicitly. What actually matters is whether you're intentionally targeting people in the EU — and there's a real, specific set of factors used to figure that out.

The Two Roles GDPR Covers

Controllers decide why and how personal data gets processed. Processors act on a controller's instructions, handling data on their behalf. Both roles are covered by GDPR, with different obligations attached to each.

It Doesn't Matter Where You're Based

This is the part that surprises a lot of non-EU companies: GDPR doesn't care where your business is headquartered. If you're processing the personal data of people physically in the EU or EEA, you can be on the hook for GDPR even if you've never set foot there. What matters is whether one of two triggers applies.

Trigger 1: Offering Goods or Services to People in the EU

This applies whether or not money changes hands — a free app counts just as much as a paid one. The real test is whether you're actually trying to reach EU customers, not just whether an EU resident happens to find you.

Here's where the EDPB has been explicit: a website being technically reachable from the EU, having an email address, or even using a language that happens to be common in the EU isn't enough on its own. What actually signals intent to target EU customers:

• Using a language specific to an EU country (not just a widely-spoken one like English)

• Pricing in euros or another EU currency

• Naming specific EU countries in your marketing

• Offering shipping to EU addresses

• Using an EU country-specific domain (like .de or .fr)

• Mentioning existing customers or users based in the EU

• Running ads targeted at EU audiences

The EDPB's own guidance uses a clean example of what doesn't count: a Swiss university that only accepts payment in Swiss francs isn't targeting EU students just because some of them happen to attend. No intent to specifically reach EU users, no targeting.

Trigger 2: Monitoring the Behavior of People in the EU

This one catches a lot of companies off guard, especially anything involving analytics, tracking, or profiling. If you're monitoring how people in the EU behave — tracking their activity, building behavioral profiles, anything in that vein — that's enough to trigger GDPR on its own, separate from whether you're "offering" anything.

A practical example: a city-mapping app that tracks a tourist's location once they start using it in an EU city, in order to serve them targeted recommendations, is monitoring behavior under GDPR — regardless of where the app company itself is based.

The B2B Question Nobody Fully Answers

Here's a genuinely unresolved gray area worth knowing about: if your goods or services are aimed at businesses rather than individual consumers, the targeting trigger likely doesn't apply, since GDPR's "offering goods or services" language is about reaching data subjects, not companies. But what about a non-EU company selling B2B software that incidentally processes the personal data of an EU client's employees? Regulatory guidance hasn't fully settled this. The safer assumption, if there's real doubt, is to treat employee data processing as in scope rather than bet on the gray area.

Why Getting This Wrong Is Expensive Either Way

Assuming GDPR doesn't apply when it actually does is the obvious risk — you build a product with zero privacy infrastructure and find out the hard way. But the opposite mistake happens too: companies sometimes assume GDPR applies more broadly than it does, building out compliance machinery for markets they're not actually targeting under the legal test. Knowing the real factors — not just "do EU people visit our site" — saves wasted effort in both directions.

Where This Connects to Other Frameworks

A lot of global companies running ISO 27001, SOC 2, HIPAA, and PCI DSS programs build GDPR scoping into the same governance structure, rather than treating it as a separate, one-off legal question. Once you know whether GDPR applies, the actual compliance work — risk assessment, access control, vendor management — overlaps substantially with what those other frameworks already require.