Standard Contractual Clauses (SCCs) are the main mechanism used to transfer personal data from the EU to countries without an EU adequacy decision. If your company uses US cloud services, analytics platforms, or any SaaS tool hosted outside the EEA, SCCs are probably the instrument making that transfer legal.
Most SaaS companies need to understand SCCs but do not need to draft them. This article explains what they are, when you need them, and what your actual obligations are.
Why SCCs Exist
GDPR Chapter V prohibits transferring personal data outside the European Economic Area unless the receiving country provides "adequate" protection. Most countries do not have EU adequacy decisions — including the United States (for most purposes), India, and most of the world.
SCCs are a set of standardised contractual clauses approved by the European Commission that create binding data protection obligations between the EU data exporter and the non-EU data importer. They are a way of contractually exporting GDPR-equivalent protections to third countries.
When Do You Need SCCs?
You need SCCs (or an alternative transfer mechanism) when:
- Personal data of EU individuals is transferred to a country without an EU adequacy decision
- The transfer is to a commercial entity (not a public body or for law enforcement)
In practice, you need SCCs for virtually every US-based SaaS tool you use to process personal data:
- AWS, Google Cloud, Azure (outside EU-hosted regions)
- HubSpot, Salesforce, Marketo
- Intercom, Zendesk
- Stripe (US entity)
- SendGrid, Mailchimp
- Any US-based analytics, monitoring, or security tool
The 2021 SCCs: What Changed
The European Commission updated SCCs in June 2021. The current version (the 2021 SCCs) replaced the 2010 version and must be used for any transfers agreed from that date. They cover four scenarios (called "modules"):
Module 1: Controller to Controller When both the EU party and the third-country party are data controllers. Example: sharing customer data with a US marketing partner.
Module 2: Controller to Processor When the EU company is the controller and the US company is the processor. Example: using AWS to host your database. This is the most common module for SaaS companies.
Module 3: Processor to Processor When an EU processor is transferring to a third-country sub-processor. Example: a European SaaS company using a US monitoring tool to process customer data.
Module 4: Processor to Controller When the EU processor sends data back to the non-EU controller. Less common.
Executing SCCs: The Practical Steps
Step 1: Identify the transfer. For each US vendor processing EU personal data, determine whether an adequacy decision covers the transfer (US adequacy for DPF-certified entities) or whether SCCs are needed.
Step 2: Determine the module. Are you the controller or processor? Is the vendor the processor or controller?
Step 3: Execute the SCCs. The 2021 SCCs are modular documents. You adopt the relevant module and fill in the required annexes:
- Annex I: Description of the transfer (parties, purposes, data categories, data subjects, recipients, frequency, nature of transfer)
- Annex II: Technical and organisational security measures
- Annex III: Sub-processors (for Module 2 and 3)
In practice, most US vendors provide their own DPA/Data Processing Addendum that incorporates the 2021 SCCs. You review and accept their DPA rather than drafting SCCs from scratch.
Step 4: Document the transfer. Record the SCCs in your Article 30 RoPA as the transfer mechanism.
Step 5: Transfer Impact Assessment (TIA). Post-Schrems II, GDPR requires exporters to assess whether SCCs are effective in practice in the destination country. The concern: government surveillance laws in the US (FISA, EO 12333) might undermine the protections SCCs are supposed to provide.
For most standard commercial transfers to large US cloud providers using EU data regions and certified under the DPF, the TIA will conclude that the risk is acceptable. Document this assessment — the existence of the assessment is what matters for most purposes.
The Data Privacy Framework (DPF): An Alternative
The EU-US Data Privacy Framework (DPF) is an adequacy decision that applies to US companies that have certified under the DPF programme. For DPF-certified companies:
- You can transfer to them without SCCs (the adequacy decision covers the transfer)
- They are listed at dataprivacyframework.gov
Major DPF-certified companies: Google, Meta (limited), Microsoft, Amazon, Stripe, HubSpot, and many others.
Check certification status before relying on it — DPF certification must be renewed annually, and some companies have let certifications lapse.
Caveat: The DPF has faced legal challenges in Europe. There is a risk that it could be invalidated by the CJEU as the Privacy Shield was in Schrems II. Companies relying solely on DPF may want to maintain SCCs as a fallback.
Common SCC Mistakes
Not executing SCCs at all. The most common mistake. Companies using US SaaS tools without any transfer mechanism are making unlawful transfers.
Using the old 2010 SCCs. The old versions were invalid from December 2022. If you have legacy DPAs referencing 2010 SCCs, they should be updated.
Relying on the vendor's terms without reviewing them. Most vendor DPAs are fine, but the key details (which module, which data categories, which security measures) need to match your actual processing.
No TIA documentation. Post-Schrems II, a documented transfer impact assessment is expected. It does not need to be long, but it must exist.