# C-317/25: Warum „unsere Partner“ beim Marketing-Consent zum Problem werden könnte Wer Leads über [Gewinnspiele] (https://de.wikipedia.org/wiki/Gewinnspiel) , Co-Registrierungen oder andere Partner-Modelle generiert, kennt Formulierungen wie „Ich willige ein, Informationen von ausgewählten Partnern zu erhalten“. Technisch ist ein solcher Consent schnell gespeichert. Rechtlich könnte die Sache deutlich anspruchsvoller sein. Am 17.09.2026 hat Generalanwalt Dean Spielmann im Verfahren C-317/25 Groupe Canal+ seine Schlussanträge vorgelegt. Seine Auffassung könnte erhebliche Auswirkungen auf [Direktmarketing] (https://de.wikipedia.org/wiki/Direktmarketing) -Modelle haben, bei denen eine Person zunächst gegenüber einem Unternehmen einwilligt, später aber von weiteren, bei der Einwilligung noch nicht konkret bekannten Unternehmen kontaktiert wird. Der zentrale Punkt: Nach Auffassung des Generalanwalts kann eine Einwilligung für Direktmarketing durch pauschal bezeichnete „Partner“ nur dann tragen, wenn die betroffene Person deren Identität kennt. War der später werbende Verantwortliche bei Erteilung der Einwilligung nicht bekannt, soll vor dem [Marketing] (https://www.sodah.de/online-marketing-agentur/) eine neue Einwilligung erforderlich sein, spätestens bei der ersten Kommunikation. Ebenso deutlich fällt ein weiterer Aspekt der Schlussanträge aus: Eine nachträgliche Möglichkeit zur Abmeldung soll die vorher erforderliche Einwilligung nicht ersetzen können. Das ist für viele Marketing-Setups relevant. Es bedeutet allerdings noch nicht, dass der [Europäische Gerichtshof] (https://de.wikipedia.org/wiki/Europ%C3%A4ischer _Gerichtshof) diese Auslegung übernehmen wird. Bei dem Dokument vom 17.09.2026 handelt es sich um die Schlussanträge des Generalanwalts. Sie sind für den Gerichtshof nicht bindend. Das endgültige Urteil steht noch aus. Gerade deshalb ist jetzt nicht der Zeitpunkt für hektische Umbauten auf Grundlage vermeintlich endgültiger Rechtslage. Sehr wohl ist es aber ein guter Zeitpunkt, bestehende Consent-Systeme technisch und organisatorisch zu überprüfen. ### Betroffen ist mehr als die Formulierung im Formular Auf den ersten Blick könnte man die Diskussion für ein Copywriting-Problem halten: Statt „unsere Partner“ müssten eben konkretere Formulierungen verwendet werden. Das greift zu kurz. Hinter einem Partner-Consent steht fast immer eine Datenkette. Eine Person füllt ein Formular aus. Ein Consent-Datensatz wird gespeichert. Kontaktdaten werden intern weiterverarbeitet oder an Dritte übertragen. Andere Systeme übernehmen die Information. [Kampagnen] (https://www.sodah.de/google-ads-agentur/) werden zu einem späteren Zeitpunkt aus einem [CRM] (https://de.wikipedia.org/wiki/Customer-Relationship-Management) , einer Marketing-Automation oder einer Partnerdatenbank gestartet. Die entscheidende Frage lautet deshalb nicht nur: Was stand neben der Checkbox? Ebenso relevant ist, was das System zu diesem Zeitpunkt tatsächlich wusste und was davon später noch nachvollziehbar ist. War bekannt, welches Unternehmen die Person kontaktieren sollte? Wurde dessen Identität im Consent-Prozess angezeigt? Für welchen Zweck wurde eingewilligt? Welche Version des Textes war zu diesem Zeitpunkt aktiv? Wann wurde die Einwilligung erteilt? Welche Empfänger waren dieser Version zugeordnet? Damit verschiebt sich das Thema vom sichtbaren Formular in die Datenarchitektur. ### Leadgenerierung und Partner-Marketing stehen besonders im Fokus Die Schlussanträge können insbesondere Modelle betreffen, bei denen Kontakte für mehrere Unternehmen generiert oder später zwischen Unternehmen weitergegeben werden. Dazu gehören Lead-Verkauf und Co-Registrierung ebenso wie Gewinnspiele mit mehreren Sponsoren, gemeinsam aufgebaute Newsletter-Verteiler, Affiliate-Modelle und größere Partnerdatenbanken. Gemeinsam ist diesen Modellen häufig, dass sich der Kreis der später werbenden Unternehmen vom ursprünglichen Kontaktpunkt entfernt. Genau dort wird die Frage nach der konkreten Identität des Verantwortlichen technisch relevant. Je dynamischer ein Partnernetzwerk aufgebaut ist, desto schwieriger kann eine pauschale Einwilligungslogik werden. Wenn sich Partner ändern, neue Empfänger hinzukommen oder Kontakte in verschiedenen Kampagnen wiederverwendet werden, muss das System abbilden können, worauf sich die ursprüngliche Einwilligung tatsächlich bezog. ## Die eigentliche Herausforderung liegt in der Consent-Datenstruktur Eine Checkbox erzeugt noch keinen belastbaren Consent-Prozess. Für Marketingverantwortliche ist der sichtbare Teil eines Formulars häufig der Ausgangspunkt. Für [Entwickler] (https://www.sodah.de/webentwicklung-agentur/) ist er nur die Benutzeroberfläche eines deutlich größeren Systems. Dahinter müssen Daten gespeichert, Beziehungen modelliert und Zustände nachvollziehbar gemacht werden. Genau an dieser Stelle wird C-317/25 technisch interessant. Wenn die Identität eines später werbenden Unternehmens bereits zum Zeitpunkt der Einwilligung relevant ist, muss diese Information nicht nur irgendwo auf einer [Website] (https://www.sodah.de/webdesign-agentur/) auftauchen. Sie sollte auch mit dem Einwilligungsvorgang selbst verknüpft sein. Ein System, das lediglich consent = true im CRM speichert, liefert dafür kaum Substanz. ### Welche Informationen ein Consent-System auseinanderhalten sollte Aus den Schlussanträgen ergibt sich für die technische Prüfung bestehender Setups eine Reihe konkreter Fragen. Nicht jede davon ist für jedes Geschäftsmodell gleich relevant. Sie zeigen aber, warum Consent nicht als einzelnes Boolean-Feld behandelt werden sollte. | Datenaspekt | Technische Fragestellung | Typisches Risiko bei vereinfachten Setups | | --- | --- | --- | | **Identität ** | Welcher werbende Verantwortliche war bei Erteilung der Einwilligung bekannt? | Es wird nur eine generische Partnergruppe gespeichert | | **Zweck ** | Für welche Form der Kommunikation wurde eingewilligt? | Verschiedene Marketingzwecke werden in einem Status zusammengefasst | | **Zeitpunkt ** | Wann wurde die Einwilligung abgegeben? | Spätere Änderungen lassen sich nicht sauber zuordnen | | **Empfänger ** | Welche Unternehmen waren von der Einwilligung umfasst? | Aktuelle Partnerlisten werden fälschlich auf ältere Leads angewendet | | **Consent-Version ** | Welche Text- und Formularversion wurde angezeigt? | Nachträglich geänderte Texte überschreiben den historischen Kontext | | **Nachweis ** | Welche Informationen können für einen konkreten Lead rekonstruiert werden? | Im CRM ist nur „Opt-in: Ja“ vorhanden | Diese Trennung ist keine theoretische Datenmodellierungsübung. Sie entscheidet darüber, ob sich später rekonstruieren lässt, was eine Person tatsächlich gesehen und wozu sie eingewilligt hat. ### Warum eine Partnerliste allein technisch nicht genügt Ein häufiges Modell besteht darin, auf einer Website eine Partnerliste zu verlinken und den Consent anschließend zentral zu speichern. Solche Konstruktionen sollte man aus technischer Perspektive genauer untersuchen. Entscheidend ist beispielsweise, welche Liste zum Zeitpunkt der Einwilligung galt. Wenn heute 20 Partner auf einer Seite stehen, bedeutet das nicht automatisch, dass diese 20 Unternehmen auch Bestandteil eines Consent-Vorgangs von vor sechs Monaten waren. Partner kommen hinzu. Andere scheiden aus. Firmierungen ändern sich. Systeme werden migriert. Ohne Versionierung entsteht deshalb schnell ein historisches Problem: Das System kennt den aktuellen Zustand, aber nicht mehr den Zustand, auf dessen Basis die Einwilligung erteilt wurde. Eine saubere technische Architektur sollte Änderungen nicht rückwirkend unsichtbar machen. ## Was Marketing-Teams jetzt in bestehenden Lead-Flows prüfen können Solange das endgültige Urteil nicht vorliegt, wäre es verfrüht, aus den Schlussanträgen eine abschließende Vorgabe für jedes Consent-Modell abzuleiten. Für deutsche Projekte kommt außerdem die konkrete Einordnung nach den unionsrechtlichen DSGVO- und ePrivacy-Anforderungen hinzu. Die rechtliche Bewertung eines konkreten Setups gehört daher in fachjuristische Hände. Technische Vorbereitung ist trotzdem sinnvoll. Gerade bestehende Lead-Strecken lassen sich bereits jetzt daraufhin untersuchen, wie transparent und belastbar ihre Consent-Logik aufgebaut ist. ### Zuerst sollte der vollständige Datenweg sichtbar werden Der sinnvollste Ausgangspunkt ist nicht die Checkbox, sondern die gesamte Strecke eines Leads. Wo entsteht der Datensatz? Welches System speichert ihn zuerst? Welche Informationen zum Consent werden dabei übertragen? Gibt es einen Wechsel zwischen Formularsystem, CRM, Middleware, Marketing-Automation und Partnerplattform? Und welche Informationen gehen bei diesen Übergängen verloren? In der Praxis findet man häufig unterschiedliche Wahrheiten in verschiedenen Systemen. Das Frontend kennt beispielsweise den exakten Consent-Text. Das CRM speichert lediglich einen Zeitstempel. Eine Middleware überträgt ein einfaches Opt-in-Flag. Beim Empfänger landet schließlich nur die Information, dass Marketing erlaubt sei. Damit geht der Kontext schrittweise verloren. Eine technische Prüfung sollte deshalb nicht nur einzelne Anwendungen betrachten, sondern die komplette Verarbeitungskette. ### Danach folgt die Frage nach dem Verantwortlichen Besonders wichtig dürfte im Kontext der Schlussanträge sein, wie der konkrete spätere Werbende im System repräsentiert wird. Ist ein Partner lediglich Teil einer aktuellen Liste? Oder existiert eine explizite Beziehung zwischen Lead, Consent-Vorgang und Empfänger? Der Unterschied ist erheblich. Bei einer expliziten Zuordnung könnte ein Datensatz beispielsweise nachvollziehbar machen, dass Person A am 12.08.2026 einer bestimmten Consent-Version zugestimmt hat und dabei Unternehmen B als möglichen werbenden Empfänger angezeigt bekam. Bei einem generischen Partner-Flag lässt sich diese Aussage möglicherweise nicht treffen. Genau hier zeigt sich, weshalb Datenschutzanforderungen und [Softwarearchitektur] (https://de.wikipedia.org/wiki/Softwarearchitektur) eng miteinander verbunden sein können. ## Consent-Versionierung wird zum zentralen technischen Baustein Webseiten verändern sich ständig. Texte werden optimiert, Partner ausgetauscht und Formulare neu gestaltet. Für Consent-Nachweise ist diese Dynamik problematisch, wenn nur der jeweils aktuelle Zustand gespeichert wird. Ein belastbares System sollte deshalb unterscheiden können, welche Version eines Consent-Texts zu einem konkreten Zeitpunkt angezeigt wurde. Gleiches gilt für damit verbundene Empfänger oder Partner. ### Ein Zeitstempel allein beantwortet zu wenige Fragen Ein Zeitstempel dokumentiert, wann etwas passiert ist. Er dokumentiert nicht automatisch, was passiert ist. Die Information consent _at = 2026-08-12 14:31 sagt noch nichts darüber aus, welchen Text die Person gesehen hat, welche Unternehmen genannt wurden oder welcher Zweck beschrieben war. Technisch belastbarer wäre eine Verknüpfung mit einer definierten Consent-Version. Diese Version könnte wiederum den zu diesem Zeitpunkt verwendeten Text, den Zweck und die zugeordneten Empfänger referenzieren. Dadurch bleibt der historische Zustand reproduzierbar, auch wenn sich die Live-Seite längst verändert hat. ### Änderungen dürfen ältere Einwilligungen nicht semantisch verändern Besonders problematisch sind Systeme, in denen Partner über eine zentrale Tabelle verwaltet werden und jeder Consent lediglich auf diese jeweils aktuelle Tabelle verweist. Wird dort ein neuer Partner hinzugefügt, kann technisch der Eindruck entstehen, dieser Partner sei auch von älteren Einwilligungen umfasst. Die historische Aussage des Datensatzes verändert sich damit nachträglich. Sauberer sind Modelle, bei denen die zu einem bestimmten Consent gehörende Empfängerkonstellation unverändert rekonstruierbar bleibt. Wie genau das umgesetzt wird, hängt von Systemarchitektur und Geschäftsmodell ab. Möglich sind beispielsweise versionierte Beziehungen oder unveränderliche Snapshots des relevanten Zustands. Der zentrale Gedanke bleibt derselbe: Ein späterer Systemzustand darf den ursprünglichen Inhalt einer Einwilligung nicht unsichtbar umdefinieren. ## Warum eine Abmeldemöglichkeit ein Consent-Problem nicht rückwirkend löst Ein weiterer Punkt der Schlussanträge betrifft die Abgrenzung zwischen vorheriger Einwilligung und späterer Abmeldung. Nach Auffassung des Generalanwalts kann eine nachträgliche Opt-out-Möglichkeit die vorher erforderliche Einwilligung nicht ersetzen. Für technische Systeme ist diese Trennung elementar. Opt-in und Opt-out sollten nicht einfach als zwei Zustände desselben simplen Feldes verstanden werden. Es handelt sich um unterschiedliche Ereignisse mit unterschiedlicher zeitlicher Bedeutung. Ein System sollte beispielsweise unterscheiden können, wann eine Einwilligung erteilt wurde und wann sie gegebenenfalls später widerrufen oder eine Abmeldung vorgenommen wurde. Wird nur der aktuelle Endzustand gespeichert, geht die Historie verloren. Gerade in verteilten Marketing-Systemen wird das schnell komplex. Ein Widerruf im Newsletter-System muss möglicherweise Auswirkungen auf CRM, Marketing-Automation und weitere angebundene Systeme haben. Gleichzeitig muss nachvollziehbar bleiben, welche Daten zu welchem Zeitpunkt vorlagen. Das erfordert mehr als einen Abmelde-Link am Ende einer E-Mail. ## Warum das Thema für Agenturen technisch anspruchsvoller ist, als es wirkt Consent-Projekte landen organisatorisch häufig zunächst bei Marketing, Datenschutz oder Legal. Technisch umgesetzt werden sie anschließend als Formularanpassung. Das kann zu kurz greifen. Sobald Lead-Daten über mehrere Systeme, Partner und Kampagnen laufen, wird Consent zu einem Architekturthema. Datenmodelle, [APIs] (https://de.wikipedia.org/wiki/Programmierschnittstelle) , Schnittstellen, Event-Logs und historische Versionierung spielen dann eine mindestens ebenso große Rolle wie der Text an der Checkbox. Bei Sodah betrachten wir solche Fragestellungen deshalb nicht isoliert aus der Perspektive einer Marketingoberfläche. Von unserem zehnköpfigen Team arbeiten fünf Entwickler spezialisiert in Full-Stack-, Frontend- und Backend-Disziplinen. Das verändert die Art, wie wir Consent-Flows analysieren. Wir können nicht nur prüfen, welche Informationen ein Nutzer im Frontend sieht. Ebenso relevant ist, was im Backend gespeichert wird, welche Daten über APIs an andere Systeme übertragen werden und ob sich der ursprüngliche Zustand später noch rekonstruieren lässt. Gerade bei Leadgen-Architekturen liegt das eigentliche Problem häufig zwischen den Systemen. ### Frontend, Backend und CRM müssen dieselbe Geschichte erzählen Ein sauberer Consent-Prozess sollte über die gesamte technische Strecke konsistent sein. Wenn das Frontend fünf konkrete Unternehmen nennt, das Backend jedoch nur partner _marketing = true speichert, geht relevante Information verloren. Wenn das CRM einen Consent-Zeitpunkt kennt, aber keine Version, fehlt historischer Kontext. Wenn ein Partner nur einen Lead-Datensatz ohne Informationen über Herkunft und Consent erhält, kann die Nachvollziehbarkeit zusätzlich erschwert werden. Deshalb lohnt es sich, Consent-Flows wie eine Datenpipeline zu betrachten. Die zentrale Frage lautet: Bleibt die Bedeutung der Einwilligung vom Klick im Frontend bis zum späteren Marketingvorgang erhalten? ## Drei Consent-Muster, die nach den Schlussanträgen überprüft werden sollten Besondere Aufmerksamkeit verdienen Setups, in denen ein pauschaler Partnerbegriff verwendet und anschließend ein dynamischer Empfängerkreis bedient wird. Das erste typische Muster sind Gewinnspiele oder Lead-Formulare, bei denen Nutzer Marketing „von uns und ausgewählten Partnern“ akzeptieren. Hier sollte nachvollziehbar sein, welche Partner die Person tatsächlich erkennen konnte und wie diese Information gespeichert wurde. Das zweite Muster sind zentrale Lead-Pools. Ein Lead wird einmal generiert und später abhängig von Produkt, Region oder Kampagne unterschiedlichen Unternehmen zugeteilt. Technisch stellt sich dann die Frage, ob der spätere Empfänger überhaupt Bestandteil der ursprünglichen Consent-Situation war. Das dritte Muster betrifft Partnerlisten, die nachträglich verändert werden. Wird ein Unternehmen heute ergänzt, sollte das System nicht automatisch so behandeln, als sei dieses Unternehmen bereits bei allen historischen Einwilligungen genannt worden. Diese drei Konstellationen können sehr unterschiedlich ausgestaltet sein. Sie zeigen aber dasselbe Grundproblem: Ein Consent ist kein zeitloses Attribut einer Person. Er bezieht sich auf einen konkreten Vorgang und einen konkreten Informationsstand. ## Was bis zum Urteil sinnvoll vorbereitet werden kann Das Urteil in C-317/25 steht noch aus. Deshalb sollte aus dem Schlussantrag keine endgültige Rechtsregel für jedes Leadgenerierungsmodell abgeleitet werden. Unternehmen müssen dennoch nicht untätig bleiben. Eine technische Bestandsaufnahme schafft Klarheit unabhängig davon, wie der Gerichtshof letztlich entscheidet. Dabei lässt sich feststellen, welche Verantwortlichen und Empfänger tatsächlich in den Systemen abgebildet werden, ob Consent-Texte versioniert sind und ob ein historischer Einwilligungsvorgang vollständig rekonstruiert werden kann. Besonders wertvoll ist die Verbindung aus technischer und juristischer Prüfung. Juristen können beurteilen, welche Anforderungen sich aus der konkreten Rechtslage für das jeweilige Geschäftsmodell ergeben. Entwickler können feststellen, ob die vorhandenen Systeme diese Anforderungen überhaupt abbilden können und an welchen Stellen Daten oder Nachweise verloren gehen. Genau an dieser Schnittstelle wird C-317/25 für Online-Marketing-Agenturen relevant. Der mögliche Handlungsbedarf liegt nicht nur darin, einen Satz neben einer Checkbox umzuschreiben. Er kann bis in Datenbanken, Consent-Schemas, APIs, CRM-Strukturen und Partner-Schnittstellen reichen. ## Der entscheidende Perspektivwechsel: Consent als Datenmodell Die Schlussanträge vom 17.09.2026 lenken die Aufmerksamkeit auf eine Frage, die in vielen Marketing-Systemen lange zu grob behandelt wurde: Was bedeutet eine gespeicherte Einwilligung technisch eigentlich? Ein einfaches Ja oder Nein reicht für komplexe Partnerstrukturen häufig nicht aus. Sobald mehrere Verantwortliche, unterschiedliche Zwecke und veränderliche Empfängerkreise im Spiel sind, braucht ein System mehr Kontext. Identität, Zweck, Zeitpunkt, Empfänger und Consent-Version sollten getrennt gedacht und nachvollziehbar miteinander verbunden werden. Ob der EuGH der Argumentation des Generalanwalts in C-317/25 folgt, bleibt abzuwarten. Die technische Schwachstelle vieler Systeme existiert unabhängig davon: Wer nur speichert, dass irgendeine Einwilligung vorhanden ist, weiß später möglicherweise nicht mehr, wofür und gegenüber wem sie ursprünglich erteilt wurde. Für Unternehmen mit Leadgenerierung, Co-Registrierungen oder Partner-Marketing ist das ein guter Anlass, die eigene Architektur genauer anzusehen. Nicht nur die Checkbox. Den gesamten Datenweg. ## Faqs ### [Hat der EuGH bereits entschieden, dass „ausgewählte Partner“ in einer Einwilligung unzulässig sind?] (#d6df631e550359bfe) Nein. Am 17.09.2026 wurden die Schlussanträge des Generalanwalts Dean Spielmann im Verfahren C-317/25 Groupe Canal+ veröffentlicht. Sie sind für den Europäischen Gerichtshof nicht bindend. Das endgültige Urteil steht noch aus. ### [Muss jeder Marketingpartner nach den Schlussanträgen namentlich bekannt sein?] (#33e4e006eb974862f) Nach der Auffassung des Generalanwalts kann eine Einwilligung in Direktmarketing durch pauschal bezeichnete Partner nur tragen, wenn die betroffene Person die Identität des betreffenden Unternehmens kennt. Wie der Gerichtshof diese Frage letztlich beurteilt und was daraus für ein konkretes Geschäftsmodell folgt, ist noch offen. ### [Reicht ein Abmelde-Link aus, wenn der werbende Partner bei der ursprünglichen Einwilligung nicht bekannt war?] (#35ee3a7164a77b08a) Nach Auffassung des Generalanwalts nein. Eine nachträgliche Möglichkeit zur Abmeldung soll die vorher erforderliche Einwilligung nicht ersetzen. Auch dieser Punkt ist Bestandteil der Schlussanträge und noch keine abschließende Entscheidung des Gerichtshofs. ### [Welche technischen Daten sollte ein Consent-System speichern?] (#e38cdb68b93dcb380) Für die technische Nachvollziehbarkeit sind insbesondere Identität, Zweck, Zeitpunkt, Empfänger und Consent-Version relevant. Entscheidend ist, dass sich später rekonstruieren lässt, welche Informationen einer Person bei Erteilung ihrer Einwilligung tatsächlich vorlagen. Welche Daten im konkreten Fall rechtlich erforderlich sind, sollte fachjuristisch geprüft werden. ### [Welche Unternehmen sollten ihre Consent-Flows jetzt besonders prüfen?] (#d40381db13b594bcf) Besonders relevant ist das Thema für Unternehmen, die Leads verkaufen oder zwischen Partnern verteilen, Gewinnspiele mit Co-Sponsoren durchführen, Co-Registrierungen einsetzen, gemeinsame Newsletter-Leads nutzen oder mit Affiliate- und Partnerdatenbanken arbeiten. Technisch sollte dabei nicht nur der Consent-Text geprüft werden, sondern die vollständige Verarbeitungskette vom Formular über Datenbank und CRM bis zum späteren werbenden Empfänger.