KERN-THESE Pseudonymisierung ohne kundenseitige Schlüsselhoheit — also ohne die ausschließliche rechtliche und technische Kontrolle des Verantwortlichen über die Verschlüsselungsschlüssel — ist keine Risikominimierung gegenüber dem CLOUD Act und FISA Section 702. Sie ist der Anschein einer solchen. Nur eine Architektur, in der der Schlüssel niemals in die Infrastruktur des Anbieters gelangt, verwandelt ein vertragliches Versprechen (werden nicht) in eine technische Tatsache (können nicht).

Vor wenigen Tagen landete eine Akte auf meinem Schreibtisch, die die gesamte Mechanik der gegenwärtigen Cloud-Compliance-Praxis offenlegte. Eine von mir beratene Organisation, die besonders sensible personenbezogene Daten verarbeitet, hatte ein Einwilligungsersuchen von einem versicherungsmathematischen Auftragsverarbeiter erhalten. Das Unternehmen migrierte seine Verarbeitung — langjährige Pensions- und Versorgungsberechnungen — aus einer Private Cloud in die Microsoft Azure Public Cloud. In den begleitenden Unterlagen standen die drei Worte, die seit drei Jahren als eine Art Compliance-Beruhigungsmittel durch deutsche Auftragsverarbeitungsverträge zirkulieren: „Pseudonymisierung” (das Ersetzen direkter Identifikatoren wie Name oder Personalnummer durch ein neutrales Token, sodass die Daten nur über eine separat gehaltene Zuordnungstabelle einer Person zugeordnet werden können), „Verschlüsselung mit eigenen Schlüsseln” und „Datenhaltung in der EU”. Drei Worte, die alles in Ordnung erscheinen lassen. Drei Worte, von denen zwei nichts erklären, solange man die richtige Anschlussfrage nicht stellt.

Die Anschlussfrage lautet: Wo liegt der Verschlüsselungsschlüssel — der kryptografische Code, ohne den die verschlüsselten Daten nicht gelesen werden können? Und: Wer hält ihn? Diese beiden Fragen entscheiden, ob „Verschlüsselung” eine wirksame Schutzmaßnahme ist oder nur ein Wort im Vertrag.

In deutschen Auftragsverarbeitungsverträgen ist diese Frage zwischen 2020 und 2026 weitgehend unsichtbar geblieben. Sie taucht selten in Klauseln auf, selten in Transfer-Impact-Assessment-Berichten (TIA — die nach der Schrems-II-Rechtsprechung erforderliche Bewertung des Drittlandtransferrisikos), selten in Einwilligungsersuchen. Microsoft selbst liefert die Antwort, wenn man danach sucht — die technische Dokumentation ist transparent, der architektonische Raum ist gut beschrieben.¹ Aber der Vertragsmarkt zwischen Auftragsverarbeitern und Verantwortlichen stellt die Frage selten, weil ihre Beantwortung unbequeme Konsequenzen hat. „Wir verschlüsseln” ist eine Compliance-Aussage. „Der Schlüssel liegt bei uns, nicht beim Anbieter” ist eine architektonische Entscheidung. Die zweite kostet Geld und Betriebsaufwand. Die erste nicht.

Das Argument dieses Textes lässt sich in einem Satz fassen: Pseudonymisierung ohne kundenseitige Schlüsselhoheit — also ohne die ausschließliche rechtliche und technische Kontrolle des Verantwortlichen über die Schlüssel — ist keine Risikominimierung gegenüber dem CLOUD Act und FISA Section 702. Sie ist der Anschein einer solchen. Dieser Text erklärt, warum, in welchem rechtlichen und technischen Kontext, und was im AVV stehen muss, damit die Maßnahme tatsächlich greift.

Zwei Gesetze, zwei Bedrohungsprofile, ein gemeinsamer Hebel

Der CLOUD Act und FISA Section 702 werden in deutschen Compliance-Diskussionen routinemäßig in einem Atemzug genannt, als wären sie zwei Varianten desselben Risikos. Das sind sie nicht. Sie zielen auf unterschiedliche Verarbeitungssituationen, aktivieren unterschiedliche prozessuale Pfade und — was für die Verteidigung zählt — hinterlassen unterschiedliche Spuren.

Der CLOUD Act ist ein US-Bundesgesetz aus dem Jahr 2018, das US-Strafverfolgungsbehörden ermöglicht, US-ansässige Anbieter zur Herausgabe von Daten in deren „possession, custody, or control” zu verpflichten — also Daten, über die der Anbieter rechtliche oder tatsächliche Kontrolle hat — unabhängig davon, wo diese Daten physisch gespeichert sind.² Der Begriff „control” ist entscheidend: Er knüpft nicht am Speicherort an, sondern an der rechtlichen und tatsächlichen Verfügungsmacht, die der US-Anbieter über die Daten hat. Adressat ist ein einzelnes Unternehmen, das Ziel ein konkretes Strafverfahren. Der Anbieter hat formale Anfechtungsrechte; der betroffene Kunde in der Regel nicht. Microsoft hat in jüngeren Fassungen seines Datenschutz-Nachtrags (Data Protection Addendum, DPA) Verpflichtungen aufgenommen, US-Behördenanforderungen anzufechten, wo rechtlich möglich, und den Kunden zu informieren, wo US-Recht dies nicht ausdrücklich verbietet.³

FISA Section 702 folgt einer grundlegend anderen Logik. Eingeführt 2008 als Teil des FISA Amendments Act, handelt es sich um ein Auslandsaufklärungsprogramm, das die Massenerfassung von Kommunikation nicht-amerikanischer Personen außerhalb der USA durch US-Geheimdienste autorisiert.⁴ Anders als beim CLOUD Act gibt es hier keine Einzelfallanordnungen eines Strafgerichts, sondern jährliche Direktiven des Foreign Intelligence Surveillance Court (FISC) — eines für Geheimdienstverfahren eigens errichteten US-Gerichts. Diese Direktiven verpflichten Anbieter zur fortlaufenden Mitwirkung. Der Kunde wird nicht informiert; den Anbieter trifft eine strafbewehrte Geheimhaltungspflicht. Die Neugenehmigung 2024 durch den Reforming Intelligence and Securing America Act (RISAA) erweiterte zusätzlich die Definition des electronic communications service provider (ECSP) — der zur Kooperation verpflichteten Anbieter — um eine wesentlich breitere Klasse von Cloud- und Infrastrukturanbietern zu erfassen.⁵ Section 702 sollte am 20. April 2026 auslaufen; Mitte April wurde eine 10-tägige Verlängerung verabschiedet und kurz vor Fristablauf in Kraft gesetzt.⁶ Am 30. April 2026 verabschiedete der Kongress eine weitere 45-tägige Verlängerung, sodass Section 702 bis zum 12. Juni 2026 in Kraft bleibt, während die Verhandlungen über eine Neugenehmigung fortgeführt werden.⁷ Während dieser Text erscheint, läuft jene Verlängerung noch und die substanzielle Neugenehmigungsdebatte ist ungelöst. All das berührt die Substanz unserer Frage nicht: Selbst wenn der Kongress ein zeitweiliges Auslaufen zulässt, bleiben die jährlich erteilten FISC-Direktiven in Kraft, und eine Neugenehmigung ist nach allen Indikatoren wahrscheinlich.⁸

Für die architektonische Frage sticht ein Punkt heraus: Es war FISA Section 702, nicht der CLOUD Act, der die Entscheidung des EuGH gegen die Privacy-Shield-Angemessenheit in Schrems II getragen hat.⁹ Der Gerichtshof stellte fest, dass Section 702 zusammen mit der Executive Order 12333 keine den europäischen Grundrechten entsprechenden Verhältnismäßigkeitsgarantien aufweise. Die Empfehlungen 01/2020 des Europäischen Datenschutzausschusses (EDSA), als unmittelbare Antwort auf Schrems II erarbeitet, sind in ihrer Use-Case-Logik exakt auf dieses Bedrohungsszenario kalibriert.¹⁰

Beide Gesetze teilen — und das ist der Punkt — denselben technischen Hebel: Sie greifen das ab, was der Anbieter herausgeben oder durchreichen kann. Was der Anbieter weder herausgeben noch entschlüsseln kann, weil es ihm technisch nicht zur Verfügung steht, ist beiden Programmen entzogen. Daraus folgt: Die wirksame Verteidigung ist nicht juristisch, sondern architektonisch.

Geografie ist keine Verteidigung

Die häufigste deutsche Antwort auf dieses Bedrohungsszenario lautet seit Jahren: „Datenhaltung in der EU”. Das Argument geht so: Wenn die Daten in einem deutschen Rechenzentrum liegen, gilt deutsches Recht und US-Behörden haben keinen Zugriff. Diese Antwort ist rechtlich ungenau und technisch unvollständig.

Sie ist rechtlich ungenau, weil weder der CLOUD Act noch FISA Section 702 den Speicherort, sondern die Rechtspersönlichkeit des Anbieters zum Anknüpfungspunkt nehmen. Die Microsoft Corporation ist eine US-amerikanische juristische Person mit Sitz in Redmond, Washington. Die Microsoft Ireland Operations Limited, die Microsoft Deutschland GmbH und alle anderen Tochtergesellschaften unterliegen über die Konzernstruktur mittelbar US-Recht: Was die Muttergesellschaft rechtlich anweisen kann, fällt unter den „control”-Test des CLOUD Act. Das Programm „EU Data Boundary” von Microsoft — eine vertragliche Zusage, dass bestimmte Kundendaten innerhalb des EWR verarbeitet werden — hat diese Realität nie adressiert; es betrifft den Ort der Verarbeitung, nicht die rechtliche Jurisdiktion.¹¹ Microsoft selbst hat dies in eigenen Veröffentlichungen klar formuliert: Die Rechte des gastgebenden Landes seien „limited in the context of accessing that data”.¹² Diese Einschränkung gilt für nationale Behörden des gastgebenden Landes — nicht für US-Behörden, die Microsoft als US-Konzern adressieren.

Hier hört der Fall auf, ausschließlich von Microsoft zu handeln. Amazon Web Services (Amazon.com, Inc., Seattle) und Google Cloud (Google LLC, Mountain View) sind US-Konzerne auf exakt derselben Grundlage. Die AWS European Sovereign Cloud und Googles EU-Regionen verlagern die Daten; sie verlagern die Konzernmutter nicht aus der US-Jurisdiktion. Der verbreitete Reflex, „eine europäische Region eines US-Hyperscalers” zu wählen, adressiert die Geografie und lässt die Jurisdiktionsfrage unberührt. Welcher der drei Anbieter auch gewählt wird — CLOUD Act und FISA 702 greifen auf gleichem Weg, und, wie der nächste Abschnitt zeigt, ebenso die einzige wirksame Verteidigung.

Sie ist technisch unvollständig, weil EU-Speicherung allenfalls die primären Kundendaten erfasst. Abgeleitete Daten — Logs, Telemetrie (kontinuierliche Betriebs- und Nutzungsmessdaten), Diagnostikausgaben, Betriebsmetadaten — fließen in zentralisierte Observability-Plattformen, die je nach Konfiguration nicht im EU-Perimeter liegen. Diese Datenkategorie kann personenbezogene Inhalte enthalten und ist im Anschreiben unseres Falls — wie in den meisten vergleichbaren Fällen — nicht erwähnt.

Geografie ist also keine Verteidigungsmauer. Sie ist ein Etikett. Worauf es ankommt, ist die kryptografische Eigentumsposition — das heißt: Wer hält den Schlüssel, mit dem die Daten lesbar gemacht werden können?

Pseudonymisierung in drei Konfigurationen

Die DSGVO definiert Pseudonymisierung in Art. 4 Nr. 5 als Verarbeitung personenbezogener Daten in einer Weise, in der die personenbezogenen Daten ohne Hinzuziehung „zusätzlicher Informationen” nicht mehr einer spezifischen betroffenen Person zugeordnet werden können.¹³ Der rechtlich entscheidende Begriff ist nicht „Pseudonymisierung”, sondern „zusätzliche Informationen”. Diese zusätzlichen Informationen — die Zuordnungstabelle, das Schlüsselmaterial, die Re-Identifikationslogik — existieren stets. Die Daten wären erst dann anonymisiert, wenn sie endgültig gelöscht wären. Solange sie existieren, lautet die rechtlich relevante Frage: Wer hat Zugriff auf diese zusätzlichen Informationen?

In Cloud-Architekturen lassen sich drei Konfigurationen unterscheiden, die in deutschen AVVs sämtlich unter derselben Formulierung — „Pseudonymisierung mit Verschlüsselung” — gebündelt werden, obwohl sie grundsätzlich unterschiedliche Schutzniveaus repräsentieren. Die Unterscheidung ist nicht anbieterspezifisch. Jeder der drei großen Hyperscaler bietet dieselbe Optionsleiter unter unterschiedlichen Produktnamen an; der entscheidende Unterschied ist stets derselbe: Wo, physisch und logisch, liegt der Schlüssel?

Schlüsselort	Microsoft Azure	Amazon Web Services	Google Cloud
Anbieter hält den Schlüssel (Anbieter- Infrastruktur)	Customer-Managed Keys (CMK) im Azure Key Vault	Customer Managed Keys in AWS KMS	Customer-Managed Encryption Keys (CMEK) in Cloud KMS
Kunde erzeugt Schlüssel, Anbieter hält ihn	BYOK-Import in Azure Key Vault	Importiertes Schlüsselmaterial in KMS	Importiertes Schlüsselmaterial in Cloud KMS
Schlüssel vollständig außerhalb des Anbieters (externes HSM)	Hold Your Own Key (HYOK) / Managed HSM External Key Storage	Key Store (XKS) via externes HSM	Cloud External Key Manager (EKM) + Key Access Justifications

Für die Konkretheit läuft der vorliegende Fall auf Microsoft Azure, sodass die drei Konfigurationen nachfolgend in Azure-Begriffen beschrieben werden; die AWS- und Google-Äquivalente verhalten sich gegenüber CLOUD Act und FISA 702 identisch.

Konfiguration A — Customer-Managed Keys (CMK), anbieter-gehalten. Der Kunde verwaltet die Verschlüsselungsschlüssel formal, doch liegen sie im Azure Key Vault, also innerhalb der Microsoft-Infrastruktur (die AWS-KMS- und Google-Cloud-KMS-Äquivalente liegen genauso). Microsoft hat keinen routinemäßigen Klartext-Zugriff, kann jedoch auf rechtlich zwingende Anordnung — sei es CLOUD Act oder FISA-Direktive — sowohl die verschlüsselten Daten als auch das Mittel zu ihrer Entschlüsselung bereitstellen. Die vertragliche Selbstverpflichtung des Anbieters ist aufschlussreich, aber begrenzt: Sie ist ein Versprechen, die eigene kundenseitig kontrollierte Verschlüsselung nicht zu umgehen, und eine Verpflichtung, jeder rechtlichen Forderung dazu zu widersprechen — eine vertragliche Haltung und eine prozessuale Position, keine Aussage über technische Unmöglichkeit (Microsofts genauer Wortlaut, und was er implizit einräumt, wird im nächsten Abschnitt untersucht). Das gilt unabhängig davon, ob zusätzlich pseudonymisiert wird, wo die Pseudonymisierungstabelle gehalten wird oder ob sie über Microsoft-Schlüssel gesichert ist. Die Schutzwirkung gegenüber CLOUD Act und FISA 702 ist in dieser Konfiguration überwiegend vertraglich und nicht architektonisch — und hält einer rechtlich vollstreckbaren Herausgabeanordnung möglicherweise nicht stand, sobald die Anfechtung des Anbieters erschöpft ist.

Konfiguration B — Bring Your Own Key (BYOK). Der Kunde erzeugt den Schlüssel innerhalb seiner eigenen Infrastruktur und importiert ihn in den Schlüssel-Vault des Anbieters. Die operative Verfügbarkeit liegt nun innerhalb eines Anbieter-Systems, während der Erzeugungspfad kundenseitig ist. In der praktischen rechtlichen Bewertung unterscheidet sich BYOK kaum von CMK: Sobald der Schlüssel im Vault des Anbieters sitzt, ist er im Sinne des „control”-Tests des CLOUD Act für den Anbieter zugänglich. Die Schutzwirkung ist marginal höher als unter CMK, aber konzeptionell unzureichend.

Konfiguration C — Schlüssel vollständig außerhalb des Anbieters** **(HYOK / XKS / Cloud EKM). Der Schlüssel liegt ausschließlich in einem kundenbetriebenen Hardware Security Module (HSM — ein spezialisiertes Hardware-Bauteil, in dem kryptografische Schlüssel manipulationsfest erzeugt und gespeichert werden), physisch und logisch außerhalb der Anbieter-Infrastruktur. Verschlüsselungs- und Entschlüsselungsoperationen laufen über Aufrufe gegen das externe HSM des Kunden; der Anbieter erhält den Schlüssel nie. Microsoft beschreibt seine Variante als eine, in der „you always retain full control over your keys”;¹⁴ AWS positioniert External Key Store als Möglichkeit für Kunden, „bar AWS’s access” auf Schlüssel und Daten zu erreichen, die andernfalls unter dem CLOUD Act angefordert werden könnten;¹⁵ Google ergänzt Key Access Justifications, mit denen der Kunde eine Entschlüsselungsanforderung programmatisch ablehnen kann, selbst wenn sie von einer Drittbehörde ausgeht.¹⁶ Bei einer CLOUD-Act-Anordnung könnte der Anbieter pseudonymisierte und verschlüsselte Daten herausgeben — aber sie weder entschlüsseln noch die Pseudonymisierungstabelle des Kunden erreichen. Bei einer FISA-Direktive könnte der Anbieter denselben verschlüsselten Strom durchreichen, ohne dass die Geheimdienstbehörde Klartext erhält. Die Schutzwirkung ist substanziell — und über alle drei Anbieter identisch.

Die These dieses Textes ergibt sich aus dieser Aufzählung: Die Konfigurationen A und B reduzieren nicht das Risiko, sie reduzieren den Eindruck des Risikos. Nur Konfiguration C macht aus der Pseudonymisierung, was sie sein soll — eine Maßnahme, die den Anbieter aus der Position des Zwischenstücks entfernt.

„Der Schlüssel ist auf unserer Seite” — ein Satz, der nichts klärt

Der Fall, mit dem dieser Text einsetzt, macht den Punkt konkret. Auf die Frage, wo die Verschlüsselungsschlüssel gehalten werden, antwortete der Auftragsverarbeiter, die Verschlüsselung erfolge mit kundenseitig verwalteten Schlüsseln, die von der eigenen IT-Abteilung erzeugt und verwaltet würden, und der Schlüssel „liege in der Hand des Verantwortlichen”. Im schnellen Lesen ist das beruhigend. Im genauen Lesen beantwortet es eine andere Frage als die, auf die es ankommt.

„Von unserer IT erzeugt und verwaltet” beschreibt, wer den Lebenszyklus des Schlüssels administriert. Es sagt nicht, wo der Schlüssel physisch liegt. Im Standardmodell der kundenseitig verwalteten Schlüssel lautet die Antwort: innerhalb des Schlüssel-Vaults des Anbieters — bei Azure der Azure Key Vault; bei AWS der AWS KMS; bei Google Cloud der Cloud KMS. Der Kunde kontrolliert Richtlinie und Rotation, das Schlüsselmaterial liegt jedoch innerhalb der Anbieter-Infrastruktur, und jede Entschlüsselungsoperation läuft dort (Abbildung 1).

Das ist kein verstecktes Detail; der Anbieter formuliert seine Position offen. Microsoft verpflichtet sich, die eigenen kundenseitig kontrollierten Verschlüsselungs-Funktionen nicht zu umgehen, und erklärt, dass es einer entsprechenden rechtlichen Forderung „would challenge such a demand on any lawful basis” entgegenhalten würde.¹⁷ Gelesen, wie ein Sicherheitsingenieur das liest, ist dieser Satz eher ein Eingeständnis als eine Beruhigung. Ein Anbieter, der verspricht, seine eigene Verschlüsselung nicht zu umgehen — und der sich verpflichtet, eine entsprechende rechtliche Anordnung anzufechten —, sagt damit in klaren Worten, dass die Umgehung technisch in seiner Reichweite liegt. Werden nicht ist eine Richtlinie. Würden anfechten ist eine Prozessposition. Keines davon ist können nicht. Erst eine Architektur, in der der Schlüssel niemals in die Infrastruktur des Anbieters gelangt, verwandelt werden nicht in können nicht — und das ist HYOK bei Azure, XKS bei AWS, Cloud EKM bei Google (Abbildung 2).

Wenn ein Auftragsverarbeiter also schreibt, „der Schlüssel liege auf der Seite des Kunden”, lautet die Aufgabe des Verantwortlichen, diesen Satz in die eine Frage zu übersetzen, die die Sache entscheidet: Wird der Schlüssel vom Kunden verwaltet, aber im Vault des Anbieters gespeichert — oder liegt er in einem kundenbetriebenen HSM, das der Anbieter nicht erreichen kann? Das Erste ist ein vertragliches Versprechen. Das Zweite ist eine technische Tatsache. Diese Unterscheidung ist der gesamte Unterschied zwischen einer Schranke, die eine gerichtliche Anordnung durchdringen kann, und einer, die sie nicht durchdringen kann (Abbildung 3).

Es lohnt sich, festzuhalten, warum das zählt, denn der Zweck geht hinter der Mechanik leicht verloren. Ein kundenseitig verwalteter Schlüssel und eine Pseudonymisierung sind keine Selbstzwecke. In einem Cloud-Auftragsverarbeitungsvertrag bestehen sie aus genau einem Grund: um das Übermittlungsrisiko zu neutralisieren, das der CLOUD Act und FISA 702 erzeugen — dasselbe Risiko, dessen Beherrschung ein Verantwortlicher bei einer Übermittlung personenbezogener Daten an einen US-Anbieter nach Schrems II und Artt. 44 ff. DSGVO rechtlich nachweisen muss. Sie sind ergänzende Maßnahmen im Sinne der EDSA-Empfehlungen, und sie verdienen diesen Status nur, wenn sie den Zugriff durch US-Behörden wirksam ausschließen. Das ist der Prüfstein, den sie bestehen müssen. Die Frage hinter „Reicht ein kundenseitig verwalteter Schlüssel?” und „Reicht Pseudonymisierung?” ist in Wahrheit eine einzige Frage: Erreichen diese Maßnahmen noch den Zweck, für den sie eingesetzt wurden? Die Antwort folgt unmittelbar aus allem Vorangegangenen. Wenn der Anbieter den Schlüssel hält und zur Entschlüsselung gezwungen werden kann — oder die Mittel zur Re-Identifizierung pseudonymisierter Daten besitzt —, dann erreichen CLOUD Act und FISA 702 lesbare personenbezogene Daten genauso, als gäbe es überhaupt keine Maßnahme. Das Risiko, das die Maßnahme beseitigen sollte, ist nach wie vor vorhanden. Die Kontrolle existiert auf dem Papier; der Schutz existiert nicht. Und eine Drittland-Übermittlung, die nur auf dem Papier geschützt ist, ist keine compliance-konforme Übermittlung — es ist ein offener Befund, der auf die nächste Prüfung wartet. Verschlüsselung und Pseudonymisierung wurden eingesetzt, um diesen beiden Gesetzen zu entgehen; wenn der Anbieter den Schlüssel weiterhin herausgeben kann, hat dieses Entgehen nicht stattgefunden.

Versicherungsmathematik als Stresstest

An dieser Stelle wird der versicherungsmathematische Anwendungsfall lehrreich, weil er die Grenzen der Pseudonymisierung selbst in Konfiguration C zeigt. Versicherungsmathematische Arbeit ist auf den ersten Blick ein Bereich, in dem Pseudonymisierung leicht sein müsste — Namen, Sozialversicherungsnummern und Personalnummern lassen sich ohne weiteres durch Pseudonyme ersetzen, ohne die Berechnung zu beeinträchtigen. Auf den zweiten Blick wird es komplizierter. Versicherungsmathematische Arbeit läuft auf einer reichen Menge von Quasi-Identifikatoren — Datenfelder, die für sich allein nicht identifizieren, in Kombination jedoch eine eindeutige Zuordnung ermöglichen: Geburtsdatum, Geschlecht, Eintrittsdatum, Familienstand, Anzahl unterhaltsberechtigter Kinder, Gehaltsband, Versorgungsklasse.

In ihrer Arbeit aus dem Jahr 2000 zeigte Latanya Sweeney, dass die Kombination aus Postleitzahl, Geburtsdatum und Geschlecht ausreicht, um etwa 87 Prozent der US-Bevölkerung eindeutig zu identifizieren.¹⁸ El Emam und Kollegen fanden 2011 für Montreal eine sogar noch dramatischere Zahl: Mit vollständiger Postleitzahl, Geburtsdatum und Geschlecht waren 98 Prozent der Bevölkerung eindeutig.¹⁹ Diese Zahlen steigen, wenn longitudinale Daten — also wiederholte Beobachtungen derselben Person über die Zeit — vorliegen. Versicherungsmathematische Arbeit liefert genau solche longitudinalen Reihen: Eine Pensionsberechnung wird über Jahrzehnte fortgeschrieben.

Für die Bedrohungsmodellierung gegen FISA Section 702 ist dies besonders relevant. FISA 702 ist keine Einzelfallanordnung, sondern ein Programm. Ein über fünf Jahre kontinuierlich abgegriffener Datenstrom kann aggregiert, korreliert und mit externen Datensätzen verknüpft werden — Wählerverzeichnisse, öffentliche Register, kommerzielle Data-Broker-Feeds. Selbst pseudonymisierte Datensätze mit reichen Quasi-Identifikatoren werden in diesem Bedrohungsszenario re-identifizierbar.

Die Schlussfolgerung lautet nicht, Pseudonymisierung aufzugeben. Die Schlussfolgerung lautet, die Maßnahme zu vervollständigen: kundenseitige Schlüsselhoheit als Fundament, Pseudonymisierung an der Quelle (mit einer ausschließlich beim Verantwortlichen, nicht beim Auftragsverarbeiter liegenden Zuordnungstabelle), und — soweit möglich — Generalisierung der Quasi-Identifikatoren, also das Ersetzen genauer Werte durch Bänder: Altersbänder statt Geburtsdaten, Gehaltsbänder statt Beträge, Dienstzeitklassen statt exakter Eintrittsdaten. Diese Schichtung ist die einzige, die der langlaufenden Korrelationslogik von FISA 702 standhält.

Was die EDSA-Empfehlungen 01/2020 tatsächlich sagen

In der Praxis wird Use Case 2 der EDSA-Empfehlungen 01/2020 — der Anwendungsfall Pseudonymisierung — meist verkürzt wiedergegeben: „Wenn pseudonymisiert wird, ist die Übermittlung zulässig.” Das ist nicht, was das Dokument sagt.

Use Case 2 verlangt ausdrücklich, dass die zur Re-Identifizierung befähigenden zusätzlichen Informationen ausschließlich beim Datenexporteur gehalten werden und gesondert in einem Mitgliedstaat oder in einem Drittland mit angemessenem Schutzniveau aufbewahrt werden.²⁰ Der Datenimporteur — also der Cloud-Anbieter im Drittland — darf weder über die zusätzlichen Informationen verfügen noch über Mittel, die eine Re-Identifizierung mit zumutbarem Aufwand ermöglichen. Der EDSA verlangt weiter, dass die Pseudonymisierung selbst nach aktuellem Stand der Technik so gestaltet wird, dass eine Re-Identifizierung — auch unter Hinzuziehung externer Daten — „very unlikely” ist.

In seinen Pseudonymisierungs-Leitlinien 2025 hat der EDSA diese Position bestätigt und über das Konzept der Pseudonymisierungs-Domäne erweitert: also den Verarbeitungsraum, in dem die zusätzlichen Informationen verfügbar sind und in dem eine Re-Identifizierung im Prinzip möglich wäre.²¹ In unsere architektonische Frage übersetzt: Wenn der Zuordnungsschlüssel beim Anbieter liegt, ist die Pseudonymisierungs-Domäne identisch mit der Anbieter-Domäne. Erst wenn der Schlüssel — und damit die Pseudonymisierungs-Domäne — beim Verantwortlichen bleibt, bleibt die Schutzwirkung gegenüber einem Drittland-Anbieter intakt.

Dies ist die rechtliche Grundlage für die These, dass kundenseitige Schlüsselhoheit keine technische Option, sondern eine Voraussetzung für eine wirksame Pseudonymisierung angesichts der CLOUD-Act- und FISA-702-Risiken ist. Wer den Schlüssel beim Anbieter belässt, erfüllt nicht die EDSA-Anforderung unter Use Case 2 — gleichgültig, wie sorgfältig die Pseudonymisierung selbst implementiert ist.

Die vollständige Schutzarchitektur

Was muss also in einer Microsoft-Azure-Architektur tatsächlich vorhanden sein, damit ein deutscher Verantwortlicher seine Sorgfaltspflicht erfüllt? Drei Schichten, in der folgenden Reihenfolge.

Schicht 1: Kundenseitige Schlüsselhoheit. HYOK über externes HSM ist die robusteste Variante; sie führt allerdings zu funktionalen Einschränkungen, weil bestimmte Microsoft-Funktionen — etwa serverseitige Suche, eDiscovery oder Web-Vorschau — Klartext-Zugriff voraussetzen, der unter HYOK ausgeschlossen ist.²² Eine Zwischenlösung ist Azure Key Vault Managed HSM External Key Storage, bei der der Schlüssel in einer kundenkontrollierten HSM-Umgebung außerhalb der Microsoft-Räumlichkeiten liegt — in der Microsoft-eigenen Dokumentation ausdrücklich als eine Form von HYOK eingeordnet. Wer mehr Dienst-Funktionalität benötigt, kann Azure Key Vault Managed HSM mit Customer-Managed Keys verwenden, muss aber akzeptieren, dass die Schutzwirkung gegenüber CLOUD Act und FISA 702 erheblich reduziert ist. Dieselbe Logik gilt bei den beiden anderen Hyperscalern: AWS External Key Store (XKS) und Google Cloud External Key Manager (Cloud EKM) platzieren den Schlüssel in einem kundenbetriebenen HSM außerhalb des Anbieters, mit derselben „Kill-Switch”-Eigenschaft — trennt man den externen Schlüsselmanager ab, hören alle kryptografischen Operationen auf, und der Anbieter kann nur noch Chiffretext herausgeben. Die Produktnamen unterscheiden sich; der architektonische Prüfstein nicht.

Schicht 2: Pseudonymisierung an der Quelle. Die Pseudonymisierung muss stattfinden, bevor die Daten die Perimeter des Verantwortlichen verlassen. Die Zuordnungstabelle bleibt beim Verantwortlichen — physisch, organisatorisch, kryptografisch. Microsoft erhält nur pseudonymisierte und verschlüsselte Daten. Die Umsetzung kann über kundenseitige Preprozessoren, Edge-Komponenten oder dedizierte Pseudonymisierungs-Gateways erfolgen. Der entscheidende Prüfstein ist nicht der Implementierungspfad, sondern wo die Zuordnungstabelle liegt.

Schicht 3: Confidential Computing und ergänzende operative Schichten. Azure Confidential Computing verwendet Trusted Execution Environments (TEE) — hardware-isolierte Speicherbereiche, abgeschirmt vom übrigen Betriebssystem, in denen Daten auch während der Verarbeitung verschlüsselt bleiben.²³ Diese Schicht adressiert ein Restrisiko, das HYOK allein nicht ausräumt: Klartext-Exposition während der In-Memory-Verarbeitung, in jedem Szenario, in dem der Anbieter dazu gezwungen werden könnte, Operationen auf Kundendaten in seiner eigenen Infrastruktur durchzuführen. Customer Lockbox — Microsofts vertragliche Zusicherung, dass Microsoft-Personal in einem Support-Szenario nur mit ausdrücklicher Genehmigung des Kunden auf Kundendaten zugreifen darf — adressiert Microsoft-Personal-Zugriff im Support, nicht Anforderungen von Justiz- oder Sicherheitsbehörden. Es findet daher auf CLOUD-Act- oder FISA-702-Szenarien keinerlei Anwendung: Diese operieren über völlig getrennte Zwangsmechanismen, auf die Lockbox keinen Zugriff hat.²⁴ Die EU Data Boundary kontrolliert, wie oben ausgeführt, allein den Ort der Verarbeitung und ist kein Schutz gegen US-Behördenzugriff.

Zusammen bilden diese Schichten eine Verteidigungslinie, die sich in einem Satz zusammenfassen lässt: Microsoft kann auf Anordnung verschlüsselte Bytes herausgeben — und nichts weiter. Was hinter diesen Bytes liegt, kann ohne den kundenseitig gehaltenen Schlüssel nicht entschlüsselt werden, ohne die kundenseitig gehaltene Zuordnungstabelle nicht re-identifiziert werden und ohne Klartext-Verarbeitungs-Zugriff nicht abgegriffen werden. Das ist nicht die Abschaffung des CLOUD Act und von FISA 702. Es ist ihre technische* *Neutralisierung — der rechtliche Anspruch besteht weiter, aber seine Durchsetzung läuft ins Leere.

Was im AVV stehen muss

Aus dieser architektonischen Logik folgt eine pragmatische Checkliste für jeden, der einen AVV mit einem Cloud-Auftragsverarbeiter schließt. Vier Fragen genügen, um innerhalb von zehn Minuten zu beurteilen, ob der behauptete Schutz hält.

Erstens: Wo liegt der Verschlüsselungsschlüssel? Die Antwort muss konkret sein — Customer-Managed Keys (Schlüssel beim Anbieter), Bring-Your-Own-Key (Schlüssel kundenseitig erzeugt, aber im Vault des Anbieters) oder das Externe-Schlüssel-Modell (Schlüssel in einem kundenbetriebenen HSM: HYOK bei Azure, XKS bei AWS, Cloud EKM bei Google). Lautet die Antwort „beim Anbieter” oder „in der Cloud”, endet das Gespräch dort.

Zweitens: Wo liegt die Pseudonymisierungstabelle? Liegt die Tabelle beim Auftragsverarbeiter oder beim Cloud-Anbieter, ist die Pseudonymisierung gegenüber CLOUD-Act- oder FISA-702-Risiko keine wirksame Schutzmaßnahme. Es ist eine interne Datenminimierungs-Maßnahme — sinnvoll, aber unzureichend.

Drittens: Welche Quasi-Identifikatoren bleiben im pseudonymisierten** **Datensatz erhalten und sind Generalisierungen angewandt worden? Die Antwort sollte die Sweeney-Referenz und zumindest grundlegende k-Anonymitäts-Erwägungen widerspiegeln — k-Anonymität ist das mathematische Maß dafür, wie viele Personen mit identischer Quasi-Identifikator-Kombination im Datensatz vorhanden sein müssen, damit Einzelne nicht herausgesucht werden können. Lautet die Antwort „wir pseudonymisieren nur die Namen”, ist die Maßnahme gegenüber einem Akteur, der zu Aggregation und Korrelation fähig ist, wirkungslos.

Viertens: Adressiert das Transfer Impact Assessment diese Architektur** **— oder begnügt es sich mit der Aussage, dass pseudonymisiert wird? Ein TIA, das kryptografische Schlüsselhoheit, Pseudonymisierungs-Domäne und Generalisierung der Quasi-Identifikatoren explizit bewertet, ist verteidigungsfähig. Ein TIA, das auf das EU-US Data Privacy Framework und „Datenhaltung in der EU” verweist, ohne die architektonische Frage zu stellen, ist es nicht.

Wird auch nur eine dieser Fragen mit „Microsoft” oder mit Vagheit beantwortet, liefert der AVV möglicherweise formale Compliance-Indikatoren, ohne das zugrunde liegende Offenlegungsrisiko materiell zu reduzieren.

C3A: Vom CISO-Standpunkt zur Aufsichtserwartung

Bis April 2026 war die in diesem Text vertretene Position das Argument einer Minderheit von Datenschutz-Architekten und CISOs, die in ihrer Praxis erfahren hatten, was technische Wirklichkeit von vertraglicher Poesie trennt. Mit der Veröffentlichung von C3A — Criteria enabling* *Cloud Computing Autonomy — durch das Bundesamt für Sicherheit in der Informationstechnik (BSI) am 27. April 2026 ist dieses Argument zu einer bundesbehördlichen Erwartung geworden.

Das C3A setzt voraus, dass der Cloud-Anbieter die Kriterien des C5-Katalogs (Cloud Computing Compliance Criteria Catalogue, der etablierte Cloud-Sicherheitsstandard des BSI) erfüllt; es operationalisiert die Frage der Souveränität auf einer zweiten Schicht über dieser Sicherheitsbasislinie.²⁵ Unter den sechs Souveränitätsdomänen ist die Domäne SOV-3 Datenhoheit unmittelbar einschlägig: Sie definiert kundenkontrolliertes externes Schlüsselmanagement als auditfähiges Souveränitätskriterium — ohne eine bestimmte technische Umsetzung vorzuschreiben. Die Domäne SOV-4 Operative Souveränität geht weiter und kodifiziert, was das BSI in seiner begleitenden Pressemitteilung vom 27. April 2026 als Cyber-Dominanz bezeichnet — die anhaltende Fähigkeit eines Anbieters, Zugriff auf Systeme und Daten seiner Kunden zu behalten.²⁶ Der Hessische Beauftragte für Datenschutz und Informationsfreiheit (HBDI) war in seiner Microsoft-365-Analyse vom November 2025 bereits zu einer analogen Schlussfolgerung gelangt: Selbst mit den vertraglichen Verbesserungen, die Microsoft im AVV für öffentliche Stellen eingeführt hat, ist das Restrisiko eines Zugriffs durch US-Behörden nicht beseitigt.²⁷ Die Position des BSI ist unmissverständlich: nicht-europäische Produkte dürfen weiterhin verwendet werden, jedoch nur unter Bedingungen, die eine selbstbestimmte Nutzung ermöglichen.

Das verändert den Charakter der Diskussion um Pseudonymisierung und Schlüsselhoheit. Was 2025 noch als Best Practice einzelner Akteure diskutiert wurde, ist 2026 zu einer auditfähigen Erwartung des nationalen IT-Sicherheitsregulators geworden.²⁸ Für souveräne Beschaffungsentscheidungen — und durch deren Schwerkraftwirkung für den breiteren regulierten Markt in Deutschland — wird der Maßstab für die Cloud-Bewertung in den kommenden Jahren nicht mehr „Datenhaltung in der EU” sein, sondern „kundenseitige Schlüsselhoheit, kundenseitige Pseudonymisierungs-Domäne, auditfähige Trennfähigkeit”. Wer diese Maßstäbe nicht in seinem AVV abbildet, wird sie spätestens bei der nächsten Aufsichtsprüfung abbilden müssen.

Drei Sätze zum Mitnehmen

ZUSAMMENFASSUNG FÜR ENTSCHEIDER Pseudonymisierung ist eine bedingte Maßnahme. Die Bedingung lautet: kundenseitige Schlüsselhoheit (HYOK / XKS / Cloud EKM), kombiniert mit einer kundenseitig gehaltenen Pseudonymisierungs-Domäne und einer Generalisierung der Quasi-Identifikatoren. Wem diese Schichtung fehlt, der hat keine Pseudonymisierung — er hat ein Etikett. Wer den Schlüssel beim Anbieter belässt, hat eine begrenzte Risikominimierung gegenüber dem CLOUD Act und FISA Section 702 — was bleibt, ist der Anschein von Compliance, nicht ein technisch durchsetzbares Schutzmodell. Die beiden Gesetze lassen sich nicht abschaffen, aber sie lassen sich technisch neutralisieren — wenn die Architektur stimmt.

Pseudonymisierung ist eine bedingte Maßnahme. Die Bedingung lautet: kundenseitige Schlüsselhoheit, kombiniert mit einer kundenseitig gehaltenen Pseudonymisierungs-Domäne und einer Generalisierung der Quasi-Identifikatoren. Wem diese Schichtung fehlt, der hat keine Pseudonymisierung — er hat ein Etikett.

Wer den Schlüssel beim Anbieter belässt, hat eine begrenzte Risikominimierung gegenüber dem CLOUD Act und FISA Section 702 — was bleibt, ist der Anschein von Compliance, nicht ein technisch durchsetzbares Schutzmodell. Diese Aussage ist nicht polemisch; sie ist die unmittelbare Konsequenz aus Art. 4 Nr. 5 DSGVO, EDSA Use Case 2 und Microsofts eigener Architektur-Dokumentation.

Der CLOUD Act und FISA 702 lassen sich nicht abschaffen. Aber sie lassen sich technisch neutralisieren — wenn die Architektur stimmt. Genau das ist die Aufgabe der nächsten zwei Jahre: AVVs, die die richtigen Worte enthalten, in AVVs zu überführen, die die richtigen Architekturen abbilden.

Glossar der Abkürzungen

Begriff	Definition
AVV	Auftragsverarbeitungsvertrag (engl. Data Processing Agreement, DPA)
BYOK	Bring Your Own Key — kundenseitig erzeugter Schlüssel, in den Vault des Anbieters importiert
C3A	Criteria enabling Cloud Computing Autonomy — BSI-Souveränitätsrahmen, April 2026
C5	Cloud Computing Compliance Criteria Catalogue — etablierter BSI-Cloud-Sicherheitsstandard
CLOUD Act	Clarifying Lawful Overseas Use of Data Act — US-Bundesgesetz von 2018
CMK	Customer-Managed Key — Kunde kontrolliert die Richtlinie, Schlüssel im Vault des Anbieters
CMEK	Customer-Managed Encryption Keys — Google-Cloud-Äquivalent zu CMK
DEK	Data Encryption Key — symmetrischer Schlüssel, der die eigentlichen Daten verschlüsselt
DSGVO	Datenschutz-Grundverordnung (Verordnung (EU) 2016/679)
ECSP	Electronic Communications Service Provider — unter FISA 702 zur Mitwirkung verpflichtete Anbieter
EDSA	Europäischer Datenschutzausschuss (engl. EDPB)
EKM	(Cloud) External Key Manager — Google-Cloud-Modell für externe HSMs
FISA 702	Foreign Intelligence Surveillance Act, Section 702 — US-Auslandsaufklärungsprogramm
FISC	Foreign Intelligence Surveillance Court — US-Gericht für Geheimdienstverfahren
HBDI	Hessischer Beauftragter für Datenschutz und Informationsfreiheit
HSM	Hardware Security Module — manipulationsfeste Hardware zur Schlüsselspeicherung
HYOK	Hold Your Own Key — Schlüssel gelangt niemals in die Anbieter-Infrastruktur
KMS	Key Management Service — AWS-Vault-Produkt
RISAA	Reforming Intelligence and Securing America Act (2024)
SOV-3 / SOV-4	C3A-Souveränitätsdomänen — Datenhoheit (SOV-3), Operative Souveränität (SOV-4)
TEE	Trusted Execution Environment — hardware-isolierter, verschlüsselter Speicherbereich
TIA	Transfer Impact Assessment — Bewertung des Drittlandtransferrisikos nach Schrems II
XKS	External Key Store — AWS-Modell für externes HSM

Bibliografie

Gesetze & Rechtsprechung

CLOUD Act: Clarifying Lawful Overseas Use of Data Act, Pub. L. No. 115-141, 132 Stat. 348 (2018), kodifiziert als 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, eingeführt durch den FISA Amendments Act of 2008, Pub. L. No. 110-261, kodifiziert als 50 U.S.C. § 1881a

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

EuGH Schrems II: Urteil v. 16. Juli 2020, Rs. C-311/18, Rn. 178–185 und 198–202 https://eur-lex.europa.eu/legal-content/de/TXT/?uri=CELEX:62018CJ0311

DSGVO Art. 4 Nr. 5: Verordnung (EU) 2016/679, Definition der Pseudonymisierung

EU-Aufsichtsleitlinien

EDSA: Empfehlungen 01/2020 zu Maßnahmen, die die Übermittlungs-Tools ergänzen, um die Einhaltung des EU-Datenschutzniveaus zu gewährleisten, Endfassung v2.0, 18. Juni 2021 https://www.edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf

EDSA: Guidelines 01/2025 on Pseudonymisation — analytische Zusammenfassung im 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: Pressemitteilung — C3A: BSI veröffentlicht Souveränitätskriterien für Cloud-Dienste, 27. April 2026 https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260427_C3A.html

HBDI: Bericht zur Nutzung von Microsoft 365, 15. November 2025, 137 Seiten https://datenschutz.hessen.de/sites/datenschutz.hessen.de/files/2025-11/hbdi_bericht_m365_2025_11_15.pdf

Anbieter-Dokumentation

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), aktuelle Fassung 2025

Microsoft: EU Data Boundary for the Microsoft Cloud — offizielle Dokumentation

Microsoft: Customer Lockbox for Microsoft Azure — Produktbeschreibung

Microsoft Tech Community: Azure Information Protection with HYOK (Hold Your Own Key) — funktionale 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) und Key Access Justifications — offizielle Dokumentation https://cloud.google.com/kms/docs/ekm

Forschungsliteratur

Latanya Sweeney: Simple Demographics Often Identify People Uniquely, Carnegie Mellon University, Data Privacy Working Paper 3 (2000); siehe auch 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/

Presse & Analyse

JURIST: Controversy and Change — Navigating the Reauthorization of FISA’s Section 702, 21. Juni 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, Februar 2026 https://www.brookings.edu/articles/a-key-intelligence-law-expires-in-april-and-the-path-for-reauthorization-is-unclear/

heise online: BSI definiert, wann eine Cloud wirklich souverän ist, 27. April 2026 https://www.heise.de/news/BSI-definiert-wann-eine-Cloud-wirklich-souveraen-ist-11272737.html

Fortanix: AWS XKS External Key Store — Ausschluss des AWS-Zugriffs unter dem CLOUD Act (Branchenanalyse)

Securosys: Data sovereignty mit AWS XKS — Branchenanalyse

Rechtlicher Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung im Sinne des Rechtsdienstleistungsgesetzes (RDG) dar. Für eine rechtssichere Beurteilung im konkreten Einzelfall wird die Konsultation eines auf Datenschutzrecht spezialisierten Rechtsanwalts empfohlen. Stand: Juni 2026.

1. Microsoft Learn, „Data controls — Sovereign Public Cloud”, April 2026. ↩

2. Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713 (2018). ↩

3. Microsoft, Online Services Data Protection Addendum (aktuelle Fassung), Abschnitt zu behördlichen Auskunftsersuchen und Benachrichtigung der Kunden. ↩

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

5. RISAA, H.R. 7888 (2024); JURIST, „Controversy and Change”, 21.06.2024, zur Erweiterung der ECSP-Definition. ↩

6. CNBC, „Three things to know about FISA Section 702”, 17.04.2026, zur 10-tägigen Verlängerung bis zum 30.04.2026. ↩

7. CNBC, „FISA Section 702: Congress passes short-term surveillance program extension just before deadline”, 30.04.2026, zur weiteren 45-tägigen Verlängerung, die Section 702 bis zum 12. Juni 2026 in Kraft hält. ↩

8. Brookings, „A key intelligence law expires in April”, Februar 2026. ↩

9. EuGH, Schrems II, C-311/18, Urteil v. 16.07.2020, Rn. 178–185 (FISA 702) und 198–202 (Verhältnismäßigkeitsfrage). ↩

10. EDSA-Empfehlungen 01/2020, Endfassung v2.0, 18.06.2021. ↩

11. Microsoft, „EU Data Boundary for the Microsoft Cloud”, offizielle Dokumentation. ↩

12. Microsoft Learn, „Data sovereignty — Sovereign Cloud”, Abschnitt zu Hosting Country Rights. ↩

13. Verordnung (EU) 2016/679 (DSGVO), Art. 4 Nr. 5. ↩

14. Microsoft Learn, „Controls and principles in Sovereign Public Cloud”, April 2026. ↩

15. AWS, „AWS Key Management Service — External Key Store (XKS)“; Branchenzusammenfassung bei Fortanix, „AWS XKS External Key Store”, mit dem Hinweis, dass XKS Organisationen ermöglicht, „bar AWS’s access” auf Schlüssel und Daten zu erreichen, die andernfalls unter dem CLOUD Act angefordert werden könnten. ↩

16. Google Cloud, „Cloud External Key Manager (Cloud EKM)” und „Key Access Justifications”, offizielle Dokumentation; extern verwaltete Schlüssel werden niemals in Google Cloud zwischengespeichert, und Key Access Justifications erlauben dem Kunden, eine Entschlüsselungsanforderung selbst dann abzulehnen, wenn sie von einer Drittbehörde ausgeht. ↩

17. Microsoft Learn, „Control your cloud data by using Managed HSM”, Abschnitt zur Reaktion von Microsoft auf rechtliche Anforderungen. Das Key-Vault-Team erklärt, über keine Betriebsverfahren zu verfügen, einen solchen Zugriff zu gewähren, und einer rechtlichen Anforderung zur Umgehung der kundenseitig kontrollierten Verschlüsselung zu widersprechen. https://learn.microsoft.com/en-us/azure/key-vault/managed-hsm/mhsm-control-data ↩

18. Latanya Sweeney, „Simple Demographics Often Identify People Uniquely”, Carnegie Mellon University, Data Privacy Working Paper 3, 2000. ↩

19. Khaled El Emam et al., „The re-identification risk of Canadians from longitudinal demographics”, BMC Medical Informatics and Decision Making 11, 46 (2011). ↩

20. EDSA-Empfehlungen 01/2020, Anhang 2, Use Case 2, Rn. 85 ff. ↩

21. EDSA Guidelines 01/2025 on Pseudonymisation; analytische Zusammenfassung im European Law Blog. ↩

22. Microsoft Tech Community, „Azure Information Protection with HYOK (Hold Your Own Key)“. ↩

23. Microsoft Learn, „Confidential computing overview”, April 2026. ↩

24. Microsoft, „Customer Lockbox for Microsoft Azure”, Produktbeschreibung. ↩

25. BSI, „Criteria enabling Cloud Computing Autonomy (C3A)“, v1.0, 27.04.2026, Abschnitt 1.2. ↩

26. BSI, Pressemitteilung „C3A: BSI veröffentlicht Souveränitätskriterien für Cloud-Dienste”, 27.04.2026. ↩

27. Der Hessische Beauftragte für Datenschutz und Informationsfreiheit (HBDI), „Bericht zur Nutzung von Microsoft 365”, 15. November 2025; insbesondere die Feststellung, dass vertragliche Verbesserungen im AVV für öffentliche Stellen das Restrisiko eines Zugriffs durch US-Behörden nicht beseitigen. https://datenschutz.hessen.de/sites/datenschutz.hessen.de/files/2025-11/hbdi_bericht_m365_2025_11_15.pdf ↩

28. heise online, „BSI definiert, wann eine Cloud wirklich souverän ist”, 27.04.2026, zur Marktrezeption des C3A und zum breiteren Cyber-Dominanz-Rahmen. ↩