Schrems II und Tracking-Pixel: wo das DPF Sie 2026 stehen laesst

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

Es folgten drei Jahre Leitlinien zu zusaetzlichen Massnahmen, Transfer-Folgenabschaetzungs-Vorlagen und Durchsetzungsmassnahmen der Aufsichtsbehoerden. Dann, im Juli 2023, nahm die Europaeische Kommission die EU-US Data Privacy Framework-Angemessenheitsentscheidung an und stellte fuer DPF-zertifizierte US-Unternehmen die Angemessenheit wieder her. Meta, Google, Salesforce und HubSpot stehen alle auf der Liste.

Die Frage fuer Marketing- und Compliance-Teams im Jahr 2026 ist nicht "existiert das DPF" - es existiert. Die Frage ist, was es tatsaechlich abdeckt, wo das Restrisiko liegt und wie eine Transferarchitektur aussieht, die einer moeglichen DPF-Anfechtung in der Praxis standhaelt.

TL;DR#

• Der Privacy Shield (2016) wurde von Schrems II im Juli 2020 aufgehoben. SCCs plus zusaetzliche Massnahmen ueberbrueckten die Luecke 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 ueberlebt.

Was Schrems II tatsaechlich gesagt hat#

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

DSGVO Artikel 44 verbietet Transfers in Drittlaender, 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 ungueltig sei, entzog daher jedem darauf gestuetzten Transfer die Angemessenheitsgrundlage.

Standardvertragsklauseln wurden nicht aufgehoben - aber das Gericht hielt im selben Urteil fest, dass SCCs fuer Transfers in die USA nicht automatisch ausreichend sind. Der Verantwortliche oder Auftragsverarbeiter, der SCCs einsetzt, muss von Fall zu Fall pruefen, ob das Rechtssystem des Ziellandes verhindern wuerde, dass die SCC-Schutzwirkung in der Praxis funktioniert. Diese Pflicht ist die Transfer Impact Assessment: eine dokumentierte Bewertung des US-Ueberwachungsrechts und seiner Wirkung auf die uebertragenen Daten.

Die EDSA-Empfehlungen 01/2020 zu zusaetzlichen Massnahmen operationalisierten diese Pflicht. Sie legten einen Sechs-Schritte-Prozess und einen Katalog zusaetzlicher Massnahmen - technische (Verschluesselung, Pseudonymisierung), vertragliche und organisatorische - fest, die Verantwortliche bei Stuetzung auf SCCs fuer US-Transfers bewerten sollten. Fuer Standard-Marketing-Pixel waren die meisten dieser technischen Massnahmen praktisch unmoeglich: Sie koennen einen Payload, dessen Zweck es ist, dass Meta eine Conversion einer Anzeigenimpression zuordnet, nicht sinnvoll verschluesseln.

Das ist die Architektur, mit der Marketing-Teams von Juli 2020 bis Juli 2023 lebten. SCCs wurden unterzeichnet. TIAs wurden versucht. Datenschutzbehoerden in Oesterreich, Frankreich und Italien fanden konkrete Implementierungen - Google Analytics an vorderster Stelle - trotz der SCCs als nicht-konform, weil die zusaetzlichen Massnahmen unzureichend waren.

Was sich mit dem Data Privacy Framework geaendert 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 Praemisse ist, dass der US-Rechtsrahmen - geaendert durch Praesident 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 muessen verifizieren, dass die empfangende Einheit auf der DPF-Teilnehmerliste steht, die oeffentlich 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. Fuer 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 massgebliche Quelle; gehen Sie nicht von Zertifizierung aus. Zweitens deckt die DPF-Zertifizierung bestimmte Taetigkeiten 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. Fuer Standard-Marketing-Attribution via Pixel ist der DPF-Geltungsbereich abgedeckt.

Was das in der Praxis fuer Marketing-Pixel bedeutet#

Mit DPF-Abdeckung sieht die rechtliche Position fuer 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 fuer das Meta Pixel dokumentiert die Transfergrundlage als "Angemessenheitsentscheidung (DPF)" statt "SCCs". Die TIA, die unter dem SCC-Pfad erforderlich gewesen waere, ist nicht erforderlich.

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

Angemessenheit ist jedoch eine Schicht eines mehrschichtigen Compliance-Bildes. Drei zusaetzliche Anforderungen muessen erfuellt 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 Endgeraet des Nutzers. Marketing-Pixel sind nicht essentiell. Consent-Banner muessen spezifisch fuer 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 gegenueber den betroffenen Personen. DSGVO Artikel 13 verlangt, dass der Verantwortliche die betroffenen Personen zum Zeitpunkt der Erhebung ueber die Empfaenger ihrer Daten und etwaige Transfers in Drittlaender informiert. Das DPF aendert diese Transparenzpflicht nicht. Wenn Ihre Datenschutzerklaerung "wir verwenden das Meta Pixel" und "Transfers in die USA werden durch Angemessenheit abgedeckt" sagt, ist das ausreichend. Wenn sie den US-Transfer ueberhaupt nicht erwaehnt, heilt die Angemessenheitsentscheidung die Luecke 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 fuer die Pixel-Beziehung. Stellen Sie sicher, dass sie unterzeichnet sind.

Die verbleibenden Risiken#

Das DPF ist keine endgueltige Regelung. Es ist eine Angemessenheitsentscheidung, die vor dem EuGH von jedem Mitgliedstaats-Gericht, dem Europaeischen Parlament oder jeder nationalen Aufsichtsbehoerde angefochten werden kann. Max Schrems und NOYB haben oeffentlich die Absicht signalisiert, das DPF anzufechten - ein potenzielles Schrems III. Die Rechtstheorie fuer diese Anfechtung ist aehnlich wie bei Schrems II: dass EO 14086 und das Data Protection Review Court inhaltlich keine Rechtsbehelfe bieten, die denen unter EU-Recht gleichwertig sind.

Aufsichtsbehoerden haben nicht auf ein EuGH-Urteil gewartet. Die oesterreichische DSB hat noch 2022 entschieden - vor dem Inkrafttreten des DPF -, dass eine Google-Analytics-Implementierung rechtswidrig war, weil die SCCs und zusaetzlichen Massnahmen unzureichend waren. Die franzoesische CNIL und die italienische Garante erliessen aehnliche Feststellungen. Diese Urteile ergingen unter dem Vor-DPF-Regime, etablieren aber ein Aufsichts-Muster: Datenschutzbehoerden sind bereit, die technische Mechanik pixelbasierter Transfers zu pruefen, nicht nur den vertraglichen Papierkram. Eine kuenftige Entscheidung unter einer Nach-DPF-Anfechtung wuerde wahrscheinlich pruefen, ob die durch EO 14086 etablierte Rechtsordnung tatsaechlich den FISA-702-Zugriff auf die gespeicherten Daten zertifizierter Unternehmen einschraenkt.

Die spezifische Sorge bei Tracking-Pixeln geht ueber den Rechtsmechanismus hinaus. Ein client-seitiges Pixel macht mehr, als Daten an ein zertifiziertes Unternehmen zu transferieren. Es fuehrt 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 ausserhalb Ihrer Kontrolle - Sie koennen kein Identifier-Hashing anwenden, bevor sie abgeschickt werden, Sie koennen nicht begrenzen, welche Felder befuellt werden, und Sie koennen ohne Netzwerk-Inspektion zur Laufzeit nicht verifizieren, was das Pixel tatsaechlich sendet. Die DPF-Angemessenheit deckt das Ziel ab; sie regelt nicht, was das Pixel vor dem Transfer sammelt.

Diese Kombination - potenzielle DPF-Anfechtung, Pruefung der Mechanik durch die Aufsichtsbehoerden statt nur des Papierkrams und strukturelle Grenzen dessen, was ein Verantwortlicher ueber 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 moeglichen DPF-Ungueltigkeitserklaerung haelt, 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. Fuer die meisten Marketing-Teams ist das der Modus, der Ihre Attributions-Dashboards heute fuellt.

Der zweite Modus ist die server-seitige Conversion-Weiterleitung von EU-Infrastruktur. Wenn ein Nutzer einen Link klickt, empfaengt 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 Aequivalent. 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 laeuft.

Wenn das DPF aufgehoben wird, wird das client-seitige Pixel zu einem nicht-konformen Transfermechanismus, bis ein Ersatzrahmen vorhanden ist. Der serverseitige Pfad, der ueber SCCs mit angewandten zusaetzlichen Massnahmen laeuft - verschluesselt waehrend des Transfers, Identifier vor Abgang gehasht, eng auf das Attributionssignal beschraenkt - ist das Backup, das Ihr Rechtsteam mit einer kohaerenten 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 verfuegbar den EU-Endpunkt des Anbieters. GA4 mit data_collection_endpoint auf region1.google-analytics.com haelt 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, unabhaengig davon. Die zusaetzliche Massnahme ist Identifier-Hashing, nicht Endpunkt-Geografie.

Fuer die vollstaendige Mechanik des serverseitigen Weiterleitungspfads und wie er sich in die Short-Link-Klick-Attribution integriert, deckt cookieless attribution explained die technische Architektur ab. Fuer 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 ueber 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 oeffentliche Sub-Processor-Liste nennt seine fuenf Anbieter; die Pixel-Anbieter sind Sub-Processors auf der Verantwortlichen-Ebene, nicht auf der Elido-Ebene. Ihr Artikel-30-Verarbeitungsverzeichnis sollte sie separat auffuehren.

Eine Feinheit: DSGVO Artikel 28 Absatz 2 verlangt, dass der Auftragsverarbeiter vor dem Einsatz von Sub-Processors die Genehmigung des Verantwortlichen einholt. Fuer 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 Weiterleitungsstueck - 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 laeuft durch Elidos Standard-AVV.

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

Fuer die vollstaendigen DSGVO-Auftragsverarbeiter-Pflichten auf Artikel-Ebene ist GDPR for URL shorteners der Cornerstone-Beitrag in diesem Cluster.

Die Beschaffungs-Checkliste der DPO fuer Pixel-Anbieter#

Fuenf Fragen, die jedem Tracking-Pixel-Anbieter bei der Beschaffung gestellt werden sollten. Sie sind fuer eine Pruefung in der DPF-Aera geschrieben; passen Sie die Transfermechanismus-Frage an, falls sich der DPF-Status geaendert hat, wenn Sie das lesen.

1. Ist Ihr Unternehmen derzeit auf der DPF-Teilnehmerliste gelistet, und welche Taetigkeiten 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 taetigkeitsbezogen; ein Anbieter kann DPF-zertifiziert fuer Personaldaten sein, aber nicht fuer kommerzielle Klick-Attributionsdaten.

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

Das DPF deckt den Transfer zu einem zertifizierten US-Empfaenger ab. Wenn ein EU-Regionen-Endpunkt verfuegbar ist, reduziert seine Nutzung das Transferrisiko und kann die TIA-Analyse beeinflussen, falls das DPF spaeter 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 muessen wissen, dass der AVV existiert und wo er zu finden ist. Der AVV regelt die Auftragsverarbeiter-Beziehung unabhaengig vom Transfermechanismus.

4. Wie handhaben Sie Anfragen zu Betroffenenrechten - speziell Loeschung nach Artikel 17 - fuer pixel-gesammelte Daten?

Fuer client-seitige Pixel wird die Loeschung typischerweise ueber die Datenschutz-Steuerungen der Plattform abgewickelt (Metas Privacy Centre, Googles My Ad Centre). Dokumentieren Sie den Prozess, damit Sie eine Betroffenenanfrage beantworten koennen, ohne improvisieren zu muessen.

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

Diese Frage prueft, ob der Anbieter einen Notfallplan hat. Unter dem Uebergang vom Privacy Shield zu SCCs (2020-2021) waren einige Anbieter langsam beim Aktualisieren ihrer Vertraege. Ein Anbieter, der SCCs als DPF-Ungueltigkeits-Backup bereits dokumentiert hat - mit spezifizierten zusaetzlichen Massnahmen - hat diese Arbeit erledigt. Ein Anbieter, der sagt "wir werden unseren AVV aktualisieren, wenn es noetig ist", hat sie nicht erledigt.

Zur Elido-spezifischen Umsetzung: Die serverseitige Conversion-Weiterleitung ist heute verfuegbar, 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 primaerer Weiterleitungsmechanismus zur Verfuegung, nicht nur als Backup.