DEV Community

Custodia-Admin
Custodia-Admin

Posted on • Originally published at app.custodia-privacy.com

Standard Contractual Clauses (SCCs): How to Use Them for GDPR-Compliant Data Transfers

If your business uses any US-based software — Stripe, Mailchimp, AWS, Salesforce, HubSpot, Intercom — you are transferring personal data outside the EU and EEA. Under GDPR, that transfer is only lawful if it's covered by a valid mechanism.

The most widely used mechanism is Standard Contractual Clauses (SCCs). But most businesses either don't have them in place, are using the old invalidated versions, or haven't done the additional assessment that's been required since the Schrems II ruling in 2020.

This guide covers what SCCs are, how the 2021 versions work, which module applies to your situation, what else you need to do beyond signing them, and a practical checklist for auditing your transfer mechanisms today.


Why International Data Transfers Are Regulated Under GDPR

GDPR doesn't stop at EU borders. Chapter V of the regulation (Articles 44–49) governs the transfer of personal data to third countries — any country outside the EU/EEA.

The core principle is simple: the level of protection afforded to personal data must travel with the data. If you send EU residents' personal data to a country with weaker privacy laws and no adequate safeguards, GDPR's protections become meaningless in practice.

The two main routes to a lawful transfer are:

  1. Adequacy decisions — the European Commission has formally decided that a country provides an adequate level of protection, so transfers can flow freely
  2. Appropriate safeguards — in the absence of an adequacy decision, you must put safeguards in place. SCCs are the primary safeguard used by most businesses.

There are also derogations under Article 49 (explicit consent, performance of a contract, etc.) but these are meant to be exceptional, not routine.


Schrems II: Why Your Old SCCs Are Invalid

In July 2020, the Court of Justice of the European Union (CJEU) issued its landmark Schrems II ruling, which invalidated the EU-US Privacy Shield framework and added significant requirements to SCCs.

The court held that SCCs alone may not be sufficient to protect data transferred to countries where surveillance laws allow government access to data in ways incompatible with EU fundamental rights. This is particularly relevant for the United States, where laws like FISA 702 and Executive Order 12333 permit mass surveillance of foreign nationals' data.

The ruling meant that:

  1. SCCs remain valid as a mechanism, but they come with homework: you must conduct a Transfer Impact Assessment (TIA) before relying on them
  2. The old SCCs (2001 and 2010 versions) were already technically superseded and had a hard deadline for replacement
  3. Processor-to-processor and processor-to-controller transfers were not covered by the old SCCs at all

The European Commission replaced the old SCCs in June 2021. The new 2021 SCCs had a transitional period ending December 27, 2022. After that date, any contract still relying on the old SCCs is non-compliant.

If you signed data processing agreements with US vendors before December 2022 and haven't reviewed them since, there is a real chance you're still relying on SCCs that are no longer valid.


The Four Modules of the 2021 SCCs

The 2021 SCCs are structured around four modules, each covering a different relationship between data exporters and importers.

Module 1: Controller to Controller (C2C)

When it applies: Both parties independently determine the purposes and means of processing. Neither is acting on the instructions of the other.

Typical scenarios:

  • You share customer data with a business partner who uses it for their own purposes
  • You share employee data with a group company that uses it independently
  • Co-marketing partnerships where both parties use the data for their own campaigns

Key clauses: Both parties take on direct obligations to data subjects. Each controller is liable only for its own processing.

Module 2: Controller to Processor (C2P)

When it applies: You (the controller) instruct a third-party processor located outside the EU to process personal data on your behalf.

Typical scenarios: This is the most commonly used module. It covers:

  • Your EU users' data going to a US SaaS tool that processes it on your instructions (email marketing platforms, CRM, analytics, support tools)
  • Cloud infrastructure providers processing your data

Key clauses: The processor must act only on documented instructions, implement appropriate security measures, assist with data subject rights, and agree to subprocessor restrictions.

Module 3: Processor to Processor (P2P)

When it applies: You are a processor (you process data on behalf of your clients/controllers), and you engage a sub-processor located outside the EU.

Typical scenarios:

  • You run a SaaS platform and use AWS or Google Cloud (located outside the EEA) to host client data
  • You're an agency processing client customer data and you use a US tool as part of your service delivery

Key clauses: The sub-processor must comply with the same obligations you owe to your controller clients. You remain liable to the original controller.

Module 4: Processor to Controller (P2C)

When it applies: You (as processor) send data back to the controller, and that controller is located outside the EU.

Typical scenarios:

  • You're a EU-based SaaS company and your non-EU clients (controllers) have you process data on their behalf, then receive it back
  • EU-based analytics or processing companies sending results to non-EU clients

Key clauses: This module has lighter obligations since the controller is receiving its own data back. The main requirements cover security and data subject rights assistance.


How to Actually Execute SCCs

Step 1: Determine which module applies

Map your data flows. For each transfer, ask:

  • Are you the controller or processor for this data?
  • Is the recipient a controller or processor?
  • This determines your module.

Step 2: Identify all third-country transfers

This is often where businesses fall short. A "transfer" includes:

  • Direct API calls to US-based services
  • Data stored in cloud services with infrastructure outside the EEA
  • Remote access to EU systems by staff or contractors located outside the EEA
  • Subprocessors your vendors use in third countries

Step 3: Complete the annexes

The 2021 SCCs have three mandatory annexes that must be filled in:

Annex I — List of Parties, Description of Transfer, Competent Supervisory Authority

  • Who the exporter and importer are
  • Categories of data subjects
  • Categories of personal data
  • Sensitive data (if any)
  • Frequency of transfer
  • Nature and purpose of processing
  • Retention period
  • Your lead supervisory authority (for EU exporters)

Annex II — Technical and Organisational Measures (TOMs)

  • Encryption in transit and at rest
  • Access controls
  • Incident response processes
  • Audit and certification status (ISO 27001, SOC 2, etc.)

Annex III — List of Subprocessors (Module 2 and 3 only)

  • All subprocessors the importer uses to deliver the service

Step 4: Select optional clauses

The 2021 SCCs include a number of optional clauses you can include or exclude:

  • Docking clause (Clause 7): Allows additional parties to join the SCCs later without re-executing
  • Additional redress mechanisms: For data subjects to bring claims
  • Specific liability allocation between controllers (Module 1)

Step 5: Sign and retain

SCCs must be signed by both parties. In practice, most major vendors make their SCCs available as part of their Data Processing Agreement (DPA), which you agree to by accepting their terms or clicking through their DPA process. You should retain evidence of this agreement.


The Transfer Impact Assessment (TIA) Requirement

Post-Schrems II, SCCs alone are not sufficient. You must also conduct a Transfer Impact Assessment before relying on SCCs to transfer data to a country without an adequacy decision.

A TIA requires you to assess:

1. The laws and practices of the destination country

Specifically, does the destination country have surveillance laws or government access rights that could undermine the protections in the SCCs?

For the US, this means considering FISA 702, Executive Order 12333, the Cloud Act, and how they interact with EU data. The European Data Protection Board (EDPB) has published guidance on this.

2. Whether supplementary measures are needed

If the laws of the destination country undermine the SCCs, you need to consider supplementary technical, contractual, or organisational measures:

Technical measures:

  • End-to-end encryption where only you hold the keys (so the importer cannot access the data in clear)
  • Pseudonymisation before transfer
  • Split processing (so no single importer holds the complete dataset)

Contractual measures:

  • Stronger obligations on the importer to challenge government access requests
  • Notification requirements if the importer receives a government access request

Organisational measures:

  • Policies and procedures that minimise what data is actually transferred

3. Document it

Your TIA should be documented and retained. It doesn't need to be a lengthy legal document, but it should record: the country assessed, the laws reviewed, your conclusion, and any supplementary measures implemented.

In practice, many businesses conduct a "light touch" TIA that says: the vendor is large enough that legal challenges to government access would be expected, encryption is in place, and the risk is acceptable given the nature of the data being transferred. This is generally defensible for standard business tools processing non-sensitive data.


Adequacy Decisions: When You Don't Need SCCs

If personal data flows to a country with an adequacy decision, SCCs and TIAs are not required. The European Commission has issued adequacy decisions for:

  • United Kingdom (post-Brexit adequacy, currently under review for renewal in 2025)
  • Switzerland (note: Swiss data protection law is separate from EU GDPR but transfers are covered)
  • Japan (mutual adequacy since 2019)
  • South Korea (adequacy since December 2021)
  • New Zealand
  • Israel
  • Uruguay
  • Argentina
  • Canada (partial — covers PIPEDA-regulated private sector organisations)

The adequacy decision for the UK is particularly important for businesses that assumed Brexit wouldn't change their data flows — it means transfers to UK processors don't require SCCs, but this adequacy decision has a finite term and must be renewed.


The EU-US Data Privacy Framework and Its Current Status

After Privacy Shield was invalidated by Schrems II, the EU and US negotiated a replacement: the EU-US Data Privacy Framework (DPF), which came into force in July 2023.

The DPF allows US organisations that self-certify under the framework to receive EU personal data without SCCs, similar to how Privacy Shield worked.

Current status: The DPF is operational. However, it faces legal challenges. Max Schrems and noyb have already filed challenges, and there is a real possibility of a "Schrems III" ruling that invalidates the DPF. The main critiques remain the same: US surveillance laws have not fundamentally changed, and FISA 702 was reauthorised in 2024.

What this means practically:

  • If your US vendor is DPF-certified, you may be able to rely on that instead of SCCs
  • But you should treat DPF-certified transfers as potentially needing SCCs as a backup mechanism
  • Check whether your vendors include SCC fallback provisions in their DPAs in case DPF is invalidated

Practical Examples: What Covers Your Common Transfers

Stripe

Stripe is a US company. Most businesses use Stripe as a controller (Stripe determines how it uses data for fraud, financial compliance, etc.) and also as a processor (Stripe processes payments on your instruction).

Transfer mechanism: Stripe's Data Processing Agreement includes Module 1 SCCs (controller to controller) for data Stripe processes independently, and Module 2 SCCs (controller to processor) for data Stripe processes on your instruction. Stripe is also DPF-certified.

Your action: Accept Stripe's DPA. Review whether you've done so — if you signed up to Stripe without explicitly agreeing to their DPA, it may have been incorporated by reference.

Mailchimp (Intuit)

Mailchimp processes your subscribers' personal data (email, name, engagement data) on your instructions. You are the controller; Mailchimp is the processor.

Transfer mechanism: Module 2 SCCs, included in Mailchimp's Data Processing Agreement. Intuit (Mailchimp's parent) is DPF-certified.

Your action: Accept Mailchimp's DPA via their account settings. Verify you have done so. Note that Mailchimp uses subprocessors — review Annex III of their SCC and assess whether any of those subprocessors' locations are concerning.

AWS (Amazon Web Services)

AWS processes whatever data you put into its services. You are the controller; AWS is the processor.

Transfer mechanism: Module 2 SCCs (and Module 3 if you are yourself a processor). AWS provides a comprehensive DPA with SCCs incorporated. AWS infrastructure is globally distributed — if you're an EU customer and you've configured your region to eu-west-1 or eu-central-1, your data doesn't leave the EEA under normal operation. Transfers only occur if you configure cross-region replication or use global services.

Your action: Accept the AWS DPA. Configure your infrastructure to use EU regions. Check whether you've enabled any features (CloudFront, global DynamoDB tables, etc.) that may route data through US regions.

Salesforce

Salesforce acts as a processor for the CRM data you load into it — contact details, deal history, communications logs.

Transfer mechanism: Module 2 SCCs, included in Salesforce's Data Processing Addendum. Salesforce is DPF-certified and also offers EU-hosted options for some products.

Your action: Accept the Salesforce DPA. If you use Salesforce's EU data residency option, confirm which data is truly EU-resident and which flows through US infrastructure for features like Einstein AI.


When SCCs Are Not Sufficient on Their Own

SCCs are a legal mechanism, not a technical protection. There are situations where they are not sufficient even with a TIA:

1. High-risk data categories: If you're transferring health data, biometric data, financial data, or data about children, the bar for adequacy of protection is higher. SCCs need to be accompanied by stronger supplementary technical measures (encryption, pseudonymisation).

2. Large-scale surveillance risk: If your data is of a type that realistically attracts government surveillance interest (political data, data on journalists, activists, or minority groups), SCCs plus a standard TIA are unlikely to be sufficient.

3. Importer cannot comply: If the laws of the destination country legally prohibit the importer from complying with SCCs (e.g., they are legally required to hand data to authorities without notification), SCCs cannot overcome that legal barrier. You should not transfer data in that scenario.

4. Importer insolvency or change of control: SCCs are a contract — if the importer ceases to exist or is acquired by an entity that won't honour them, the legal mechanism fails. Consider data repatriation rights in your contracts.


Checklist: Audit Your Transfer Mechanisms

Use this checklist to assess your current position:

1. Map your transfers

  • [ ] Have you identified every third-country transfer your business makes?
  • [ ] Do you know which module applies to each transfer relationship?

2. Check your SCCs

  • [ ] Are you using the 2021 SCCs? (Old 2001/2010 SCCs are no longer valid)
  • [ ] Have both parties signed/accepted the SCCs?
  • [ ] Have all three annexes been completed accurately?

3. TIA documentation

  • [ ] Have you conducted a Transfer Impact Assessment for each third-country transfer?
  • [ ] Is it documented?
  • [ ] Have you identified and implemented any required supplementary measures?

4. Vendor DPAs

  • [ ] Have you accepted your key vendors' DPAs? (Stripe, Mailchimp, Google, AWS, Salesforce, etc.)
  • [ ] Do those DPAs include the 2021 SCCs?
  • [ ] Are you on the vendor's subprocessor notification list where relevant?

5. Adequacy decisions

  • [ ] Have you checked whether any of your transfers go to adequacy-covered countries (removing the SCC requirement)?
  • [ ] Are you tracking the UK adequacy renewal process?

6. DPF certification

  • [ ] For US vendors, have you checked whether they're DPF-certified?
  • [ ] Do your DPAs include SCC fallback provisions in case DPF is challenged?

7. Records

  • [ ] Do your Records of Processing Activities (RoPA) document your transfer mechanisms?
  • [ ] Can you demonstrate compliance to a supervisory authority if asked?

Getting Compliant

If you don't know what third-party tools your website is loading, what data they're collecting, or whether you have SCCs in place — you're not alone, but you are exposed.

Start by understanding what your website actually does. Run a free scan at https://app.custodia-privacy.com/scan to identify the trackers and third-party tools active on your site. Custodia will flag the tools that involve third-country data transfers and help you understand what mechanisms you need.

From there, the steps are systematic: identify your vendors, accept their DPAs (most major vendors now make this straightforward), document your TIAs, and update your privacy notice to reflect your transfer mechanisms.

SCCs are not complicated to implement — they're a legal contract with standard terms. The hard part is knowing which transfers you have and staying on top of changes as vendors update their infrastructure and the legal landscape evolves.


This guide provides general information about Standard Contractual Clauses and GDPR data transfer mechanisms. It does not constitute legal advice. The legal landscape around international data transfers is evolving — the EU-US Data Privacy Framework faces ongoing legal challenges, and adequacy decisions are subject to review. Consult a qualified privacy lawyer for advice tailored to your specific situation.

Top comments (0)