Die meisten KMU mit einem Cookie-Banner glauben, sie seien mit der Cookie-Compliance fertig. Sind sie nicht. Der Banner ist die Hälfte des Bildes — der Einwilligungsmechanismus. Die andere Hälfte — das Inventar dessen, wofür der Banner tatsächlich Einwilligung einholt — ist dort, wo Audits der Aufsichtsbehörden immer wieder Lücken finden. Eine Sweep-Aktion 2024 durch die niederländische Autoriteit Persoonsgegevens, die französische CNIL und die italienische Garante fand auf Hunderten von Websites dasselbe Muster: Banner vorhanden, aber kein zugrundeliegendes Verzeichnis darüber, welche Tracker feuern, wer sie setzt, welche Daten sie vom Gerät lesen und ob sie tatsächlich korrekt klassifiziert sind.

Ein Cookie- und Tracker-Inventar ist die Dokumentationsschicht unter Ihrem CMP. Es ist das, wonach ein Auditor fragt, wenn die Banner-Prüfung bestanden ist. Dieser Leitfaden erklärt, was ein Inventar enthalten sollte, warum es getrennt von Ihrer DSGVO-Datenkarte lebt, was ePrivacy Artikel 5(3) tatsächlich verlangt, und wie man das Inventar aktuell hält, ohne die Arbeit doppelt zu machen.

ePrivacy Art. 5(3): die Regel, die die meisten KMU falsch verstehen

ePrivacy-Richtlinie 2002/58/EG Artikel 5(3) — manchmal das "Cookie-Gesetz" genannt, präziser die Endgeräte-Regel — verlangt vorherige Einwilligung, bevor Informationen auf dem Gerät eines Nutzers gespeichert oder von ihm gelesen werden. Zwei Dinge machen sie schwieriger, als sie aussieht:

Sie gilt auch dann, wenn die gespeicherten Daten keine personenbezogenen Daten sind. Ein Zähler-Cookie, das "dies ist der dritte Besuch des Nutzers" festhält, fällt unter Art. 5(3), unabhängig davon, ob diese Zählung mit einer identifizierten Person verknüpfbar ist. ePrivacy und DSGVO sind getrennte Rechtsrahmen; DSGVO-Compliance erfüllt die ePrivacy-Compliance nicht.

Sie gilt für alles, was auf dem Gerät gespeichert ist, nicht nur für Cookies. localStorage, sessionStorage, IndexedDB-Einträge, Pixel-Tags, die bestehende Identifier lesen, SDK-Beacons, Fingerprinting, das ein stabiles Signal aus dem Browser ableitet, Service-Worker-Caches — all das sind "Informationen, die im Endgerät eines Teilnehmers oder Nutzers gespeichert sind". Wenn Ihr Inventar nur Cookies nach Namen verfolgt, übersehen Sie das meiste, worauf Aufsichtsbehörden heute achten.

Die Ausnahme ist eng: Ein Tracker ist ohne Einwilligung nur dann zulässig, wenn er "unbedingt erforderlich" ist, um den vom Nutzer ausdrücklich angeforderten Dienst zu erbringen. Der EuGH und nationale Aufsichtsbehörden haben dies streng ausgelegt. Sitzungs-Cookies für einen eingeloggten Checkout-Flow erfüllen das. Analytics, die "uns helfen, den Dienst zu verbessern", nicht. Marketing-Pixel niemals.

Was zu inventarisieren ist

Ein Cookie- und Tracker-Inventar ist breiter als die Cookie-Liste, die Ihr CMP-Scanner zeigt. Sechs Kategorien von Speicher- und Signalerfassungsmechanismen zählen:

  • Cookies — first-party und third-party, Sitzung und persistent
  • localStorage und sessionStorage — Browser-Schlüssel-Wert-Speicher, die für first-party-Origins länger als Cookies bestehen
  • Pixel-Tags — 1×1-Bildanfragen, die Identifier in der URL transportieren oder bestehende Cookies auf der Zieldomain lesen
  • SDKs — JavaScript-Bibliotheken von Dritten (Analytics, Chat-Widgets, Fehlermonitore, Werbenetzwerke), die oft eigene Cookies setzen und aus localStorage lesen oder schreiben und Beacons feuern
  • Fingerprinting — Ableitung eines stabilen Identifiers aus Geräteeigenschaften (Canvas, WebGL, Schriftartenliste, Audio-Kontext). Selbst ohne Speichern liest Fingerprinting vom Gerät — Artikel 5(3) gilt.
  • Beacons — navigator.sendBeacon()-Aufrufe, die beim Verlassen der Seite feuern, üblich in Analytics- und Fehlerberichts-SDKs

Für jeden Eintrag braucht der prüfbare Datensatz mindestens: Name, Anbieter (das Unternehmen dahinter), Domain, auf die er gesetzt wird, Typ, Zweck, Dauer, die ePrivacy-Grundlage (Einwilligung oder unbedingt erforderlich) und der Einwilligungsmechanismus, der ihn steuert (Ihr CMP, oder "kein CMP — unbedingt erforderlich"). Weniger als das, und Sie können die Frage der Aufsichtsbehörde "Zeigen Sie mir die Rechtsgrundlage für diesen spezifischen Tracker auf diesem spezifischen Dienst" nicht beantworten.

Inventar ≠ CMP — sie haben verschiedene Aufgaben

Ein CMP (Consent Management Platform) — Cookiebot, OneTrust, Didomi, Iubenda, Usercentrics, Cookie Information, Axeptio — tut drei Dinge:

  1. Den Banner anzeigen mit Kategorie-Schaltern
  2. Einzelne Einwilligungserklärungen speichern mit Zeitstempel und der Version der geltenden Richtlinie
  3. Tracker blockieren, bis eingewilligt wird (die technische Durchsetzungsschicht)

Ein CMP ist operativ. Es läuft bei jedem Seitenaufruf. Seine Aufgabe ist es, Einwilligung in Echtzeit zu verwalten.

Ein Inventar tut etwas anderes: Es ist die Dokumentation dessen, wofür das CMP Einwilligung einholt. Es beantwortet Fragen, die ein CMP nicht kann:

  • Warum ist dieser Tracker als Analytics statt als Marketing klassifiziert?
  • Wer in der Organisation hat das Hinzufügen des LinkedIn Insight Tags genehmigt, und an welchem Datum?
  • Welche Daten liest oder schreibt dieses SDK tatsächlich — über das hinaus, was die Anbieterdokumentation behauptet?
  • Wenn eine Aufsichtsbehörde fragt "Belegen Sie die Erforderlichkeit dieses Analytics-Cookies unter Ihrer berechtigten-Interessen-Bewertung", was ist die Antwort?
  • Wenn sich die Cookie-Liste ändert — ein neues SDK hinzugefügt, ein Anbieter gewechselt — erscheint die Änderung in Ihrem Audit-Log?

Ein CMP-Scan sagt Ihnen, welche Cookies heute feuern. Ein Inventar sagt Ihnen, welche feuern sollten, warum jedes auf der Liste steht und was sich in den letzten sechs Monaten geändert hat. Beides ist komplementär; keines ersetzt das andere.

Genau deshalb verlangen Aufsichtsbehörden zunehmend beides. Ein CMP ohne Inventar ist ein Banner ohne Begründung. Ein Inventar ohne CMP ist ein Verzeichnis ohne Durchsetzungsmechanismus. KMU, die beides vermischen — meist indem sie den Auto-Scan des CMP als Inventar behandeln —, stellen während eines Audits fest, dass der CMP-Scanner die SDKs übersehen hat, die nur nach einem Klick feuern, das Analytics-Beacon, das nur bei Fehlern auslöst, und den localStorage-Eintrag, den das Chat-Widget schreibt, nachdem der Nutzer eine Nachricht eingegeben hat.

Die vier Tracker-Kategorien

Jedes ernstzunehmende CMP und jedes Aufsichtsbehörden-Leitfadendokument klassifiziert Tracker in dieselben vier Kübel. Die Klassifikation bestimmt sowohl den Einwilligungsfluss als auch die Risikohaltung des Inventars.

Unbedingt erforderlich. Tracker, ohne die der ausdrücklich angeforderte Dienst nicht funktionieren kann. Sitzungs-Identifier für eine authentifizierte Sitzung, ein CSRF-Token-Cookie, das Cookie, das Ihre Sprachpräferenz für den aktuellen Besuch speichert, das Load-Balancer-Affinitäts-Cookie. Diese sind von der Einwilligungspflicht ausgenommen. Seien Sie konservativ — wenn eine Aufsichtsbehörde plausibel sagen könnte "der Dienst würde auch ohne dies funktionieren", ist er nicht unbedingt erforderlich.

Funktional. Tracker, die das Nutzererlebnis verbessern, aber nicht essenziell sind — UI-Präferenzen über Sitzungen hinweg merken, eine Liste kürzlich angesehener Elemente, Sprachpräferenz über Besuche hinweg. Diese erfordern Einwilligung. Die Grenze zwischen unbedingt erforderlich und funktional ist eng und oft umstritten; Ihre Begründung pro Tracker zu dokumentieren ist das, was ein Audit überlebt.

Analytics. Tracker, die messen, wie der Dienst genutzt wird — Seitenaufrufe, Sitzungsdauer, Konversionspfade, Fehlerquoten. Der EuGH und die meisten nationalen Aufsichtsbehörden haben entschieden, dass selbst first-party-Analytics Einwilligung benötigen, es sei denn, die Daten sind wirklich aggregiert und werden nur vom Verantwortlichen zur Messung des eigenen Dienstes verwendet. Selbstgehostetes Matomo mit IP-Anonymisierung und ohne Cross-Site-Tracking kommt einer einwilligungsfreien Analytics-Konfiguration am nächsten; Google Analytics 4 nicht.

Marketing. Retargeting-Pixel, Werbenetzwerk-Identifier, Konversions-Tags, Social-Media-Tracking-Pixel. Erfordern immer Einwilligung. Fast immer third-party. Die Kategorie, die die meiste Durchsetzungsaufmerksamkeit auf sich zieht.

Das Inventar erfasst die Kategorie für jeden Tracker, die ePrivacy-Grundlage (Einwilligung oder erforderlich) und — entscheidend — die Begründung. Die Kategorie bestimmt den Einwilligungsfluss; die Begründung bestimmt, ob die Klassifikation unter Inspektion standhält.

ePrivacy-Grundlage vs DSGVO Art. 6 Rechtsgrundlage: nicht vermischen

Dies ist der häufigste Fehler in der KMU-Cookie-Dokumentation. ePrivacy Art. 5(3) und DSGVO Art. 6 sind getrennte Rechtsrahmen, die getrennte Fragen stellen:

  • ePrivacy Art. 5(3) fragt: Darf dieser Tracker überhaupt auf dem Gerät platziert werden? Die Antwort ist Einwilligung oder unbedingt erforderlich.
  • DSGVO Art. 6 fragt: Wenn aus dieser Verarbeitung personenbezogene Daten resultieren, was ist die Rechtsgrundlage für die Verarbeitung? Die Antwort ist eine der sechs Art. 6(1)-Grundlagen — Einwilligung, Vertrag, rechtliche Verpflichtung, lebenswichtige Interessen, öffentliche Aufgabe, berechtigte Interessen.

Ein first-party-Analytics-Cookie, das unter ePrivacy Nutzereinwilligung erfordert, kann nach erteilter Einwilligung die resultierenden Daten unter DSGVO Art. 6(1)(a) (Einwilligung) verarbeiten — oder unter Art. 6(1)(f) (berechtigte Interessen), sobald für das Platzieren des Cookies wirksam Einwilligung eingeholt wurde. In manchen Auslegungen beruhen sowohl Platzierung als auch Verarbeitung auf der Einwilligung; in anderen ist die Platzierung einwilligungsgesteuert und die Verarbeitung beruht auf berechtigten Interessen. Die Leitlinien der nationalen Aufsichtsbehörden variieren. Universell ist: Die beiden Grundlagen werden getrennt erfasst. Ein Inventar mit nur einem "Rechtsgrundlage"-Feld pro Tracker vermischt beide und liefert ein Verzeichnis, das keine Aufsichtsbehörde akzeptieren wird.

Ein ernstzunehmendes Inventar hat ein legal_basis_eprivacy-Feld bei jedem Tracker (Einwilligung / erforderlich) und ein separates legal_basis-Feld bei den personenbezogenen Datenkategorien, die der Tracker erzeugt (die DSGVO Art. 6-Grundlage). Sie liegen in verschiedenen Tabellen im Datenmodell, weil sie verschiedene Fragen beantworten.

Was sich unter dem Digital-Omnibus-Vorschlag ändert

Im November 2025 veröffentlichte die Europäische Kommission den Digital-Omnibus-Vorschlag COM(2025) 837 final. Er ist noch nicht angenommen — und es ist nicht sicher, dass er in seiner aktuellen Form durchgehen wird — aber die Richtung ist von Bedeutung, weil er die ePrivacy-Durchsetzung umgestalten würde.

Der Vorschlag würde die Cookie/Endgeräte-Regel aus ePrivacy Art. 5(3) in einen neuen DSGVO Art. 88a für natürliche-Personen-Abonnenten verschieben. Sechs benannte Zwecke wären ohne Einwilligung rechtmäßig: die Durchführung einer elektronischen Kommunikation, die Bereitstellung eines ausdrücklich angeforderten Dienstes, aggregierte Reichweitenmessung für die eigene Nutzung des Verantwortlichen, die Aufrechterhaltung der Dienstsicherheit und die Unterstützung von Diensten der Informationsgesellschaft, die der Nutzer angefordert hat. Die Ablehnung der Einwilligung müsste mit einem Klick erfolgen, und ein abgewiesener Verantwortlicher müsste mindestens sechs Monate warten, bevor er erneut fragt.

Ein begleitender Art. 88b würde Verantwortliche verpflichten, maschinenlesbare Einwilligungssignale zu respektieren — Global Privacy Control, einen eventuellen ESO-Standard —, sobald technische Spezifikationen veröffentlicht werden, und Nicht-KMU-Browser dazu verpflichten, sie bereitzustellen.

Für KMU, die heute ein Tracker-Inventar pflegen, ändert sich operativ nichts. Die aktuelle Unterscheidung Einwilligung/erforderlich nach ePrivacy Art. 5(3) bleibt unter der geltenden Richtlinie korrekt. Aber zwei zukunftsorientierte Hinweise folgen:

  • Die künftig wichtige Taxonomie ist Zweck, nicht Cookie-Typ. Ein Inventar, das den Zweck jedes Trackers erfasst (der vom Nutzer ausdrücklich angeforderte Dienst, Reichweitenmessung für eigene Nutzung usw.), portiert sauber in das Art. 88a-Regime, falls es kommt. Ein Inventar, das nur "Analytics — Einwilligung erforderlich" erfasst, muss neu klassifiziert werden.
  • Unterstützung für maschinenlesbare Einwilligungssignale wird ein CMP-Feature, kein Inventar-Feature — aber das Inventar muss erfassen, welches CMP im Einsatz ist, damit der Auditor die Art. 88b-Compliance verifizieren kann, sobald der Standard veröffentlicht ist.

Der Vorschlag ist datiert und stellt ausdrücklich künftiges Recht in Aussicht. Bauen Sie für das geltende Recht; entwerfen Sie für die vorgeschlagene Richtung.

Wie Readmodel® Cookie- und Tracker-Inventare handhabt

Readmodel® führt das Cookie- und Tracker-Inventar auf Service-Ebene — unter demselben Datenmodell, das Ihre Dienste, Datenelemente und Übermittlungen speichert —, sodass ein Tracker immer mit dem Dienst, der ihn setzt, den Daten, die er liest oder erzeugt, und (wo personenbezogene Daten resultieren) dem DSGVO-Verarbeitungsverzeichnis, das ihn nutzt, verknüpft ist.

Jeder Tracker-Eintrag erfasst: Name, Anbieter, Domain, Typ (Cookie / localStorage / Pixel / Fingerprint / SDK / Beacon / sonstige), Kategorie (unbedingt_erforderlich / funktional / analytics / marketing), die legal_basis_eprivacy (Einwilligung / erforderlich) — bewusst so benannt, um eine Verwechslung mit der DSGVO Art. 6 legal_basis bei Datenelementen zu vermeiden — Zweck, Dauer, die Einwilligungsmechanismus-Referenz (Ihr CMP) und eine optionale URL zur Anbieterdokumentation.

Eine geseede Bibliothek von 167 verbreiteten Trackern — mit EU-CMPs (Cookiebot, Didomi, Iubenda, Usercentrics, Axeptio), Analytics (GA4, Matomo, Piwik PRO, Hotjar, Microsoft Clarity), Werbenetzwerken (Meta, LinkedIn, TikTok, Criteo, RTB House, Google Ads), Chat-Widgets (Intercom, Crisp, LiveChat, Tidio), Payment-SDKs (Stripe, Adyen, Mollie, Klarna), Identity (Auth0, Keycloak, NextAuth.js), Commerce (Shopify, WooCommerce, Magento), Error/APM (Sentry, Datadog, New Relic) und CMS-Mustern (WordPress, Drupal, TYPO3) — deckt die meisten KMU-Stacks in wenigen Klicks ab. Eigene Einträge folgen demselben Schema.

Das Risikoregister markiert automatisch jeden nicht-essenziellen Tracker (category != 'strictly_necessary' und legal_basis_eprivacy = 'consent'), für den weder auf Zeilenebene ein Einwilligungsmechanismus dokumentiert ist noch projektweit ein CMP gesetzt ist. Beide Ebenen lösen die Markierung — KMU, die ein einziges CMP auf Projektebene dokumentieren (Cookiebot für die gesamte Site etwa), müssen das nicht in jeder Tracker-Zeile wiederholen.

Ein eingebauter Cookie-Richtlinien-Generator erzeugt ein druckfertiges und Kopieren-als-Markdown / Kopieren-als-HTML-Cookie-Richtliniendokument, das Tracker nach Kategorie gruppiert und Beschreibungen sowie Dauern enthält. Es ist das Dokument, das Sie auf Ihrer Website veröffentlichen, um die Transparenzanforderung zu erfüllen, die neben der Einwilligungsanforderung steht.

Entscheidend: Readmodel® ersetzt Ihr CMP nicht. Es generiert keine Einwilligungsbanner, speichert keine einzelnen Einwilligungserklärungen, parsed keine TCF-Strings und scannt Ihre Site nicht automatisch. Es ist die Inventarschicht unter dem CMP, das Sie betreiben. Für das größere Bild, wie Readmodel® zum Rest Ihres Privacy-Stacks passt, siehe den Vergleich von DSGVO-Compliance-Tools.

Cookie- und Tracker-Inventar: häufig gestellte Fragen

Ist ein Cookie-Inventar gesetzlich vorgeschrieben? Das Cookie-Inventar selbst wird in keinem Gesetz benannt, aber die Pflicht, die es erfüllt, schon. ePrivacy Art. 5(3) verlangt Einwilligung vor dem Platzieren oder Lesen von Informationen auf dem Gerät eines Nutzers, außer für unbedingt erforderliche Tracker. Nach dem DSGVO-Rechenschaftsprinzip (Art. 5(2)) muss der Verantwortliche die Compliance nachweisen können — was in der Praxis ein dokumentiertes Inventar jedes Trackers, seiner Kategorie, seines Zwecks und der Rechtsgrundlage bedeutet. Aufsichtsbehörden fordern das Inventar bei Audits zunehmend an.

Liefert mir mein CMP-Scanner nicht automatisch das Inventar? Ein CMP-Scanner liefert eine Momentaufnahme von Cookies, die während des Scans gefeuert haben. Er übersieht Tracker, die bedingt feuern (nach einem Klick, bei Fehlern, in authentifizierten Bereichen, in die der Scanner nicht eingeloggt war), er übersieht in den meisten Plänen Nicht-Cookie-Speicher (localStorage, Fingerprinting, Beacons) und er erfasst nicht die Begründung hinter Ihren Kategorienklassifikationen. Verwenden Sie den Scanner als Eingabe für das Inventar; behandeln Sie die Scanner-Ausgabe nicht als Inventar.

Was ist der Unterschied zwischen unbedingt erforderlich und funktional? Unbedingt erforderliche Tracker sind solche, ohne die der vom Nutzer ausdrücklich angeforderte Dienst nicht funktionieren kann — Sitzungs-Identifier für einen Checkout-Flow, CSRF-Tokens, Load-Balancer-Affinität. Funktionale Tracker verbessern das Nutzererlebnis, sind aber nicht essenziell — UI-Präferenzen über Sitzungen hinweg merken, kürzlich angesehene Listen. Unbedingt erforderlich ist von der Einwilligung ausgenommen; funktional erfordert Einwilligung. Nationale Aufsichtsbehörden lesen die Ausnahme streng; im Zweifel als funktional klassifizieren und Einwilligung verlangen.

Muss ich third-party-Tracker inventarisieren? Ja. Alles, was Informationen auf dem Gerät des Nutzers platziert oder liest, zählt, unabhängig davon, wer es betreibt. Eingebettete YouTube-Videos, die DoubleClick-Cookies setzen, Stripe Elements, die Betrugspräventions-Cookies setzen, der Google-Maps-Embed, der NID setzt — all dies muss im Inventar stehen, mit dokumentiertem Drittanbieter.

Muss meine Fingerprinting-Bibliothek im Inventar stehen? Ja. Fingerprinting liest Eigenschaften vom Gerät des Nutzers, um einen stabilen Identifier abzuleiten — der EuGH und der EDPB haben bestätigt, dass dies unter Art. 5(3) fällt, auch wenn nichts gespeichert wird. Dokumentieren Sie die Bibliothek, ihren Zweck und den Einwilligungsmechanismus, der sie steuert. Das meiste Fingerprinting in der Produktion ist für Betrugsprävention (Sift, Forter, DataDome) und kann als unbedingt erforderlich für den Sicherheitszweck qualifizieren; dokumentieren Sie die Begründung.

Wie verhält sich das zur EU-KI-Verordnung? Wenn Sie KI auf den Daten einsetzen, die Ihre Tracker sammeln — Clickstream-gespeiste Empfehlungssysteme, verhaltensbezogene Werbe-Targeting-Modelle, Betrugserkennung-ML —, wird die KI-Verarbeitungsschicht von der EU-KI-Verordnung beherrscht, während die zugrundeliegende Tracker-Platzierung von ePrivacy beherrscht wird. Beide müssen separat dokumentiert werden. Siehe den KI-Governance-Leitfaden für die KI-Schicht.

Was passiert, wenn der Digital-Omnibus-Vorschlag angenommen wird? Die Cookie/Endgeräte-Regel verschiebt sich von ePrivacy Art. 5(3) in einen neuen DSGVO Art. 88a für natürliche-Personen-Abonnenten, mit sechs benannten Zwecken, die ohne Einwilligung rechtmäßig sind. Ein Inventar, das um Zweck herum aufgebaut ist (statt um Cookie-Namen), portiert sauber. Der Vorschlag ist noch nicht angenommen; bauen Sie für das geltende Recht.

Wie oft sollte ich das Inventar aktualisieren? Mindestens vierteljährlich, plus bei jeder Änderung: ein neues SDK auf der Site, ein Anbieterwechsel (Cookiebot → OneTrust), ein neues Feature, das bedingte Tracker einführt, ein CMP-Regelupdate. Das Inventar ist ein lebendes Dokument; das Audit-Log bei jedem Tracker beweist, dass Sie es pflegen.

Beginnen Sie, Ihre Tracker zu dokumentieren

Cookie- und Tracker-Inventare sind undankbar. Sie sind auch der Ort, an den sich Audits der Aufsichtsbehörden bewegen, da die reine Banner-Durchsetzung an ihre Decke stößt. Die Arbeit ist für ein KMU wirklich beherrschbar, sobald Sie die Struktur haben: ein Tracker pro Zeile, eine Kategorie, eine Grundlage, ein Zweck, eine CMP-Referenz und eine Dauer.

Erstellen Sie ein kostenloses Readmodel®-Konto, ziehen Sie die geseede Bibliothek herein, und Sie haben in unter einer Stunde ein audit-fertiges Inventar. Die Tracker-Seite, der Cookie-Richtlinien-Generator, die Risikoregister-Markierung für fehlende Einwilligung und die Aufnahme in das Verarbeitungsverzeichnis sind in jedem Plan verfügbar, einschließlich des kostenlosen Explore-Plans.