MOFU Compliance Guide · 2026

GDPR for US SaaS Companies: An Engineer's Guide

You do not need an EU office to be on the hook for GDPR. Here is when the regulation reaches a US SaaS, the data subject rights your software has to support, how DPAs and subprocessors work, and the engineering you need to build to back it all up.

By Bill Beltz, founder of QUANT LAB USA INC · Published June 3, 2026

Quick answer: does GDPR apply to my US SaaS?

If people in the EU or EEA can use your product, or you track their behavior, GDPR likely applies — regardless of where you are incorporated or hosted. You will need a lawful basis for processing, signed Data Processing Agreements with customers and every subprocessor, a current public subprocessor list, and software that can find, export, and delete one person's data across your database, backups, logs, and vendors within about a month. You also need detection and incident response fast enough to hit the 72-hour breach-notification clock. The engineering is the hard part; build it in rather than bolting it on.

Not legal advice. QUANT LAB USA is a software engineering and cybersecurity firm, not a law firm. GDPR applicability, lawful bases, and cross-border transfer mechanisms are legal determinations. This article is engineering and operational guidance for building a product that can comply; confirm your specific obligations with qualified privacy counsel.

Most US founders assume GDPR is a European problem. Then a German prospect sends a security and privacy questionnaire asking for a signed DPA and a subprocessor list, and the project stalls. At QUANT LAB USA we treat GDPR as an architecture concern: the rights are easy to promise and hard to engineer, so we build the plumbing early.

Related background: our HIPAA-compliant SaaS architecture guide covers many of the same data-handling patterns from the healthcare angle.

When GDPR reaches a US company

GDPR has extraterritorial scope. A US company is generally caught when it does either of the following with the personal data of people located in the EU or EEA:

Offers goods or services to them — even free ones. Pricing in euros, an EU-language site, or EU-targeted ads are strong signals, but EU users simply signing up can be enough.
Monitors their behavior — analytics, tracking pixels, behavioral profiling, and similar.

What does not get you off the hook: having no EU entity, hosting only in US regions, or never invoicing an EU customer. The hook is the data, not the corporate structure. If EU residents can meaningfully use your SaaS, assume you are in scope until counsel tells you otherwise.

Controller vs processor: which hat are you wearing?

Your obligations depend on your role for a given dataset, and most SaaS companies wear both hats at once:

Processor for your customers' end-user data. You process it on their instructions; they are the controller. This is the typical B2B SaaS posture.
Controller for your own data — your marketing leads, your account holders' admin profiles, your employees. You decide why and how it is processed.

Getting this mapping right drives your contracts: as a processor you sign your customers' DPAs; as a controller you owe your own privacy notice and lawful basis. Many disputes start because a company never decided which role applied to which data.

The data subject rights — and what each demands in code

Right	What the user can ask for	Engineering implication
Access	A copy of their data	A reliable per-subject export across all stores
Rectification	Correct inaccurate data	Editable fields + propagation to derived data
Erasure	Delete their data	Cascade delete across DB, logs, backups, subprocessors
Restriction	Pause processing	A flag your code honors everywhere
Portability	A machine-readable export	Structured JSON/CSV export endpoint
Objection	Opt out of certain processing	Preference center wired into pipelines

You generally have one month to respond. The painful part is erasure: deleting one person everywhere — primary database, read replicas, search indexes, caches, object storage, analytics, error tracker, email tool — means you need a data map and deletion fan-out built in advance.

DPAs, subprocessors, and the contract chain

Article 28 requires a Data Processing Agreement between controller and processor. In practice that means a chain of contracts:

Upstream: you sign your customers' DPAs as their processor.
Downstream: you sign DPAs with every subprocessor that touches personal data — cloud host, database provider, email, analytics, error tracking, support tooling, AI vendors.
Transparency: you maintain a current, public list of subprocessors and a way to notify customers of changes.
Transfers: cross-border data movement (EU to US) needs a valid mechanism — the EU-US Data Privacy Framework or Standard Contractual Clauses with a transfer impact assessment — referenced in the DPA.

Missing downstream DPAs is one of the most common gaps we find in audits. Every vendor in the personal-data path needs one, the same way every PHI vendor needs a BAA under HIPAA.

Engineering implications: privacy by design

GDPR's Article 25 calls for “data protection by design and by default.” Translated into a SaaS build, that is concrete engineering work:

Data inventory and mapping. Know every place personal data lives, including logs, backups, and third parties. You cannot honor erasure for data you have not catalogued.
Deletion and export pipelines. One job that fans out a per-subject delete or export across all stores and subprocessors, with an audit trail.
Consent and preference management. A real cookie consent and marketing preference system, captured with timestamps, honored in code.
Data minimization and retention. Collect only what you use; enforce retention windows with scheduled purges, not manual cleanup.
Pseudonymization and encryption. Separate identifiers from sensitive attributes where practical; encrypt at rest and in transit.
Logging that does not leak. Redact personal data at the application boundary so it does not end up in third-party logs without a DPA — the same discipline we describe for PHI.

Build these on tenant-isolated foundations. Our multi-tenant SaaS with Postgres RLS guide shows how row-level security keeps one customer's personal data away from another's.

The 72-hour breach clock is an engineering problem

When a personal data breach poses a risk to individuals, a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. A processor must tell its controller without undue delay. You cannot meet that clock with paperwork alone — you need to detect the breach.

Centralized, retained audit logs with anomaly alerting.
A written incident response plan with defined severities and an incident commander.
Notification templates prepared in advance.
An annual tabletop exercise so the team has run the drill before it is real.

This is the same detection-and-response backbone that supports SOC 2 and ISO 27001. See cybersecurity services for SaaS startups.

FAQ

When does GDPR apply to a US company?

GDPR reaches a US company when it offers goods or services to people in the EU or EEA, or monitors their behavior — even with no EU office and no euros changing hands. A free signup form that EU residents can use, EU-targeted marketing, or analytics that track EU visitors can all bring you in scope. The trigger is processing the personal data of people in the EU, not where your servers or your incorporation sit.

What is the difference between a controller and a processor?

A controller decides why and how personal data is processed; a processor handles data on the controller's behalf. Most B2B SaaS act as a processor for their customers' data and a controller for their own data (employees, prospects, their own account holders). Your obligations differ by role, and your contracts must state which hat you wear for which data.

Which data subject rights does my software need to support?

Build for access (export a copy of someone's data), rectification (correct it), erasure (the right to be forgotten), restriction, data portability (machine-readable export), and objection. Operationally you generally have one month to respond. The engineering implication is that you need to locate, export, and delete a single person's data across your primary database, backups, logs, caches, and every subprocessor — which is hard to bolt on later.

What is a Data Processing Agreement (DPA) and do I need one?

A DPA is the contract required under Article 28 between a controller and a processor. If you process personal data for your customers, you sign DPAs with them (you as processor), and you sign DPAs downstream with every subprocessor that touches that data — your cloud host, email provider, analytics, error tracker, and so on. You also keep a public, current list of subprocessors. Missing DPAs is one of the most common gaps we find.

Can a US SaaS legally transfer EU personal data to the United States?

Yes, with a valid transfer mechanism. The common routes in 2026 are the EU-US Data Privacy Framework (for certified US organizations) and Standard Contractual Clauses backed by a transfer impact assessment. The mechanism belongs in your DPA. This is a legal determination — confirm your specific approach with privacy counsel rather than assuming a default.

What are the engineering implications of GDPR for SaaS?

Five big ones: a data inventory so you know what personal data lives where; deletion and export pipelines that span database, backups, logs, and subprocessors; consent and preference management for cookies and marketing; data minimization and retention windows enforced in code; and breach-detection plus logging good enough to meet the 72-hour notification clock. Privacy by design means building these in, not retrofitting them.

How fast must I report a personal data breach under GDPR?

A controller must notify the relevant supervisory authority without undue delay and where feasible within 72 hours of becoming aware of a personal data breach that poses a risk to individuals. A processor must notify its controller without undue delay. That clock only works if your logging, alerting, and incident response are already in place — which is why detection engineering matters as much as the paperwork.

Make GDPR an architecture decision, not a fire drill.

Free 30-minute review. We will map where personal data lives in your stack, find the missing DPAs and deletion gaps, and show you what to build so the next EU prospect's questionnaire is a formality.

Or call Bill at (770) 652-1282

More compliance + architecture reading

All posts

All blog postsUpdated June 3, 2026