GDPR International Data Transfers: SCCs, Adequacy, and the DPF

International data transfers are one of the most complex areas of GDPR compliance, and for SaaS companies, they’re nearly unavoidable. If you use AWS US regions, send emails through Mailchimp, track analytics with Amplitude, process payments through Stripe, or host anything on a US-based platform, personal data is crossing borders — and GDPR has strict rules about when and how that can happen.

Chapter V of the GDPR (Articles 44–50) establishes that personal data can only be transferred outside the European Economic Area if adequate protections are in place. The regulation provides several mechanisms to establish those protections, and choosing the right one for each data flow is a critical part of your compliance program.

This guide covers the available transfer mechanisms, how they work in practice for SaaS companies, and what you need to document.

Why International Transfers Matter

The GDPR’s transfer restrictions exist because data protection laws outside the EEA may not provide the same level of protection. When personal data leaves the EEA, it may be subject to foreign government surveillance, weaker privacy regulations, or inadequate enforcement — all of which could undermine the protections GDPR provides.

For SaaS companies, this isn’t an abstract concern. Your vendor stack almost certainly includes US-based services. Your infrastructure may span multiple continents. Your customers may be global. Every one of these data flows needs a valid legal basis for the transfer.

Transfer Mechanism 1: Adequacy Decisions

How It Works

The European Commission can determine that a country (or a sector within a country) provides an “adequate” level of data protection. Once an adequacy decision is in place, data can flow to that country as freely as it flows within the EEA — no additional safeguards required.

Currently Adequate Countries

As of 2026, the European Commission has issued adequacy decisions for:

• Andorra, Argentina, Canada (commercial organizations under PIPEDA), Faroe Islands, Guernsey, Isle of Man, Israel, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, United Kingdom, Uruguay

And for the United States, the EU-US Data Privacy Framework provides a sector-specific adequacy decision (covered in detail below).

Using Adequacy in Practice

If your vendor is established in an adequate country and processes data there, you can rely on the adequacy decision without additional contractual safeguards. However, you should:

• Verify that the vendor’s processing actually occurs in the adequate country (not outsourced to a non-adequate country)
• Monitor for changes to adequacy decisions (the Commission can revoke them)
• Document the adequacy decision as your transfer mechanism in your ROPA

Transfer Mechanism 2: The EU-US Data Privacy Framework (DPF)

Background

The EU-US Data Privacy Framework replaced the Privacy Shield (invalidated by the Court of Justice of the EU in the Schrems II decision in 2020). The DPF was adopted by the European Commission as an adequacy decision in July 2023, enabling data transfers to US organizations that have self-certified under the Framework.

How It Works

US organizations can self-certify to the DPF through the International Trade Administration of the US Department of Commerce. Certified organizations commit to a set of data protection principles (notice, choice, accountability for onward transfer, security, data integrity, purpose limitation, access, and recourse/enforcement/liability).

Checking DPF Certification

Before relying on the DPF as your transfer mechanism, verify that your specific vendor is actually certified:

1. Check the Data Privacy Framework List maintained by the Department of Commerce
2. Verify the certification is current (not expired or withdrawn)
3. Confirm the certification covers the type of data you’re transferring (the DPF distinguishes between HR data and non-HR data)

Practical Considerations

DPF is vendor-specific. The adequacy decision covers transfers to certified organizations, not all US transfers. If a vendor isn’t DPF-certified, you need a different mechanism.

DPF can be challenged. Privacy advocates have already filed challenges against the Framework. While it stands as of 2026, the history of US-EU data transfer agreements (Safe Harbor invalidated in 2015, Privacy Shield invalidated in 2020) suggests that DPF’s longevity isn’t guaranteed. Having SCCs as a backup is prudent.

Sub-processor chains. Even if your primary vendor is DPF-certified, verify whether their sub-processors are also certified or covered by an alternative transfer mechanism.

Transfer Mechanism 3: Standard Contractual Clauses (SCCs)

How SCCs Work

Standard Contractual Clauses are pre-approved contractual terms adopted by the European Commission that provide data protection safeguards for international transfers. By incorporating SCCs into your contract with a data recipient outside the EEA, both parties commit to specific data protection obligations.

The Current SCCs

The European Commission adopted new SCCs in June 2021 (replacing the older versions). The new SCCs are modular, with four scenarios:

Module 1: Controller to Controller. For transfers between two controllers — e.g., sharing customer data with a partner organization outside the EEA.

Module 2: Controller to Processor. The most common module for SaaS companies — for transfers to processors that process data on your behalf outside the EEA. This covers your relationship with US-based vendors when you’re the controller.

Module 3: Processor to Processor. For transfers between processors — when your processor engages a sub-processor outside the EEA.

Module 4: Processor to Controller. For less common scenarios where a processor transfers data back to a controller outside the EEA.

SCCs in Practice

Integration with DPAs. SCCs are typically incorporated as an annex to your Data Processing Agreement. Most major SaaS vendors include SCCs in their DPA by default.

Supplementary measures. Since Schrems II, SCCs alone may not be sufficient. You must assess whether the laws of the recipient country undermine the protections provided by the SCCs and, if so, implement supplementary measures. This assessment is formalized as a Transfer Impact Assessment (see below).

Cannot be modified. The SCCs are standardized — you can’t change their core clauses. You can add additional clauses (e.g., commercial terms) as long as they don’t contradict the SCCs’ protections.

Transfer Mechanism 4: Binding Corporate Rules (BCRs)

BCRs are internal data protection policies adopted by a multinational group of companies for transfers of personal data within the group. They must be approved by the competent supervisory authority.

BCRs are primarily relevant for large corporations with entities in multiple countries. For most SaaS companies, SCCs and the DPF are the practical mechanisms. If you’re part of a corporate group with BCRs, you can rely on them for intra-group transfers.

Transfer Impact Assessments

Why They’re Needed

The Schrems II decision established that before relying on SCCs (or BCRs) for transfers, you must assess whether the legal framework of the destination country provides protections “essentially equivalent” to those guaranteed within the EU. If it doesn’t, you must implement supplementary measures to bridge the gap — or stop the transfer.

How to Conduct a TIA

Step 1: Know your transfer. Identify the data being transferred, the purpose, the recipient, and the destination country.

Step 2: Identify the transfer mechanism. Which SCCs module applies? Is the DPF an alternative?

Step 3: Assess the destination country’s laws. Does the country have surveillance laws that could compel the recipient to disclose personal data? Are there effective legal remedies for data subjects? Key areas to evaluate:

• Government access to data (surveillance laws, law enforcement requests)
• Data protection legislation and enforcement
• Rule of law and judicial independence
• International commitments on data protection

Step 4: Evaluate whether the transfer mechanism is effective. Given the destination country’s laws, do the SCCs provide sufficient protection? If government authorities could compel the recipient to disclose data in ways that override the SCC protections, the mechanism alone isn’t effective.

Step 5: Identify supplementary measures if needed. These can be:

• Technical: Encryption where the recipient doesn’t hold the key, pseudonymization, split processing
• Organizational: Strict access controls, transparency reports, policies on government requests
• Contractual: Additional commitments to challenge government requests, notification obligations

Step 6: Document the assessment. Record your analysis, conclusions, and any supplementary measures. This documentation demonstrates accountability.

Practical Guidance for US Transfers

For transfers to the United States — the most common destination for SaaS companies — the analysis depends on the mechanism:

DPF-certified vendors: The adequacy decision addresses the concerns raised in Schrems II (including US surveillance reforms through Executive Order 14086). No additional TIA is required for transfers to DPF-certified organizations. However, monitor for challenges to the Framework.

SCCs to non-DPF-certified US vendors: You need a TIA. The supplementary measures should address the risk of US government access. Encryption in transit and at rest, where keys are controlled by you (the controller), is the strongest technical measure.

What to Document in Your ROPA

For each international transfer, your Record of Processing Activities should include:

• The destination country
• The transfer mechanism (adequacy, DPF, SCCs module, BCRs)
• The recipient (vendor name and role)
• The data categories transferred
• Reference to the TIA (if SCCs are used)
• Reference to supplementary measures (if applicable)

Common Pitfalls for SaaS Companies

Assuming all US vendors are covered by the DPF. The DPF is opt-in. Not all US companies have certified. Verify each vendor’s status individually.

Forgetting sub-processor transfers. Your vendor may be in the EU, but their sub-processors might not be. Review your vendors’ sub-processor lists to identify where data actually goes.

Not updating when vendors change. If a vendor changes their hosting region, adds a sub-processor in a new country, or loses their DPF certification, your transfer mechanism may need updating.

Ignoring employee data transfers. If you use US-based HR platforms, payroll providers, or benefits administrators, employee data is being transferred internationally. These transfers need the same legal basis as customer data transfers.

Treating the UK as EEA. Since Brexit, the UK is a “third country” for GDPR purposes. The EU has issued an adequacy decision for the UK (valid as of 2026), so transfers can proceed freely — but if that adequacy decision lapses or is revoked, you’ll need SCCs.

How GRCTrail Maps Your Transfers

GRCTrail provides visibility into your international data flows:

Vendor registry with transfer mapping. Each vendor in your registry includes their data processing locations, transfer mechanisms, and DPF certification status. See at a glance which vendors transfer data internationally and under which mechanism.

Connected to your ROPA. International transfers are documented in your Record of Processing Activities automatically, linked to the relevant vendor records and DPA entries.

Certification monitoring. Track DPF certification status for your US vendors. Get alerted if a vendor’s certification lapses or changes.

Map your international data flows →

Related Guides

• Data Processing Agreements (DPA) — Contracts that govern processor relationships
• GDPR Compliance Checklist — The full compliance framework
• GDPR Fines and Penalties — The cost of non-compliant transfers
• Records of Processing Activities (ROPA) — Documenting your processing

Get started with GRCTrail →