Schrems II im Jahr 2026: US-Datentransfers, die eine Prüfung der Aufsichtsbehörde überstehen

#Schrems II Compliance 2026
Sandor Farkas - Founder & Lead Developer at Wolf-Tech

Sandor Farkas

Gründer & Lead Developer

Experte für Softwareentwicklung und Legacy-Code-Optimierung

Schrems II Compliance 2026 ist längst keine Checkbox-Übung mehr. Aufsichtsbehörden in Deutschland, Frankreich, Österreich und den Niederlanden sind von der Veröffentlichung von Leitlinien zu aktiven Vollzugsverfahren gegen Unternehmen übergegangen, die nicht darlegen können, wie ihre US-Datentransfers tatsächlich abgesichert sind. Wenn Ihre Antwort auf eine Anfrage der Datenschutzbehörde lautet "wir haben Standardvertragsklauseln unterzeichnet", verlassen Sie dieses Gespräch mit hoher Wahrscheinlichkeit mit einer Anordnung zur Abhilfe.

In diesem Beitrag geht es darum, wie ein belastbares Programm für US-Datentransfers tatsächlich aussieht, wenn eine Aufsichtsbehörde Einsicht verlangt: die Dokumentation, die technischen Kontrollen und die Architekturentscheidungen, die einer echten Prüfung standhalten.

Was sich zwischen 2020 und heute geändert hat

Das Schrems II-Urteil vom Juli 2020 kippte das Privacy Shield und machte Standardvertragsklauseln bedingt wirksam: gültig nur dort, wo ein Transfer Impact Assessment bestätigt, dass die Gesetze des Drittlands die vertraglich zugesagten Schutzmechanismen nicht aushebeln. Damals taten die meisten Organisationen eines von drei Dingen: Sie unterzeichneten aktualisierte Standardvertragsklauseln, legten ein TIA ab, das ohne echte rechtliche Analyse zu dem Schluss kam "Standardvertragsklauseln genügen", oder sie taten stillschweigend gar nichts.

Den Behörden fehlten anfangs die Kapazitäten für einen systematischen Vollzug. Das hat sich geändert. Die irische Datenschutzbehörde, lange für ihr zögerliches Vorgehen in den Meta-Verfahren kritisiert, hat wesentliche Verfahren abgeschlossen. Deutsche Landesdatenschutzbehörden haben Vollzugsbescheide gegen Unternehmen veröffentlicht, die Google Analytics, von US-Servern geladenes Cookiebot oder in den USA gehostete Font-CDNs einsetzen. Die CNIL in Frankreich und die DSB in Österreich waren bei cookie-nahen Übermittlungen besonders aktiv. Das Muster ist durchgängig: Die Behörden warten nicht mehr auf Beschwerden. Sie prüfen ganze Branchen proaktiv.

Im Jahr 2026 bietet das EU-US Data Privacy Framework einen Angemessenheitsmechanismus für Übermittlungen an zertifizierte US-Unternehmen. Angemessenheit ist jedoch kein Freibrief. Sie deckt Übermittlungen an die konkret zertifizierte Stelle ab, nicht jeden US-basierten Unterauftragsverarbeiter, den diese Stelle nachgelagert einsetzt. Und Angemessenheitsbeschlüsse können angegriffen werden: Das Schrems-III-Verfahren läuft bereits vor EU-Gerichten. Organisationen, die ihr Compliance-Programm vollständig auf den Angemessenheitsbeschluss gestützt haben, stehen ungeschützt da, wenn dieser fällt.

Am besten aufgestellt sind heute die Unternehmen, die ihr Programm auf Standardvertragsklauseln mit echten TIAs gebaut und den Angemessenheitsbeschluss anschließend als zusätzliche Ebene genutzt haben, nicht als Fundament.

Was ein Transfer Impact Assessment tatsächlich verlangt

Ein TIA ist kein Selbstauskunftsformular. Es ist eine dokumentierte rechtliche Analyse dreier Punkte: welche Daten übermittelt werden, auf welcher Rechtsgrundlage, und ob die Überwachungsgesetze des Ziellands Behörden einen Zugriff eröffnen, der die vertraglichen Schutzmechanismen aushebeln würde.

Für US-Transfers sind die einschlägigen Rechtsgrundlagen FISA Section 702, Executive Order 12333 sowie die Reformen durch Executive Order 14086 und das Data Privacy Framework. Ein belastbares TIA muss sich mit allen davon auseinandersetzen und nicht nur behaupten, EO 14086 habe das Problem gelöst.

Die Empfehlungen des Europäischen Datenschutzausschusses zu ergänzenden Maßnahmen (angenommen im Juni 2021, seither aktualisiert) geben die Mindeststruktur vor. Für jede Übermittlung müssen Sie dokumentieren:

  • Die übermittelten Datenkategorien und deren Sensibilitätsniveau
  • Den Übermittlungsmechanismus (Standardvertragsklauseln, Angemessenheitsbeschluss, Binding Corporate Rules)
  • Eine Bewertung des Rechtsrahmens im Zielland, insbesondere ob Behörden auf Daten in einer Weise zugreifen können, die über das nach EU-Maßstäben Erforderliche und Verhältnismäßige hinausgeht
  • Ob sich die identifizierten Risiken auf ein Niveau senken lassen, das die Übermittlung rechtmäßig macht
  • Welche ergänzenden technischen oder organisatorischen Maßnahmen die Lücke schließen

Die Kernfrage bei US-Transfers unter FISA 702 lautet, ob die Dienste des US-Anbieters Anordnungen zur Auslandsaufklärung unterliegen. Für Hyperscaler wie AWS, Azure und GCP sowie für große SaaS-Plattformen lautet die ehrliche Antwort: Sie können solche Anordnungen erhalten und sind rechtlich zur Befolgung verpflichtet. Ein TIA, das dies ignoriert und die Übermittlung ohne jede ergänzende Maßnahme für unbedenklich erklärt, wird eine aufsichtsbehördliche Prüfung nicht überstehen.

Ergänzende technische Maßnahmen, die wirklich tragen

Der EDSA nennt drei Kategorien ergänzender technischer Maßnahmen, die das Risiko so weit senken können, dass eine Übermittlung vertretbar wird, selbst wenn die Rechtslage im Zielland problematisch ist.

Verschlüsselung, bei der der Datenimporteur keinen Zugriff auf die Schlüssel hat. Wenn Sie Daten an einen in den USA gehosteten Dienst übermitteln, die Schlüssel aber selbst in der EU verwahren, liefert eine an den US-Anbieter gerichtete FISA-702-Anordnung nur Chiffrat. Das funktioniert allerdings nur, wenn die Schlüsselverwaltung tatsächlich verhindert, dass der Anbieter an den Klartext gelangt. Cloud-verwaltete Verschlüsselung, bei der der Anbieter die Schlüssel hält oder auf sie zugreifen kann, zählt nicht. Echte Ende-zu-Ende-Verschlüsselung mit Schlüsselverwaltung auf EU-Seite ist für die meisten SaaS-Anwendungsfälle schwer umsetzbar, weil der Anbieter auf verschlüsselten Daten arbeiten müsste. Für Backup-Speicher und Archivübermittlungen ist sie jedoch praktikabel.

Pseudonymisierung vor der Übermittlung. Direkte Identifikatoren vor dem Grenzübertritt durch Token zu ersetzen senkt das Risiko, sofern die Zuordnungstabelle für die Re-Identifikation in der EU bleibt. Der übermittelte Datensatz enthält weiterhin pseudonyme Daten, aber ohne die Zuordnungstabelle kann eine empfangende Überwachungsbehörde die Datensätze ohne zusätzlichen Zugriff keinen konkreten Personen zuordnen. Diese Maßnahme ist bei Analytics-Workloads am wirksamsten: Sie übermitteln aggregierte oder pseudonymisierte Ereignisdaten an eine US-Analytics-Plattform und behalten die Identitätszuordnung in einem in der EU gehosteten Datenspeicher.

Ausschließliche Nutzung der EU-Regionen US-kontrollierter Infrastruktur. AWS eu-central-1, Azure West Europe und GCP europe-west4 liegen physisch in der EU und unterliegen für ruhende Daten EU-Recht. Der Mutterkonzern bleibt jedoch eine US-Gesellschaft im Anwendungsbereich von FISA 702. Der EDSA vertritt die Position, dass das Routing in EU-Rechenzentren das Risiko senkt, es aber nicht beseitigt, weil eine FISA-Anordnung die US-Muttergesellschaft grundsätzlich auch zum Zugriff auf Daten in EU-Regionen zwingen könnte. Das praktische Risiko ist geringer, und die meisten Aufsichtsbehörden werten EU-Hosting als spürbare Risikoreduktion. Es sollte aber nicht so dargestellt werden, als mache es die Übermittlung einem innereuropäischen Transfer gleichwertig.

Vertragliche Maßnahmen allein sind keine ergänzenden technischen Maßnahmen. Das ist ein häufiger Fehler. Zusätzliche Klauseln im Auftragsverarbeitungsvertrag, ausgehandelte Auditrechte oder die Pflicht des Anbieters, Sie über Anordnungen zu informieren, sind organisatorische Maßnahmen. Sie senken das Risiko, dass ein Zugriff unbemerkt bleibt, aber sie hindern eine technisch leistungsfähige Überwachungsbehörde nicht am Datenzugriff. Ein sauber dokumentiertes TIA muss diese Unterscheidung offen benennen.

Die Architekturentscheidungen, die Ihr Risiko senken

Über die anbieterbezogenen TIAs hinaus bestimmt die Architektur Ihres Produkts, wie viel Risiko Sie tragen und wie gut sich dieses Risiko reduzieren lässt.

Erfassen Sie Ihre tatsächlichen Datenflüsse, nicht Ihre beabsichtigten. Verzeichnisse von Verarbeitungstätigkeiten nach Artikel 30 bilden die reale Zahl grenzüberschreitender Übermittlungen häufig unvollständig ab. Error-Monitoring-Werkzeuge wie Sentry oder Datadog erhalten Exception-Payloads, die oft Nutzerkennungen, Sitzungsdaten oder rohe Request-Parameter enthalten. Session-Replay-Werkzeuge erhalten partielle DOM-Snapshots, die Formulareingaben enthalten können. E-Mail-Versandplattformen erhalten Empfängeradressen, Betreffzeilen und je nach Konfiguration auch Inhalte. Nichts davon steht üblicherweise im Verarbeitungsverzeichnis neben "Übermittlung in die USA auf Basis von Standardvertragsklauseln", und dennoch übermitteln all diese Dienste personenbezogene Daten.

Eine vollständige Datenflusskarte beginnt beim Produkt: jeder ausgehende Netzwerkaufruf aus Backend-Diensten, jedes im Frontend geladene Drittanbieterskript, jeder Webhook und jeder API-Aufruf aus dem Infrastruktur-Tooling. Für jeden Aufruf wird nachvollzogen, welche Daten er transportiert. Das ist ebenso sehr eine Engineering-Aufgabe wie eine juristische. Code-Quality-Reviews fördern regelmäßig undokumentierte Drittanbieter-Integrationen zutage, die schrittweise ohne begleitende Compliance-Prüfung hinzugekommen sind.

Bevorzugen Sie EU-gehostete Alternativen für Hochrisikokategorien. Nicht für jedes US-Werkzeug gibt es ein EU-Äquivalent, aber für mehr, als die meisten Teams annehmen. Plausible Analytics (EU-gehostet, Privacy-first), Matomo (selbst hostbar), Hetzner und OVH für Cloud-Infrastruktur, Mailpace für transaktionale E-Mails, selbst gehostetes Sentry auf EU-Infrastruktur: Diese Optionen müssen auf fachliche Passung geprüft werden. Für Kategorien mit sensiblen Übermittlungsdaten (Authentifizierungsereignisse, Zahlungsmetadaten, gesundheitsnahe Daten) ist der Aufwand eines Wechsels jedoch geringer als das Compliance-Risiko des Verharrens.

Bauen Sie Abstraktionsschichten jetzt, nicht erst im Bedarfsfall. Wenn Ihr Anwendungscode Drittanbieter-SDKs direkt aufruft, erfordert der Wechsel von einem US-Anbieter zu einer EU-Alternative eine Änderung an der Codebasis. Liegt die Integration hinter einer schlanken Schnittstelle oder einem Adapter, ist der Wechsel eine Konfigurationsänderung. Diese Abstraktion einzuziehen kostet wenig, solange die Integration neu gebaut wird, und viel, wenn Sie unter Zeitdruck auf eine behördliche Anfrage reagieren müssen. Projekte der individuellen Softwareentwicklung mit compliance-bewusstem Briefing sollten dieses Muster als Standard vorsehen, nicht als Zusatzoption.

Trennen Sie die Frage der Datenresidenz von der Frage der Rechtsgrundlage. Beides hängt zusammen, ist aber nicht dasselbe. Datenresidenz, also die physische Speicherung in EU-Rechenzentren, senkt das Risiko eines Überwachungszugriffs und erfüllt vertragliche Anforderungen von Enterprise-Kunden. Die Rechtsgrundlage der Übermittlung, also Standardvertragsklauseln, Angemessenheitsbeschluss oder Binding Corporate Rules, entscheidet über die Rechtmäßigkeit unabhängig davon, wo die Daten physisch landen. Sie können in der EU gespeicherte Daten auf unzureichender Rechtsgrundlage übermitteln oder in den USA gespeicherte Daten auf solider Rechtsgrundlage mit starken ergänzenden Maßnahmen. Das Compliance-Programm muss beides adressieren.

Worauf Aufsichtsbehörden im Jahr 2026 tatsächlich achten

Auf Basis veröffentlichter Vollzugsentscheidungen und behördlicher Leitlinien sind dies die Fragen, die bei einer Prüfung durch eine Aufsichtsbehörde wahrscheinlich gestellt werden:

  • Können Sie ein aktuelles Verzeichnis nach Artikel 30 vorlegen, das sämtliche Übermittlungen in die USA umfasst und nicht nur den primären Auftragsverarbeiter?
  • Haben Sie mit jedem Anbieter unterzeichnete Standardvertragsklauseln, und handelt es sich um die aktuellen Klauseln in der Fassung von Juni 2021?
  • Liegt für jede Übermittlung ein abgeschlossenes TIA vor, und setzt sich dieses tatsächlich mit dem FISA-702-Risiko auseinander, statt lediglich zu behaupten, Standardvertragsklauseln seien ausreichend?
  • Welche ergänzenden technischen oder organisatorischen Maßnahmen hat das TIA benannt, und haben Sie diese umgesetzt?
  • Wie überwachen Sie Änderungen im Recht des Ziellands, die das TIA hinfällig machen würden?
  • Wie sieht Ihr Verfahren aus, wenn ein Anbieter Ihnen mitteilt, dass er ein behördliches Zugriffsersuchen erhalten hat?

Die letzten beiden Fragen treffen viele Organisationen unvorbereitet. Ein TIA ist kein einmaliges Dokument. Es braucht einen Überprüfungsauslöser, der an wesentliche Änderungen der Rechtslage gekoppelt ist. Und die meisten SaaS-Unternehmen haben kein dokumentiertes Verfahren für den Umgang mit Meldungen über behördliche Zugriffsersuchen, obwohl ihre Auftragsverarbeitungsverträge mit US-Anbietern eine solche Meldung typischerweise vorsehen.

Alles zusammengeführt

Ein belastbares Schrems-II-Programm hat im Jahr 2026 diese Bestandteile: ein vollständiges Datenflussinventar auf Anwendungsebene, Standardvertragsklauseln mit jedem US-Anbieter auf Basis der aktuellen Vorlagen, TIAs, die das FISA-Risiko ehrlich bewerten und dokumentieren, welche ergänzenden Maßnahmen die Lücke schließen, echte technische Maßnahmen dort, wo das Risiko hoch genug ist, sowie einen Überprüfungsprozess mit definierten Auslösern.

Nichts davon erfordert ein Team von Juristen oder ein sechsstelliges Compliance-Werkzeug. Eine gut strukturierte Tabelle und die veröffentlichten Leitlinien des EDSA decken das Meiste ab. Der begrenzende Faktor ist meist das Datenflussinventar, denn dafür braucht es jemanden mit ausreichend Zugang zu Codebasis und Infrastruktur, um nachzuvollziehen, wohin Daten tatsächlich fließen, und nicht nur, wohin das Architekturdiagramm sie schickt.

Wenn Sie nicht sicher sind, wohin Ihr Produkt personenbezogene Daten über Grenzen hinweg sendet, oder wenn Sie einschätzen möchten, ob Ihre aktuelle Dokumentation der Rechtsgrundlage einer Prüfung standhält, ist genau das der richtige Startpunkt. Wir haben SaaS-Teams im Rahmen von Code-Quality-Consulting und Webanwendungsentwicklung durch genau diese Art von Audit-Vorbereitung begleitet.

Melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io, um zu besprechen, wo Ihr Programm aktuell steht.