SCC Standard Contractual Clauses.

What SCCs actually do

Standard Contractual Clauses are a pre-written contract between a data exporter in the EU and an importer in a country without an adequacy decision. By signing them, the importer commits to GDPR-grade obligations: purpose limitation, security, onward-transfer controls, data-subject rights and cooperation with the supervisory authority. Because the European Commission has already approved the wording, you do not have to negotiate or justify the clauses themselves, which is why they are the default transfer mechanism for almost every non-EU SaaS, cloud or sub-processor relationship.

The clauses are modular. You pick the module that matches the real-world relationship: controller-to-controller, controller-to-processor, processor-to-processor, or processor-to-controller. Getting the module wrong is the most common drafting error, because the obligations and the docking points for sub-processors differ between them. SCCs also include a docking clause that lets new parties join an existing set, which keeps long sub-processor chains manageable.

Why the TIA changed the game

Before the 2020 Schrems II judgement, signing SCCs was treated as enough on its own. The Court of Justice ended that. It ruled that contractual promises cannot bind a foreign government, so the exporter must assess whether the importer can genuinely honour the clauses given local surveillance and access law. That assessment is the Transfer Impact Assessment. In practice you document the destination country, the laws that could compel disclosure, the nature and sensitivity of the data, and whether supplementary measures such as strong encryption, pseudonymisation or split processing close any gap you find.

If the TIA concludes the importer cannot meet the SCC commitments and no supplementary measure fixes it, the transfer should not proceed on SCCs. This is where SCCs differ sharply from an adequacy decision: adequacy is a Commission finding that removes the case-by-case burden, while SCCs push that burden onto you for every transfer. The EU-US Data Privacy Framework now offers an adequacy route for certified US importers, but SCCs remain the workhorse for every other third country and for US vendors that are not certified.

What practitioners actually do

A working SCC process is repeatable, not a one-off legal exercise. The pattern most teams settle on looks like this.

1. Map the transfer: identify exporter, importer, the data categories and the correct module before touching the template.
2. Complete the annexes: the parties, the description of processing and the technical and organisational security measures. Vague annexes are the part regulators question first.
3. Run and document the TIA, including any supplementary measures, and keep it with the signed clauses.
4. Wire SCCs into your vendor onboarding so they are signed before data flows, not retrofitted after an audit finds the gap.
5. Re-review when the vendor changes sub-processors, when the destination country or its laws change, or on a fixed cadence.

SCCs sit inside your wider GDPR accountability story. They reference the records of processing, the DPIA where one is required, and the security controls you have already committed to. Treated as living documents rather than a signature collected once, they are the difference between a transfer you can defend and one that collapses the moment a regulator or a data subject asks how you protect data leaving the EU.