Schrems II — The Operational Reading Most Counsel Are Still Missing

The Schrems II Compliance Trap: Why Data Transfers Remain Architecturally Indefensible

Schrems II (2020) is read by most legal and compliance teams as a transatlantic data-transfer problem to be solved via Standard Contractual Clauses (SCCs), Transfer Impact Assessments (TIAs), and supplementary measures—a regulatory theatre that leaves operational security untouched and the underlying exposure structure intact.

The correct reading is sharper: Schrems II exposed that once data exists in identifiable form anywhere on your infrastructure—whether in a US cloud region, a EU data centre, or a supposedly "adequacy-compliant" third country—law enforcement, foreign intelligence services, and opportunistic threat actors all operate under the same architectural assumption: the data is there, it is knowable, and therefore it is obtainable. No contractual clause, encryption wrapper, or data-processing agreement remediates this. Legal counsel cannot enforce physics.

The operational lesson most organisations have failed to extract is that Schrems II's real mandate is not "fix your vendor lock-in negotiation," but rather "stop building systems where the data itself is the persistent, exfiltrable asset." This article examines what the regulatory judgment actually said, why standard remediation deepens rather than solves the structural exposure, and what architectural principles permit organisations subject to GDPR, DORA, NIS2, and equivalent regimes to operate lawfully and defensibly.

The Regulatory Narrative: What Schrems II Actually Forbade

The judgment (C-311/18, July 2020) invalidated the Privacy Shield framework and severely constrained the use of Standard Contractual Clauses. The core finding was that US federal law—specifically the FISA Amendments Act of 2008 and Executive Order 12333—permits bulk surveillance of non-US persons' data without individualized judicial oversight, and that no private contractual mechanism can override sovereign law. Organisations could no longer rely on the fiction that a DPA with a US vendor created a legal firewall.

In the operational aftermath, the Financial Conduct Authority (FCA), the European Banking Authority (EBA), the European Data Protection Board (EDPB), and (later) the National Competent Authorities (NCAs) clarified expectations. The EDPB issued Recommendations 01/2020 and 06/2023. The EBA's July 2023 guidelines on outsourcing to cloud service providers (EBA/GL/2023/06) made explicit that reliance on encryption, TIAs, and supplementary measures did not permit continued operation—the mere possibility of foreign access to in-scope data, combined with inadequate legal redress in the third country, remained non-compliant. The Irish Data Protection Commissioner's enforcement action against Meta (€1.2 billion, October 2022) and subsequent actions against Amazon AWS Ireland (€746 million, July 2021) affirmed this.

The practical compliance response has been threefold. First, organisations rewrote Data Processing Agreements and issued new Standard Contractual Clauses with ostensibly "supplementary measures"—clause 5(a) wording, binding corporate rules (BCRs), sub-processor prior approval workflows. Second, cloud vendors—primarily AWS, Azure, and Google Cloud—introduced regional data residency commitments, data-processing certifications, and contractual assurances that US law-enforcement queries would be subject to ECPA (Electronic Communications Privacy Act) warrant requirements and legal challenge mechanisms. Third, compliance teams deployed Transfer Impact Assessments (Article 6 EDPB Recommendation 01/2020)—risk matrices that scored the adequacy of third-country safeguards and documented "residual risk" as an inherent feature of transatlantic operations.

None of this has worked at the operational level.

Why Standard Remediation Fails: The Data Persistence Problem

The architectural flaw at the heart of the compliance response is the assumption that having data located in a compliant jurisdiction, with contractual assurances and encryption, is a solved problem. This is false.

Consider the 2024 Snowflake customer-tenant compromise cascade. Snowflake is a US cloud-native data warehouse. Between August 2023 and May 2024, attackers accessed customer environments—including those of Ticketmaster, AT&T, LendingClub, and others—via compromised customer service accounts, credential theft, and inadequate multi-factor authentication controls. The attack chain was entirely operational: no zero-day, no software vulnerability, no cryptographic break. The attacker needed only valid credentials to view and extract the data as it was stored—identifiable, structured, directly queryable. Ticketmaster alone lost customer PII for millions of users. The data was already in a US region, already encrypted at rest (AES-256), already subject to a Data Processing Agreement and Standard Contractual Clauses. None of those controls mattered.

Similarly, the 2023 MOVEit zero-day (CVE-2023-34362, later CVE-2023-35078) demonstrated that when a SaaS platform holds customer data in transferable form, the platform's security is everyone's security. Attackers chained unauthenticated file-transfer exploits across thousands of organisations—financial services, healthcare, government—and extracted personnel records, patient data, and tax information. The data was present, the vulnerability was present, and TIAs and SCCs were absent in the immediate moment of operational failure.

The Synnovis attack (June 2024) on the UK's NHS pathology services—orchestrated by the LockBit ransomware gang—destroyed not just the data but the entire operational capacity of one of England's largest pathology providers. The attackers encrypted over 100 NHS organisations' laboratory results, patient records, and diagnostic databases. NHS England had contracted with Synnovis, a third-party provider with legitimate access. Synnovis maintained backups and access logs. None of this prevented total operational collapse because the operational architecture was built on the assumption that the data exists somewhere, it is accessible to anyone with sufficient privilege, and therefore any compromise of that privilege is total compromise of the system.

These incidents share a structural pattern. Compliance frameworks like Schrems II, GDPR, DORA, and NIS2 are designed to mitigate the risk of data exposure and loss of availability. But they operate at the layer of governance, vendor selection, and incident response—they are post-breach narratives. They do not address the foundational architectural question: Why does your system store identifiable data in a form that any authenticated user (or any attacker with valid credentials) can read, copy, and exfiltrate?

The standard remediation—encryption, DPAs, TIAs, supplementary measures, regional residency, contractual liability clauses—treats the data itself as an inevitable asset that must be protected in place. This is the precise opposite of what Schrems II's structural reading demands. The judgment says that once data exists in identifiable form under the operational control of any entity (yourself, a vendor, a cloud provider) in a jurisdiction with foreign intelligence legislation, the data is no longer a legal problem you can solve with better contracts. It is an architectural problem that can only be solved by not having the data exist in that form.

The PULSE Reading: Zero-Knowledge Infrastructure as Architectural Necessity

The PULSE doctrine reads Schrems II as an accidental mandate for zero-knowledge substrate design—architecture where the organisation and its infrastructure do not hold, process, or store identifiable data in plaintext or derivable form at any point in the operational lifecycle.

This is not metaphorical. Consider the operational requirements: GDPR Article 32(1)(a) mandates "pseudonymisation and encryption of personal data." Article 5(1)(f) mandates "integrity and confidentiality." DORA Article 10 mandates "high-level of cryptographic systems and tools." NIS2 Article 21(2) mandates baseline controls including "encryption of sensitive data." None of these provisions allow the interpretation that encryption at rest, with managed keys held by the platform operator, satisfies the requirement. Encryption where the cloud vendor, the system administrator, or any integrated service holds the decryption key is not encryption from the perspective of the data subject—it is encryption to other people, not to the organisation responsible for the data.

The architectural shift requires three operational principles—

Data-Plane Cryptography as Substrate. The organisation, not the vendor, holds the encryption keys. Data is encrypted client-side—in the application layer, in the user's browser, in the mobile device—before transmission. Once encrypted, the data is indistinguishable from noise to every intermediate system: the cloud provider, the SaaS platform, the CDN, the analytics vendor, the backup service, law enforcement accessing the data centre physically, and foreign intelligence services. The data is not there in a form that is intelligible to anyone except the holder of the key. This is not "encryption in transit" (TLS) or "encryption at rest" (AES with vendor-managed keys). This is cryptographic architecture where the data is never stored in decrypted form by any system except the client.

Control-Plane Isolation. The systems that manage access, verify identity, issue keys, and log operations must be architecturally isolated from the systems that store data. Control-plane compromise (credential theft, insider access, law enforcement demands for access logs) does not permit the attacker to read the encrypted data. The compromise permits only the recording of which user attempted to access which encrypted object—metadata that is harmful, but not catastrophic. The data itself remains opaque.

Continuous Adversarial Posture Drift. Rather than assuming a static threat model (MITRE ATT&CK, NIST CSF, ISO 27001), the architecture must embed mechanisms that continuously shift the operational posture in response to evolving threat surface. If an attacker compromises a user's credentials, the architecture does not rely on detection (EDR, SIEM alerts) and response procedures (access revocation, incident review). Instead, the architecture rotates the user's key material, rekeys all accessed data-objects, and invalidates prior access—operationally, before the attacker can exfiltrate at scale. This is not "continuous monitoring" (the compliance language). This is active defensive posture mutation embedded into the substrate.

Domain-Specific Automation. Generic SIEM, SOAR, and EDR platforms operate at the signature and alert level—they are fundamentally reactive. For financial services, healthcare, and critical infrastructure, the system must embed domain-specific primitives: for healthcare, every access to a patient record automatically triggers a cryptographic audit trail (Certificate Transparency-style append-only logs) that the patient can independently verify; for financial services, every transaction triggers a zero-knowledge proof that the transaction is compliant with regulatory thresholds, without revealing the transaction content to intermediate systems; for critical infrastructure, every configuration change triggers a cryptographic attestation that the change meets security policy, without transmitting the plaintext policy definition to external auditors.

These principles are not theoretical. They are embedded into zero-knowledge proof systems (Aztec, Aleo), hardware security modules with key-derivation capabilities (TPM 2.0, FIPS 140-3 Level 3+), and decentralised key management infrastructures (threshold cryptography, shamir's secret sharing, MPC-based signing). They are the architectural substrate of DeFi protocols, anonymity networks, and classified military systems. They are not yet mainstream in enterprise software, because the incentive structure of cloud vendors and SaaS platforms depends on centralised data aggregation and vendor-managed encryption.

Regulatory Momentum: DORA, NIS2, and the Operational Codification of Zero-Knowledge

Schrems II was a privacy judgment. But regulatory momentum is shifting the requirement from data protection law into operational resilience law—and that shift makes zero-knowledge architecture a compliance necessity rather than an edge case.

The Digital Operational Resilience Act (DORA, in force January 2024) applies to "large" financial entities and critical third parties. Article 10 mandates "advanced" cryptographic techniques. Article 6(2) mandates that entities "implement and maintain governance arrangements, policies, procedures, and processes" including "security policies which ensure a high level of protection." Article 15 introduces the concept of "information and communication technology (ICT) concentration risk"—the regulatory term for what happens when an organisation concentrates its data and processing with a single cloud vendor or platform. DORA's definition of "advanced cryptography" remains contestable in implementation, but the Italian CONSOB and the Dutch AFM have begun issuing guidance indicating that "vendor-managed encryption" does not satisfy the requirement.

The Network and Information Security Directive 2 (NIS2, in effect October 2024) applies to "essential services" and "important services" across energy, water, healthcare, transport, digital infrastructure, and public administration. Article 21(3)(a) requires "encryption of sensitive data in transit and at rest." More importantly, Article 23 mandates "backup and recovery policies and procedures" with independent verification and testing. The operational reading is that regular backup and recovery exercises must be conducted in a way that is independent from the attacker's access to the primary systems—implying that encryption keys, recovery mechanisms, and audit trails must be kept separate from the operational infrastructure. NIS2 also requires that essential service operators conduct biennial risk assessments with third parties and verify "technical and organisational measures."

The FCA's Operational Resilience regime (COBS 1R, in effect December 2024) and the PRA's BS 23/2023 require that firms identify "important business services" and test their ability to deliver these services even under a "severe but plausible stress scenario"—which now explicitly includes cyber attack with extended data loss or unavailability. The only credible way to pass such testing is to build infrastructure where the attacker's access to encrypted data does not translate into loss of operational function—which is the zero-knowledge architecture.

The Operational Mandate: Architecture, Not Compliance Paperwork

Schrems II was published in July 2020. It is now January 2025. Four and a half years of compliance effort—millions of pounds in consulting fees, hundreds of hours in legal review, tens of thousands of revised Data Processing Agreements—have produced exactly zero reduction in the incident rate for organisations subject to GDPR and equivalent regimes. Snowflake, MOVEit, and Synnovis occurred after Schrems II. So have the Change Healthcare ransomware attack (February 2024, affecting millions of US patients), the Latitude compromise (August 2023), and the Medibank breach (September 2022).

The pattern indicates that the compliance layer has decoupled from the operational layer. Legal counsel, compliance officers, and auditors are working from a model where Schrems II requires contractual and procedural remediation. But the judgment—read architecturally—demands something far more radical: that organisations stop building systems where identifiable data is persistently stored, centrally managed, and accessible to any user (or attacker) with sufficient privilege.

The mandate is clear. It is not new guidance on Standard Contractual Clauses. It is not a revised Transfer Impact Assessment template. It is not a supplementary measure checklist. It is the redesign of the operational infrastructure from substrate upward, such that—

• Data is encrypted at the source, before ingestion into any shared infrastructure.
• Keys are held and managed by the organisation, not delegated to the vendor.
• Access to data is mediated by zero-knowledge proofs or cryptographic signatures, not by authentication alone.
• The control plane (who accessed what) is architecturally isolated from the data plane (what the data contains).
• Continuous drift of the operational posture replaces static compliance frameworks.
• Domain-specific automation embeds regulatory primitives into the infrastructure itself.

This is not optional for organisations subject to GDPR, DORA, NIS2, or equivalent regimes. It is the architectural reading of what those regulations demand.

---

Qualified operational teams are invited to request a technical briefing under mutual NDA; contact PULSE Digital Security to discuss your specific infrastructure and regulatory scope.