The GDPR and U.S. Businesses

The regulation applies to processing in the context of the activities of an "establishment" in the Union, regardless of where the processing takes place, and also to "controllers" and "processors" outside the Union when processing relates to "offering goods or services" to people there or to "monitoring" their behavior there. In GDPR terms, a "controller" decides why and how personal data is used, while a "processor" handles that data on the controller's behalf. For a U.S. business, the relevant question is not where the company is incorporated or where its servers sit, but whether your business has an EU establishment, whether it is directing goods or services to people in the Union, or whether its tracking and profiling practices amount to behavioral monitoring of people located there.

This is the point that gets misread in both directions. Some founders assume that any website reachable from Germany or France triggers the regulation. Others assume no exposure exists without a European office. The European Data Protection Board's territorial-scope guidance draws a more careful line, distinguishing between a website that happens to be "accessible" in Europe and a business that is directing goods or services there. Lawyers often use the word "targeting" as shorthand for that second concept, but the real question is whether your business is showing an intention to reach people in the Union. The analysis moves toward coverage when a company uses EU languages or currencies beyond what a U.S.-only business would need, references customers in Member States, runs country-specific campaigns, ships into the Union deliberately, or otherwise demonstrates an intent to reach people there.

Article 3 covers the offering of goods or services regardless of whether payment is involved, which means a free app, a newsletter, a SaaS trial, a gated resource library, or a community platform can fall within the regulation if it is directed at people in the Union. Many U.S. teams assess exposure by counting paying EU customers, which is the wrong measure. If a business intentionally signs up users in the Union, allows them to create accounts, captures their contact details, personalizes content for them, or moves them through a free-to-paid funnel, the fact pattern may support GDPR coverage even when the paid customer count is modest.

For many U.S. digital businesses, the "monitoring" limb of Article 3 is more significant than the "targeting" analysis. The regulation covers monitoring behavior as far as that behavior takes place within the Union, and European Commission guidance makes clear that monitoring includes tracking and profiling on the internet, including behavioral advertising. That does not mean every analytics event creates jurisdiction, but businesses should look carefully at advertising pixels, persistent identifiers, retargeting systems, cross-site tracking, location-based profiling, user scoring, and product analytics tied to individual behavior over time, because if your business is observing what a person in the Union does in order to analyze, predict, or influence that person's behavior, the question is no longer theoretical.

This is where U.S. teams consistently under-scope what compliance requires. A privacy policy is necessary, but it is one output of a broader analysis, not the analysis itself. Articles 13 and 14 require controllers to provide individuals with specific information including the identity of the controller, the purposes of processing, the "lawful basis" or legal justification for each purpose, the recipients of personal data, details of any transfers, retention periods, the individual's rights, and how to lodge a complaint. A page that says the company values privacy and may collect information to improve its services does not come close to satisfying those requirements. The business first needs to know why it is processing data, which "lawful basis" it is relying on for each purpose, who receives the data, how long it is kept, and where it goes, because if the internal answers are weak, the external policy will reflect that.

"Lawful basis" is the GDPR's term for the legal justification that permits a company to collect, use, disclose, or retain personal data for a specific purpose under Article 6. That sounds straightforward until a company tries to map its operations against the bases the regulation makes available. "Consent" cannot be buried in a footer or bundled into a terms acceptance. "Contract" is not a catch-all for anything connected to a customer relationship. "Legitimate interests" is available for some purposes, but it requires a defensible explanation of your business interest being pursued and a careful assessment of the impact on the individual. This is one of the fastest ways a U.S. privacy program loses credibility, because marketing treats everything as consent, product treats everything as contract, and growth wants to retain data indefinitely because it might be useful later. A serious GDPR review forces the company to separate what is necessary to provide the service, what depends on valid consent, what can rest on legitimate interests, and what should stop entirely.

A U.S. business subject to the GDPR has obligations that go well beyond the public-facing notice. It needs processor agreements satisfying Article 28 wherever vendors process personal data on its behalf, records of processing activities under Article 30 unless an exception clearly applies, retention discipline, access controls, deletion workflows, and a defensible incident response posture. These obligations reach the vendor stack, the product analytics setup, customer support tooling, CRM systems, payment infrastructure, and internal governance around data access, which is why compliance does not work well as a content exercise delegated entirely to marketing.

Article 27 requires controllers and processors covered by Article 3(2) to designate a representative in the Union, but the obligation is not universal. The regulation carves out an exception for processing that is "occasional," does not involve large-scale "special-category" or criminal-offense data, and is unlikely to result in risk to individuals, and that exception is narrower than most businesses assume. A U.S. company with recurring EU users, regular behavioral tracking, or a stable EU customer base should not treat its processing as merely occasional. The same careful analysis applies to data protection officers, since the GDPR requires a DPO where core activities involve large-scale regular and systematic monitoring of individuals or large-scale processing of special-category data, meaning some U.S. businesses in ad tech, health tech, or analytics may need one regardless of whether they have a European presence.

Even when a U.S. company is directly subject to the GDPR, personal data flowing from the EU or EEA to the United States requires a Chapter V transfer mechanism, because Article 44 states that transfers to third countries may only take place where the conditions in that chapter are satisfied. U.S. businesses typically look to adequacy decisions, Standard Contractual Clauses, or another recognized safeguard depending on the structure of the data flow. The EU-U.S. Data Privacy Framework currently provides an adequacy basis for participating U.S. commercial organizations, and where adequacy is not available for a specific transfer, the modernized SCCs adopted in 2021 remain the central mechanism. A company that has reviewed its privacy notice but never analyzed how EU personal data lawfully reaches its U.S. systems has not finished the work.

The most useful first pass for a U.S. business is operational rather than documentary. Identify whether the company has any EU establishment, and if not, whether your business is intentionally offering goods or services to people in the Union or monitoring their behavior there. Then trace what personal data is collected, why it is collected, which vendors receive it, whether special-category data is involved, whether profiling is taking place, where data is stored, and which transfer mechanism supports movement of that data to the United States.

The privacy policy should be written after that work, not before it. If the scope analysis is wrong, your policy will be wrong. If the "lawful basis" analysis is underdeveloped, your policy will be vague where it needs to be specific. If the transfer analysis is missing, your policy will avoid a question the regulation requires your business to answer. The companies that handle the GDPR most effectively are generally not the ones with the longest privacy notice. They are the ones that can explain, in concrete terms, what data they process, why they process it, what legal basis supports each purpose, and how the surrounding controls function in practice.