If you’re a US-based B2B SaaS company with no EU entity, no EU employees, and no EU office, you might assume GDPR doesn’t apply to you. That assumption is wrong the moment you have a customer with EU-based end users.
GDPR applies to the processing of personal data of individuals in the EU, regardless of where the processor is located. If your SaaS product processes data about EU residents on behalf of your customers, GDPR reaches you. The same principle applies to UK GDPR for individuals in the United Kingdom.
The good news: your obligations as a processor (the role most B2B SaaS companies occupy for customer data) are more contained than the full GDPR framework that applies to controllers. The practical compliance path for a US B2B SaaS company is manageable if you understand what’s required and implement it through your existing document stack.
When GDPR Triggers
GDPR applies to your company in two scenarios.
First, if you have an establishment in the EU (an office, an entity, employees) and process personal data in the context of that establishment’s activities. Most US B2B SaaS companies at seed stage don’t have this.
Second, and more commonly, if you process personal data of individuals in the EU in connection with offering goods or services to them, or monitoring their behavior within the EU. For a B2B SaaS company, this typically triggers when your customer is an EU-based business whose employees use your product, or when your customer is a US or non-EU business with EU-based employees or end users whose data flows through your platform.
The trigger is the location of the data subjects (the end users), not the location of your customer’s headquarters or your own. A US customer with a London office whose employees use your product means you’re processing UK personal data. A German company signing up for your service means you’re processing EU personal data. In both cases, the relevant data protection framework applies.
UK GDPR: The Same Framework, Different Jurisdiction
The UK left the EU but retained GDPR in substance as the UK GDPR, enforced by the Information Commissioner’s Office (ICO). For practical purposes, UK GDPR imposes the same obligations as EU GDPR, with a few differences in supervisory authority, transfer mechanisms, and enforcement.
For US B2B SaaS companies, the UK market is significant. It’s the largest English-speaking market in Europe and often the first international market US SaaS companies enter. If you have UK customers or customers with UK-based end users, UK GDPR applies alongside (or instead of) EU GDPR depending on where the data subjects are located.
The practical approach: treat EU GDPR and UK GDPR as a single compliance program with jurisdiction-specific transfer mechanisms. The substantive obligations are nearly identical. The differences are in how you transfer data across borders, which we’ll cover below.
Your Obligations as a Processor
As a B2B SaaS provider processing customer data, you’re typically a processor under GDPR (or a “service provider” under CCPA, as covered in the previous post). Your customer is the controller. This distinction significantly narrows your obligations compared to what a controller must do.
Your processor-specific obligations include:
Process data only on documented instructions. You can only process personal data in accordance with the controller’s (your customer’s) instructions. Those instructions are documented in your DPA. This is why having a DPA is required under GDPR, not optional.
Maintain records of processing activities. You must maintain a record of the categories of processing you carry out on behalf of your customers. This doesn’t need to be a complex system. A documented record of what data you process, for which categories of customers, and for what purposes satisfies the requirement.
Implement appropriate security measures. You must implement technical and organizational measures appropriate to the risk. What’s “appropriate” depends on the nature of the data and the processing. For most B2B SaaS companies, this means encryption in transit and at rest, access controls, monitoring and logging, and incident response procedures. Your DPA’s security schedule (Schedule B) should document these measures.
Notify the controller of data breaches. If you become aware of a personal data breach, you must notify the controller (your customer) without undue delay. Under GDPR, the controller has 72 hours from becoming aware of a breach to notify the relevant supervisory authority. That means your notification to the controller needs to happen fast enough to give them time to assess the situation and meet their own 72-hour deadline. Your DPA should specify the processor-to-controller notification timeline explicitly. If your DPA says 48 hours or “without undue delay,” make sure your incident response process can actually deliver on that commitment. A notification timeline you can’t meet becomes an independent contractual breach on top of the underlying incident.
Assist with data subject rights requests. When your customer receives a request from a data subject (access, deletion, correction, portability), you must assist the customer in fulfilling that request. This means your platform needs the technical capability to export, delete, or correct individual user data on request.
Engage subprocessors only with authorization. You need either specific or general prior written authorization from the controller before engaging subprocessors. Under general authorization (the more common approach in B2B SaaS), you must notify customers of any intended changes to your subprocessor list and give them an opportunity to object.
Delete or return data on termination. When the processing relationship ends, you must delete or return all personal data to the controller, unless EU or member state law requires continued storage.
Make available information necessary for audits. You must make available to the controller all information necessary to demonstrate compliance with GDPR processor obligations and allow for audits.
The Data Processing Addendum Is Your Primary Compliance Mechanism
For a US B2B SaaS company, the DPA is where GDPR compliance lives contractually. Article 28 of the GDPR requires a binding contract between the controller and processor that sets out the subject matter and duration of processing, the nature and purpose, the type of personal data, the categories of data subjects, and the obligations and rights of both parties.
If you don’t have a DPA, you can’t demonstrate GDPR compliance as a processor, and your EU/UK customers can’t demonstrate that they’ve met their obligation to only use processors that provide sufficient guarantees. This is another reason the DPA is part of the core document stack from day one, as covered in the first post in this series.
Your DPA should include a GDPR-specific section or annex that addresses the processor obligations listed above. If your DPA was drafted primarily for US compliance (CCPA service provider framework), review it to confirm it satisfies Article 28 requirements. The frameworks overlap but aren’t identical.
International Data Transfers: Getting Data From the EU/UK to the US
This is the area that causes the most confusion for US companies. When personal data moves from the EU or UK to the US, GDPR requires a legal mechanism to authorize that transfer.
There are currently two primary mechanisms available to US B2B SaaS companies.
EU-US Data Privacy Framework (DPF)
The DPF is a self-certification program administered by the US Department of Commerce. Companies that self-certify commit to adhering to the DPF Principles (notice, choice, accountability for onward transfers, security, data integrity, access, and enforcement). Self-certified companies appear on the official Data Privacy Framework List, and EU/UK data exporters can verify certification status before transferring data.
Self-certification is available to companies subject to FTC or DOT jurisdiction (which covers most US commercial entities). The process involves registering on the DPF website (dataprivacyframework.gov), updating your privacy policy to reflect DPF participation, designating an independent dispute resolution mechanism, making a contribution to the ICDR-AAA binding arbitration mechanism, and implementing internal procedures to verify compliance with the DPF Principles. Certification must be renewed annually.
The UK Extension to the EU-US DPF provides the equivalent mechanism for UK data transfers. To participate in the UK Extension, you must first participate in the EU-US DPF.
The DPF is the most streamlined transfer mechanism available. If you’re eligible, self-certification simplifies your compliance posture and reduces friction with EU/UK customers who need to verify that data transfers have a legal basis.
Standard Contractual Clauses (SCCs)
SCCs are pre-approved contractual terms adopted by the European Commission that provide adequate safeguards for data transfers. They’re incorporated into your DPA as an annex and don’t require separate certification or registration.
For the EU, the current SCCs were adopted in 2021 and include modular clauses for different transfer scenarios (controller-to-processor, processor-to-processor, etc.). For the UK, the International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs serves the equivalent function.
SCCs are the fallback mechanism if you’re not self-certified under the DPF, or as a belt-and-suspenders approach alongside DPF certification. Many companies maintain both: DPF as the primary mechanism and SCCs in the DPA as a backup in case DPF status lapses or is challenged.
When using SCCs, you should also conduct a Transfer Impact Assessment (TIA) evaluating whether the legal framework in the destination country (the US) provides adequate protection for the transferred data. The TIA should consider US surveillance laws, your security measures, and any supplementary measures you implement to mitigate risk.
Which to Use
For most US B2B SaaS companies, the recommended approach is: self-certify under the DPF as your primary transfer mechanism, include SCCs in your DPA as a backup, and document a Transfer Impact Assessment. This layered approach provides maximum legal certainty and insulates you from disruption if any single mechanism is challenged.
The Practical Minimum
If you’re a US B2B SaaS company with EU or UK customers (or customers with EU/UK end users), here’s the minimum you should implement:
Have a DPA that satisfies GDPR Article 28 requirements, including a GDPR-specific section or annex addressing processor obligations, subprocessor management, breach notification, data subject rights assistance, and audit cooperation.
Self-certify under the EU-US Data Privacy Framework (and the UK Extension) through the Department of Commerce. Include SCCs in your DPA as a backup transfer mechanism.
Maintain a subprocessor list and a process for notifying customers of changes.
Update your privacy policy to disclose your DPF participation, your role as a processor for customer data, and your data transfer mechanisms.
Implement security measures consistent with what your DPA commits to and what your SOC 2 report (if you have one) describes.
Maintain a record of processing activities.
Ensure your platform can technically support data subject rights requests (access, deletion, correction, portability) when passed through by your customers.
None of this requires establishing an EU entity or appointing a local representative (though Article 27 of GDPR may require a representative in certain circumstances). For most seed-stage B2B SaaS companies, the compliance path runs through your existing documents and infrastructure, not through new legal entities.
No Boiler provides self-service legal document generation and educational content. This material and our service is not a substitute for legal advice. Please have a qualified attorney review any documents before relying on them. No Boiler is not a law firm, and communications with us do not create an attorney-client relationship or carry any expectation of confidentiality. Use of our platform and content is governed by our Terms of Service and Privacy Policy.
This is the final post in the Privacy Policy pillar. Previously: Cookie Policies, Analytics, and Tracking: The B2B Edition. Next: What Is a DPA and Why Your Enterprise Customers Keep Asking for One.