A US software company can be subject to the GDPR without an office, an employee, or a server in Europe. It often finds out when a European prospect's procurement team sends over a data processing agreement and a transfer questionnaire, or when a US enterprise customer flows down its own GDPR obligations.
The questions that follow are predictable. Does the GDPR apply to us at all? Which obligations are ours, and which are our customers'? What do we put in place first? This article answers them in that order, and points to deeper treatments of each obligation.
When the GDPR applies to a company outside the EU
Article 3 sets the territorial scope. Two routes matter to a US company.
Establishment (Article 3(1)). The GDPR applies to processing in the context of the activities of an establishment in the EU, regardless of where the processing itself takes place. An EU subsidiary or branch is an establishment, and the EDPB's guidelines note that a stable arrangement with very little physical presence can be enough. If you have one, its processing is in scope.
Targeting (Article 3(2)). Without an EU establishment, the GDPR still applies to a controller or processor whose processing relates to:
offering goods or services to data subjects in the EU, whether or not payment is required, or
monitoring their behavior, as far as that behavior takes place in the EU.
Offering requires more than accessibility. Recital 23 says the mere accessibility of your website, an email address, or other contact details from the EU is not enough on its own, and neither is using a language generally used in your own country. Indicators of targeting include using a language or currency of a member state with the possibility of ordering in it, or mentioning customers or users in the EU. Recital 24 says monitoring includes tracking individuals on the internet, including profiling to analyze or predict their preferences, behaviors, and attitudes.
The EDPB's guidelines on territorial scope work through examples of both routes. Use them if your position is not obvious.
The contractual route
Even where Article 3 does not reach you directly, the GDPR arrives through contracts. An EU customer that uses your product as a processor must bind you to Article 28 terms and put a transfer mechanism in place. In practice, a US vendor with EU customers takes on most of a processor's obligations either way, directly or by contract.
Your two roles
Most B2B SaaS companies hold two roles at once, and the obligations differ.
Processor for your customers' data. When a customer puts its users', employees', or clients' data into your product, the customer usually decides why and how that data is processed. You process it on the customer's instructions. Your obligations come from Article 28, the DPA, and the transfer clauses.
Controller for your own data. Your marketing lists, website visitors, sales prospects, billing contacts, product analytics you run for your own purposes, and any EU-based employees. For this data you decide the purposes, and the full set of controller obligations applies: lawful basis, transparency, data subject rights, and the rest.
The line between the two is a question of fact, not of what your terms say. If you use customer data for your own purposes, such as building benchmarks across customers, you are likely to be a controller for that processing.
What to put in place, in order
The order below puts first the items customers ask for before they sign. It is a sequence for a company starting from little, not a complete program.
1. A map of what you process
List your processing activities, as controller and as processor. That list becomes your Article 30 record and the input to nearly every step below. Without it, each later step is guesswork.
2. A standard DPA
Prepare a data processing agreement that covers all eight Article 28(3) obligations. Having your own reduces the number of customer drafts you negotiate. Its security annex should describe controls you actually operate.
3. A transfer mechanism
Personal data that reaches you from the EU is a transfer under Chapter V. Two routes are common:
Certify under the EU-US Data Privacy Framework. Certification is made through the US Department of Commerce, must be renewed annually, and commits you publicly to the framework's principles, enforceable by the Federal Trade Commission or the Department of Transportation.
Sign standard contractual clauses: Module 2 with controller customers, and Module 3 with your own sub-processors, each supported by a transfer impact assessment.
The two are not exclusive. Keeping SCCs in place alongside certification means a change to the framework's status does not leave your transfers without a mechanism.
4. A sub-processor list
Customers expect a list of the sub-processors that handle their data, with locations, and notice when it changes. Article 28(2) requires that notice under general authorization. Keep the list current: an outdated one is a contract problem as well as a privacy one.
5. An EU representative, if Article 3(2) applies
Article 27 requires a controller or processor subject to the GDPR under Article 3(2) to designate, in writing, a representative in the EU. The exception covers processing that is occasional, does not include large-scale processing of special category or criminal conviction data, and is unlikely to result in a risk to individuals. Ongoing service to EU customers is hard to describe as occasional, so the exception rarely fits a SaaS business.
6. Data subject request handling
Article 12(3) gives you one month to respond to most requests, extendable in limited cases. Set up intake and a search process before the first request arrives. For customer data, your role as processor is to forward the request and assist the controller.
7. A breach process with a GDPR branch
Your incident response plan needs a step that assesses whether an incident is a personal data breach, and a step that notifies affected customers. As a processor you notify controllers without undue delay. As a controller you have 72 hours to notify the supervisory authority where notification is required, and without an EU establishment you may face several authorities rather than one. The detail is in GDPR breach notification and the 72-hour clock.
8. Lawful bases and a privacy notice for your own processing
For your controller activities, choose and document a lawful basis for each purpose, and reflect it in your privacy notice under Articles 13 and 14. Website analytics and advertising cookies also fall under the EU's ePrivacy rules, which generally require consent for non-essential cookies whatever your GDPR basis.
What your existing frameworks already cover
If you hold a SOC 2 report or an ISO 27001 certification, much of the security side of the GDPR is already evidenced. Article 32 requires appropriate technical and organizational security measures, and your control set describes them.
What those frameworks do not cover is the privacy-specific work: lawful bases, data subject rights, transfers, records of processing, and processor terms. ISO 27701 extends an ISO 27001 management system to cover much of that, and is worth considering if your customers already ask for ISO certificates.
Where US companies go wrong
These are the patterns worth checking for in your own program:
Assuming B2B means no personal data. Business contact details, user accounts, and support conversations are all personal data.
Describing your customers' processing in your privacy notice. Your notice should describe your controller processing. Your customers describe theirs.
Treating a DPA signature as the finish line. The DPA commits you to operate controls, notify breaches, and support audits. Each commitment needs an owner.
Overlooking people in the EU. A single EU-based hire brings employment data, local employment law, and possibly an establishment question.
Whether the GDPR applies to you directly, and through which route, depends on facts that are worth having counsel confirm, particularly around establishment and targeting.
How TrustLynce helps
TrustLynce's data privacy workflows hold your record of processing, transfer assessments, and data subject requests in one place, linked to the vendors and systems they depend on. The same record supports the DPA, transfer, and request steps above.