Schrems II und Tracking-Pixel: wo das DPF Sie 2026 stehen lässt

Im Juli 2020 sprach der EuGH Schrems II (C-311/18). Der Privacy Shield, der seit 2016 der Standardmechanismus für EU-US-Datentransfers war, wurde aufgehoben. Über Nacht übertrug jedes Marketing-Team, das ein Meta Pixel oder einen Google Tag betrieb, Daten entweder ohne einen gültigen Rechtsmechanismus, hetzte um die Ausfertigung von Standardvertragsklauseln oder verließ sich auf die hoffnungsvolle Interpretation, die DSGVO erreiche irgendwie nicht einen JavaScript-Schnipsel im Browser eines Nutzers.

Es folgten drei Jahre Leitlinien zu zusätzlichen Maßnahmen, Transfer-Folgenabschätzungs-Vorlagen und Durchsetzungsmaßnahmen der Aufsichtsbehörden. Dann, im Juli 2023, nahm die Europäische Kommission die EU-US Data Privacy Framework-Angemessenheitsentscheidung an und stellte für DPF-zertifizierte US-Unternehmen die Angemessenheit wieder her. Meta, Google, Salesforce und HubSpot stehen alle auf der Liste.

Die Frage für Marketing- und Compliance-Teams im Jahr 2026 ist nicht "existiert das DPF" - es existiert. Die Frage ist, was es tatsächlich abdeckt, wo das Restrisiko liegt und wie eine Transferarchitektur aussieht, die einer möglichen DPF-Anfechtung in der Praxis standhält.

TL;DR

• Der Privacy Shield (2016) wurde von Schrems II im Juli 2020 aufgehoben. SCCs plus zusätzliche Maßnahmen überbrückten die Lücke von 2020 bis 2023.
• Der EU-US Data Privacy Framework (Juli 2023) ist die aktuelle Angemessenheitsentscheidung. Transfers DPF-zertifizierter Unternehmen profitieren von Angemessenheit, ohne SCCs oder eine TIA zu erfordern.
• Client-seitige Pixel zu DPF-zertifizierten Anbietern sind 2026 rechtlich vertretbar, sofern die empfangende Einheit zertifiziert ist, die betroffene Person informiert wurde und die ePrivacy-Einwilligung - wo erforderlich - vorliegt.
• Das DPF ist Gegenstand erwarteter rechtlicher Anfechtung. Dual-Mode-Tracking - client-seitig unter DPF-Abdeckung, server-seitige Weiterleitung von EU-Infrastruktur als strukturelles Backup - ist die Architektur, die ein drittes Schrems-Urteil überlebt.

Was Schrems II tatsächlich gesagt hat

Das Urteil ist es wert, direkt gelesen zu werden, statt über eine Zusammenfassung. Die operative Argumentation steht in den Absätzen 180-202. Die zentrale Feststellung ist nicht, dass US-Datentransfers per se illegal sind. Sie ist, dass das US-Überwachungsrecht - speziell FISA 702 und Executive Order 12333 - US-Geheimdiensten Zugriff auf personenbezogene Daten von EU-Subjekten gewährt, und zwar in einer Weise, die diesen Subjekten unter den DSGVO-Artikeln 77-79 keinen wirksamen Rechtsbehelf bietet.

DSGVO Artikel 44 verbietet Transfers in Drittländer, sofern nicht einer der Mechanismen aus Kapitel V greift. Der Privacy Shield war eine Angemessenheitsentscheidung nach Artikel 45. Die Feststellung des Gerichts, dass der Privacy Shield ungültig sei, entzog daher jedem darauf gestützten Transfer die Angemessenheitsgrundlage.

Standardvertragsklauseln wurden nicht aufgehoben - aber das Gericht hielt im selben Urteil fest, dass SCCs für Transfers in die USA nicht automatisch ausreichend sind. Der Verantwortliche oder Auftragsverarbeiter, der SCCs einsetzt, muss von Fall zu Fall prüfen, ob das Rechtssystem des Ziellandes verhindern würde, dass die SCC-Schutzwirkung in der Praxis funktioniert. Diese Pflicht ist die Transfer Impact Assessment: eine dokumentierte Bewertung des US-Überwachungsrechts und seiner Wirkung auf die übertragenen Daten.

Die EDSA-Empfehlungen 01/2020 zu zusätzlichen Maßnahmen operationalisierten diese Pflicht. Sie legten einen Sechs-Schritte-Prozess und einen Katalog zusätzlicher Maßnahmen - technische (Verschlüsselung, Pseudonymisierung), vertragliche und organisatorische - fest, die Verantwortliche bei Stützung auf SCCs für US-Transfers bewerten sollten. Für Standard-Marketing-Pixel waren die meisten dieser technischen Maßnahmen praktisch unmöglich: Sie können einen Payload, dessen Zweck es ist, dass Meta eine Conversion einer Anzeigenimpression zuordnet, nicht sinnvoll verschlüsseln.

Das ist die Architektur, mit der Marketing-Teams von Juli 2020 bis Juli 2023 lebten. SCCs wurden unterzeichnet. TIAs wurden versucht. Datenschutzbehörden in Österreich, Frankreich und Italien fanden konkrete Implementierungen - Google Analytics an vorderster Stelle - trotz der SCCs als nicht-konform, weil die zusätzlichen Maßnahmen unzureichend waren.

Was sich mit dem Data Privacy Framework geändert hat

Der EU-US Data Privacy Framework (Beschluss (EU) 2023/1795, wirksam ab 10. Juli 2023) ist eine Angemessenheitsentscheidung nach DSGVO Artikel 45. Seine rechtliche Prämisse ist, dass der US-Rechtsrahmen - geändert durch Präsident Bidens Executive Order 14086 und die nachfolgenden Regeln zur Errichtung des Data Protection Review Court - ein im Wesentlichen gleichwertiges Schutzniveau bietet wie das in der EU garantierte.

Praktisch bedeutet das DPF Folgendes: Transfers an DPF-zertifizierte US-Unternehmen profitieren von Angemessenheit. Sie brauchen keine SCCs. Sie brauchen keine TIA. Sie müssen verifizieren, dass die empfangende Einheit auf der DPF-Teilnehmerliste steht, die öffentlich durchsuchbar ist und nahezu in Echtzeit aktualisiert wird.

Meta Platforms, Inc. ist DPF-zertifiziert. Google LLC ist DPF-zertifiziert. Salesforce, Inc. ist DPF-zertifiziert. HubSpot, Inc. ist DPF-zertifiziert. Für diese Anbieter sind Transfers von personenbezogenen EU-Daten im Zusammenhang mit Werbung und Analytik seit Juli 2023 von Angemessenheit abgedeckt, vorausgesetzt sie empfangen die Daten in ihrer DPF-zertifizierten Eigenschaft.

Zwei Klarstellungen sind wichtig. Erstens ist die DPF-Zertifizierung freiwillig. Nicht jedes US-Unternehmen, das EU-Daten verarbeitet, hat sich selbstzertifiziert. Die Teilnehmerliste ist die maßgebliche Quelle; gehen Sie nicht von Zertifizierung aus. Zweitens deckt die DPF-Zertifizierung bestimmte Tätigkeiten ab. Ein Unternehmen, das DPF-zertifiziert ist, kann Ihre Pixel-Daten je nach Datentyp und Zweck unter dem zertifizierten Geltungsbereich oder unter einer anderen Rechtsgrundlage verarbeiten. Für Standard-Marketing-Attribution via Pixel ist der DPF-Geltungsbereich abgedeckt.

Was das in der Praxis für Marketing-Pixel bedeutet

Mit DPF-Abdeckung sieht die rechtliche Position für client-seitige Marketing-Pixel an zertifizierte Anbieter so aus.

Das client-seitige Meta Pixel, das an Meta Platforms Inc. (DPF-zertifiziert) feuert, ist ein Transfer zu einem angemessenen Ziel. Der Transfermechanismus ist die DPF-Angemessenheitsentscheidung, nicht SCCs. Ihr Eintrag in der Verarbeitungsverzeichnis nach Artikel 30 für das Meta Pixel dokumentiert die Transfergrundlage als "Angemessenheitsentscheidung (DPF)" statt "SCCs". Die TIA, die unter dem SCC-Pfad erforderlich gewesen wäre, ist nicht erforderlich.

Dieselbe Analyse gilt für Google Tag Manager und GA4, die an Google LLC feuern, für HubSpots Tracking-Pixel, das an HubSpot Inc. feuert, und für Salesforce Marketing Clouds Attributionsereignisse, die an Salesforce Inc. feuern.

Angemessenheit ist jedoch eine Schicht eines mehrschichtigen Compliance-Bildes. Drei zusätzliche Anforderungen müssen erfüllt sein, bevor diese Position trauet.

ePrivacy-Einwilligung. Die ePrivacy-Richtlinie 2002/58/EG, Artikel 5 Absatz 3, verlangt Einwilligung vor jeder nicht-essentiellen Speicherung oder jedem Zugriff auf dem Endgerät des Nutzers. Marketing-Pixel sind nicht essentiell. Consent-Banner müssen spezifisch für das fragliche Pixel sein, freiwillig erteilt und widerruflich. Die Tatsache, dass das Transferziel DPF-angemessen ist, beeinflusst die ePrivacy-Einwilligungspflicht nicht. Das sind separate Rechtsinstrumente.

Transparenz gegenüber den betroffenen Personen. DSGVO Artikel 13 verlangt, dass der Verantwortliche die betroffenen Personen zum Zeitpunkt der Erhebung über die Empfänger ihrer Daten und etwaige Transfers in Drittländer informiert. Das DPF ändert diese Transparenzpflicht nicht. Wenn Ihre Datenschutzerklärung "wir verwenden das Meta Pixel" und "Transfers in die USA werden durch Angemessenheit abgedeckt" sagt, ist das ausreichend. Wenn sie den US-Transfer überhaupt nicht erwähnt, heilt die Angemessenheitsentscheidung die Lücke nach Artikel 13 nicht.

Artikel-28-AVV mit dem Anbieter. Der Pixel-Anbieter bleibt Auftragsverarbeiter unter DSGVO Artikel 28. Das DPF deckt den Transfermechanismus ab; es ersetzt nicht den AVV. Metas, Googles und HubSpots Standard-Datenverarbeitungsbedingungen sind die Artikel-28-Instrumente für die Pixel-Beziehung. Stellen Sie sicher, dass sie unterzeichnet sind.

Die verbleibenden Risiken

Das DPF ist keine endgültige Regelung. Es ist eine Angemessenheitsentscheidung, die vor dem EuGH von jedem Mitgliedstaats-Gericht, dem Europäischen Parlament oder jeder nationalen Aufsichtsbehörde angefochten werden kann. Max Schrems und NOYB haben öffentlich die Absicht signalisiert, das DPF anzufechten - ein potenzielles Schrems III. Die Rechtstheorie für diese Anfechtung ist ähnlich wie bei Schrems II: dass EO 14086 und das Data Protection Review Court inhaltlich keine Rechtsbehelfe bieten, die denen unter EU-Recht gleichwertig sind.

Aufsichtsbehörden haben nicht auf ein EuGH-Urteil gewartet. Die österreichische DSB hat noch 2022 entschieden - vor dem Inkrafttreten des DPF -, dass eine Google-Analytics-Implementierung rechtswidrig war, weil die SCCs und zusätzlichen Maßnahmen unzureichend waren. Die französische CNIL und die italienische Garante erließen ähnliche Feststellungen. Diese Urteile ergingen unter dem Vor-DPF-Regime, etablieren aber ein Aufsichts-Muster: Datenschutzbehörden sind bereit, die technische Mechanik pixelbasierter Transfers zu prüfen, nicht nur den vertraglichen Papierkram. Eine künftige Entscheidung unter einer Nach-DPF-Anfechtung würde wahrscheinlich prüfen, ob die durch EO 14086 etablierte Rechtsordnung tatsächlich den FISA-702-Zugriff auf die gespeicherten Daten zertifizierter Unternehmen einschränkt.

Die spezifische Sorge bei Tracking-Pixeln geht über den Rechtsmechanismus hinaus. Ein client-seitiges Pixel macht mehr, als Daten an ein zertifiziertes Unternehmen zu transferieren. Es führt JavaScript im Browser des Nutzers aus, setzt First-Party- und Third-Party-Cookies im Kontext der Pixel-Domain und sendet Daten direkt aus dem Browser. Die Daten, die den Browser verlassen, sind außerhalb Ihrer Kontrolle - Sie können kein Identifier-Hashing anwenden, bevor sie abgeschickt werden, Sie können nicht begrenzen, welche Felder befüllt werden, und Sie können ohne Netzwerk-Inspektion zur Laufzeit nicht verifizieren, was das Pixel tatsächlich sendet. Die DPF-Angemessenheit deckt das Ziel ab; sie regelt nicht, was das Pixel vor dem Transfer sammelt.

Diese Kombination - potenzielle DPF-Anfechtung, Prüfung der Mechanik durch die Aufsichtsbehörden statt nur des Papierkrams und strukturelle Grenzen dessen, was ein Verantwortlicher über das Verhalten eines client-seitigen Pixels verifizieren kann - ist der Grund, warum eine reine client-seitige Strategie architektonisch zerbrechlich bleibt.

Die praktische Position: Dual-Mode-Tracking

Die Architektur, die sowohl unter dem DPF als auch unter einer möglichen DPF-Ungültigkeitserklärung hält, ist Dual-Mode.

Der erste Modus sind client-seitige Pixel zu DPF-zertifizierten Anbietern, betrieben unter aktueller Angemessenheit mit vorhandener ePrivacy-Einwilligung. Das liefert das breiteste Attributionssignal, solange das DPF Bestand hat. Für die meisten Marketing-Teams ist das der Modus, der Ihre Attributions-Dashboards heute füllt.

Der zweite Modus ist die server-seitige Conversion-Weiterleitung von EU-Infrastruktur. Wenn ein Nutzer einen Link klickt, empfängt Elidos EU-Edge den Klick, protokolliert ihn in unserem EU-Analysespeicher und leitet das Conversion-Signal server-zu-server an die Conversion-API der Werbeplattform weiter - Meta CAPI, GA4 Measurement Protocol oder Äquivalent. Der Browser des Nutzers kontaktiert den US-Endpunkt nicht. Die Daten, die die EU-Infrastruktur verlassen, wurden gehasht (SHA-256 auf E-Mail-Adressen und Telefonnummern, wie Meta CAPI es verlangt), und der Transfer geht von Infrastruktur unter Ihrer Kontrolle aus, statt von Code, der im Browser des Nutzers läuft.

Wenn das DPF aufgehoben wird, wird das client-seitige Pixel zu einem nicht-konformen Transfermechanismus, bis ein Ersatzrahmen vorhanden ist. Der serverseitige Pfad, der über SCCs mit angewandten zusätzlichen Maßnahmen läuft - verschlüsselt während des Transfers, Identifier vor Abgang gehasht, eng auf das Attributionssignal beschränkt - ist das Backup, das Ihr Rechtsteam mit einer kohärenten TIA verteidigen kann. Da der serverseitige Pfad Daten zuerst in EU-Infrastruktur verarbeitet, kann der Transfer als Controller-to-Processor dokumentiert werden statt als direkter Browser-to-US-Endpunkt-Transfer.

Bevorzugen Sie wo verfügbar den EU-Endpunkt des Anbieters. GA4 mit data_collection_endpoint auf region1.google-analytics.com hält mehr Verarbeitung in Googles EU-Infrastruktur, auch wenn laut Googles eigener Dokumentation immer noch ein Teil der Verarbeitung in US-Infrastruktur stattfindet. Meta CAPI bietet derzeit keinen EU-Regionen-Endpunkt; der Server-zu-Server-Transfer geht in die USA, unabhängig davon. Die zusätzliche Maßnahme ist Identifier-Hashing, nicht Endpunkt-Geografie.

Für die vollständige Mechanik des serverseitigen Weiterleitungspfads und wie er sich in die Short-Link-Klick-Attribution integriert, deckt cookieless attribution explained die technische Architektur ab. Für das breitere Bild der EU-Datenresidenz - wo "EU-gehostet" in einem Marketing-Tool-Stack beginnt und endet - ist EU data residency for marketing der Begleitbeitrag.

Sub-Processor-Einwilligung unter dem DPF

Jeder DPF-zertifizierte Pixel-Anbieter ist nach wie vor Auftragsverarbeiter unter DSGVO Artikel 28. Die DPF-Angemessenheitsentscheidung deckt den Transfermechanismus ab; sie sagt nichts über die parallel bestehenden Auftragsverarbeiter-Pflichten aus.

Das bedeutet, dass der Verantwortliche mit jedem Pixel-Anbieter einen Auftragsverarbeitungsvertrag braucht, der die Pflichten aus Artikel 28 Absatz 3 Buchstaben a-h abdeckt. Metas Standard-Werbedaten-Bedingungen, Googles Datenverarbeitungsnachtrag und HubSpots AVV sind hier die Instrumente. Sie sind vorunterzeichnet und durch Verweis in die Vertragsbedingungen aufgenommen, wenn Sie den Vertragsbedingungen des Anbieters zustimmen; die Frage ist, ob Sie diese Vereinbarung in Ihren Compliance-Akten dokumentiert haben.

Die Sub-Processor-Liste, nach der Ihre DPO fragen wird, umfasst diese Anbieter. Jeder Pixel-Anbieter wird zu einem Sub-Processor in der Attributionskette zwischen Ihrer Link-Tracking-Plattform und der Werbeplattform. Elidos öffentliche Sub-Processor-Liste nennt seine fünf Anbieter; die Pixel-Anbieter sind Sub-Processors auf der Verantwortlichen-Ebene, nicht auf der Elido-Ebene. Ihr Artikel-30-Verarbeitungsverzeichnis sollte sie separat aufführen.

Eine Feinheit: DSGVO Artikel 28 Absatz 2 verlangt, dass der Auftragsverarbeiter vor dem Einsatz von Sub-Processors die Genehmigung des Verantwortlichen einholt. Für die Pixel-Beziehung sind Sie der Verantwortliche, der Meta oder Google direkt beauftragt - das ist eine Controller-to-Processor-Beziehung, keine Sub-Processor-Kette durch Elido. Der Artikel-28-AVV liegt zwischen Ihnen und dem Pixel-Anbieter. Das serverseitige Weiterleitungsstück - wo Elidos Edge Events in Ihrem Auftrag an Meta CAPI weiterleitet - ist eine Sub-Processor-Beziehung: Elido ist der Auftragsverarbeiter, Meta CAPI ist der Sub-Processor, und die AVV-Pflicht läuft durch Elidos Standard-AVV.

Diese Unterscheidung ist für Ihr Verarbeitungsverzeichnis wichtig. Ein AVV-Compliance-Team, das Ihre Aufzeichnungen prüft, will zwei separate Einträge sehen: einen für die Elido-Auftragsverarbeiter-Beziehung (zur Abdeckung der Link-Layer-Klick-Events) und einen für jede Pixel-Anbieter-Beziehung (zur Abdeckung der browserseitigen Attributionsdaten). Sie zu vermengen, erzeugt einen Verarbeitungsverzeichnis-Eintrag, der in keiner Richtung korrekt ist.

Für die vollständigen DSGVO-Auftragsverarbeiter-Pflichten auf Artikel-Ebene ist GDPR for URL shorteners der Cornerstone-Beitrag in diesem Cluster.

Die Beschaffungs-Checkliste der DPO für Pixel-Anbieter

Fünf Fragen, die jedem Tracking-Pixel-Anbieter bei der Beschaffung gestellt werden sollten. Sie sind für eine Prüfung in der DPF-Ära geschrieben; passen Sie die Transfermechanismus-Frage an, falls sich der DPF-Status geändert hat, wenn Sie das lesen.

1. Ist Ihr Unternehmen derzeit auf der DPF-Teilnehmerliste gelistet, und welche Tätigkeiten deckt Ihre Zertifizierung ab?

Die Liste steht unter dataprivacyframework.gov. Fragen Sie nach dem konkreten Zertifizierungs-Geltungsbereich, nicht nach einem pauschalen "ja, wir sind zertifiziert". Die Zertifizierung ist tätigkeitsbezogen; ein Anbieter kann DPF-zertifiziert für Personaldaten sein, aber nicht für kommerzielle Klick-Attributionsdaten.

2. Wo werden die Daten, die ich via Pixel sende, tatsächlich gespeichert, und gibt es einen EU-Regionen-Endpunkt, den ich nutzen kann?

Das DPF deckt den Transfer zu einem zertifizierten US-Empfänger ab. Wenn ein EU-Regionen-Endpunkt verfügbar ist, reduziert seine Nutzung das Transferrisiko und kann die TIA-Analyse beeinflussen, falls das DPF später angefochten wird. Dokumentieren Sie die Antwort in Ihrem Verarbeitungsverzeichnis-Eintrag.

3. Was ist Ihr Standard-Auftragsverarbeitungsvertrag, und deckt er die Pflichten aus Artikel 28 Absatz 3 Buchstaben a-h explizit ab?

Vorunterzeichnete AVVs, die per Verweis in die Vertragsbedingungen aufgenommen sind, sind in Ordnung; Sie müssen wissen, dass der AVV existiert und wo er zu finden ist. Der AVV regelt die Auftragsverarbeiter-Beziehung unabhängig vom Transfermechanismus.

4. Wie handhaben Sie Anfragen zu Betroffenenrechten - speziell Löschung nach Artikel 17 - für pixel-gesammelte Daten?

Für client-seitige Pixel wird die Löschung typischerweise über die Datenschutz-Steuerungen der Plattform abgewickelt (Metas Privacy Centre, Googles My Ad Centre). Dokumentieren Sie den Prozess, damit Sie eine Betroffenenanfrage beantworten können, ohne improvisieren zu müssen.

5. Falls das DPF aufgehoben wird, welchen Backup-Transfermechanismus werden Sie anbieten, und in welchem Zeitrahmen?

Diese Frage prüft, ob der Anbieter einen Notfallplan hat. Unter dem Übergang vom Privacy Shield zu SCCs (2020-2021) waren einige Anbieter langsam beim Aktualisieren ihrer Verträge. Ein Anbieter, der SCCs als DPF-Ungültigkeits-Backup bereits dokumentiert hat - mit spezifizierten zusätzlichen Maßnahmen - hat diese Arbeit erledigt. Ein Anbieter, der sagt "wir werden unseren AVV aktualisieren, wenn es nötig ist", hat sie nicht erledigt.

Zur Elido-spezifischen Umsetzung: Die serverseitige Conversion-Weiterleitung ist heute verfügbar, mit SHA-256-Identifier-Hashing, bevor Daten die EU-Infrastruktur verlassen. Die Konfiguration ist pro Workspace und im Standard-AVV unter /legal/dpa dokumentiert. Wenn Ihre DPF-Risikobereitschaft niedrig ist, steht der serverseitige Pfad als primärer Weiterleitungsmechanismus zur Verfügung, nicht nur als Backup.