If your SaaS has a single paying customer in the EU — or even a free-tier user in Germany who signed up with their personal email — GDPR applies to you. It doesn't matter that your company is incorporated in Delaware and your servers are in Virginia. The EU's General Data Protection Regulation has extraterritorial reach, and that means US founders need to care about it.
The good news: GDPR compliance for a B2B SaaS startup is far less daunting than the consultants selling €50,000 projects make it sound. You don't need a Data Protection Officer on day one. You don't need to re-architect your entire database. You need to be systematic about a manageable set of requirements.
This is the minimal viable checklist — what you actually need, prioritized by risk.
Disclaimer: This is practical guidance, not legal advice. For your specific situation, especially if you're processing sensitive categories of data (health, financial, biometric), consult a qualified privacy lawyer. That said, everything below reflects common practice for B2B SaaS companies at the startup stage.
1. Establish a Lawful Basis for Every Type of Processing
GDPR Article 6 requires that every time you process personal data, you have a lawful basis for doing so. There are six options, but for B2B SaaS, two cover the vast majority of use cases:
- Contractual necessity (Article 6(1)(b)): You need the data to perform the contract. For B2B SaaS, this covers processing customer account data, usage data, and anything you need to deliver the service. This is your primary lawful basis for core product functionality.
- Legitimate interests (Article 6(1)(f)): You have a legitimate business reason that outweighs the individual's privacy interests. Marketing to existing customers, fraud prevention, and product analytics typically fall here. You need to document your legitimate interests assessment (LIA) — a short written analysis of why your interests outweigh the privacy impact.
- Consent (Article 6(1)(a)): Often over-relied upon by startups because it sounds straightforward. Consent must be specific, informed, and freely given — and users must be able to withdraw it easily. For B2B SaaS, consent is rarely the right lawful basis for core processing. It is appropriate for optional marketing newsletters.
Practical step: build a Record of Processing Activities (RoPA). This is a spreadsheet mapping each type of personal data you collect, what you use it for, and the lawful basis for that use. GDPR Article 30 formally requires this for companies with 250+ employees, but smaller companies who have a data breach and can't produce one will face regulatory scrutiny. It takes a day to build and protects you significantly.
2. Rewrite Your Privacy Policy
Most US startup privacy policies fail GDPR requirements. A GDPR-compliant privacy policy must include, in plain language:
- The identity and contact details of the data controller (that's you)
- The contact details of your Data Protection Officer, if you have one
- The purposes and lawful basis for each type of processing
- Any legitimate interests you rely on
- The categories of personal data you collect
- Who you share data with (including categories of recipients)
- Whether data is transferred outside the EU and under what safeguards (e.g., Standard Contractual Clauses)
- How long you retain each category of data
- The individual rights available to users and how to exercise them
- The right to lodge a complaint with a supervisory authority
A Termly or Iubenda-generated policy can cover most of these if configured correctly. For a company processing any significant volume of EU data, a lawyer-reviewed custom policy is worth the $500–$1,500 investment.
3. Sign Data Processing Agreements (DPAs) with Every Vendor
If you share personal data with any third-party vendor — even just passing an email address to an email marketing platform — you are legally required to have a Data Processing Agreement in place. This is GDPR Article 28.
A DPA specifies what the processor can do with the data, security measures they must implement, how they handle breaches, and how data is deleted when the relationship ends.
The practical steps:
- Identify all processors: Any SaaS tool that touches personal data from your EU users — Stripe, Intercom, Mixpanel, AWS, SendGrid, Salesforce, Zendesk, etc.
- Check if they already have a standard DPA: Most major vendors (AWS, Google, Stripe) have pre-signed DPAs available in their settings or legal portals. Accept them. This takes 5 minutes per vendor.
- For smaller vendors without a standard DPA: You can either use a template (the ICO has one) or simply not use that vendor for data involving EU individuals until they can sign one.
Maintain a vendor register documenting which processors you use, what data they access, where they store it, and the DPA status. This is the document DPA regulators ask for first in an investigation.
4. Build a Process for Data Subject Access Requests (DSARs)
Under GDPR, any EU individual can request to know what data you hold about them (access request), ask you to delete it (right to erasure), ask you to correct inaccurate data, or request a portable copy. You have 30 days to respond from the date of a valid request.
For a startup, "process" doesn't mean enterprise software. It means:
- A designated email address (e.g., privacy@yourcompany.com) for receiving requests
- A simple checklist of everywhere you store personal data (your database, Stripe, Intercom, your email tool)
- A process for verifying the requester's identity before disclosing data
- A template response document
- A log of requests received and responses sent
Most B2B SaaS companies in the startup phase receive zero to a handful of DSARs per year. The risk isn't volume — it's being caught with no process at all when a regulator asks how you handle them.
5. Cookie Consent (and Why It's More Annoying Than Risky)
Cookie banners are required if you use cookies for non-essential purposes (analytics, advertising, tracking) on pages accessible to EU users. The rules come from the ePrivacy Directive, which predates GDPR, but are enforced alongside it.
The minimal viable implementation for B2B SaaS:
- Use a consent management platform: Cookieyes, Axeptio, or Osano all have free or low-cost tiers.
- Categorize your cookies honestly: session cookies and security cookies are typically "necessary" and don't require consent. Analytics (Google Analytics, Mixpanel, Hotjar) require consent.
- Don't set non-essential cookies before consent is given — this is the most common violation and the one regulators actually test for.
- Provide a genuine "reject all" option. A banner that only offers "Accept" is a violation.
If your product is B2B SaaS and the cookies in question are only firing for logged-in users who are employees of your B2B customers, the regulatory risk is lower. The high-risk scenario is a public marketing site with aggressive tracking before any consent is obtained.
6. The 72-Hour Breach Notification Rule
GDPR Article 33 requires you to notify your lead supervisory authority within 72 hours of becoming aware of a personal data breach. "Breach" includes unauthorized access, accidental deletion, ransomware, and even sending an email containing personal data to the wrong recipient.
The 72-hour clock starts when you "become aware" — which regulators interpret as when anyone in your organization knew, not just when leadership was formally informed.
Practical implication: Your incident response runbook needs a GDPR escalation path. As soon as anyone on your team suspects a breach involving EU personal data, the clock starts. The first 4 hours should be: confirm the breach, assess scope, notify your DPO or privacy lead, begin the notification assessment. You don't have to have all the answers within 72 hours — but you do have to notify the supervisory authority with the information you have.
If the breach is likely to result in high risk to individuals, you must also notify the affected individuals directly — and there's no fixed timeline for that, but "without undue delay" means as fast as reasonably possible.
7. Standard Contractual Clauses (SCCs) for Data Transfers
If you transfer personal data from the EU to the US — which you do if EU users' data hits US servers — you need a legal transfer mechanism. Since the invalidation of Privacy Shield in 2020, the primary mechanism for US companies is Standard Contractual Clauses (SCCs), updated in 2021 by the European Commission.
The updated 2021 SCCs must be incorporated into your DPAs with EU customers and your agreements with subprocessors. AWS, Google Cloud, and Azure all offer EU SCCs as part of their data processing agreements. For your own customer contracts, you need either to include the SCCs directly or reference them in your DPA.
The EU-US Data Privacy Framework (DPF) reinstated in 2023 provides an alternative certification pathway for US companies that prefer not to use SCCs. Certification costs around $1,500 per year and requires you to comply with DPF principles. For startups, SCCs are typically simpler.
The Minimal Viable GDPR Checklist
- Map all personal data you collect and document lawful basis in a RoPA
- Rewrite your privacy policy to include all GDPR-required disclosures
- Sign DPAs with every third-party processor (check vendor portals first)
- Create a DSAR process: designated email, identity verification, 30-day SLA
- Implement a cookie consent manager that allows genuine rejection
- Add GDPR breach notification escalation to your incident response plan
- Include 2021 SCCs in your customer DPA and sub-processor agreements
- Maintain a vendor register documenting all processors and their DPA status
- Implement data minimization: don't collect data you don't have a purpose for
- Define retention periods: know how long you keep each category of data