GDPR for US startups: the four obligations that actually reach you

Are you even caught?

GDPR reaches a US company in two main ways. The first is offering goods or services to people in the EU, and the tells are ordinary commercial ones: euro pricing, marketing aimed at EU countries, a sales motion pointed at Europe. The second is monitoring their behavior, which routine analytics and tracking can amount to without anyone intending it. A handful of incidental EU visitors landing on a US product is a very different case from an EU enterprise customer with four thousand seats, and where you sit between those two decides everything that comes after. So decide it first, and write down the reasoning while you still remember it.

Controller or processor, the question your DPA turns on

For your customers' data you are usually a processor, meaning you handle it on their instructions, and their DPA can fairly ask for Article 28 terms: process only on instruction, keep it confidential, secure it, keep your subprocessors in line, delete it when they leave. For your own users and your own marketing lists you are a controller, and those obligations belong to you. Companies that don't hold that line end up signing controller duties for data they merely process, which quietly moves the customer's compliance burden onto your side of the table for free.

The four that bite

• 1. A lawful basis you can name out loud. For most B2B SaaS that means contract performance and legitimate interests, documented once and documented honestly.
• 2. Article 28 processor terms. Your EU enterprise customers will send you a DPA, and you'll negotiate it from either their paper or yours. Having a pre-approved template of your own, with a current subprocessor list attached, turns a month of negotiation into a week.
• 3. A transfer mechanism. Data leaving the EU for your US infrastructure needs a recognized route, which for most startups means standard contractual clauses or a Data Privacy Framework certification. Whichever you use, know which one you are actually relying on today, because buyers ask and the answer has to match your paperwork.
• 4. Requests and breaches, on the clock. A user asking for their data starts a legal deadline, and that deadline doesn't pause because the request landed in your support queue. A breach starts one too, and the European clock is measured in hours and days, tighter than most US state timelines.

What's mostly noise at your size

A Data Protection Officer, in most cases. Representative appointments have a specific trigger, so check whether you have actually hit it and then decide, rather than defaulting to yes because a vendor said so. Records of processing scaled to a forty-person company are a spreadsheet somebody keeps current, not a platform you buy. Here's the test for any GDPR spend: could you explain it to your CFO in one paragraph and have the explanation survive the follow-up question?

Build once

US state privacy laws and GDPR overlap enough that a single architecture serves both: one data map, one vendor list, one deletion capability, one incident playbook. Build it to satisfy the strictest customer you actually want to sell to, and every other customer inherits the work without a second project.

The first-EU-customer checklist

GDPR rewards proportion. The companies that get hurt are rarely the ones that deliberately did a little; they're the ones that never sat down and decided what applied to them in the first place.