If you are a US B2B SaaS company with customers in the EU or UK, personal data is crossing borders every time those customers use your product. GDPR does not care that you have no office in Berlin or Dublin. It cares that personal data originating in the European Economic Area is being processed on servers in Virginia, and it requires a legal mechanism authorizing that transfer.
This is the area where founders get tripped up most often. Not because the rules are impossibly complex, but because the landscape has been unstable for a decade and the compliance guidance tends to assume you have a privacy team and outside counsel on retainer. You probably do not. So here is what you actually need to understand and implement.
A Brief History of Instability
To understand why this matters and why simply picking a transfer mechanism is not enough, you need the context of how we got here.
The EU and the US have tried three times to create a framework allowing personal data to flow across the Atlantic. The first attempt, Safe Harbor, was struck down by the Court of Justice of the European Union in 2015 after Edward Snowden’s disclosures revealed the scope of US surveillance programs. The second attempt, Privacy Shield, lasted from 2016 to 2020 before the same court invalidated it in a case called Schrems II, again over concerns that US intelligence agencies could access European personal data without adequate judicial oversight.
The third attempt is the EU-US Data Privacy Framework, adopted in July 2023. It is currently in force. Whether it remains in force is an open question, and that uncertainty directly shapes how you should structure your compliance.
Understanding this history matters because it explains why experienced procurement teams and European customers do not simply accept “we’re DPF-certified” as a complete answer. They have been through two invalidations. They want to see fallback mechanisms.
The Two Primary Transfer Mechanisms
For a US B2B SaaS company, there are two practical mechanisms for authorizing data transfers from the EU and UK: the Data Privacy Framework and Standard Contractual Clauses.
EU-US Data Privacy Framework
The DPF is a self-certification program administered by the US Department of Commerce. Companies that self-certify commit to adhering to a set of principles covering notice, choice, accountability for onward transfers, security, data integrity, access, and enforcement. Self-certified companies appear on the official Data Privacy Framework List, and European 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 dataprivacyframework.gov, updating your privacy policy to reflect DPF participation, designating an independent dispute resolution mechanism, contributing 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.
When it works, the DPF is the most streamlined transfer mechanism available. Self-certification simplifies your compliance posture and reduces friction with EU and UK customers who need to verify that their data transfers have a legal basis.
Standard Contractual Clauses
SCCs are pre-approved contractual terms adopted by the European Commission that provide adequate safeguards for data transfers. They are incorporated into your DPA as an annex and do not require separate certification or registration.
For the EU, the current SCCs were adopted in 2021 and use a modular structure covering different transfer scenarios. The two modules relevant to B2B SaaS are Module 2 (controller-to-processor, covering the standard scenario where your EU customer transfers personal data to you for processing) and Module 3 (processor-to-processor, covering transfers from you to your US-based subprocessors).
For the UK, the equivalent mechanisms are the International Data Transfer Agreement or the UK Addendum to the EU SCCs. Both serve the same function but reflect UK-specific requirements under the UK GDPR and the Data Protection Act 2018.
SCCs are the fallback mechanism if you are not self-certified under the DPF, or they serve as a belt-and-suspenders layer alongside DPF certification. The critical point: SCCs are contractual. They get incorporated into your DPA. This means having a properly structured DPA is a prerequisite to relying on SCCs as your transfer mechanism.
Transfer Impact Assessments
When using SCCs, you should also conduct a Transfer Impact Assessment evaluating whether the legal framework in the destination country provides adequate protection for the transferred data. A TIA is not a one-time document you file and forget. It should consider US surveillance laws, the security measures you implement, any supplementary measures you apply, and the practical likelihood that authorities would actually seek access to the specific categories of personal data you process.
For most seed-stage B2B SaaS companies processing business contact data and usage analytics, the practical risk profile is low. That does not mean you skip the TIA. It means the TIA is straightforward to complete and defend.
Why You Need Both (Not Either/Or)
The recommended approach for most US B2B SaaS companies is layered: 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 is not overcautious lawyering. This is practical risk management informed by the history outlined above.
The DPF’s two predecessors were both invalidated by the CJEU. The current framework survived its first legal challenge in September 2025 when the EU General Court dismissed a case brought by French parliamentarian Philippe Latombe. But that decision has been appealed to the CJEU, where the prior frameworks were struck down, and a ruling is pending.
Meanwhile, in January 2025 the Trump administration removed the Democratic members of the Privacy and Civil Liberties Oversight Board, leaving it without a quorum. The PCLOB was a key element of the oversight architecture that the European Commission relied on when issuing its adequacy decision. Its effective non-functionality has drawn concern from European regulators, including Norway’s Datatilsynet, which recommended that businesses prepare contingency plans.
None of this means the DPF is about to collapse tomorrow. A CJEU challenge would take months or years to resolve. The European Commission has stated it is monitoring the situation. But if you have only DPF certification with no SCCs in your DPA, and the framework is invalidated, you have no authorized transfer mechanism the day the decision lands. Every transfer of personal data from the EU becomes unlawful.
If you have SCCs in your DPA alongside DPF certification, you switch from one mechanism to the other without interrupting your business or renegotiating every customer contract.
How This Shows Up in Your DPA
Your DPA should contain a section on international data transfers that specifies which mechanisms apply. There are three common structures.
The first is DPF-only. Your DPA states that transfers are authorized under the EU-US Data Privacy Framework and references your certification. This is the simplest but carries the risk described above.
The second is SCCs-only. Your DPA incorporates the EU SCCs (Modules 2 and 3) as an annex, with the required annexes specifying the parties, the data being transferred, and the technical and organizational security measures. For UK transfers, you include the UK Addendum or IDTA. This is the most conservative approach and does not require DPF certification.
The third is DPF primary with SCC fallback. Your DPA provides that transfers are primarily authorized under the DPF, and incorporates SCCs as a fallback mechanism that automatically activates if DPF certification lapses or the adequacy decision is suspended, withdrawn, or invalidated. This is the approach most experienced privacy counsel recommend.
In all three structures, your DPA should also address your subprocessors. If you are transferring personal data to US-based subprocessors (your cloud provider, your analytics tools, your payment processor), those onward transfers also need a legal basis. The SCC Module 3 (processor-to-processor) covers this scenario when incorporated into your subprocessor agreements.
The UK Wrinkle
The UK operates its own data protection regime under the UK GDPR and the Data Protection Act 2018. While closely aligned with EU GDPR, UK transfer mechanisms are technically separate.
The UK Extension to the EU-US DPF allows US companies to receive personal data from the UK under the same self-certification framework. Participation in the UK Extension requires first being certified under the EU-US DPF.
For SCCs, the UK uses either the International Data Transfer Agreement (a standalone UK instrument) or the UK Addendum to the EU SCCs. The addendum approach is more common in practice because it lets you incorporate the EU SCCs and the UK provisions as a single package in your DPA rather than maintaining two parallel transfer agreements.
If you have both EU and UK customers, which most B2B SaaS companies serving European markets do, your DPA should address both regimes.
What About Canada?
Canadian transfers are simpler for US B2B SaaS companies. Canada’s federal privacy law, PIPEDA, does not use the same adequacy framework as GDPR. Cross-border transfers under PIPEDA are permitted as long as the transferring organization ensures a comparable level of protection through contractual or other means. Your DPA and the security commitments in it generally satisfy this requirement.
The practical step: ensure your DPA covers Canadian personal information alongside EU and UK personal data, and that your privacy policy discloses that data may be processed in the United States.
The Practical Minimum
If you are a US B2B SaaS company with EU or UK customers, or customers whose end users include EU or UK residents, here is what you should implement.
Start with a DPA that satisfies GDPR Article 28 requirements. This means 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 fallback transfer mechanism. Use Module 2 (controller-to-processor) for your direct customer relationship and Module 3 (processor-to-processor) for subprocessor transfers.
Document a Transfer Impact Assessment. For most B2B SaaS companies processing business contact data, this is a straightforward exercise. Keep it on file and update it when circumstances change.
Maintain a subprocessor list and a process for notifying customers of changes.
Update your privacy policy to disclose DPF participation, your role as a processor for customer data, and your data transfer mechanisms.
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 depending on your processing activities. For most seed-stage B2B SaaS companies, the compliance path runs through your existing documents and infrastructure.
The Founder’s Decision
International data transfers are one of those areas where founders are tempted to either ignore the issue entirely (“we don’t have EU customers yet”) or over-engineer a solution (“we need to set up EU data residency”). Neither is usually right.
If you are selling to businesses, some of those businesses will have European employees, European customers, or European operations. The question is not whether you will need a transfer mechanism. The question is whether you will have one ready when the enterprise prospect sends you their DPA for review.
Having your transfer mechanisms documented in your DPA, your DPF certification active, and your SCCs incorporated as a fallback puts you in the same position as companies ten times your size. The cost is a few hours of administrative work and a properly structured DPA. The alternative is discovering during a procurement review that you cannot close the deal without a transfer mechanism you do not have.
No Boiler provides self-service legal document generation and educational content. This material is general in nature and 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 DPA pillar. Previously: Subprocessor Management for B2B SaaS: AI APIs, CCPA Service Providers, and the Operational Framework. Related: What Is a DPA and Why Your Enterprise Customers Keep Asking for One · GDPR as a B2B SaaS Company Without EU Operations · Security Measures in Your DPA: Don’t Promise What You Can’t Deliver.