How Do Standard Contractual Clauses Address Data Sovereignty Concerns — and Where Do They Fall Short?

Standard Contractual Clauses SCCs are the most widely used mechanism for transferring EU personal data to third countries. They are also, since Schrems II, widely misunderstood — treated as a sovereignty solution when they are, at best, a sovereignty starting point. SCCs satisfy GDPR’s transfer documentation requirement. They do not — and legally cannot — override the surveillance laws of the countries data is transferred to.

Understanding precisely where SCCs work and where they break down is the foundation of any serious cross-border data sovereignty program.

Executive Summary

Main Idea: Standard contractual clauses establish binding contractual obligations between data exporters and importers for cross-border personal data transfers under GDPR Chapter V. Post-Schrems II, SCCs must be supplemented by Transfer Impact Assessments evaluating whether destination-country law undermines their effectiveness — and where active risk is identified, by technical supplementary measures. For transfers to U.S.-controlled infrastructure, the EDPB has identified customer-controlled encryption with keys outside the provider’s infrastructure as the primary adequate technical measure. SCCs without this architectural backing are legal documentation without genuine protection.

Why You Should Care: Austrian, French, and Italian DPAs have issued enforcement decisions ruling that certain U.S. cloud provider arrangements violate GDPR — explicitly because SCCs were not supplemented by adequate technical measures. Fines reach 4% of global annual revenue. An SCC program that hasn’t been reviewed against post-Schrems II standards is not a compliance posture — it is documented exposure.

Key Takeaways

1. SCCs are a legal instrument, not a technical control. They bind parties to each other. They do not bind foreign governments, override surveillance law, or prevent compelled disclosure. What they protect against is voluntary misuse by the data importer — not government-compelled access that the importer has no legal power to resist.
2. Schrems II fundamentally changed what SCCs require. The CJEU’s 2020 ruling established that SCCs for U.S. transfers must be supplemented by Transfer Impact Assessments and, where active CLOUD Act or FISA 702 risk is identified, by technical supplementary measures. SCCs alone no longer satisfy the transfer standard for U.S. provider arrangements.
3. The EDPB has named customer-controlled encryption as the required supplementary measure. Recommendations 01/2020 identified encryption with keys held exclusively outside the destination country — outside the provider’s infrastructure — as the technical measure capable of addressing compelled government access. Contractual supplementary measures (notification commitments, challenge procedures) are explicitly insufficient.
4. SCCs do not address non-personal data, transit risk, supply chain exposure, or DLP gaps. Their scope is GDPR personal data. Cross-border data sovereignty requires a broader control framework that addresses non-personal data under the EU Data Act, transit interception, and third-party processor chains.
5. Static SCC programs are active enforcement liability. GDPR’s accountability principle requires ongoing review. TIAs built before Schrems II, before Austrian/French/Italian DPA enforcement decisions, or before the EU-US Data Privacy Framework’s legal challenges are likely no longer adequate under current regulatory standards.

What SCCs Actually Do — and Don’t Do

Standard contractual clauses are model contract terms approved by the European Commission providing a lawful basis for transferring EU personal data outside the EEA under GDPR Article 46. They bind the data importer to specific obligations: process data only for specified purposes, implement appropriate security measures, notify the exporter of government access requests where permitted, and challenge requests believed to be unlawful. The current SCCs were updated in 2021 to reflect the post-Schrems II environment.

What SCCs do not do is equally important. They do not change the legal obligations of U.S. companies under the U.S. CLOUD Act or FISA Section 702. A U.S. provider with the most rigorous SCC arrangement is still legally required to comply with a valid CLOUD Act demand. SCCs obligate the provider to challenge overbroad demands; they cannot obligate the provider to refuse compliance with a valid legal order from its own government. This is not a drafting flaw — it is a structural limitation of contracts as data protection instruments. Contracts bind parties to each other. They do not bind sovereign governments. The CJEU confirmed this in Schrems II: where destination-country law enables government access incompatible with EU fundamental rights, SCCs alone are insufficient.

The Schrems II Requirement: Transfer Impact Assessments

Since Schrems II, organizations relying on SCCs for U.S. transfers must conduct Transfer Impact Assessments — documented evaluations of whether U.S. law undermines the SCCs’ effectiveness for the specific transfer. A TIA is not a formality. It must honestly address the CLOUD Act and FISA 702 as active legal authorities capable of compelling data disclosure without European judicial oversight — and conclude whether technical supplementary measures are adequate to address the identified risk.

A TIA that acknowledges CLOUD Act exposure but concludes that notification commitments and challenge procedures adequately address it is not meeting the post-Schrems II standard. The EDPB distinguishes between contractual supplementary measures — which modify what the provider promises — and technical supplementary measures — which modify what the provider is technically capable of doing. For CLOUD Act-exposed transfers, only technical measures are adequate. A provider that can be compelled to produce readable data provides insufficient protection regardless of what it has promised not to do. This is precisely what national DPA enforcement decisions have turned on.

The EDPB’s Required Technical Measure: Customer-Controlled Encryption

EDPB Recommendations 01/2020 identified a specific technical supplementary measure adequate for CLOUD Act exposure: encryption where the U.S. provider never has access to the encryption keys. Keys must be generated by the EU customer, stored in infrastructure outside the provider’s control, and never transmitted to the provider. Under this architecture, a CLOUD Act demand yields only ciphertext — the provider is technically incapable of producing readable data regardless of legal compulsion. This satisfies both the CLOUD Act’s disclosure obligation and GDPR’s protection requirement simultaneously.

Customer-managed encryption (BYOK/BYOE) with keys held in Hardware Security Modules under the EU customer’s exclusive control is the practical implementation. Organizations that cannot point to a specific key management architecture demonstrating that the U.S. provider holds no decryption capability have not met the Schrems II technical supplementary measure standard — regardless of SCC completeness. The same logic governs data residency controls: SCC data localization commitments must be backed by infrastructure-level geofencing — a technical supplementary measure — not contractual statements that administrative action could override.

Where SCCs Leave Gaps

Even a fully compliant SCC program addresses only part of the cross-border data sovereignty picture. Three gaps remain regardless of SCC completeness.

Non-personal data. SCCs cover GDPR personal data only. Non-personal data is governed by the EU Data Act’s Chapter VII, which requires cloud providers to implement technical measures preventing unlawful non-EU government access. A fully GDPR-compliant SCC program leaves non-personal data entirely unaddressed from a sovereignty standpoint.

Supply chain exposure. SCCs govern the direct exporter-importer relationship. Where a U.S. provider uses sub-processors in additional jurisdictions, each creates a separate government access vector. Effective third-party risk management requires mapping and assessing the full sub-processor chain independently.

Sector-specific obligations. DORA’s ICT third-party risk requirements and the NIS 2 Directive’s supply chain security mandate impose sovereignty obligations beyond GDPR transfer compliance. SCCs satisfy the GDPR dimension; they do not satisfy the sector-specific ones.

How Kiteworks Supports SCC Compliance — and Goes Beyond It

Kiteworks delivers the architectural controls that make SCC programs genuinely protective rather than documentarily complete. The Kiteworks Private Data Network implements customer-managed encryption (BYOK/BYOE) with FIPS 140-3 Level 1 validated encryption and AES-256 at rest — keys held exclusively by the EU customer, never accessible to Kiteworks.

A CLOUD Act demand served on Kiteworks yields only ciphertext. The TIA conclusion becomes defensible not because of what Kiteworks has promised, but because of what Kiteworks is technically incapable of doing. Single-tenant deployment in the customer’s chosen European location enforces data residency at the infrastructure level, not the contract level.

Zero trust security controls govern all access with every event captured in immutable audit logs through the CISO Dashboard. Pre-configured reporting for GDPR, NIS 2, DORA, and ISO 27001 keeps transfer documentation current across all applicable frameworks. Email, file sharing, MFT, web forms, and APIs governed under one platform with consistent controls — closing the fragmentation gaps that multi-platform environments create.

To see how Kiteworks supports your SCC compliance program and closes the architectural gaps it cannot address alone, schedule a custom demo today.

Additional Resources 

• Blog Post
  Data Sovereignty: a Best Practice or Regulatory Requirement?
• eBook
  Data Sovereignty and GDPR
• Blog Post
  Avoid These Data Sovereignty Pitfalls
• Blog Post
  Data Sovereignty Best Practices
• Blog Post
  Data Sovereignty and GDPR [Understanding Data Security]