GDPR content for US audiences generally falls into two failure modes. European law firms write long pieces that treat GDPR as a jurisdictional puzzle box, all hedged language and “may apply” and “depending on the circumstances.” US consultants write confident pieces that compress the whole regulation to a seven-step checklist and sell a compliance platform at the end. Neither helps the actual reader, which is the privacy lead or compliance manager at a US SaaS company selling into EU or UK markets trying to run a defensible programme without hiring a Brussels firm.
GDPR for US SaaS is a six-month implementation project. It’s work, not interpretation. This article is the plan.
GDPR for US companies: what actually applies to you
GDPR applies to your US SaaS company if either of two things is true. First, you offer goods or services to individuals in the European Union (or United Kingdom, under UK GDPR) — regardless of whether the offering is free. Second, you monitor the behaviour of individuals in the EU or UK (online tracking, behavioural analytics, targeted advertising). The applicability test is in Article 3, and the threshold is much lower than most US SaaS companies realise.
A company whose customers are US enterprises, but whose product is used by those enterprises’ EU-based employees, processes personal data of EU data subjects. A company that sells a B2B SaaS product in English to businesses anywhere, but whose marketing site runs analytics that can identify EU visitors, monitors behaviour of EU data subjects. In most cases, GDPR applies, and the thing US companies do — wait for their first customer to ask before taking it seriously — is risk management by procrastination.
The second thing to establish up front: GDPR is not one regulation. EU GDPR (Regulation 2016/679) and UK GDPR are substantively similar but not identical, and diverge in specific places — notably on international data transfers, the supervisory authority, and a handful of national derogations. If you operate in both markets, you need to account for both regimes. For the purposes of this article, “GDPR” means the combined EU+UK picture unless specifically distinguished.
The third: GDPR requires specific artefacts, not a general commitment to privacy. Supervisory authorities and customer privacy teams ask for Article 30 records, Data Protection Impact Assessments where required, Records of Data Subject Requests, breach notification records, and written agreements with all processors. If you can’t produce these documents, your programme has gaps regardless of how privacy-respecting your product actually is.
The 6-month programme at a glance
Six months is realistic for a US SaaS company of 50–500 people implementing GDPR-compliant posture for the first time, typically triggered by commercial pressure from an EU customer or by expansion planning. Teams already running SOC 2 can compress; teams starting from no privacy infrastructure should budget eight to nine months.
Phase 1: Data mapping and Article 30 Months 1–2
Phase 2: Policy framework and DPIA process Months 2–3
Phase 3: Data subject rights infrastructure Months 3–4
Phase 4: Vendor DPAs and transfers Months 3–5
Phase 5: Breach response and ongoing ops Months 5–6Phases 3 and 4 run in parallel. Phase 4 specifically — vendor DPA negotiation — is externally bottlenecked and benefits from starting as early as Phase 2 if your vendor inventory is long.
Phase 1: Data mapping and Article 30 records (months 1–2)
Two months to produce the foundational artefact of the whole programme.
Data mapping. Document every flow of personal data through your systems. For each flow: the category of data (names, emails, IP addresses, device identifiers, location data, behavioural data, payment data, health data, biometric data, other special category data), the category of data subject (customers, end users of customers’ products, visitors, employees, job applicants), the purpose of processing, the legal basis for processing, the systems involved, the retention period, and the onward disclosures.
Most first-time GDPR data mapping exercises produce a first draft that is 40–60% incomplete. Common omissions: behavioural data sent to analytics platforms, support ticket content (often contains personal data volunteered by users), sales enablement tools, marketing automation, error reporting, session replay products. Expect to rewrite the map once after a week of operating it and noticing what’s missing.
Article 30 records (Records of Processing Activities). GDPR Article 30 requires controllers and processors over certain size thresholds to maintain written records of their processing activities. In practice, the exemption for small organisations is narrow enough that most US SaaS companies should maintain Article 30 records regardless of whether they technically qualify for the exemption — supervisory authorities increasingly expect them, and customer privacy teams specifically ask for them.
The Article 30 record is structurally similar to the data mapping output but more formal. For controllers: purposes of processing, categories of data subjects, categories of personal data, recipients, international transfers, retention periods, and a general description of security measures. For processors: the controller on whose behalf processing is done, categories of processing, international transfers, and security measures.
Most SaaS companies are both controller and processor — controller for their own business data (employees, marketing contacts), processor for customer data handled on customers’ behalf. Maintain both records.
Legal bases. For each processing activity, document the GDPR Article 6 legal basis (consent, contract, legal obligation, vital interests, public task, legitimate interests). Special category data (Article 9) has its own tighter list. Claiming legitimate interests requires a documented Legitimate Interests Assessment that can be produced on demand.
Phase 2: Policy framework and DPIA process (months 2–3)
One month of policy work and process design.
Privacy policies. External-facing privacy notices addressing the Article 13 and 14 disclosure requirements — what data you collect, why, legal basis, retention, recipients, transfers, data subject rights, supervisory authority contact. Internal privacy policies governing how your team handles personal data — access controls, retention, deletion, training. Cookie policies and banners where applicable.
DPIA process. Data Protection Impact Assessments are required for high-risk processing — automated decision-making with legal or similarly significant effects, systematic monitoring of public spaces, large-scale processing of special category data, and other cases specified by supervisory authorities. The DPIA is not optional where it applies; it’s a prerequisite to processing. Build a DPIA template and a decision process that identifies when a DPIA is required before new processing begins.
Records of Data Subject Request process. Document how your organisation handles the rights discussed in Phase 3. Include request intake channels, identity verification procedures, response workflows, response time tracking, and escalation paths for complex cases.
Phase 3: Data subject rights infrastructure (months 3–4)
One month to build the infrastructure for handling rights requests.
GDPR grants data subjects a specific set of rights — access, rectification, erasure, restriction of processing, portability, and objection, plus rights related to automated decision-making. The common response time for a request is one month from receipt, extendable by a further two months for complex requests provided you notify the data subject within the first month.
The operational reality: a SaaS company serving EU or UK customers will eventually receive data subject requests. Sometimes from individual users. Sometimes from lawyers acting on their behalf. Sometimes as a batch from a customer’s privacy team passing through aggregated requests. The infrastructure needs to handle all three.
Intake. A privacy-specific contact channel (an email address or web form) prominently disclosed in privacy notices. The channel must be monitored and requests must be acknowledged — silence during the response period is a breach of the right in itself.
Identity verification. You can’t service an access request from someone whose identity you can’t verify. A documented verification procedure appropriate to the sensitivity of the data is required. Asking for government ID to verify a newsletter unsubscribe is disproportionate; asking for authentication via the same credentials that access the account is reasonable.
Access responses. Producing a copy of an individual’s personal data in an intelligible format. “Intelligible” rules out raw database exports in most cases. For SaaS companies this often means standing up a self-service export feature or a structured manual export process.
Erasure. The right to erasure is narrower than most users believe — it applies where the data is no longer needed, where consent has been withdrawn and no other basis applies, where processing was unlawful, or a few other grounds. Not every erasure request is valid. But responding to invalid requests still requires a documented response explaining the grounds, within the one-month window.
Portability. For processing based on consent or contract carried out by automated means, data subjects have the right to receive their personal data in a structured, commonly-used, machine-readable format. CSV or JSON satisfies this.
Phase 4: Vendor DPAs and cross-border transfer mechanisms (months 3–5)
Two months of contract work running in parallel with Phase 3.
Data Processing Agreements. GDPR Article 28 requires a written agreement between controllers and processors that includes specific terms — processing instructions, confidentiality obligations, security measures, sub-processor authorisation, audit rights, assistance with data subject requests, assistance with breach notification, deletion or return of data at end of processing. Every processor you use needs a DPA with these terms. Every sub-processor your processor uses needs equivalent downstream terms.
The practical work: inventory every third-party service that processes personal data on your behalf. For each, confirm a DPA is in place. For those without, request one — or use the vendor’s standard DPA if it’s substantively adequate. Vendors that won’t sign a DPA or whose DPA is clearly deficient need to be replaced or architected out of the personal data path.
Cross-border transfers. GDPR restricts transfers of personal data outside the EU/UK unless a transfer mechanism applies. The current options for US SaaS companies:
- EU-US Data Privacy Framework (DPF). In effect since July 2023, replacing the invalidated Privacy Shield. US organisations can self-certify to the DPF and become adequate recipients for transfers from the EU. The framework is subject to ongoing legal challenge, so self-certification is not a “once and done” decision — monitor the legal landscape.
- UK Extension to the DPF. Extends the DPF framework to cover transfers from the UK under UK GDPR.
- Standard Contractual Clauses (SCCs). The EU Commission’s standard-form clauses, mandatory template language included in cross-border contracts. Required alongside a transfer impact assessment. The UK has its own version (the International Data Transfer Agreement or the UK Addendum to the EU SCCs) for UK transfers.
- Binding Corporate Rules. Approved intragroup data protection policies for multinational organisations. High overhead, appropriate for large enterprises with substantial intra-group data flows.
For most US SaaS companies, the practical answer is DPF self-certification for US operations plus SCCs as a backup mechanism and for transfers that don’t fit DPF. Don’t treat DPF alone as sufficient — its legal durability remains contested and SCCs function as a belt-and-braces fallback.
Phase 5: Breach response and ongoing operations (months 5–6)
One month to build breach response infrastructure and operationalise the programme.
GDPR Article 33 requires notification of personal data breaches to the supervisory authority within 72 hours of becoming aware, where the breach is likely to result in risk to the rights and freedoms of natural persons. Article 34 requires notification to affected data subjects where the breach is likely to result in high risk. Seventy-two hours is a tight window; preparation is the difference between meeting it and missing it.
Build: a breach detection and escalation process integrated with your incident response, a breach assessment process that determines notification obligations, templates for supervisory authority notification and data subject notification, a decision log for every breach (notified or not) documenting the assessment.
Ongoing operational rhythms that run beyond Phase 5: quarterly review of Article 30 records, annual DPIA refresh for ongoing high-risk processing, ongoing monitoring of vendor list and DPA freshness, ongoing monitoring of data subject request volumes and response times, annual privacy training for all staff with access to personal data.
EU AI Act overlap
If your product uses AI, the EU AI Act layers on top of GDPR rather than replacing it. GDPR governs the processing of personal data; the EU AI Act governs the AI systems. For high-risk AI systems under the AI Act, both regimes apply simultaneously and a single compliance programme needs to address both. The EU AI Act compliance timeline covers the AI Act-specific implementation work for US SaaS with EU exposure; run it as a parallel programme where both regulations apply.
Where US companies underestimate effort
Four patterns account for most overruns.
Data mapping as a one-time exercise. The team maps data in Phase 1, produces an Article 30 record, and assumes the record stays current. By month eight, engineering has shipped a new feature that processes a new category of data, the Article 30 record isn’t updated, and a customer audit catches the gap. Mitigation: build Article 30 updates into product-development intake processes, not just into annual reviews.
DPIA process that nobody triggers. The team writes a DPIA template in Phase 2 and files it. New processing gets introduced in Phase 3 onwards without anyone asking whether a DPIA is required. Mitigation: privacy review as a required step in new-feature design, with the DPIA question explicit and documented.
Vendor DPAs collected but not tracked. The team collects DPAs in Phase 4 and never revisits them. Vendors change DPA terms, sub-processor lists expand, some vendors get replaced but the old DPA record persists. Mitigation: a DPA register with vendor, DPA version, date collected, key terms, next review date. Reviewed at least annually.
Data subject requests handled manually without tracking. The team handles the first few access requests ad-hoc. Request volumes grow, response times start slipping, and the team has no record of how long requests have been outstanding until a supervisory authority complaint surfaces. Mitigation: request intake logged from day one, response time tracked, SLA monitored.
The pattern: GDPR rewards programmes that treat it as an operational discipline and punishes programmes that treat it as a project. The implementation is the project; the programme is forever.
FAQ
Does GDPR apply to my US SaaS if I have no European offices?
If you offer goods or services to individuals in the EU or UK, or monitor their behaviour, yes. The threshold is low. “No offices in Europe” doesn’t exempt you.
What’s the difference between EU GDPR and UK GDPR?
They’re substantively similar — the UK GDPR is based on the EU text with national derogations. They diverge on international transfers, the supervisory authority (ICO in the UK, separate data protection authorities in each EU member state), and a handful of national provisions. Operate to both where you serve both markets.
Do I need a Data Protection Officer?
GDPR requires a DPO for public authorities, for core activities involving regular and systematic monitoring on a large scale, or for large-scale processing of special category data. Most US SaaS companies aren’t required to appoint one, but many customer privacy teams ask about DPO status during procurement. A privacy lead with clear responsibility is appropriate where a formal DPO isn’t required.
Is self-certification to the Data Privacy Framework sufficient for EU transfers?
Legally, yes — at present. Practically, many privacy-sophisticated EU customers ask for SCCs in addition. The DPF is subject to ongoing legal challenge; most mature programmes maintain SCC-based transfer mechanisms alongside DPF self-certification.
What’s the penalty for GDPR non-compliance?
Tiered fines up to 4% of worldwide annual turnover or €20 million, whichever is higher, for the most serious infringements. Lower-tier infringements up to 2% / €10 million. Enforcement practice varies by supervisory authority and by nature of the infringement; multi-million-euro fines on US tech companies are well-documented.
How long do I have to respond to a data subject request?
One month from receipt. Extendable by a further two months for complex or numerous requests, provided you notify the data subject within the first month.
Do I need cookie banners?
Under ePrivacy (separate from but adjacent to GDPR), consent is generally required before setting non-essential cookies on EU visitors’ devices. The ePrivacy regime and its national implementations are separately enforced from GDPR, and yes, you need a compliant consent mechanism for most SaaS websites serving EU traffic.
Does GDPR apply if I only process business contact data?
Business contact data — names, titles, work emails of individuals in their professional capacity — is still personal data under GDPR. Processing is often legitimate under a legitimate interests basis, but the data subject rights and breach notification obligations still apply.
Do I need to localise EU personal data to EU servers?
No. GDPR does not mandate data localisation. It restricts international transfers unless an appropriate mechanism (DPF, SCCs, etc.) applies. Storing EU personal data on US infrastructure is lawful under the current mechanisms but needs the documentation to support the transfer.
How does CCPA/CPRA relate to GDPR?
They’re different regimes with some overlap. CCPA/CPRA applies to California residents and has California-specific rights and thresholds. GDPR applies to EU/UK data subjects. A company serving both jurisdictions runs both programmes, though internal infrastructure (rights request handling, data mapping) is often shared.