A Data Processing Agreement and Standard Contractual Clauses (SCCs) solve two different problems that happen to show up in the same GDPR compliance conversation. A DPA, required by Article 28, governs what a processor is allowed to do with personal data on a controller’s behalf, the subject matter, security measures, breach notice, and audit rights covered in What to Include in a Data Processing Agreement. SCCs, authorized under Article 46, are the legal mechanism that makes it lawful to move that personal data outside the EU/EEA to a country that hasn’t received an adequacy decision from the European Commission. Most SaaS companies with EU customers and any non-EEA infrastructure or vendors need both documents, not one instead of the other.
DPA vs Standard Contractual Clauses
| DPA | SCCs | |
|---|---|---|
| Legal basis | GDPR Article 28 | GDPR Article 46 |
| What it governs | What a processor may do with the data | Whether moving data outside the EU/EEA |
| Required when | Any controller-processor relationship | Data leaves the EU/EEA without adequacy |
| Typically signed as | A standalone contract or addendum | An annex incorporated into the DPA |
What SCCs Actually Do
The European Commission adopted the current SCCs in June 2021 (Implementing Decision (EU) 2021/914), replacing the older 2001 and 2010 clause sets. They’re modular: Module 1 covers controller-to-controller transfers, Module 2 covers controller-to-processor, Module 3 covers processor-to-processor (the shape most SaaS sub-processor chains take), and Module 4 covers processor-to-controller. A company signs only the modules that match its actual data flows, and a “docking clause” lets new parties join the same set of clauses later without renegotiating from scratch.
Signing SCCs doesn’t require government approval or registration. The clauses themselves are the Commission-approved terms; two parties agree to be bound by them the same way they’d agree to any other contract, and the parties fill in specific annexes describing the data categories, purposes, and technical/organizational security measures.
When You Actually Need SCCs
Not every international data flow requires SCCs. The European Commission has issued adequacy decisions for a specific list of countries, including the UK, Switzerland, Japan, South Korea, and, for U.S. companies that self-certify, the EU-U.S. Data Privacy Framework adopted in 2023. If your processor or sub-processor sits in a country with an adequacy decision, or is a self-certified DPF participant, that specific transfer doesn’t need SCCs, the adequacy decision already satisfies Chapter V. If it sits anywhere else, the U.S. outside the DPF, India, most of Asia and Latin America, SCCs (or one of the narrower Article 49 derogations, rarely a good long-term fit for routine SaaS processing) are the standard mechanism.
For a typical SaaS company, this catches more vendors than expected: cloud hosting, analytics, customer support tools, and email delivery all commonly run through U.S. infrastructure, and unless the specific vendor is a DPF participant for that service, each one needs SCCs in place, not just a general DPA.
The Transfer Impact Assessment
Since the Schrems II ruling in 2020, signing SCCs alone isn’t automatically sufficient. The exporting party (usually the controller, sometimes the processor on the controller’s behalf) is expected to complete a transfer impact assessment, evaluating whether the destination country’s laws, particularly government surveillance and data access powers, could undermine the protections SCCs are supposed to guarantee. If the assessment finds a real risk, the parties are expected to add supplementary measures: stronger encryption where the destination-country provider can’t access the underlying keys, pseudonymization before transfer, or contractual commitments to notify the exporter if a government request for the data arrives. Skipping this step is one of the more common gaps regulators flag, signing the clauses on paper without ever assessing whether they hold up in practice for that specific vendor and country.
Where SCCs Live in Practice
For most SaaS relationships, SCCs aren’t a separate contract negotiated on their own. They’re attached as an annex or addendum to the DPA, incorporated by reference, with the DPA’s subject-matter and security terms doing double duty as the annex content SCCs require anyway. A controller reviewing a vendor’s compliance package should expect to see both: the DPA governing the processing relationship, and the SCC annex (or confirmation of adequacy/DPF status) covering wherever that vendor’s infrastructure actually lives.
If you’re still working out whether your business needs a DPA at all before worrying about international transfers, start with Do You Need a Data Processing Agreement?. Once you know you need one, our DPA generator builds the document with the transfer mechanism section included, so you’re not tracking SCCs as a separate compliance project bolted onto a DPA that doesn’t mention them.
