GDPR for US SaaS Companies (2026): The Operator's Guide to Scope, Roles, Transfers, and Fines

Does GDPR apply to your US SaaS? (The Article 3 self-assessment)

The GDPR reaches far beyond the EU’s borders. Under Article 3(2), a company with no establishment in the Union is still bound by the Regulation if it either (a) offers goods or services to individuals who are in the EU — payment is not required, so free tiers count — or (b) monitors the behaviour of individuals who are in the EU (for example, tracking, profiling, or analytics). Separately, Article 3(1) captures processing carried out “in the context of the activities of an establishment” in the Union, which can be triggered by an EU subsidiary, branch, or even a single sales employee. Auditsuisse’s GDPR audit and assessment service starts with exactly this scoping question.

The most common misconception is that GDPR follows citizenship. It does not. The Regulation protects individuals who are in the Union — it is location-based. A US SaaS whose entire user base is US persons located in the US is generally out of scope even if some of those users hold EU passports; conversely, a US company selling to a US customer whose employees sit in Berlin or Paris can be squarely in scope. The EDPB Guidelines 3/2018 on territorial scope is the authoritative reading of Article 3.

The establishment test (Art. 3(1)) vs the targeting/monitoring test (Art. 3(2))

Article 3(1) is about your footprint: if processing happens in the context of an EU establishment, GDPR applies regardless of where the processing physically occurs or whose data it is. Article 3(2) is about who you reach: it applies to non-EU controllers and processors based on whether their activities are directed at people in the EU. Most US SaaS companies without an EU entity fall under Article 3(2) rather than 3(1).

Common US-SaaS scenarios that trigger scope

Use the decision table to place your product. It maps the four situations we see most often to the exact Article 3 basis and the first obligation that follows.

Are you a controller or a processor? (Articles 4(7)–(8))

GDPR assigns duties by role. A controller (Article 4(7)) decides the purposes and means of processing; a processor (Article 4(8)) processes on the controller’s behalf and on its documented instructions. The essential insight for SaaS is that the same company holds both roles at once — it just depends on the processing activity. For the end-user data your customers upload into your app, you are typically a processor acting on their instructions. For your own marketing lists, CRM, prospect data, and employee HR records, you are the controller.

There is an important exception the role matrix flags: if you determine the purposes or means of the customer’s data — for instance, using uploaded data to train shared models or for your own product analytics beyond the service you were contracted to provide — you become a controller or joint controller for that activity, with the fuller set of controller duties. Do not assume “processor” universally.

Your GDPR obligations as a US SaaS, by role

Once you know your role per activity, the obligations follow a predictable pattern. The four that generate the most procurement questions are records, lawful basis, contracts, and security.

Records of Processing Activities (Article 30)

Article 30 requires a written inventory — the RoPA — of your processing activities. Buyers and supervisory authorities both ask for it, and it is the backbone of the rest of your program. A workable RoPA row captures the following fields:

Lawful basis (Article 6)

Every controller activity needs one of the six lawful bases in Article 6. For SaaS, the workhorses are Article 6(1)(b) (processing necessary to perform the contract with the user) and Article 6(1)(f) (legitimate interests, subject to a balancing test). Special categories of data (health, biometrics, and more) require an additional Article 9 condition. Matching each activity to the right basis is worth doing carefully — our companion guide walks through which lawful basis applies to each processing activity in a B2B SaaS.

Data processing agreements (Article 28)

Whenever a controller uses a processor, Article 28(3) requires a written DPA that specifies the subject-matter, duration, nature and purpose of processing, the types of personal data and categories of data subjects, and the eight mandatory processor obligations (confidentiality, security, sub-processor rules, assistance with data-subject rights, breach support, deletion/return, audits, and notice of unlawful instructions). Sub-processor engagement requires prior authorization under Article 28(2), and under Article 28(4) the processor must impose the same data-protection obligations on each sub-processor by contract and remains fully liable to the controller for the sub-processor’s failures. As a SaaS you need a DPA with every customer (you as processor) and with every sub-processor you engage.

Security of processing (Article 32)

Article 32 requires “appropriate technical and organisational measures” — encryption, resilience, and regular testing of security effectiveness among them. This is where GDPR overlaps heavily with the controls you already run for other frameworks: the same access management, encryption, and logging controls that satisfy your SOC 2 Trust Services Criteria map directly onto Article 32, so you should map shared controls once rather than twice. Regular penetration testing is one of the clearest ways to evidence the “regularly testing” requirement in Article 32(1)(d).

Data subject rights and DSAR SLAs (Articles 12–22)

Individuals have enforceable rights — access, rectification, erasure, portability, and objection among them. Under Article 12(3) you must respond within one month of receipt, extendable by two further months for complex or numerous requests with notice to the individual. Responses are free unless the request is manifestly unfounded or excessive.

As a processor, you assist your customer (the controller) in meeting these deadlines rather than answering the individual directly — a duty your DPA should spell out.

Cross-border data transfers: getting EU data to the US legally in 2026

Chapter V of the GDPR (Articles 44–49) governs sending personal data outside the EU. The reason the US needs special treatment is not commercial — it is government surveillance access. In Schrems II (Case C-311/18) the Court of Justice struck down the Privacy Shield because US signals-intelligence laws (FISA 702 and EO 12333) and the lack of individual redress meant EU data was not adequately protected. Every transfer mechanism to the US since then is an answer to that surveillance-and-redress problem, not a generic paperwork exercise.

You have four routes. The deep operational mechanics live in our US-EU-UK cross-border data transfer guide; the selection table below is the decision layer.

The DPF works because the US adopted Executive Order 14086 (limits on signals intelligence plus a two-layer redress process ending at the Data Protection Review Court in the US DOJ), which the Commission judged adequate for certified importers only. There is still no general US adequacy finding, so a transfer to any US recipient that has not self-certified to the DPF still needs the 2021 SCCs (the modular clauses in Commission Implementing Decision (EU) 2021/914, covering controller-to-controller, controller-to-processor, processor-to-processor, and processor-to-controller) plus a Transfer Impact Assessment.

What changed for 2026 (and why it is still evolving)

The DPF is standing but contested, and this is the fastest-moving part of the topic. Track it as evolving:

• The DPF adequacy decision is Commission Implementing Decision (EU) 2023/1795, adopted 10 July 2023.
• The EU General Court dismissed the Latombe challenge (Case T-553/23) on 3 September 2025. An appeal to the CJEU was filed on 31 October 2025 — reported as Case C-703/25 P, which should be re-verified on curia.europa.eu before you rely on the number.
• Separately, reported changes in early 2025 to the membership of the PCLOB and the Data Protection Review Court raised questions about the independence and quorum of the US redress mechanism the DPF depends on.
• Following mid-2026 US developments affecting the removal protections of independent agency officials, privacy campaigners publicly urged the Commission to reconsider the DPF and signalled a possible fresh annulment action.

The practical takeaway: keep the 2021 SCCs plus a TIA in place as a fallback even if you also self-certify to the DPF, so a future adverse ruling does not strand your data flows.

The UK dimension

UK transfers are governed by the UK GDPR and require either the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs; certified US importers can use the UK Extension to the DPF. Note that the UK Data (Use and Access) Act 2025 amended UK GDPR during 2025–2026 — touching DSAR handling, automated decision-making, and a set of “recognised legitimate interests” — so treat UK requirements as diverging from the EU baseline rather than identical. The ICO’s international transfers guidance is the primary UK source. If you are expanding into Europe, our EMEA region page outlines how we support that move.

Appointing an EU representative under Article 27

The representative is an external, EU-located contact point that supervisory authorities and data subjects can address directly. It is not the same as a Data Protection Officer, and founders constantly conflate the two. The table below disambiguates the three roles that get confused.

Note that the UK has its own parallel requirement: an in-scope non-UK company generally needs a UK representative under UK GDPR Article 27, with the ICO as the UK supervisory authority.

Cold email, cookies, and the ePrivacy Directive

Two of the most common real-world GDPR exposures for US SaaS are not in the “lawful basis” abstraction at all — they sit at the intersection of GDPR and the ePrivacy Directive, and they are where EU regulators (notably France’s CNIL) issue the most enforcement.

Can you cold email EU business contacts?

This is the question founders ask most. Cold B2B outreach can, in principle, rely on legitimate interests (Article 6(1)(f)), but the ePrivacy Directive layers a separate rule on unsolicited electronic marketing, and many Member States require prior consent even for B2B email. The safe operating posture is: run a documented legitimate-interest assessment, keep lists tightly targeted and relevant, provide a one-click opt-out in every message, and check the national rules of the country you are emailing into — because stricter local ePrivacy rules can override the legitimate-interest route.

Cookie consent is a separate obligation

Placing non-essential cookies and analytics/marketing trackers on the device of an EU visitor requires prior, informed consent under the ePrivacy Directive — a distinct obligation from choosing a GDPR lawful basis for the underlying data. A compliant cookie banner must let users refuse as easily as they accept, must not use pre-ticked boxes, and must not deploy trackers before consent. Analytics running on your EU web traffic is the single most-cited enforcement area, so treat the banner as a first-class control, not an afterthought.

Children’s data

If your product could reach EU users under 16 (edtech, consumer, or freemium tools), Article 8 requires verifiable parental consent for information-society services offered directly to children, with the exact age threshold set by each Member State (between 13 and 16). Articles 13–14 transparency obligations must also be written in language a child can understand.

When you need a DPIA (Article 35)

A Data Protection Impact Assessment is required under Article 35 only where processing is “likely to result in a high risk” to individuals. Not every SaaS feature triggers one. Use this three-line screen:

• Are you doing systematic and extensive automated evaluation or profiling that produces legal or similarly significant effects?
• Are you processing special-category data (Art. 9) at large scale?
• Are you carrying out systematic monitoring of a publicly accessible area at large scale?

If any answer is yes, you likely need a DPIA. Rather than reproduce the mechanics here, work from our GDPR DPIA template and trigger guide, which walks through the full assessment. The EDPB’s WP248 criteria remain the reference for what counts as “high risk.”

GDPR fines and enforcement for US companies

GDPR enforcement reaches non-EU firms — and the Article 27 representative is one route by which authorities and individuals pursue a US company. Fines come in two tiers, and it matters which enumerated obligations sit in which tier, so the table mirrors the Article 83(4) and 83(5) lists rather than paraphrasing them.

Beyond fines, the 72-hour breach clock is the operational deadline most likely to catch a growing SaaS off guard. Under Article 33, a controller must notify the competent supervisory authority within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals; under Article 34, high-risk breaches must also be communicated to affected data subjects without undue delay. A pre-built breach runbook with roles, decision criteria, and notification templates is the difference between meeting and missing that window. The full text of Article 83 and Article 33 is worth reading in the original.

The GDPR readiness checklist for US SaaS

This checklist maps directly to what enterprise procurement diligence probes. Assign each step an owner and an evidence artifact — and reuse the controls you already run for SOC 2 and, for healthtech teams, HIPAA if you also handle US health data. Auditsuisse’s audit methodology is built around evidencing exactly this kind of accountability.

The overlap with SOC 2 and HIPAA is real: map shared technical controls once and evidence them for every framework, rather than running parallel programs.

How Auditsuisse helps

Auditsuisse is a US and Swiss licensed CPA firm, which is an unusual and useful vantage point for GDPR. Our Swiss practice works daily with the revised Swiss Federal Act on Data Protection (nFADP, in force September 2023) — a regime closely aligned with GDPR — while our US CPA practice runs the SOC 2 and HIPAA programs your buyers also ask for. That cross-border position means we can scope your GDPR obligations, map them onto the technical controls you already evidence, and stand up the DPAs, transfer mechanism, and Article 27 arrangements without duplicating work. Start with our GDPR audit services to see how we approach it.