The first time GDPR becomes real for a US SaaS company is usually a sales call: a UK or EU buyer's procurement team sends a data-protection questionnaire, and suddenly 'we'll deal with privacy later' is the thing blocking a six-figure deal. GDPR applies to you the moment you process the personal data of people in the EU or UK — regardless of where your servers or your company sit. The reassuring part is that GDPR is less about lawyers and more about a handful of concrete engineering and process commitments. Here is what actually matters.
Lawful basis: you need a reason to hold the data
GDPR's foundation is that you must have a lawful basis for every bit of personal data you process. For B2B SaaS the two that matter most are 'contract' (you need the data to deliver the service the customer signed up for) and 'legitimate interest' (a justifiable business reason that doesn't override the individual's rights). Consent is a third basis, but it's fragile — it must be freely given, specific, and as easy to withdraw as to give — so don't lean on it for core processing. The practical takeaway: be able to point at each category of data you store and name why you're allowed to have it. If you can't, you shouldn't be collecting it.
Data transfers: the part US companies miss
Moving EU or UK personal data to the US is a regulated 'international transfer,' and it's where US SaaS most often trips. You have options. If you self-certify under the EU-US Data Privacy Framework (and its UK extension), transfers to your US entity are covered. If you don't, you fall back to Standard Contractual Clauses — the SCCs — in your contracts, ideally backed by a transfer impact assessment. Either way, this has to be real, not just a clause: your subprocessors (the cloud and SaaS vendors that touch the data) need to be covered too. Map where EU and UK data physically flows, and make sure every hop has a legal mechanism.
The DPA and your subprocessor chain
When your customer is a 'controller' and you process data on their behalf, GDPR requires a Data Processing Agreement between you. Buyers will expect you to have one ready to sign — not to negotiate one from scratch. Your DPA names your subprocessors (AWS, your analytics, your email provider, your support tooling), commits you to notify customers of changes, and flows the same obligations down to those vendors. A clean, current subprocessor list and a standard DPA you can send within an hour of a request is a genuine sales accelerator. Scrambling to assemble one mid-deal signals you're not ready for enterprise.
Subject rights are an engineering feature
- Access and portability: a person can ask for a copy of their data, so you need a reliable way to find and export everything tied to an individual.
- Erasure: the 'right to be forgotten' means you must be able to delete a person's data on request — including from backups and logs on a defined schedule, not just the primary database.
- Rectification: let people correct inaccurate data about them.
- These aren't legal abstractions — they're features. If deleting a user means hand-running SQL across six systems, you don't really have erasure. Build the tooling before a regulator or a deletion request forces you to.
Privacy by design, breach clocks, and records
Three more obligations round it out. Privacy by design means data minimization and sensible retention are defaults in how you build, not bolt-ons — collect less, keep it shorter. Breach notification is on a clock: a reportable personal-data breach generally must reach the relevant authority within 72 hours, so you need detection and an incident process that can actually move that fast. And you must keep records of processing activities — a living inventory of what data you hold, why, where it lives, and who you share it with. That inventory is also the artifact that makes every security questionnaire and SOC 2 or ISO 27001 audit faster.
How Infiniti Tech Partners operationalizes GDPR
We turn GDPR from a sales blocker into a checklist you've already cleared: data mapping and a records-of-processing inventory, transfer mechanisms and a subprocessor chain that hold up, deletion and export tooling wired into your systems, and a breach process that fits the 72-hour clock. Compliance that's built into the architecture, not stapled on by a consultant. If a UK or EU deal is waiting on your privacy posture, start a conversation.
Related reading
ISO 27001 vs SOC 2: Which Compliance Path for US & UK SaaS in 2026
SOC 2 or ISO 27001 — or both? A practical 2026 guide for US and UK SaaS founders on which security certification your buyers actually want, what each costs, and how to sequence them.
SecurityHIPAA-Compliant Software Architecture: Patterns That Hold Up
The architecture patterns that make healthtech software genuinely HIPAA-compliant — encryption, access control, audit logging, and PHI isolation that survive an audit.
SecuritySOC 2 in 90 Days: The Engineering-Led Playbook
How a senior engineering team can take a growth-stage SaaS company from zero SOC 2 controls to a Type I attestation in 90 days — without buying a compliance platform.