GDPR for US SaaS: A No-Nonsense Guide
You're a US-based SaaS company. You built your product for the American market. Then a customer in Germany signs up — or a US enterprise client tells you they have employees in the EU.
Suddenly, GDPR applies to you.
This is increasingly common. The question isn't whether US SaaS companies need to think about GDPR. It's how to comply without overengineering your approach or grinding your business to a halt.
Does GDPR Actually Apply to You?
GDPR applies to your company if you:
Process personal data of people in the EU. This includes EU customers, EU employees of your customers, or EU website visitors. "Personal data" is broad — names, email addresses, IP addresses, and cookie identifiers all count.
Offer goods or services to people in the EU. If your website accepts euros, has an EU-specific domain, or markets in EU languages, you're likely in scope. A US company with a purely domestic focus that happens to get occasional EU traffic is in a grayer area — but once you actively pursue EU customers, the analysis becomes clear.
Monitor the behavior of people in the EU. If you track EU visitors with analytics, retargeting pixels, or behavioral profiling, GDPR applies to that processing.
The practical reality: if you have any meaningful EU presence — customers, users, or active marketing — assume GDPR applies.
Controller vs. Processor: Why It Matters
GDPR distinguishes between two roles, and your obligations depend on which one you occupy.
Controller. You determine why and how personal data is processed. If you're collecting data for your own purposes — marketing your product, analyzing usage patterns, billing customers — you're a controller.
Processor. You process data on behalf of someone else, following their instructions. If an enterprise customer uploads their employee data to your HR platform, you're processing that data for them. They're the controller; you're the processor.
Most SaaS companies are both:
You're a controller for data you collect directly (website visitors, your own customers' contact info, your marketing lists)
You're a processor for customer data that flows through your platform (the data your customers input or their end users generate)
This dual role means you need to address both sets of obligations.
The Six Things US SaaS Companies Must Get Right
1. Lawful Basis for Processing
Every processing activity needs a legal justification. The three most relevant for SaaS:
Contract. You need to process certain data to deliver your service. An email platform needs email addresses to send emails. A CRM needs contact records to function. This basis covers processing that's genuinely necessary to perform your service.
Legitimate interest. You have a business reason to process data, and that reason doesn't override the individual's rights. Product analytics, fraud prevention, and basic security monitoring typically fall here. You need to document a "legitimate interest assessment" showing you've balanced your interests against the user's.
Consent. The individual agreed to the processing. This is required for marketing emails, non-essential cookies, and any processing that doesn't fit neatly into another category. GDPR consent must be freely given, specific, informed, and unambiguous — pre-checked boxes don't count.
Common mistake: Relying on consent when contract or legitimate interest would work better. Consent can be withdrawn at any time, which creates operational complexity. Use it when required, not as a default.
2. Data Processing Agreements
When you process data on behalf of customers (as a processor), GDPR requires a written contract — commonly called a Data Processing Agreement or DPA.
What a DPA must include:
The subject matter and duration of processing
The nature and purpose of processing
The types of personal data processed
Your obligations as a processor (security measures, confidentiality, audit rights)
Sub-processor terms (more on this below)
Data deletion or return upon termination
Assistance with data subject requests
Practical approach: Create a standard DPA and make it available on your website. Many SaaS companies link to a pre-signed DPA from their Terms of Service, making it automatically part of every customer contract. This scales better than negotiating individual DPAs.
When enterprise customers send their own DPA, review it against the same checklist you use for customer contracts generally: liability exposure, audit obligations you can actually meet, breach notification timelines that are realistic.
3. Sub-Processor Management
If you use third-party services that process personal data on your behalf — cloud hosting, email delivery, analytics, payment processing — those vendors are your sub-processors under GDPR.
Your obligations:
Maintain a list of sub-processors (most companies publish this on their website)
Have DPAs in place with each sub-processor
Notify customers when you add new sub-processors (your DPA should specify how — usually email notice with a window to object)
Take responsibility for your sub-processors' compliance
Practical approach: Audit your vendor stack. Identify every service that touches personal data. Confirm each has GDPR-compliant terms (most major vendors do — AWS, Google Cloud, Stripe, etc. all have DPAs available). Publish your sub-processor list and create a process for updating it when you add new vendors.
4. Cross-Border Data Transfers
This is where US companies face the most complexity. GDPR restricts transfers of personal data outside the EU unless certain safeguards are in place.
The current landscape:
The EU-US Data Privacy Framework (DPF), adopted in 2023, provides a mechanism for US companies to receive EU personal data. If you self-certify under the DPF, transfers from the EU to your US systems are permitted.
To certify under the DPF:
Register with the US Department of Commerce
Develop a compliant privacy policy
Implement the required privacy principles
Establish a dispute resolution mechanism
Renew annually
If you don't certify under the DPF, you'll need an alternative transfer mechanism:
Standard Contractual Clauses (SCCs). Pre-approved contract terms that you incorporate into your agreements. The current version (adopted 2021) is modular — you select the clauses that match your role (controller-to-controller, controller-to-processor, etc.). SCCs require a "transfer impact assessment" documenting that the recipient country's laws don't undermine the protections.
Binding Corporate Rules. For transfers within a corporate group. Complex to implement, primarily used by large multinationals.
Practical approach for most US SaaS companies: Certify under the Data Privacy Framework if you have meaningful EU business. It's simpler than managing SCCs and signals credibility to EU customers. If certification isn't feasible, implement SCCs and document your transfer impact assessment.
5. Data Subject Rights
GDPR gives individuals rights over their data. You need processes to handle these requests.
The key rights:
Access. Individuals can request a copy of their data. You must respond within one month.
Rectification. Individuals can request correction of inaccurate data.
Erasure ("right to be forgotten"). Individuals can request deletion of their data in certain circumstances. This doesn't mean you must delete everything immediately — you can retain data necessary for legal compliance, contract performance, or legitimate interests that override the request.
Portability. Individuals can request their data in a machine-readable format.
Objection. Individuals can object to processing based on legitimate interest. You must stop unless you can demonstrate compelling grounds.
Practical approach: Build internal workflows for handling these requests. Most SaaS companies designate someone (often in legal, compliance, or customer success) to triage incoming requests, verify the requester's identity, and coordinate the response. Document your process and train relevant teams.
For processor relationships, your DPA should clarify that the customer (controller) handles data subject requests, and you assist as needed.
6. Security and Breach Notification
GDPR requires "appropriate technical and organizational measures" to protect personal data. What's appropriate depends on the risk — a healthcare platform needs stronger controls than a project management tool.
Baseline expectations:
Encryption in transit and at rest
Access controls and authentication
Regular security assessments
Employee training
Incident response procedures
Breach notification:
If you experience a breach involving EU personal data:
Notify the supervisory authority within 72 hours of becoming aware (unless the breach is unlikely to result in risk to individuals)
Notify affected individuals without undue delay if the breach poses high risk to their rights
Document all breaches, even those that don't require notification
Your DPA should specify how you notify customers of breaches. A common approach: notify the customer within a set timeframe (48-72 hours), and let them handle notification to the supervisory authority since they're the controller.
What You Need on Your Website
Privacy policy. GDPR requires specific disclosures: what data you collect, why, how long you retain it, who you share it with, what rights users have, and how to contact you. Your policy should be clear and accessible — not buried legal jargon.
Cookie consent. If you use non-essential cookies (analytics, advertising, tracking), you need consent before setting them for EU visitors. This means a cookie banner that allows users to accept or reject categories of cookies — not just a notice that cookies exist.
Contact point. Individuals need a way to exercise their rights. Include a privacy contact email (privacy@yourcompany.com is common).
EU representative (if applicable). If you're not established in the EU but process EU data at scale, you may need to appoint an EU-based representative. This requirement has exceptions for occasional processing that doesn't involve sensitive data.
Common Mistakes US Companies Make
Ignoring GDPR because "we're not in the EU." Jurisdiction is based on whose data you process, not where you're located. If you have EU customers, GDPR applies.
Treating GDPR as a one-time project. Compliance is ongoing. New features need privacy review. New vendors need DPA review. Policies need periodic updates.
Over-relying on consent. Consent creates operational overhead and user friction. Use contract or legitimate interest where appropriate, and reserve consent for processing that genuinely requires it.
Copying a competitor's privacy policy. Your privacy policy should reflect your actual data practices, not a generic template. Inaccurate policies create liability.
Assuming your vendors are compliant. You're responsible for your sub-processors. Verify they have appropriate terms and practices in place.
Panic-deleting data. Not every deletion request requires immediate action. You have grounds to retain data for legal compliance, contract performance, and other legitimate purposes. Assess each request against the applicable exceptions.
Building GDPR Into Your Operations
For early-stage companies:
Start with the fundamentals:
A clear, accurate privacy policy
A standard DPA available for customers
Cookie consent for EU visitors
A documented process for data subject requests
DPAs in place with your key vendors
This foundation handles most situations and positions you for enterprise sales.
For scaling companies:
Add operational maturity:
Privacy review as part of your product development process
Regular vendor audits
Data mapping (what data you have, where it flows, how long you retain it)
Training for customer-facing teams
Incident response procedures
For enterprise-focused companies:
Expect deeper diligence:
Security certifications (SOC 2 is often expected alongside GDPR compliance)
Data Privacy Framework certification
Published sub-processor lists with change notification
Detailed technical and organizational measures documentation
Ability to support customer audits
When to Get Help
GDPR compliance doesn't always require outside counsel, but certain situations warrant expert input:
You're entering a heavily regulated industry (healthcare, financial services)
You're processing sensitive data (health, biometrics, children's data)
A supervisory authority contacts you
You experience a significant data breach
An enterprise customer presents a heavily negotiated DPA
You're expanding with a physical EU presence
For routine compliance — privacy policies, standard DPAs, cookie banners — many SaaS companies handle this in-house with occasional legal review.
Conclusion
GDPR compliance for US SaaS companies isn't about checking every box in the regulation. It's about building data protection into how you operate: being clear about what data you collect and why, giving individuals control where required, protecting the data you hold, and being transparent when things go wrong.
Start with the six fundamentals. Build processes that scale. And recognize that getting this right isn't just about avoiding fines — it's increasingly a requirement for doing business with privacy-conscious customers.
Need help with GDPR compliance for your SaaS company? Reach out for a consultation.