GDPR for US SaaS: What Actually Changes in the Code

November 2, 2026

GDPR for US SaaS is an architecture problem, not a policy PDF. The seven things that have to exist in your codebase before an EU enterprise buyer will sign.

Share:LinkedInXCopy link

The Privacy Policy Was Never the Blocker

Most of what has been written about GDPR for US SaaS was written for a general counsel: appoint this role, sign that clause, publish this notice. All of it is necessary, and none of it is what stalls the deal. What stalls the deal is question 14 of the buyer's questionnaire, asking how a user's erasure request propagates to the analytics warehouse — and the honest answer is that it doesn't.

Regulation (EU) 2016/679 asks for behaviours. Know what you hold and why. Hand it back. Delete it. Don't keep it forever. Notice within 72 hours when it leaks. Behaviours live in code, which is why the weekend privacy policy closes nothing.

At Kuaray we usually get pulled into this after a term sheet, by a team with a signed DPA and a product that cannot honour it. So this is the engineering version: what has to exist in the system, in what order, and which parts you cannot retrofit. It is not legal advice — but get the architecture right and your counsel's job gets much smaller.

GDPR for US SaaS Follows the User, Not the Entity

The most expensive misunderstanding is jurisdictional. Teams assume a Delaware C-corp on US-only infrastructure is outside the regulation's reach. Article 3(2) says otherwise: the GDPR applies to processing the personal data of people in the Union when you offer them goods or services or monitor their behaviour. No EU office, no EU subsidiary, no EU server required. A checkout in euros is enough.

Article 27 then generally requires a representative established in the Union, with a narrow exemption for occasional, low-risk processing. But the consequence engineers care about is this: you need to know which users are in the EU. If your system cannot answer "is this account in scope," every control has to apply to everyone — usually the more expensive outcome.

So the first real task is making region a first-class attribute of an account, propagated downstream and treated as data you can be wrong about.

What the Regulation Asks For vs What Teams Actually Build

The pattern is consistent: the legal artefact exists, the mechanism doesn't, and the DPA promises things the code was never asked to do.

Every row on the right is ordinary engineering work, and all of it takes longer than the two weeks procurement gives you.

The Data Map Is a Build Artifact

Article 30 records of processing are usually treated as a document. Treat them as output instead. A hand-maintained data map is wrong within one sprint; one derived from what actually defines your storage is wrong only when the code is.

The technique that holds up is annotating at the schema level. Tag every column, field and event property with a classification — identifier, contact, behavioural, special category, derived — plus a lawful basis and a retention window. Generate the register from those annotations in CI, and fail the build when an untagged personal-data column arrives. That tag is a two-minute decision when the migration is written and an archaeology project six months later.

It pays for itself three times, because the same metadata drives the export job, the deletion cascade and the retention sweep. If you build one thing from this article, build this — it is what makes data-layer work tractable instead of heroic.

Data Subject Rights Are an API, Not an Inbox

Article 12(3) gives you one month to respond to a rights request, extendable by two further months for complex cases. That sounds generous until the first one arrives and you find the user's data in Postgres, the warehouse, the analytics tool, the support desk and eleven months of application logs.

Three design rules make this survivable:

• One identity resolution path. Every request starts by resolving a human to a set of keys across systems. Improvised per request, it will be inconsistent — and inconsistency is the finding.
• Export is a pipeline, not a dump. Article 20 asks for a structured, commonly used, machine-readable format. A bundle assembled by a job walking the tagged schema is defensible; a hand-built CSV is not repeatable.
• Deletion is a state machine, not a statement. Real erasure crosses systems you don't control and backups you can't surgically edit. Model it — requested → propagated → confirmed — with per-subprocessor acknowledgement and a time-bounded policy for backup expiry rather than a claim that backups were edited. A reasoned approach survives diligence; a DELETE against one table does not.

The tell: ask how long a full erasure takes, and who gets paged when an acknowledgement never arrives.

Retention Is a Cron Job

Storage limitation is the requirement teams most comfortably ignore, because nothing breaks when you keep data forever. It is also the easiest to check in diligence: pick a table, ask for the oldest row, ask which window applies.

Pair every tagged field with a window, enforce it with a scheduled job, and emit a metric per table for rows deleted and oldest surviving row. Logs deserve attention — a 400-day default log retention is a liability nobody chose.

Transfers: Build for the Mechanism Changing

Sending EU personal data to US infrastructure needs a basis under Chapter V. Two matter in practice: Commission Implementing Decision (EU) 2021/914 of 4 June 2021, which established the modernised standard contractual clauses, and the adequacy decision for the EU-US Data Privacy Framework — Decision (EU) 2023/1795, adopted 10 July 2023 — which lets certified US recipients receive data without further safeguards.

The part worth internalising as an architect: this layer has been rebuilt twice in a decade, and the current mechanisms have been litigated rather than settled. Your legal team tracks that. Your job is to keep a change of mechanism a contract-and-configuration problem rather than a re-platforming project.

Concretely: know — as structured data, not tribal knowledge — which subprocessor holds which category of personal data, in which region, under which basis. Then a mechanism moving is an afternoon, not a quarter.

EU Data Residency Is a Topology Decision You Make Once

Sooner or later a German enterprise buyer asks for EU data residency, and your answer depends on a decision made long before the question. Retrofitting regional isolation into a single-region application is punishing, because residency is not a storage setting — it is identity, queues, caches, search indexes, backups and every third-party call.

If you are early, the cheap insurance is a region-aware data plane while you still run one region: a region key on every tenant, no cross-region joins, no shared caches keyed without region. The control plane stays global. That costs almost nothing before launch and is the difference between a config change and a rewrite — the same argument we make about infrastructure design generally.

The 72-Hour Clock Is a Logging Requirement

Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach — and the notification must describe the categories and approximate number of data subjects affected. That is not a policy sentence. It is a query you run against your access logs under pressure.

Which means audit logging on personal-data access with actor, subject keys and purpose; immutable retention of those logs long enough to reconstruct an incident; and one rehearsal. Teams that have never practised scoping a breach discover during a real one that their logs record which endpoint was hit, not whose records came back — ordinary security engineering, nearly impossible mid-incident.

The Order We Do This In

Sequence matters, because each step makes the next one cheaper:

1. Make region a real attribute. Tenant-level, propagated, with a defined failure mode when it is unknown.
2. Tag the schema. Classification, lawful basis and retention window on every personal-data field, enforced in CI.
3. Generate the register. Article 30 records as build output, plus a subprocessor inventory with region and data category.
4. Build export, then deletion. Export first — it is read-only, and it finds the stores you forgot.
5. Turn on retention. Scheduled, metered, logs included.
6. Instrument for breach scoping. Access logs that answer "whose data," not "which route."
7. Then paper it. DPA, subprocessor page, notice, representative, transfer mechanism — last, because now every clause describes something real.

Most teams run this backwards, starting at step seven because that is what procurement asked for. That is how you get a signed DPA you cannot honour — a worse position than having no DPA at all.

The Uncomfortable Summary

GDPR compliance for US SaaS companies is not a document problem with an engineering appendix. It is an engineering problem with a document appendix.

The good news: nearly all of this work improves the product independent of Brussels. A generated data map is the schema documentation you never wrote. Working deletion forces your orphaned-data cleanup. Region-aware tenancy is how you serve enterprise buyers anywhere. If you are also shipping AI features into Europe, the same instinct applies one layer up — see EU AI Act compliance for SaaS.

Start with the data map. Everything else in GDPR for US SaaS is downstream of knowing what you hold.

Talk to us about your EU readiness → — we build the data mapping, rights endpoints, retention enforcement and region-aware architecture that make these obligations a property of the system rather than a quarterly scramble.