Schrems II Compliance: Protecting UK-EU Data Flows

The European Court of Justice’s Schrems II ruling in July 2020 invalidated the EU-US Privacy Shield by finding that American surveillance laws—particularly FISA 702 and Executive Order 12333—provide insufficient safeguards for EU data subjects’ fundamental rights. Whilst the immediate impact fell on US companies, the decision created profound implications for UK organisations managing data flows between Britain and the European Union. The UK’s adequacy decision from the European Commission, granted post-Brexit in June 2021, faces the same structural vulnerabilities that destroyed Privacy Shield: US cloud providers with encryption key access create technical pathways for American surveillance that no contractual safeguard can adequately address.

For UK organisations using US-based cloud providers whilst maintaining significant data exchange with EU entities, Schrems II creates an uncomfortable reality. Standard contractual clauses, the primary legal mechanism for UK-EU data transfers, require supplementary technical and organisational measures when transfers involve countries with problematic surveillance laws. The European Data Protection Board’s Recommendations 01/2020 make clear that these supplementary measures must render data “unintelligible” to government authorities—yet most UK organisations rely on cloud architectures where providers retain encryption key access, making data intelligible to US authorities through legal compulsion regardless of where that data is stored or which contractual protections purport to prevent disclosure.

The threat extends beyond compliance concerns to the preservation of UK-EU data flows themselves. If UK organisations widely adopt cloud architectures enabling US surveillance of EU personal data, privacy advocates will challenge the UK’s adequacy decision using the same Schrems II reasoning that invalidated Privacy Shield. A successful challenge would eliminate the UK’s privileged status for EU data transfers, forcing British businesses to implement the same cumbersome transfer mechanisms required for data flows to countries without adequacy decisions. UK organisations must therefore evaluate whether their cloud provider relationships satisfy not only current transfer requirements but also the architectural standards necessary to preserve the adequacy framework enabling efficient UK-EU data exchange.

Executive Summary

Main Idea: Schrems II invalidated Privacy Shield because US surveillance laws (FISA 702, Executive Order 12333) lack adequate safeguards for EU data subjects.

Why You Should Care: UK organisations using US cloud providers must implement supplementary technical measures—particularly customer-managed encryption keys—to protect UK-EU data flows and preserve UK adequacy status.

Key Takeaways

1. The European Court of Justice invalidated Privacy Shield because US surveillance laws enable access to EU personal data without adequate safeguards, finding that FISA 702 and Executive Order 12333 lack sufficient limitations on government access and fail to provide effective judicial redress for EU data subjects whose rights are violated.
2. UK adequacy from the European Commission faces identical vulnerabilities that destroyed Privacy Shield when UK organisations use US cloud providers maintaining encryption key access, creating technical pathways for American surveillance of EU personal data flowing through British infrastructure.
3. Standard Contractual Clauses require supplementary technical measures rendering data unintelligible to government authorities according to EDPB Recommendations 01/2020, but provider-managed encryption where cloud vendors retain key access fails this requirement because US authorities can compel providers to decrypt data regardless of contractual prohibitions.
4. Transfer impact assessments must evaluate the practical effectiveness of supplementary measures, not merely their theoretical design, and most TIAs underestimate how provider access to encryption keys undermines technical safeguards that contractual clauses cannot adequately replace.
5. Customer-managed encryption keys where providers never possess decryption capabilities satisfy EDPB supplementary measure requirements by ensuring data remains unintelligible even when governments compel cloud providers to disclose stored information, creating mathematical rather than contractual data protection.
6. Preserving UK adequacy requires British organisations to demonstrate that EU personal data flowing through UK systems remains protected from US surveillance, meaning widespread adoption of cloud architectures enabling American government access could trigger adequacy challenges threatening the legal foundation of UK-EU data exchange.

Schrems II and The Privacy Shield Invalidation

What is Schrems II? The Schrems II case (Case C-311/18, decided July 16, 2020) was a European Court of Justice ruling that invalidated the EU-US Privacy Shield framework whilst establishing that Standard Contractual Clauses require supplementary technical measures when transferring data to countries with inadequate surveillance safeguards.

The Schrems II case, formally known as Data Protection Commissioner v. Facebook Ireland Limited and Maximillian Schrems (Case C-311/18), represents the second successful challenge by Austrian privacy advocate Max Schrems against EU-US data transfer mechanisms. The European Court of Justice’s ruling on 16 July 2020 invalidated the EU-US Privacy Shield framework whilst upholding standard contractual clauses as valid transfer mechanisms—but only when supplemented with additional safeguards addressing specific risks in destination countries.

Why Privacy Shield Failed the Fundamental Rights Test

The Court found that US surveillance programmes, particularly Section 702 of the Foreign Intelligence Surveillance Act and Executive Order 12333, enable access to EU personal data that goes beyond what is “strictly necessary” and proportionate to protect national security. These programmes permit bulk collection of communications without individualised suspicion, operate without meaningful judicial oversight for non-US persons, and provide no effective judicial redress mechanisms enabling EU data subjects to challenge unlawful surveillance.

FISA 702 authorises the US government to compel American technology companies to provide access to communications of non-US persons located outside the United States. The FISA Court, which oversees these programmes, doesn’t assess individual warrants but rather approves annual certifications covering broad categories of intelligence targets. EU data subjects whose communications are intercepted under Section 702 have no meaningful way to learn about the surveillance or challenge its legality in US courts.

Executive Order 12333, which governs intelligence collection outside US jurisdiction, operates with even fewer restrictions. The order permits collection of communications directly from internet infrastructure, including undersea cables and network exchange points, without the limited FISA Court oversight that applies to Section 702. For EU personal data transiting US network infrastructure or stored with US companies, these surveillance programmes created what the Court deemed incompatible with EU fundamental rights to privacy and data protection.

The Contractual Limitations Problem

Crucially, the Court found that contractual mechanisms like EU-US Privacy Shield cannot overcome the problem of destination country laws enabling government access incompatible with EU fundamental rights. The United States committed through Privacy Shield to limit data access to what was necessary and proportionate, but these contractual commitments cannot override US national security laws compelling American companies to provide data access.

This principle—that contracts cannot overcome statutory obligations—forms the foundation of Schrems II’s continuing impact. If contractual commitments alone could protect data from problematic government access, Privacy Shield would have survived. The Court’s rejection of this approach means that organisations relying solely on standard contractual clauses without technical supplementary measures face the same vulnerability that destroyed Privacy Shield.

Implications for Cloud Service Providers

The Schrems II ruling doesn’t specifically name cloud providers, but its implications for US-based cloud infrastructure are unmistakable. AWS, Microsoft Azure, Google Cloud, and other American cloud providers are subject to the same FISA 702 and Executive Order 12333 authorities that the Court found incompatible with EU fundamental rights. These providers must comply with US government demands for data access, and their contractual promises to customers cannot override statutory obligations to respond to lawful surveillance orders.

For UK organisations, this creates immediate complications. Data stored with US cloud providers remains accessible to American intelligence agencies through legal mechanisms the European Court of Justice has explicitly rejected as inadequate. When that data includes personal information about EU data subjects—employees of EU companies, customers of EU businesses, or any other individuals protected by EU GDPR—UK organisations using US cloud providers facilitate surveillance that EU law deems fundamentally incompatible with data protection rights.

UK Adequacy and the Schrems II Precedent

UK Adequacy Status: The European Commission granted the UK an adequacy decision on June 28, 2021, enabling unrestricted data flows from the EU to the UK. However, this status remains vulnerable to challenge if UK organisations enable US surveillance of EU personal data through inadequate cloud architectures.

Following Brexit, the United Kingdom became a “third country” under EU data protection law, requiring an adequacy decision from the European Commission to enable unrestricted data flows from the EU. The Commission granted UK adequacy on 28 June 2021, finding that British data protection law provides essentially equivalent protection to EU GDPR standards.

The Vulnerability of UK Adequacy

UK adequacy faces the same structural vulnerability that destroyed EU-US Privacy Shield: if British organisations widely adopt technical architectures enabling US surveillance of EU personal data, privacy advocates can challenge adequacy using Schrems II reasoning. The adequacy decision assumes that data transferred to the United Kingdom will be protected according to UK GDPR and Data Protection Act 2018 standards—but if that data is immediately transferred onwards to US cloud providers subject to FISA 702, has meaningful protection occurred?

The European Commission’s adequacy decision explicitly notes that it must be reviewed if UK data protection standards change in ways affecting fundamental rights protection. Widespread UK adoption of cloud architectures facilitating US surveillance could constitute such a change, not through legislative action but through practical erosion of technical safeguards. If EU personal data flows to the UK only to be stored on US cloud infrastructure accessible to American intelligence agencies, adequacy becomes a technical loophole circumventing the protections that Schrems II established.

The Onward Transfer Problem

UK adequacy doesn’t automatically extend to onwards transfers from the UK to third countries. When UK organisations transfer EU personal data to US cloud providers, they engage in onwards transfers that must satisfy UK GDPR Article 46 requirements for appropriate safeguards. standard contractual clauses can provide the legal basis for these transfers—but post-Schrems II, SCCs alone are insufficient when transfers involve countries with surveillance laws that the European Court of Justice has deemed incompatible with fundamental rights.

This creates a cascade of compliance requirements. EU organisations transferring data to UK recipients must ensure those recipients have appropriate safeguards for onwards transfers. UK organisations must conduct transfer impact assessments evaluating whether SCCs with their US cloud providers provide adequate protection given US surveillance laws. And if those assessments identify risks that contractual clauses cannot address, supplementary technical measures become mandatory.

The challenge is that most supplementary measures—encryption during transit, encryption at rest, contractual audit rights—fail to address the fundamental vulnerability: US cloud providers retain encryption key access, making data accessible to American authorities through legal compulsion regardless of where that data is stored or what contractual protections purport to prevent access.

Preserving Adequacy Through Technical Architecture

UK adequacy survival depends partly on British organisations demonstrating that EU personal data flowing through UK systems remains genuinely protected from US surveillance. This isn’t merely a compliance obligation for individual companies—it’s a collective responsibility affecting all UK businesses benefiting from adequacy. If privacy advocates successfully demonstrate that UK organisations routinely enable US surveillance of EU personal data through poor cloud architecture choices, adequacy faces existential threats.

The solution requires technical architecture rather than contractual promises. Customer-managed encryption keys that eliminate provider access create mathematical guarantees that US cloud providers cannot provide data access even under legal compulsion. Sovereign deployment options keeping EU personal data on UK infrastructure eliminate the onwards transfer problem entirely. These architectural approaches address the fundamental Schrems II concern: government access pathways that contractual measures cannot prevent.

The Encryption Key Problem in Schrems II Context

Critical Point: Schrems II compliance requires data to be “unintelligible” to government authorities. Provider-managed encryption fails this requirement because cloud vendors can be compelled to decrypt data. Customer-managed encryption keys—where providers never possess decryption capabilities—satisfy EDPB supplementary measure requirements.

Schrems II fundamentally concerns government access to data, and encryption key control determines whether such access is possible. If cloud providers can decrypt customer data, then government authorities can compel providers to exercise that capability regardless of contractual prohibitions. If providers cannot decrypt customer data because they never possessed the keys, government demands yield only unintelligible ciphertext.

Provider-Managed Encryption and the Intelligibility Standard

The European Data Protection Board’s Recommendations 01/2020 on supplementary measures establish that technical safeguards must render data “unintelligible” to anyone who doesn’t have authorisation to access it—including government authorities in the destination country. Provider-managed encryption, where cloud vendors control keys through their Key Management Services, fails this standard because the provider can be compelled to make data intelligible to US authorities.

Most cloud encryption implementations use provider-controlled hardware security modules storing encryption keys. Whilst these HSMs provide strong protection against external attackers, they don’t protect against government demands served on the provider controlling the HSM. When US authorities issue FISA 702 orders or national security letters demanding data access, cloud providers with key access can decrypt and disclose intelligible data, making the encryption technically sound but legally meaningless for Schrems II purposes.

Some providers offer “customer-managed keys” allowing organisations to control key lifecycle and policies. However, these implementations often maintain provider access through backup keys, recovery mechanisms, or administrative privileges necessary for cloud operational purposes. Unless customer-managed keys implementations explicitly and architecturally eliminate all provider access—making it technically impossible for the provider to decrypt data even with employee cooperation and government compulsion—they fail to satisfy the EDPB’s unintelligibility requirement.

The EDPB’s Technical Measure Recommendations

EDPB Recommendations 01/2020 provide detailed guidance on supplementary technical measures appropriate for different data transfer scenarios. For transfers where the exporter maintains control over encryption keys and the importer (cloud provider) cannot access plaintext data, the EDPB considers this an effective supplementary measure preventing government access to intelligible data.

The critical requirement is that encryption keys remain exclusively under data exporter control, never residing in cloud provider infrastructure or accessible through provider systems. The keys must be generated outside provider environments, stored in customer-controlled hardware security modules or key management servers, and used only within systems the provider cannot access or modify. This architectural separation ensures that government demands served on the cloud provider cannot yield decryption keys or intelligible data.

UK organisations implementing this architecture for EU personal data stored with US cloud providers can satisfy both the SCC requirements and the Schrems II supplementary measure mandate. The contractual clauses establish legal obligations, whilst the technical architecture ensures those obligations can be honoured even when US authorities demand data access. The provider can comply with lawful US government demands by disclosing encrypted data whilst simultaneously honouring contractual commitments to protect data privacy because without the keys, disclosed data remains unintelligible.

Why This Matters for UK-EU Data Flows

When UK organisations receive EU personal data and subsequently transfer it to US cloud providers without adequate supplementary measures, they create legal exposure for both themselves and their EU data sources. The EU organisations transferring data to UK recipients must ensure adequate safeguards for onwards transfers exist. If UK cloud architecture fails Schrems II requirements, EU organisations cannot legitimately transfer data to UK recipients planning such onwards transfers.

This creates competitive implications. UK businesses offering inadequate Schrems II safeguards may find EU customers and partners reluctant to share data, preferring competitors with demonstrable technical measures satisfying supplementary measure requirements. Financial services firms, legal practices, healthcare providers, and technology companies depending on EU personal data flows must architect cloud infrastructure that EU data protection officers can confidently approve in transfer impact assessments.

Transfer Impact Assessments and Supplementary Measures

TIA Requirement: UK organisations must conduct transfer impact assessments (TIAs) evaluating whether Standard Contractual Clauses alone provide adequate protection for transfers to countries with problematic surveillance laws. TIAs must assess practical effectiveness of safeguards, not merely contractual language.

Schrems II didn’t invalidate standard contractual clauses, but it established that SCCs alone are insufficient for transfers to countries with surveillance laws incompatible with EU fundamental rights. Data exporters must conduct transfer impact assessments evaluating whether the legal and technical reality in the destination country prevents the contractual protections in SCCs from being honoured in practice.

What Transfer Impact Assessments Must Evaluate

Transfer impact assessments are not checklist exercises. The EDPB makes clear that TIAs must evaluate the practical effectiveness of safeguards, not merely their theoretical design. For UK organisations transferring EU personal data to US cloud providers, TIAs must assess:

• Whether encryption provides effective protection. If the provider holds encryption keys, the answer is no—government authorities can compel key disclosure or data decryption, rendering encryption legally meaningless even if technically sound.
• Whether contractual commitments prevent government access. US national security laws explicitly override contractual obligations, so contractual commitments from US providers cannot prevent lawfully compelled disclosure.
• Whether transparency mechanisms enable detection of government access. National security letters and FISA orders often prohibit disclosure, preventing providers from informing customers about data access, making detection impossible and accountability illusory.
• Whether legal redress exists for unlawful access. The Schrems II ruling found that non-US persons lack effective judicial redress in US courts for FISA 702 surveillance, meaning violations cannot be meaningfully challenged or remedied.

Organisations conducting honest TIAs for US cloud provider relationships typically reach uncomfortable conclusions: the safeguards they’ve implemented don’t actually address the fundamental access pathways that Schrems II identified as incompatible with EU fundamental rights.

The Supplementary Measures Requirement

Where TIAs identify that SCCs alone provide insufficient protection, supplementary technical and organisational measures become mandatory. The EDPB’s Recommendations 01/2020 outline various supplementary measures appropriate for different circumstances, but not all measures address the Schrems II surveillance concern.

Organisational measures—contractual audit rights, transparency commitments, data minimisation—cannot overcome government access authorities. If US law enables surveillance, contractual commitments not to engage in surveillance are legally meaningless. Audits cannot detect classified government access subject to non-disclosure requirements. Data minimisation reduces risk but doesn’t eliminate government access pathways to remaining data.

Technical measures offer more promise, but only those that architecturally prevent provider access to intelligible data. Transport encryption (TLS) protects data in transit but not at rest in provider infrastructure. Encryption at rest with provider-managed keys fails because providers can be compelled to decrypt. Pseudonymisation and anonymisation work only if truly irreversible, which is often impossible for operational data requiring real-world linkage.

The supplementary measure that reliably addresses Schrems II concerns is customer-managed encryption with cryptographic separation—keys generated, stored, and managed entirely outside provider infrastructure, making it technically impossible for providers to access plaintext data even under government compulsion. This measure doesn’t rely on contractual promises or legal protections that government authorities can override. It creates mathematical certainty that compelled provider disclosure yields only unintelligible ciphertext.

Common TIA Failures

Many UK organisations conduct transfer impact assessments that underestimate Schrems II risks or overestimate the effectiveness of supplementary measures. Common failures include:

• Treating provider “customer-managed key” offerings as genuine customer control without verifying that providers cannot access keys through backup, recovery, or administrative mechanisms.
• Assuming that data stored in UK or EU regions eliminates US surveillance risk without recognising that US parent companies controlling those regions remain subject to FISA 702 regardless of data location.
• Relying on provider transparency reports as evidence of limited government access without acknowledging that classified surveillance orders prohibit disclosure, making transparency reports inherently incomplete.
• Implementing encryption during transit as a supplementary measure without addressing that data must be decrypted for storage and processing, during which provider-managed systems have plaintext access.
• Confusing data residency (storing data within specific geography) with data sovereignty (maintaining exclusive control over data access), treating UK storage locations as sufficient without evaluating US parent company access pathways.

These TIA failures don’t merely create compliance risks for individual organisations. When widespread across UK businesses handling EU personal data, they strengthen the case for challenging UK adequacy using Schrems II reasoning.

Why Standard Contractual Clauses Aren’t Enough

Bottom Line: Standard Contractual Clauses (SCCs) provide necessary legal foundations but cannot overcome US surveillance laws that override contractual commitments. Technical supplementary measures—particularly customer-managed encryption eliminating provider key access—are mandatory for Schrems II compliance.

Standard contractual clauses, approved by the European Commission in 2021, provide detailed contractual obligations for international data transfers. However, Schrems II established that these contractual protections are insufficient when destination country laws enable government access incompatible with EU fundamental rights—a circumstance that explicitly includes US cloud providers subject to FISA 702.

The Legal Override Problem

SCCs require data importers to inform exporters if they cannot comply with the clauses, for example due to government demands conflicting with contractual obligations. However, US national security laws often prohibit such notification. National security letters issued under 18 U.S.C. § 2709 include non-disclosure provisions preventing recipients from revealing the letters’ existence. FISA orders similarly restrict disclosure. These legal prohibitions override contractual commitments to notify customers about government data requests.

This creates an impossible contractual situation. US cloud providers cannot honour SCC notification requirements when national security laws prohibit disclosure. They cannot refuse government demands because refusal violates US criminal law. And they cannot satisfy both legal obligations—comply with US surveillance authorities and honour contractual privacy commitments—because the obligations fundamentally conflict.

The Schrems II ruling recognised this conflict and concluded that contractual measures alone cannot provide adequate protection when destination country laws override contractual commitments. For UK organisations, this means SCCs with US cloud providers must be supplemented with technical measures that remain effective even when providers face government demands they cannot refuse or disclose.

Module-Specific Vulnerabilities

The 2021 Standard Contractual Clauses include four modules covering different transfer scenarios: controller to controller, controller to processor, processor to processor, and processor to sub-processor. Cloud service provider relationships typically use Module Two (controller to processor) where the UK organisation acts as data controller and the cloud provider processes data on the controller’s instructions.

Module Two includes specific provisions requiring processors to implement appropriate technical and organisational measures ensuring data security. However, these measures must satisfy not only the contractual requirements but also the practical effectiveness standard that Schrems II established. Provider-managed encryption satisfies the contractual language about “encryption of personal data” but fails the Schrems II requirement that encryption render data unintelligible to government authorities when the provider controlling encryption keys can be compelled to decrypt.

The SCCs also require processors to assist controllers in responding to data subject requests, conducting data protection impact assessments, and demonstrating compliance with data security obligations. When processors use encryption keys they control, they maintain technical capability to provide this assistance—but that same capability enables them to provide assistance to government authorities demanding data access. The architecture enabling operational functionality creates the vulnerability that Schrems II identifies as problematic.

Supplementary Measures as Mandatory Additions

EDPB guidance makes clear that supplementary measures aren’t optional enhancements—they’re mandatory requirements when TIAs identify risks that SCCs alone cannot address. For transfers to the United States, the presence of FISA 702 and related surveillance authorities creates presumptive need for supplementary measures. Organisations claiming that SCCs alone provide sufficient protection must demonstrate why US surveillance laws don’t create risks requiring additional safeguards—a difficult argument post-Schrems II.

The European Data Protection Supervisor has gone further, suggesting that for some types of transfers to the United States, no supplementary measures can provide adequate protection short of not transferring at all. Whilst this represents a more restrictive interpretation than the EDPB’s recommendations, it illustrates the seriousness with which EU authorities view US surveillance risks post-Schrems II.

For UK organisations, the message is clear: SCCs provide necessary legal foundations for US cloud provider relationships, but technical architecture determines whether those relationships satisfy Schrems II requirements. Contractual language about encryption, security measures, and government access notification cannot substitute for cryptographic architecture that makes provider access to plaintext data mathematically impossible.

Real-World Scenarios: UK-EU Data Flows Under Schrems II

UK Law Firm with EU Clients: Privilege Protection Across Borders

A Manchester-based law firm represents clients across Europe in commercial litigation, competition matters, and regulatory investigations. The firm previously used Microsoft 365 for document management and client communications, relying on Azure’s EU regions for data residency. When the firm began advising a German pharmaceutical company in a matter potentially involving US regulatory interest, the client’s data protection officer questioned whether the firm’s cloud architecture satisfied Schrems II supplementary measure requirements.

The data protection officer’s concern was specific: Microsoft, as a US company subject to FISA 702, could be compelled to provide US authorities access to client documents stored in Azure EU regions. Even with standard contractual clauses and Azure’s contractual commitments to data protection, US surveillance laws override these contractual protections. The client’s legal professional privilege under German law and EU Charter rights could be compromised through US surveillance enabled by the law firm’s cloud architecture.

The law firm conducted a transfer impact assessment evaluating its Azure deployment. The assessment concluded that Microsoft’s encryption key access created exactly the vulnerability the client’s data protection officer identified. Whilst data resided in EU regions, Microsoft’s US parent company maintained technical capability to decrypt and disclose that data under FISA 702 compulsion. The firm’s SCCs with Microsoft provided contractual protections that US national security laws could override.

The firm deployed Kiteworks on-premises in its UK data centre with customer-managed encryption keys stored in UK-controlled hardware security modules. EU client data never flows to US infrastructure, encryption keys remain exclusively under firm control, and geofencing prevents authentication from US IP addresses. When the German pharmaceutical client’s data protection officer reviewed the new architecture, she approved it as satisfying Schrems II supplementary measure requirements—the technical architecture rendered data unintelligible to Microsoft, US authorities, or anyone else lacking the firm’s UK-controlled encryption keys.

UK Financial Services Firm: Protecting EU Customer Data

A London-based wealth management firm serves high-net-worth individuals and family offices across the United Kingdom and European Union. The firm previously used Salesforce for customer relationship management and Google Workspace for operational communications, believing that contractual commitments and certifications provided adequate data protection for EU customer information.

When the firm sought to expand services to German and French markets, prospective clients’ compliance advisors raised Schrems II concerns. Storing EU customer financial information with US cloud providers subject to FISA 702 created potential exposure to US surveillance. Even if that surveillance targeted legitimate national security threats, its bulk collection nature meant EU customer data could be incidentally collected and retained—exactly the problem the European Court of Justice found incompatible with fundamental rights in Schrems II.

The firm’s initial response was to implement Standard Contractual Clauses with Salesforce and Google, conduct transfer impact assessments, and document that data resided in EU regions. However, prospective clients’ advisors identified that these measures didn’t address the fundamental issue: US parent companies controlling EU regions maintained encryption key access enabling government-compelled disclosure. The SCCs provided contractual protections that US surveillance laws could override. The TIAs documented risks without adequately addressing them.

The firm deployed Kiteworks for customer data management and sensitive communications, implementing customer-managed encryption with keys generated and stored in UK-controlled infrastructure. EU customer personal data flows through this sovereign architecture rather than US cloud systems. The firm’s transfer impact assessments now document technical supplementary measures satisfying EDPB Recommendations 01/2020—encryption rendering data unintelligible to cloud providers, with cryptographic key control eliminating government access pathways that contractual measures cannot prevent.

The architecture enabled the firm to secure German and French clients whose data protection officers require demonstrable Schrems II compliance. When UK adequacy faces periodic review, the firm’s EU-protective architecture demonstrates that British organisations can maintain robust data protection for EU personal data, supporting adequacy preservation arguments.

UK Healthcare Provider: Cross-Border Research Collaboration

A UK NHS trust participates in multi-national clinical research involving patient data sharing with German and Swedish research institutions. The collaboration previously used Microsoft Teams and SharePoint for research data management, relying on Microsoft’s EU regions and standard contractual clauses for legal compliance. When the German research institution’s data protection officer conducted a Schrems II review of international collaborations, the UK trust’s cloud architecture raised concerns.

The research involves health data protected under UK GDPR Article 9 and EU GDPR special category data provisions. The German institution’s data protection officer identified that Microsoft’s US parent company control and encryption key access created risks that SCCs alone couldn’t address. If US authorities served FISA 702 orders on Microsoft for data related to research subjects who might have national security relevance—however tangentially—Microsoft would face legal compulsion to provide access to EU health data stored in its systems.

The German institution’s ethics committee, advised by the data protection officer, concluded that participating in research using US cloud infrastructure created risks incompatible with research subjects’ fundamental rights under Schrems II reasoning. Either the collaboration needed to implement adequate supplementary technical measures, or the German institution would withdraw from the research programme.

The NHS trust evaluated supplementary measure options. Pseudonymisation alone was insufficient because research utility required linking data to individual subjects. Encryption at rest using Microsoft’s key management failed because Microsoft retained decryption capability under government compulsion. Organisational measures—contractual audits, transparency commitments—couldn’t overcome US legal authorities overriding contractual protections.

The trust deployed Kiteworks for research data management with customer-managed encryption keys stored exclusively in NHS-controlled infrastructure. Research data from EU institutions flows through UK sovereign architecture where neither US cloud providers nor US authorities can access plaintext data. The German institution’s data protection officer approved the architecture as satisfying Schrems II supplementary measure requirements, enabling the research collaboration to continue.

UK Technology Company: SaaS Platform for EU Customers

A UK software company provides a SaaS platform for human resources management to customers across Europe. The platform previously ran on AWS infrastructure in EU regions, with the company positioning itself as a European alternative to US competitors. When customers began requesting Schrems II compliance documentation, the company discovered that its AWS architecture created exactly the vulnerabilities customers sought to avoid.

EU customers’ data protection officers identified that AWS, as a US company subject to FISA 702, maintained encryption key access enabling government-compelled data disclosure regardless of EU regional data residency. The UK company’s Standard Contractual Clauses with customers included commitments to protect data from unauthorised access—but how could those commitments be honoured when the company’s infrastructure provider could be compelled to provide US authorities access to customer data?

The company’s position as a European alternative to US competitors depended on genuinely protecting EU customer data from US surveillance. However, its AWS infrastructure meant that customer data remained as vulnerable to FISA 702 as if hosted directly by US competitors. The company’s marketing message about European data protection wasn’t supported by technical architecture actually preventing US government access.

The company re-architected its platform deployment, moving to UK-based sovereign cloud infrastructure with customer-managed encryption keys. EU customer data is encrypted using keys generated, managed, and stored entirely outside AWS control. The company can now demonstrate to customers’ data protection officers that its architecture satisfies Schrems II supplementary measure requirements—data stored on its platform remains unintelligible to US cloud providers and US government authorities, making the company’s European data protection promises technically verifiable rather than merely contractually asserted.

Comparison: Kiteworks vs. US Hyperscale Cloud Providers

Conclusion: Technical Architecture Determines Schrems II Compliance

Schrems II fundamentally changed international data transfer compliance by establishing that contractual protections alone cannot address government surveillance in destination countries. For UK organisations managing data flows between Britain and the European Union whilst using US cloud providers, this ruling creates legal, operational, and strategic imperatives that contractual language cannot satisfy.

The European Court of Justice didn’t rule that transfers to the United States are impossible—it ruled that such transfers require supplementary measures rendering data unintelligible to US government authorities. This technical requirement cannot be satisfied through contractual commitments, compliance certifications, or organisational measures that government surveillance laws can override. It requires cryptographic architecture where cloud providers never possess the encryption keys necessary to make data intelligible, even under legal compulsion.

UK adequacy from the European Commission provides streamlined mechanisms for UK-EU data flows, but this privileged status faces vulnerability if UK organisations enable US surveillance of EU personal data through inadequate cloud architecture. Privacy advocates successfully challenged EU-US Privacy Shield using Schrems II reasoning; they could deploy the same arguments against UK adequacy if British businesses widely adopt technical architectures facilitating exactly the surveillance that Schrems II found incompatible with EU fundamental rights.

For UK organisations, the path forward requires technical architecture rather than contractual optimism. Customer-managed encryption keys eliminating provider access satisfy EDPB supplementary measure requirements by creating mathematical guarantees that government compulsion cannot overcome. Sovereign deployment options keeping EU personal data on UK infrastructure eliminate onwards transfer complications entirely. These architectural approaches don’t merely address compliance obligations—they preserve the adequacy framework enabling efficient UK-EU data exchange that benefits all British businesses operating in European markets.

Schrems II compliance isn’t achieved through documentation—it’s achieved through architecture. UK organisations that recognise this distinction can build cloud infrastructure genuinely protecting EU personal data whilst maintaining operational efficiency. Those that rely on contractual promises from US providers retaining encryption key access create exposure for themselves, their EU partners, and ultimately for UK adequacy itself.

How Kiteworks Enables Schrems II Compliance for UK Organisations

Kiteworks addresses Schrems II supplementary measure requirements through architectural design satisfying EDPB Recommendations 01/2020. Customer-owned encryption keys with zero vendor access ensure data remains unintelligible to US authorities even under FISA 702 compulsion. FIPS 140-3 Level 1 validated encryption ciphers combined with S/MIME, OpenPGP, and TLS 1.3 protect data throughout its lifecycle, whilst cryptographic key control makes government access mathematically impossible regardless of legal demands.

Flexible, secure deployment options—on-premises, UK sovereign cloud, or air-gapped environments—eliminate US jurisdictional exposure entirely. When deployed outside US infrastructure, Kiteworks cannot be compelled under FISA 702, national security letters, or other extraterritorial surveillance authorities. Granular geofencing enforces access restrictions preventing authentication from US IP addresses, whilst jurisdictional controls ensure only authorised UK or EU personnel access EU personal data.

Kiteworks’ unified Private Data Network extends Schrems II compliance across all content communication channels: secure email, secure file sharing, secure MFT
secure web forms, SFTP, and others. Comprehensive audit logs documents all data access, supporting transfer impact assessments and demonstrating supplementary measure effectiveness. Integration with SIEM solutions provides real-time monitoring of EU personal data handling.

Kiteworks enables UK organisations to satisfy both standard contractual clauses requirements and EDPB technical supplementary measures, protecting UK-EU data flows whilst supporting UK adequacy preservation through demonstrable technical safeguards preventing US surveillance of EU personal data.

To learn more about protecting EU personal data in compliance with GDPR
and other regulatory compliance requirements, 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]