What are Standard Contractual Clauses (SCCs)?
Standard Contractual Clauses (SCCs) are the European Commission's contract templates that give a legal basis for transferring personal data to countries outside the EU/EEA without an adequacy decision. They're built into data processing agreements and bind the recipient to GDPR-like obligations. After Schrems II, SCCs alone aren't enough – the transfer also needs a documented transfer impact assessment and technical safeguards.
When a Swedish company sends personal data to a vendor outside the EU/EEA, GDPR requires a valid transfer mechanism. For most AI contracts, that mechanism is Standard Contractual Clauses, or SCCs. It’s worth understanding what they do, because they turn up in nearly every vendor review.
What SCCs are, and what they solve
Standard Contractual Clauses are contract templates adopted by the European Commission. When the recipient country lacks an adequacy decision – an EU decision that the country’s level of protection is equivalent – the parties can instead write the Commission’s clauses into the contract. The clauses bind the recipient to obligations that mirror GDPR: purpose limitation, security measures, assistance with data subject requests, and liability for breaches.
The point is that protection travels with the data through the contract, when it isn’t guaranteed by the recipient country’s legislation. The substance of the clauses can’t be changed – but the annexes are filled in per contract: which categories of data are transferred, which security measures apply, and which sub-processors are involved.
The current version from 2021 is modular. There are four modules depending on the roles: controller to controller, controller to processor, processor to sub-processor, and processor to controller. The wrong module means the wrong obligations – a classic miss in reviews.
Where SCCs show up in AI contracts
In practice, you rarely negotiate SCCs separately. They’re included as an annex to the vendor’s data processing agreement (DPA) and activate automatically when a transfer to a third country occurs. At AI vendors like Anthropic and GitHub, the clauses are included in the DPA this way – you accept them along with the rest of the terms.
That also means SCCs can apply even when you’ve bought “EU storage.” Storage in the EU doesn’t prevent support, operations, or abuse detection from involving access from the US – and every such access is a transfer that needs its own mechanism. A concrete scenario: a company picks the EU region for its AI service and assumes the third-country question is solved. During review, it turns out the vendor’s US support organization can reach the logs. In that case, it’s the SCC annex in the DPA that carries that access – not the EU region.
The limitation after Schrems II
The EU Court of Justice’s 2020 Schrems II ruling established two things. First, that SCCs remain valid as a mechanism. Second, that they don’t automatically suffice. A contract only binds the parties, after all – it doesn’t bind the recipient country’s authorities. If the recipient country’s legislation gives authorities access that goes beyond what EU law allows, the exporter has to assess whether the protection holds up in practice.
That’s why an SCC-based transfer generally requires two more things:
- A TIA (Transfer Impact Assessment): a documented analysis of the recipient country’s legislation and the actual risk of government access, for example under US FISA 702 and the CLOUD Act.
- Supplementary measures: technical and organizational safeguards such as encryption with customer-controlled keys, minimizing which data is sent, short retention periods, or EU-based inference.
So SCCs are the floor, not the whole solution. Anyone who stops at “the clauses are signed” has done half the job.
The buyer’s checkpoints
When you review an AI contract with SCCs, there are four things to check off:
- The right module for your role. If you’re the data controller and the vendor is the processor, module two should apply. Chains with sub-processors should be covered by module three at each link.
- A UK Addendum for UK data. If you handle personal data under UK law, you need the special addendum to the EU clauses.
- The clauses follow the chain. When the vendor swaps a sub-processor, equivalent protection needs to be in place at the new link – check that the DPA gives you notice and the right to object.
- The annexes are filled in. Empty annexes on data categories and security measures are a warning sign; that’s where the contract gets concrete.
Want to see how the SCC question connects to residency choices, retention, and government access across a full AI project? Find more on our AI page. And if you need help reviewing a specific vendor contract before you sign – get in touch, it’s a review that’s usually done in a few hours.
Frequently asked questions
Is an SCC the same thing as a data processing agreement (DPA)?
No. The DPA regulates how the processor may handle personal data on your behalf, while an SCC gives the transfer itself to a third country a legal basis. In practice, SCCs are often baked in as an annex to the DPA, which is why many people mix them up.
Do you need SCCs if the vendor is certified under the EU-US Data Privacy Framework?
No, not for that transfer – the DPF is its own transfer mechanism. Many contracts still include SCCs as a fallback mechanism in case the DPF certification is dropped or invalidated. Check which mechanism your contract actually invokes.
Who signs the SCCs, us or the vendor?
Both parties are contracting parties. In cloud services and AI contracts, you usually accept the clauses as part of the vendor's standard terms or DPA, rather than negotiating them separately. Your job then is to check that the right module and the right annexes are included.
Do SCCs apply to data sent to the UK too?
The UK has its own adequacy decision, so transfers there normally don't require SCCs. UK law does, however, require a special UK Addendum to the EU clauses when data flows from the UK to a third country – relevant if your group has UK entities.
What happens if a sub-processor in the chain is replaced?
The transfer basis has to follow all the way through the chain. When the vendor swaps a sub-processor, equivalent clauses need to be in place at the new link, and you should get notice with the chance to object. Ask to see the updated sub-processor list.