Standard contractual clauses vs the Data Privacy Framework: what's the difference?
Updated September 25, 2026
When a vendor sends personal data from the EU to a country without its own adequacy decision, the GDPR requires a transfer mechanism (Chapter V). Two show up in almost every SaaS data processing agreement: standard contractual clauses and the EU–US Data Privacy Framework. They solve the same problem in different ways, and a DPA that names one, the other or both tells you how exposed the transfer is if the law moves.
Standard contractual clauses
Standard contractual clauses (SCCs) are contract terms written by the European Commission. The current set was adopted by Commission Implementing Decision (EU) 2021/914 of 4 June 2021, under Article 46(2)(c) of the GDPR. They come in four modules, one for each relationship: controller to controller, controller to processor, processor to processor, and processor to controller. For your data at a SaaS vendor, the controller-to-processor module is the one that applies, and the vendor uses the processor-to-processor module with its own subprocessors.
SCCs work for transfers to any country, but they come with homework. The parties may not change the clauses, and they must assess whether the law and practice of the destination country let the importer honour them (Clause 14). That assessment is the transfer impact assessment. Where the answer is “not fully”, supplementary measures such as encryption are needed, or the transfer must stop.
The EU–US Data Privacy Framework
The Data Privacy Framework (DPF) is an adequacy decision: Commission Implementing Decision (EU) 2023/1795 of 10 July 2023, under Article 45 of the GDPR. It covers transfers to US organisations that self-certify with the US Department of Commerce and appear on the Data Privacy Framework List. Certification is renewed every year, and it can cover HR data, other data, or both.
For a transfer to a certified organisation, the adequacy decision is the safeguard: no SCCs are needed, and no transfer impact assessment for that transfer. It only helps for the organisation that is certified, though. If a US vendor relies on the DPF, it is worth checking that the vendor is on the list, for the kind of data you send, and that its own US subprocessors are covered too. The framework also has a UK extension and a Swiss–US counterpart.
Side by side
| Standard contractual clauses | Data Privacy Framework | |
|---|---|---|
| Legal basis | GDPR Article 46(2)(c): an appropriate safeguard | GDPR Article 45: an adequacy decision |
| Where it works | Any country outside the EU/EEA | The United States, certified organisations only |
| What the vendor does | Signs the clauses, in the right module, with you and its subprocessors | Self-certifies each year and follows the framework’s principles |
| What you check | A transfer impact assessment, and supplementary measures where needed | That the vendor, and the data you send, are covered on the DPF List |
| If the law moves | The clauses stay valid, though an assessment may need redoing | A court can strike the decision down, as it did twice before |
Why many DPAs name both
The DPF is the third attempt at a framework for EU–US transfers. Safe Harbor fell in 2015 and the Privacy Shield in 2020 (the Schrems II judgment), each time leaving companies that relied on it without a mechanism overnight. A DPA that incorporates SCCs as well as the DPF keeps a valid mechanism if the framework falls.
The DPF has survived its first challenge: in Latombe v Commission (Case T-553/23), the General Court dismissed an action to annul it on 3 September 2025. An appeal is pending before the Court of Justice (Case C-703/25 P). The safeguards the US adopted for the DPF, in Executive Order 14086, apply to personal data transferred under SCCs too, which makes transfer impact assessments for the US easier to write, whichever mechanism the DPA names.
What to check in a vendor’s DPA
- Which mechanisms it relies on. SCCs, the DPF, binding corporate rules within the vendor’s group, or adequacy decisions for countries such as Switzerland or Japan. Most DPAs name more than one.
- The SCC version and module. The clauses should be the 2021 set, with the controller-to-processor module for your data.
- For the DPF, the list. Is the vendor certified, for HR or non-HR data as you need, and is the certification current?
- A fallback. Does the DPA say which mechanism applies if another becomes invalid?
- UK and Swiss data. UK transfers need the UK Addendum to the SCCs, the UK’s own transfer agreement, or the UK extension of the DPF. Swiss transfers have their own rules as well.
- The subprocessor list. A new subprocessor in a new country is a new transfer, under whatever mechanism the DPA names.
When the terms change
Vendors update their DPAs, and a transfer mechanism can disappear in a routine revision. ClauseTrail reads each vendor’s DPA and records the transfer mechanisms it relies on, with the sentence that says so. When a vendor drops one, the teams tracking that vendor get an alert the same day.