CORE THESIS Pseudonymisation without customer-held key sovereignty — exclusive legal and technical control over the encryption keys by the controller — is not a risk reduction against the CLOUD Act and FISA Section 702. It is the appearance of one. Only an architecture in which the key never enters the provider’s infrastructure converts a contractual promise (won’t) into a technical fact (can’t).

A few days ago a file landed on my desk that laid bare the entire mechanics of current cloud-compliance practice. An organization I advise — one that processes particularly sensitive personal data — had received a consent request from an actuarial processor. The firm was migrating its processing — long-running pension and benefits calculations — from a private cloud to Microsoft Azure Public Cloud. Inside the accompanying documents stood the three words that have circulated through German data processing agreements for the past three years as a kind of compliance sedative: “pseudonymisation” (the replacement of direct identifiers such as name or personnel number with a neutral token, so that the data can only be linked to a person via a separately held mapping table), “encryption with our own keys”, and “data storage in the EU”. Three words that make everything appear to be in order. Three words, two of which explain nothing as long as one fails to ask the right follow-up question.

The follow-up question is: where is the encryption key — the cryptographic code without which the encrypted data cannot be read? And: who holds it? These two questions decide whether “encryption” is an effective protective measure or merely a word in the contract.

In German data processing agreements this question has remained largely invisible between 2020 and 2026. It rarely appears in clauses, it rarely appears in Transfer Impact Assessment (TIA — the assessment of third-country transfer risk required by post-Schrems-II case law) reports, it rarely appears in consent submissions. Microsoft itself provides the answer if you look for it — the technical documentation is transparent, the architectural space is well described.¹ But the contractual market between processors and controllers rarely raises the question, because answering it has uncomfortable consequences. “We encrypt” is a compliance statement. “The key is with us, not with the provider” is an architectural decision. The second costs money and operational effort. The first does not.

The argument of this text fits in a single sentence: pseudonymisation without customer-held key sovereignty — that is, without the controller exercising exclusive legal and technical control over the encryption keys — is not a risk reduction with respect to the CLOUD Act and FISA Section 702. It is the appearance of one. This text explains why, in what legal and technical context, and what must be written into the DPA for the measure actually to take effect.

Two statutes, two threat profiles, one shared lever

The CLOUD Act and FISA Section 702 are routinely mentioned in the same breath in German compliance discussions, as though they were two variants of the same risk. They are not. They target different processing situations, activate different procedural pathways, and — what matters for the defence — leave different traces.

The CLOUD Act is a 2018 US federal statute that allows US law-enforcement authorities to compel US-based providers to disclose data in their “possession, custody, or control” — meaning data over which the provider has legal or factual control — regardless of where that data is physically stored.² The term “control” is decisive: it does not attach to the storage location, but to the legal and factual power of disposal that the US provider has over the data. The addressee is a single company, the goal is a specific criminal proceeding. The provider has formal challenge rights; the affected customer usually does not. Microsoft has, in recent versions of its Data Protection Addendum (DPA), included undertakings to challenge US authority requests where legally possible, and to inform the customer where US law does not expressly forbid it.³

FISA Section 702 follows a fundamentally different logic. Introduced in 2008 as part of the FISA Amendments Act, it is a foreign-intelligence programme that authorises the bulk collection of communications of non-US persons located outside the United States by US intelligence agencies.⁴ Unlike the CLOUD Act, there are no individual case orders from a criminal court here, but rather annual directives issued by the Foreign Intelligence Surveillance Court (FISC) — a US court specifically established for intelligence proceedings. These directives compel providers to ongoing cooperation. The customer is not informed; the provider is bound by a criminally enforced confidentiality obligation. The 2024 reauthorisation through the Reforming Intelligence and Securing America Act (RISAA) additionally expanded the definition of electronic communications service provider (ECSP) — the providers obligated to cooperate — to capture a substantially broader class of cloud and infrastructure providers.⁵ Section 702 was scheduled to expire on 20 April 2026; a 10-day extension was passed in mid-April and signed into law shortly before the deadline.⁶ On 30 April 2026 Congress passed a further 45-day extension, keeping Section 702 in force through 12 June 2026 while reauthorisation negotiations continue.⁷ As this text is being published, that extension is still running and the substantive reauthorisation debate is unresolved. None of this affects the substance of our question: even if Congress allows a temporary lapse, the annually granted FISC directives remain in force, and reauthorisation is, by all indicators, likely.⁸

For the architectural question, one point stands out: it was FISA Section 702, not the CLOUD Act, that drove the CJEU’s decision against Privacy Shield adequacy in Schrems II.⁹ The Court found that Section 702, together with Executive Order 12333, lacks proportionality safeguards equivalent to those required by European fundamental rights. The Recommendations 01/2020 of the European Data Protection Board (EDPB), drafted as a direct response to Schrems II, are calibrated in their use-case logic for precisely this threat scenario.¹⁰

Both statutes share — and this is the point — the same technical lever: they reach what the provider can hand over or pass through. What the provider can neither hand over nor decrypt, because it is technically unavailable to it, is removed from both programmes. From this it follows: the effective defence is not legal, it is architectural.

Geography is not a defence

The most common German answer to this threat scenario has, for years, been: “data storage in the EU”. The argument runs: if the data sits in a German data centre, German law applies and US authorities have no access. This answer is legally inaccurate and technically incomplete.

It is legally inaccurate because both the CLOUD Act and FISA Section 702 do not target the storage location, but the legal personality of the provider. Microsoft Corporation is a US legal entity headquartered in Redmond, Washington. Microsoft Ireland Operations Limited, Microsoft Deutschland GmbH, and all other subsidiaries are subject indirectly to US law through the corporate structure: what the parent can legally direct falls within the “control” test of the CLOUD Act. Microsoft’s EU Data Boundary programme — a contractual assurance that certain customer data are processed within the EEA — has never addressed this reality; it concerns the place of processing, not the legal jurisdiction.¹¹ Microsoft itself has stated this clearly in its own publications: the rights of the hosting country are “limited in the context of accessing that data”.¹² The limitation applies to national authorities of the hosting country — not to US authorities, who address Microsoft as a US corporation.

This is the point at which the case stops being about Microsoft. Amazon Web Services (Amazon.com, Inc., Seattle) and Google Cloud (Google LLC, Mountain View) are US corporations on exactly the same footing. The AWS European Sovereign Cloud and Google’s EU regions move the data; they do not move the corporate parent out of US jurisdiction. The common reflex of choosing “a European region of a US hyperscaler” addresses geography and leaves the jurisdictional question untouched. Whichever of the three you pick, the CLOUD Act and FISA 702 reach the same way — and, as the next section shows, so does the only effective defence.

It is technically incomplete because EU storage at most captures primary customer data. Derived data — logs, telemetry (continuous operational and usage measurement data), diagnostic output, operational metadata — flow into centralised observability platforms which, depending on configuration, do not lie within the EU perimeter. This data category may contain personal content and is not mentioned in the cover letter of our case — as in most comparable cases.

Geography, then, is not a defensive wall. It is a label. What counts is the cryptographic ownership position — that is: who holds the key by which the data can be made readable?

Pseudonymisation in three configurations

The GDPR defines pseudonymisation in Article 4 No. 5 as processing personal data such that it can no longer be attributed to a specific data subject “without the use of additional information”.¹³ The legally decisive term is not “pseudonymisation”, but “additional information”. This additional information — the mapping table, the key material, the re-identification logic — always exists. The data would only be anonymised once they had been finally erased. As long as they exist, the legally relevant question is: who has access to that additional information?

In cloud architectures, three configurations can be distinguished, all of which are bundled in German DPAs under the same wording — “pseudonymisation with encryption” — although they represent fundamentally different protection levels. The distinction is not specific to one provider. Each of the three large hyperscalers offers the same ladder of options under different product names; the difference that matters is always the same one: where, physically and logically, the key resides.

Key location	Microsoft Azure	Amazon Web Services	Google Cloud
Provider holds the key (provider infrastructure)	Customer-Managed Keys (CMK) in Azure Key Vault	Customer Managed Keys in AWS KMS	Customer-Managed Encryption Keys (CMEK) in Cloud KMS
Customer generates key, provider holds it	BYOK import into Azure Key Vault	Imported key material in KMS	Imported key material in Cloud KMS
Key held entirely outside provider (external HSM)	Hold Your Own Key (HYOK) / Managed HSM External Key Storage	Key Store (XKS) via external HSM	Cloud External Key Manager (EKM) + Key Access Justifications

For concreteness the case at hand runs on Microsoft Azure, so the three configurations are described in Azure terms below; the AWS and Google equivalents behave identically with respect to the CLOUD Act and FISA 702.

Configuration A — Customer-Managed Keys (CMK), provider-held. The customer formally manages the encryption keys, but they reside in the Azure Key Vault, that is, within Microsoft infrastructure (the AWS KMS and Google Cloud KMS equivalents sit the same way). Microsoft has no routine plaintext access, but on a legally compelling order — whether CLOUD Act or FISA directive — can provide both the encrypted data and the means for its decryption. The provider’s own contractual commitment is illuminating but circumscribed: it is a promise not to defeat its own customer-controlled encryption and to challenge any legal demand requiring it to do so — a policy undertaking and a litigation posture, not a statement of technical impossibility (Microsoft’s exact wording, and what it implicitly concedes, is examined in the next section). This holds regardless of whether pseudonymisation is also applied, where the pseudonymisation table is held with Microsoft or secured via Microsoft keys. The protective effect against the CLOUD Act and FISA 702 in this configuration is predominantly contractual rather than architectural — and may therefore not withstand a legally enforceable disclosure order once the provider’s challenge is exhausted.

Configuration B — Bring Your Own Key (BYOK). The customer generates the key within its own infrastructure and imports it into the provider’s key vault. Operational availability now resides within a provider system, while the generation path is customer-side. In practical legal terms, BYOK differs little from CMK: once the key sits in the provider’s vault, it is accessible to the provider within the meaning of the CLOUD Act’s “control” test. The protective effect is marginally higher than under CMK, but conceptually inadequate.

Configuration C — key held entirely outside the provider (HYOK / XKS / Cloud EKM). The key resides exclusively in a customer-operated Hardware Security Module (HSM — a specialised hardware component in which cryptographic keys are tamper-resistantly generated and stored), physically and logically outside the provider’s infrastructure. Encryption and decryption operations run via calls against the customer’s external HSM; the provider never receives the key. Microsoft describes its variant as one in which “you always retain full control over your keys”;¹⁴ AWS positions External Key Store as enabling customers to “bar AWS’s access” to keys and data that could otherwise be mandated under the CLOUD Act;¹⁵ Google adds Key Access Justifications, which let the customer programmatically deny a decryption request even when it originates from a third-party authority.¹⁶ On a CLOUD Act order, the provider could hand over pseudonymised and encrypted data — but neither decrypt it nor reach the customer’s pseudonymisation table. On a FISA directive, the provider could pass through that same encrypted stream without the intelligence agency receiving plaintext. The protective effect is substantive — and identical across all three providers.

The thesis of this text emerges from this enumeration: Configurations A and B do not reduce the risk; they reduce the impression of risk. Only Configuration C makes pseudonymisation what it ought to be — a measure that removes the provider from the position of intermediary.

”The key is on our side” — a sentence that settles nothing

The case that opened this article makes the point concrete. Asked where the encryption keys are held, the processor answered that encryption uses customer-managed keys, generated and managed by its own IT department, and that the key “lies in the hands of the controller”. Read quickly, that is reassuring. Read precisely, it answers a different question than the one that matters.

“Generated and managed by our IT” describes who administers the key’s lifecycle. It does not say where the key physically resides. In the default customer-managed-key model the answer is: inside the provider’s own key vault — on Azure, the Azure Key Vault; on AWS, AWS KMS; on Google Cloud, Cloud KMS. The customer controls the key’s policy and rotation, but the key material sits within the provider’s infrastructure, and every decryption operation runs there (Figure 1).

This is not a hidden detail; the provider states its position openly. Microsoft commits that it will not attempt to defeat its own customer-controlled encryption features, and that if faced with a legal demand to do so it “would challenge such a demand on any lawful basis”.¹⁷ Read as a security engineer reads it, that sentence is an admission rather than a reassurance. A provider that promises not to defeat its own encryption — and undertakes to challenge a legal order requiring it to — is stating, in plain terms, that defeating it lies within technical reach. Won’t is a policy. Would challenge is a litigation posture. Neither is can’t. Only an architecture in which the key never enters the provider’s infrastructure converts won’t into can’t — and that is HYOK on Azure, XKS on AWS, Cloud EKM on Google (Figure 2).

So when a processor writes “the key is on the customer side”, the controller’s task is to translate that sentence into the one question that decides the matter: is the key managed by the customer but stored in the provider’s vault — or is it held in a customer-operated HSM the provider cannot reach? The first is a policy promise. The second is a technical fact. The distinction is the whole difference between a barrier that a court order can pass through and one that it cannot (Figure 3).

It is worth restating why this matters, because the purpose is easy to lose behind the mechanics. A customer-managed key and pseudonymisation are not goods in themselves. In a cloud data processing agreement they exist for one reason: to neutralise the very transfer risk that the CLOUD Act and FISA 702 create — the same risk that, under Schrems II and Articles 44 et seq. GDPR, a controller transferring personal data to a US provider is legally required to bring under control. They are supplementary measures in the sense of the EDPB Recommendations, and they earn that status only if they render access by US authorities ineffective. That is the test they have to pass. So the question behind “is a customer-managed key enough?” and “is pseudonymisation enough?” is really one question: do these measures still achieve the purpose for which they were deployed? The answer follows directly from everything above. If the provider holds the key and can be compelled to decrypt — or holds the means to re-identify pseudonymised data — then the CLOUD Act and FISA 702 reach readable personal data exactly as they would with no measure in place at all. The risk the measure was adopted to remove is still present. The control exists on paper; the protection does not. And a third-country transfer that is protected only on paper is not a compliant transfer — it is an open finding waiting for the next audit. The encryption and the pseudonymisation were deployed to escape these two statutes; if the provider can still hand over the key, that escape has not happened.

Actuarial work as a stress test

At this point the actuarial use case becomes instructive, because it shows the limits of pseudonymisation even in Configuration C. Actuarial work is, at first glance, an area where pseudonymisation should be easy — names, social security numbers, personnel numbers can be readily replaced by pseudonyms without affecting the calculation. On second glance, things become more complicated. Actuarial work runs on a rich set of quasi-identifiers — data fields that do not identify on their own, but which in combination enable unique attribution: date of birth, gender, date of joining service, marital status, number of dependent children, salary band, pension class.

In her 2000 work, Latanya Sweeney showed that the combination of postcode, date of birth and gender suffices to uniquely identify roughly 87 percent of the US population.¹⁸ El Emam and colleagues found in 2011 an even more dramatic figure for Montreal: with full postcode, date of birth and gender, 98 percent of the population was unique.¹⁹ These figures rise when longitudinal data — that is, repeated observations of the same person over time — are present. Actuarial work supplies precisely such longitudinal series: a pension calculation is updated over decades.

For threat modelling against FISA Section 702 this is particularly relevant. FISA 702 is not a single case order but a programme. A data stream tapped continuously over five years can be aggregated, correlated, and joined with external datasets — voter rolls, public records, commercial data-broker feeds. Even pseudonymised datasets with rich quasi-identifiers become re-identifiable in this threat scenario.

The conclusion is not to abandon pseudonymisation. The conclusion is to complete the measure: customer-held key sovereignty as the foundation, pseudonymisation at source (with the mapping table residing exclusively with the controller, not with the processor), and — where possible — generalisation of quasi-identifiers, that is, replacing exact values with bands: age bands instead of dates of birth, salary bands instead of figures, service-time classes instead of exact start dates. This layering is the only one that withstands the long-running correlation logic of FISA 702.

What the EDPB Recommendations 01/2020 actually say

In practice, Use Case 2 of the EDPB Recommendations 01/2020 — the pseudonymisation use case — is usually received in shorthand: “If pseudonymisation is applied, the transfer is permissible.” This is not what the document says.

Use Case 2 expressly requires that the additional information enabling re-identification be held exclusively by the data exporter and kept separately, in a Member State or in a third country offering an adequate level of protection.²⁰ The data importer — meaning the cloud provider in the third country — must neither hold the additional information nor possess any means enabling re-identification with reasonable effort. The EDPB further requires that pseudonymisation itself be designed, according to the current state of the art, such that re-identification — even through the use of external data — is “very unlikely”.

In its 2025 Pseudonymisation Guidelines, the EDPB confirmed this position and expanded it through the concept of the pseudonymisation domain: that is, the processing space within which the additional information is available and re-identification would in principle be possible.²¹ Translated into our architectural question: if the mapping key resides with the provider, the pseudonymisation domain is identical with the provider domain. Only when the key — and therefore the pseudonymisation domain — remains with the controller is the protective effect against a third-country provider intact.

This is the legal foundation for the proposition that customer-held key sovereignty is not a technical option, but a prerequisite for effective pseudonymisation in the face of CLOUD Act and FISA 702 risks. Whoever leaves the key with the provider does not satisfy the EDPB requirement under Use Case 2 — no matter how meticulously the pseudonymisation itself is implemented.

The complete protective architecture

What, then, must actually appear in a Microsoft Azure architecture for a German controller to satisfy its duty of care? Three layers, in the following order.

Layer 1: Customer-held key sovereignty. HYOK via external HSM is the most robust variant; it does, however, lead to service-level limitations because certain Microsoft functionalities — such as server-side search, eDiscovery or web preview — require plaintext access, which is excluded under HYOK.²² An intermediate solution is Azure Key Vault Managed HSM External Key Storage, in which the key resides in a customer-controlled HSM environment outside Microsoft’s premises — explicitly classified as a form of HYOK in Microsoft’s own documentation. Those needing more service functionality may use Azure Key Vault Managed HSM with Customer-Managed Keys, but accept that the protective effect against CLOUD Act and FISA 702 is significantly reduced. The same logic applies on the other two hyperscalers: AWS External Key Store (XKS) and Google Cloud External Key Manager (Cloud EKM) place the key in a customer-operated HSM outside the provider, with the identical “kill switch” property — disconnect the external key manager and all cryptographic operations cease, leaving the provider able to surrender only ciphertext. The product names differ; the architectural test does not.

Layer 2: Pseudonymisation at source. Pseudonymisation must take place before data leave the controller’s perimeter. The mapping table remains with the controller — physically, organisationally, cryptographically. Microsoft receives only pseudonymised and encrypted data. Implementation may run via customer-side preprocessors, edge components, or dedicated pseudonymisation gateways. The decisive test is not the implementation pathway, but where the mapping table resides.

Layer 3: Confidential computing and supplementary operational layers. Azure Confidential Computing uses Trusted Execution Environments (TEE) — hardware-isolated memory regions, cordoned off from the rest of the operating system, in which data remain encrypted even during processing.²³ This layer addresses a residual risk that HYOK alone does not eliminate: plaintext exposure during in-memory processing, in any scenario where the provider could be compelled to perform operations on customer data on its own infrastructure. Customer Lockbox — Microsoft’s contractual assurance that Microsoft staff may access customer data in a support scenario only with the customer’s express approval — addresses Microsoft staff access during support, not legal authority demands. It therefore does not apply to CLOUD Act or FISA 702 scenarios at all: those operate through entirely separate compulsion mechanisms over which Lockbox has no purchase.²⁴ The EU Data Boundary, as set out above, controls only the place of processing and is no protection against US authority access.

Taken together, this architecture forms a defensive line that can be summarised in a single sentence: Microsoft can hand over encrypted bytes upon order — and nothing else. What lies behind those bytes cannot be decrypted without the customer-held key, cannot be re-identified without the customer-held mapping table, and cannot be tapped without plaintext processing access. This is not the abolition of the CLOUD Act and FISA 702. It is their technical neutralisation — the legal claim still exists, but its enforcement runs into a void.

What must appear in the DPA

From this architectural logic follows a pragmatic checklist for anyone concluding a DPA with a cloud processor. Four questions suffice to determine, within ten minutes, whether the asserted protection holds.

First: where is the encryption key? The answer must be specific — Customer-Managed Keys (key with the provider), Bring-Your-Own-Key (key customer-generated, but in the provider’s vault), or the external-key model (key in a customer-operated HSM: HYOK on Azure, XKS on AWS, Cloud EKM on Google). If the answer is “with the provider” or “in the cloud”, the conversation ends there.

Second: where is the pseudonymisation table? If the table resides with the processor or the cloud provider, pseudonymisation is no effective protection against CLOUD Act or FISA 702 risk. It is an internal data-minimisation measure — sensible, but insufficient.

Third: which quasi-identifiers remain in the pseudonymised dataset, and have generalisations been applied? The answer should reflect the Sweeney reference and at least basic k-anonymity considerations — k-anonymity is the mathematical measure of how many people with an identical quasi-identifier combination must be present in the dataset for individuals not to be singled out. If the answer is “we only pseudonymise the names”, the measure is ineffective against an actor capable of aggregation and correlation.

Fourth: does the Transfer Impact Assessment address this architecture — or does it content itself with stating that pseudonymisation is applied? A TIA that explicitly evaluates cryptographic key sovereignty, the pseudonymisation domain and quasi-identifier generalisation is defensible. A TIA that points to the EU-US Data Privacy Framework and “EU data storage”, without raising the architectural question, is not.

If even one of these questions is answered with “Microsoft” or with vagueness, the DPA may provide formal compliance indicators without materially reducing the underlying disclosure risk.

C3A: from CISO position to regulatory expectation

Until April 2026, the position taken in this text was the argument of a minority of data-protection architects and CISOs who had experienced in their practice what separates technical reality from contractual poetry. With the publication of C3A — Criteria enabling Cloud Computing Autonomy — by the Federal Office for Information Security (BSI) on 27 April 2026, this argument has become a federal-authority expectation.

The C3A presupposes that the cloud provider satisfies the criteria of the C5 catalogue (Cloud Computing Compliance Criteria Catalogue, BSI’s established cloud-security standard); it operationalises the question of sovereignty on a second layer above this security baseline.²⁵ Within the six sovereignty domains, the SOV-3 Data Sovereignty domain is directly relevant: it defines customer-controlled external key management as an auditable sovereignty criterion — without prescribing any particular technical implementation. The SOV-4 Operational Sovereignty domain goes further and codifies what BSI in its accompanying press release of 27 April 2026 framed as cyber dominance — the persistent ability of a vendor to retain access to the systems and data of its customers.²⁶ The Hessian Data Protection Commissioner (HBDI) had already reached an analogous conclusion in its November 2025 analysis of Microsoft 365: even with the contractual improvements Microsoft introduced in the public-bodies DPA, the residual risk of access by US authorities is not eliminated.²⁷ BSI’s position is unambiguous: non-European products may continue to be used, but only under conditions enabling self-determined use.

This changes the character of the pseudonymisation-and-key-sovereignty discussion. What in 2025 was discussed as best practice by individual actors has, in 2026, become an auditable expectation of the national IT-security regulator.²⁸ For sovereign procurement decisions — and, by gravitational pull, for the broader regulated market in Germany — the standard for cloud assessment in the coming years will no longer be “data storage in the EU”, but “customer-held key sovereignty, customer-held pseudonymisation domain, auditable disconnect capability”. Whoever fails to reflect these standards in their DPA will reflect them at the latest during the next supervisory audit.

Three sentences to take away

SUMMARY FOR DECISION-MAKERS Pseudonymisation is a conditional measure. The condition is: customer-held key sovereignty (HYOK / XKS / Cloud EKM), combined with a customer-held pseudonymisation domain and quasi-identifier generalisation. Whoever lacks this layering does not have pseudonymisation — they have a label. Whoever leaves the key with the provider has limited risk minimisation against the CLOUD Act and FISA Section 702 — what remains is an appearance of compliance rather than a technically enforceable protection model. The two statutes cannot be abolished, but they can be technically neutralised — if the architecture is right.

Pseudonymisation is a conditional measure. The condition is: customer-held key sovereignty, combined with a customer-held pseudonymisation domain and quasi-identifier generalisation. Whoever lacks this layering does not have pseudonymisation — they have a label.

Whoever leaves the key with the provider has limited risk minimisation against the CLOUD Act and FISA Section 702 — what remains is an appearance of compliance rather than a technically enforceable protection model. This statement is not polemical; it is the direct consequence of GDPR Article 4 No. 5, EDPB Use Case 2 and Microsoft’s own architectural documentation.

The CLOUD Act and FISA 702 cannot be abolished. But they can be technically neutralised — if the architecture is right. That is precisely the task of the next two years: turning DPAs that contain the right words into DPAs that reflect the right architectures.

Glossary of abbreviations

Term	Definition
BYOK	Bring Your Own Key — customer-generated key imported into the provider’s vault
C3A	Criteria enabling Cloud Computing Autonomy — BSI sovereignty framework, April 2026
C5	Cloud Computing Compliance Criteria Catalogue — BSI’s established cloud-security standard
CLOUD Act	Clarifying Lawful Overseas Use of Data Act — US federal statute, 2018
CMK	Customer-Managed Key — customer controls policy, key stored in provider’s vault
CMEK	Customer-Managed Encryption Keys — Google Cloud’s CMK equivalent
DEK	Data Encryption Key — symmetric key that encrypts the actual data
DPA	Data Processing Agreement (Auftragsverarbeitungsvertrag, AVV)
ECSP	Electronic Communications Service Provider — providers obligated to cooperate under FISA 702
EDPB	European Data Protection Board
EDPS	European Data Protection Supervisor
EKM	(Cloud) External Key Manager — Google Cloud’s external-HSM model
FISA 702	Foreign Intelligence Surveillance Act, Section 702 — US foreign-intelligence programme
FISC	Foreign Intelligence Surveillance Court — US court for intelligence proceedings
HBDI	Hessian Data Protection Commissioner (Hessischer Beauftragter für Datenschutz und Informationsfreiheit)
HSM	Hardware Security Module — tamper-resistant hardware for cryptographic key storage
HYOK	Hold Your Own Key — key never enters provider infrastructure
KMS	Key Management Service — AWS’s key vault product
RISAA	Reforming Intelligence and Securing America Act (2024)
SOV-3 / SOV-4	C3A sovereignty domains — Data Sovereignty (SOV-3), Operational Sovereignty (SOV-4)
TEE	Trusted Execution Environment — hardware-isolated, encrypted memory region
TIA	Transfer Impact Assessment — third-country transfer risk assessment under Schrems II
XKS	External Key Store — AWS’s external-HSM model

Bibliography

Statutes & case law

CLOUD Act: Clarifying Lawful Overseas Use of Data Act, Pub. L. No. 115-141, 132 Stat. 348 (2018), codified at 18 U.S.C. § 2713 https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title18-section2713

FISA Section 702: Foreign Intelligence Surveillance Act of 1978, Section 702, introduced by the FISA Amendments Act of 2008, Pub. L. No. 110-261, codified at 50 U.S.C. § 1881a

RISAA 2024: Reforming Intelligence and Securing America Act, H.R. 7888, Pub. L. No. 118-49 (2024)

CJEU Schrems II: Judgment of 16 July 2020, Case C-311/18, paragraphs 178–185 and 198–202 https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:62018CJ0311

GDPR Article 4 No. 5: Regulation (EU) 2016/679, definition of pseudonymisation

EU regulatory guidance

EDPB: Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, final version v2.0, 18 June 2021 https://www.edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf

EDPB: Guidelines 01/2025 on Pseudonymisation — analytical summary at European Law Blog https://www.europeanlawblog.eu/pub/tfef074h

BSI: Criteria enabling Cloud Computing Autonomy (C3A), v1.0, 27 April 2026 https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/CloudComputing/C3A_Cloud_Computing_Autonomy.pdf

BSI: Press release — C3A: BSI publishes sovereignty criteria for cloud services, 27 April 2026 https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260427_C3A.html

HBDI: Report on the use of Microsoft 365, 15 November 2025, 137 pages https://datenschutz.hessen.de/sites/datenschutz.hessen.de/files/2025-11/hbdi_bericht_m365_2025_11_15.pdf

Provider documentation

Microsoft Learn: Data controls — Sovereign Public Cloud, April 2026 https://learn.microsoft.com/en-us/azure/azure-sovereign-clouds/data-controls

Microsoft Learn: Data sovereignty — Hosting Country Rights https://learn.microsoft.com/en-us/industry/sovereign-cloud/concepts/data-controls

Microsoft Learn: Controls and principles in Sovereign Public Cloud — External Key Storage and HYOK, April 2026 https://learn.microsoft.com/en-us/industry/sovereign-cloud/sovereign-public-cloud/overview-controls-principles

Microsoft Learn: Control your cloud data by using Managed HSM, April 2026 https://learn.microsoft.com/en-us/azure/key-vault/managed-hsm/mhsm-control-data

Microsoft Learn: Confidential computing overview, April 2026 https://learn.microsoft.com/en-us/azure/azure-sovereign-clouds/public/confidential-computing

Microsoft: Online Services Data Protection Addendum (DPA), current 2025 version

Microsoft: EU Data Boundary for the Microsoft Cloud — official documentation

Microsoft: Customer Lockbox for Microsoft Azure — product description

Microsoft Tech Community: Azure Information Protection with HYOK (Hold Your Own Key) — functional trade-offs https://techcommunity.microsoft.com/blog/microsoft-security-blog/azure-information-protection-with-hyok-hold-your-own-key/249920

Amazon Web Services: AWS Key Management Service — External Key Store (XKS) https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html

Google Cloud: Cloud External Key Manager (Cloud EKM) and Key Access Justifications — official documentation https://cloud.google.com/kms/docs/ekm

Research literature

Latanya Sweeney: Simple Demographics Often Identify People Uniquely, Carnegie Mellon University, Data Privacy Working Paper 3 (2000); see also EFF, “What Information is ‘Personally Identifiable’?” (2009) https://www.eff.org/deeplinks/2009/09/what-information-personally-identifiable

Khaled El Emam et al.: The re-identification risk of Canadians from longitudinal demographics, BMC Medical Informatics and Decision Making 11, 46 (2011) https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3151203/

Press & analysis

JURIST: Controversy and Change — Navigating the Reauthorization of FISA’s Section 702, 21 June 2024 https://www.jurist.org/features/2024/06/21/controversy-and-change-navigating-the-reauthorization-of-fisas-section-702/

CNBC: Three things to know about FISA Section 702 — Congress passes short-term extension, 17 April 2026 https://www.cnbc.com/2026/04/17/section-702-fisa-congress-surveillance.html

CNBC: FISA Section 702 — Congress passes 45-day extension before deadline, 30 April 2026 https://www.cnbc.com/2026/04/30/fisa-section-702-congress-extension.html

Brookings Institution: A key intelligence law expires in April and the path for reauthorization is unclear, February 2026 https://www.brookings.edu/articles/a-key-intelligence-law-expires-in-april-and-the-path-for-reauthorization-is-unclear/

heise online: BSI defines when a cloud is truly sovereign, 27 April 2026 https://www.heise.de/news/BSI-definiert-wann-eine-Cloud-wirklich-souveraen-ist-11272737.html

Fortanix: AWS XKS External Key Store — barring AWS access under the CLOUD Act (industry analysis)

Securosys: Data sovereignty with AWS XKS — industry analysis

Legal notice: This article serves general information purposes and does not constitute legal advice. For a legally sound assessment in a specific case, consultation with a specialised data protection lawyer is recommended. As of: June 2026.

1. Microsoft Learn, “Data controls — Sovereign Public Cloud”, April 2026. Available at: https://learn.microsoft.com/en-us/azure/azure-sovereign-clouds/data-controls (accessed June 2026). ↩

2. Clarifying Lawful Overseas Use of Data Act, Pub. L. No. 115-141, 132 Stat. 348 (2018), codified at 18 U.S.C. § 2713. ↩

3. Microsoft, Online Services Data Protection Addendum (current version), section on government access requests and notification of customers. ↩

4. 50 U.S.C. § 1881a (FISA Amendments Act of 2008). ↩

5. RISAA, H.R. 7888 (2024); see JURIST, “Controversy and Change: Navigating the Reauthorization of FISA’s Section 702”, 21 June 2024, on the ECSP definitional expansion. Available at: https://www.jurist.org/features/2024/06/21/controversy-and-change-navigating-the-reauthorization-of-fisas-section-702/ (accessed June 2026). ↩

6. CNBC, “Three things to know about FISA Section 702: Congress passes short-term extension of controversial surveillance program”, 17 April 2026, on the 10-day extension to 30 April 2026. Available at: https://www.cnbc.com/2026/04/17/section-702-fisa-congress-surveillance.html (accessed June 2026). ↩

7. CNBC, “FISA Section 702: Congress passes short-term surveillance program extension just before deadline”, 30 April 2026, on the further 45-day extension keeping Section 702 in force through 12 June 2026. Available at: https://www.cnbc.com/2026/04/30/fisa-section-702-congress-extension.html (accessed June 2026). ↩

8. Brookings Institution, “A key intelligence law expires in April and the path for reauthorization is unclear”, February 2026. Available at: https://www.brookings.edu/articles/a-key-intelligence-law-expires-in-april-and-the-path-for-reauthorization-is-unclear/ (accessed June 2026). See also Lawfare, “FISA Section 702 Reauthorized for Two Years”, April 2024, on the historical practice of short-term extensions with continuing FISC directives. ↩

9. CJEU (Grand Chamber), Judgment of 16 July 2020, Case C-311/18 — Schrems II — paragraphs 178–185 (FISA 702) and 198–202 (proportionality question). Available at: https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:62018CJ0311 (accessed June 2026). ↩

10. European Data Protection Board, “Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data”, final version v2.0, 18 June 2021. Available at: https://www.edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf (accessed June 2026). ↩

11. Microsoft, “EU Data Boundary for the Microsoft Cloud”, official documentation. ↩

12. Microsoft Learn, “Data sovereignty — Sovereign Cloud”, section on Hosting Country Rights. Available at: https://learn.microsoft.com/en-us/industry/sovereign-cloud/concepts/data-controls (accessed June 2026). ↩

13. Regulation (EU) 2016/679 (GDPR), Article 4 No. 5. ↩

14. Microsoft Learn, “Controls and principles in Sovereign Public Cloud — External Key Storage and HYOK”, April 2026. Available at: https://learn.microsoft.com/en-us/industry/sovereign-cloud/sovereign-public-cloud/overview-controls-principles (accessed June 2026). ↩

15. Amazon Web Services, “AWS Key Management Service — External Key Store (XKS)”, official documentation. Available at: https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html (accessed June 2026). See also industry analysis at Fortanix, “AWS XKS External Key Store”, noting that XKS lets organisations “bar AWS’s access” to keys and data that could otherwise be mandated under the CLOUD Act. ↩

16. Google Cloud, “Cloud External Key Manager (Cloud EKM)” and “Key Access Justifications”, official documentation. Externally managed keys are never cached or stored within Google Cloud, and Key Access Justifications allow the customer to deny a decryption request even when prompted by a third-party authority. Available at: https://cloud.google.com/kms/docs/ekm (accessed June 2026). ↩

17. Microsoft Learn, “Control your cloud data by using Managed HSM”, April 2026, section on Microsoft’s response to legal demands. The Key Vault team states it has no operating procedures to grant such access and would challenge a legal demand to defeat customer-controlled encryption. Available at: https://learn.microsoft.com/en-us/azure/key-vault/managed-hsm/mhsm-control-data (accessed June 2026). ↩

18. Latanya Sweeney, “Simple Demographics Often Identify People Uniquely”, Carnegie Mellon University, Data Privacy Working Paper 3 (2000); see also EFF, “What Information is ‘Personally Identifiable’?”, 11 September 2009. Available at: https://www.eff.org/deeplinks/2009/09/what-information-personally-identifiable (accessed June 2026). ↩

19. Khaled El Emam et al., “The re-identification risk of Canadians from longitudinal demographics”, BMC Medical Informatics and Decision Making 11, 46 (2011). Available at: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3151203/ (accessed June 2026). ↩

20. EDPB Recommendations 01/2020, Annex 2, Use Case 2, paragraph 85 et seq., in particular the requirements for separate retention of additional information and assessment of re-identification risk according to the state of the art. ↩

21. European Data Protection Board, “Guidelines 01/2025 on Pseudonymisation”; analytical summary at European Law Blog, “The EDPB 01/2025 Guidelines on Pseudonymisation: A Step in the Right Direction?”. Available at: https://www.europeanlawblog.eu/pub/tfef074h (accessed June 2026). ↩

22. Microsoft Tech Community, “Azure Information Protection with HYOK (Hold Your Own Key)” — explanation of functional trade-offs (no search, no web viewers, no eDiscovery for HYOK-protected content). Available at: https://techcommunity.microsoft.com/blog/microsoft-security-blog/azure-information-protection-with-hyok-hold-your-own-key/249920 (accessed June 2026). ↩

23. Microsoft Learn, “Confidential computing overview”, April 2026, including the architecture of attested Trusted Execution Environments. Available at: https://learn.microsoft.com/en-us/azure/azure-sovereign-clouds/public/confidential-computing (accessed June 2026). ↩

24. Microsoft, “Customer Lockbox for Microsoft Azure”, product description. Customer Lockbox concerns Microsoft staff access in support contexts and contains no mechanisms against authority-ordered data disclosures. ↩

25. BSI, “Criteria enabling Cloud Computing Autonomy (C3A)”, v1.0, 27 April 2026, Section 1.2 (C5:2026 as prerequisite) and SOV-3 Data Sovereignty domain. Available at: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/CloudComputing/C3A_Cloud_Computing_Autonomy.pdf (accessed June 2026). ↩

26. BSI, press release “C3A: BSI publishes sovereignty criteria for cloud services”, 27 April 2026. Available at: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260427_C3A.html (accessed June 2026). ↩

27. Hessian Data Protection Commissioner (HBDI), “Report on the use of Microsoft 365”, 15 November 2025, 137 pages — in particular the acknowledgment that contractual improvements in the DPA for public bodies do not eliminate the residual risk of access by US authorities. Available at: https://datenschutz.hessen.de/sites/datenschutz.hessen.de/files/2025-11/hbdi_bericht_m365_2025_11_15.pdf (accessed June 2026). ↩

28. heise online, “BSI defines when a cloud is truly sovereign”, 27 April 2026, on the C3A’s market reception and the broader cyber-dominance framing. Available at: https://www.heise.de/news/BSI-definiert-wann-eine-Cloud-wirklich-souveraen-ist-11272737.html (accessed June 2026). ↩