Automatisierte DSGVO- und DSG-Scanner versprechen vieles: Sie analysieren Ihre Website, identifizieren Cookies und Tracker, erstellen Cookie-Banner, generieren Datenschutzerklärungen und prüfen Drittparty-Aufrufe gegen eine Datenbank bekannter Anbieter. CookieBot, Usercentrics, OneTrust, iubenda, Termly, Complianz, CCM19 und Dutzende andere konkurrieren in einem schnell wachsenden Markt. Für IT-Verantwortliche und Marketers wirken diese Tools wie eine bequeme Compliance-Abkürzung – «Scan einmal, Banner aktivieren, fertig.»

Die juristische Realität ist differenzierter. Diese Scanner liefern eine wertvolle technische Inventarisierung, sie sind aber kein Ersatz für eine rechtliche Bewertung. Dieser Artikel zeigt:

• was Scanner technisch messen und was sie systematisch nicht erfassen;
• wie zuverlässig die generierten Cookie-Klassifizierungen sind;
• welche rechtlichen Fragen ein Scanner gar nicht beantworten kann;
• wo Consent Management Platforms (CMP) enden und Beratung beginnt;
• wie Sie Scanner sinnvoll in einen Audit-Prozess einbetten;
• und welche typischen Fehlinterpretationen Schweizer Unternehmen begehen.

Rechtsanker: DSG (Art. 6, 8, 9, 19, 22), DSGVO (Art. 6, 13, 30, 32), ePrivacy-Richtlinie (Art. 5 Abs. 3), EDÖB-Empfehlungen zu Cookies (2023), EDSA-Leitlinien 03/2022 (Dark Patterns), EuGH C-673/17 (Planet49).

Ein moderner Cookie-/Tracker-Scanner besteht aus drei Modulen:

1. Crawler: ruft eine Liste Ihrer URLs auf, oft mit einem Headless-Browser (Chromium), und protokolliert sämtliche HTTP-Requests, DNS-Lookups, geladene Skripte, gesetzte Cookies und Local-Storage-Einträge.
2. Klassifikator: gleicht die gefundenen Domains, Cookie-Namen und Skript-URLs gegen eine kuratierte Datenbank ab (z. B. Google Analytics → Statistik, Meta Pixel → Marketing, Stripe-Cookie → notwendig).
3. Reporter: generiert ein Dashboard, eine Cookie-Tabelle und – bei integrierten CMPs – einen automatisch konfigurierten Cookie-Banner.

Was die Tools gut können:

• Vollständigkeits-Audit von Drittparty-Skripten;
• Erkennung neuer oder unautorisierter Tracker, die ein Marketing-Team ohne Genehmigung eingebunden hat;
• Erkennung von Pre-Consent-Tracking (Skripte, die vor Cookie-Banner-Klick feuern);
• Beobachtung von Domain-Hopping (z. B. wenn ein Pixel über CDN-Redirects neue Domains anspricht).

Diese technische Inventarisierung ist die Voraussetzung jeder rechtlichen Bewertung – ohne Scan tappen Sie im Dunkeln.

Ein Scanner kann technisch sehen, was geladen wird, aber er kann nicht juristisch bewerten, ob das zulässig ist. Konkret unterscheiden Scanner an mehreren Stellen nicht:

• Rechtsgrundlage: Ist ein Cookie «notwendig» im Sinne von Art. 5 Abs. 3 ePrivacy oder bloss «funktional»? Diese Einstufung ist juristisch wertvoll, aber im Scanner-Reporting oft mit «basierend auf Anbieter-Angaben» beschriftet – also nicht autoritativ.
• Kontext: Ein Session-Cookie kann auf einer Login-Seite notwendig sein und auf einer Landing-Page funktional/optional. Das Kontextwissen fehlt dem Scanner.
• Drittland-Bewertung: Der Scanner sieht «Hostname X = US-Anbieter». Er bewertet aber nicht, ob ein DPA, eine DPF-Zertifizierung, SCC oder ein TIA vorliegt.
• Inhaltliche Datenkategorien: Ein Scanner sieht «Formular-Submission an /api/contact», aber nicht, ob das Formular Gesundheitsdaten, Finanzangaben oder Mandatsdetails einsammelt.
• Vertragslandschaft: Auftragsbearbeitungsverträge, Subprozessoren-Listen, Joint-Controller-Vereinbarungen – nichts davon ist sichtbar.
• Datenflüsse jenseits der Website: Backoffice-Bearbeitungen, ERP-Integrationen, E-Mail-Marketing-Stacks, Mitarbeiterüberwachung – alle ausserhalb des Scanner-Radars.

Wer einen Scanner-Report als «DSGVO-Konformität bestätigt» liest, übersieht die 70 %, die der Scanner nicht messen kann.

Die Klassifizierung von Cookies in Kategorien wie «notwendig», «statistik», «marketing» ist der Kernwert kommerzieller Scanner. Diese Klassifikation beruht auf:

• vom Anbieter (z. B. Cookiebot) gepflegten Datenbanken mit tausenden bekannten Cookies;
• Crowdsourcing aus Scans anderer Kunden;
• teilweise manuellen Klassifizierungen durch Anbieter-Analyst:innen.

In der Praxis stimmt das in der Regel für die häufigen Cookies (Google Analytics, Meta Pixel, Cloudflare). Bei Nischen-Cookies, Custom-Cookies aus Ihrem CMS oder Kundenprojekt-spezifischen Trackern liegt die Quote der korrekten Klassifizierung deutlich tiefer. Wir sehen in Audit-Projekten regelmässig:

• Cookies, die als «notwendig» klassifiziert sind, obwohl sie nur für ein optionales Newsletter-Widget gesetzt werden;
• Tracking-Pixel, die mangels Eintrag in der Anbieter-Datenbank gar nicht erkannt oder als «unknown» geführt werden;
• Subdomain-Cookies, die fälschlich als First-Party klassifiziert werden, obwohl sie über CDN-Tricks tatsächlich an Drittparteien gehen.

Praxistipp: Jeder Scanner-Output braucht ein Vier-Augen-Review durch jemanden, der Ihre Webarchitektur kennt. Die «automatische Cookie-Klassifikation» ist eine Hilfe, kein juristisches Gutachten.

Auch der beste Scanner kann fundamentale Fragen nicht beantworten. Hier eine Auswahl typischer Audit-Themen, bei denen reine Tool-Outputs scheitern:

1. Rechtsgrundlage einer Verarbeitung: Ist die Newsletter-Speicherung «berechtigtes Interesse» oder braucht es Einwilligung? Diese Wertung ist juristisch.
2. Verhältnismässigkeit (Art. 6 Abs. 2 DSG): Ist die gesammelte Datenmenge erforderlich oder übermässig?
3. Zweckbindung: Werden CRM-Daten heimlich für ML-Training verwendet?
4. Auskunfts- und Löschpflichten: Sind die Prozesse zur Bearbeitung von Betroffenenanfragen funktionsfähig?
5. Datenpannen-Bereitschaft: Können Sie eine Datenpanne innerhalb von 72 Stunden an den EDÖB melden?
6. Drittland-Compliance: Liegt ein TIA für jeden US- oder Drittlandtransfer vor?
7. Joint-Controller-Themen: Sind die Vereinbarungen mit Meta, Google, LinkedIn als Joint Controller dokumentiert?
8. Beschäftigtendatenschutz: Wie sehen die Regelungen für Mitarbeiterüberwachung, Browser-History, E-Mail-Archive aus?

All diese Themen erfordern eine inhaltliche Auseinandersetzung mit der Bearbeitungslandschaft – Aufgabe einer Datenschutzberatung oder eines internen DSB, nicht eines Tools.

Cookiebot, Usercentrics, OneTrust und CCM19 bieten neben dem Scanner auch eine Consent Management Platform: das Cookie-Banner, das Speichern der Consent-Entscheidung, das Koppeln der Drittparty-Skripte an den Consent-Status (Consent-Loading via Tag Manager) und das Audit-Log.

Diese CMPs sind technisch ausgereift, aber sie machen einen Cookie-Banner nicht automatisch DSGVO-konform. Häufige Fehlkonfigurationen:

• Pre-Selected Boxes: Wenn das Banner Kategorien mit aktiv vorausgewählten Checkboxen anzeigt, ist das nach EuGH Planet49 keine wirksame Einwilligung.
• Unklare «Akzeptieren»-Buttons: «Akzeptieren» darf nicht visuell privilegiert sein gegenüber «Ablehnen» – sonst Dark Pattern (EDSA 03/2022).
• Pre-Consent-Skripte: Wenn Skripte vor dem Banner-Klick feuern, ist die ganze Architektur unwirksam.
• CMP-Cookie selbst: Der Consent-Cookie selbst muss «notwendig» sein – das gelingt nur mit minimalem Inhalt und kurzer Laufzeit.
• Fehlende Audit-Trails: Sie müssen nachweisen, wann eine bestimmte Person eingewilligt hat. Ohne Speicherung des Consent-Zeitstempels und der Banner-Version brechen Sie diese Beweispflicht.

Ein CMP-Roll-out gehört in eine Beratungs-Begleitung – mit klarer Konfigurationsvorgabe, Quartals-Review und einer Eskalations-Logik, wenn neue Skripte ohne Konfiguration auftauchen.

Wir setzen Scanner regelmässig in unseren Audits ein – aber als erste Stufe eines mehrstufigen Prozesses:

1. Scan: Vollständige Crawls aller Property-URLs (öffentlich + Login-Bereiche, sofern technisch möglich).
2. Triage: Klassifikation der gefundenen Cookies und Skripte – manuell überprüft, nicht blind übernommen.
3. Vertragsabgleich: Jeder gefundene Drittanbieter wird gegen die DPA-Sammlung abgeglichen. Fehlende DPAs werden eingefordert.
4. Banner-Konfiguration: CMP-Banner wird konfiguriert, Tag-Manager-Skripte werden an Consent-Kategorien gekoppelt, Tests in Audit-Mode.
5. Rechtsbewertung: Datenschutzerklärung wird gegen den realen Scanner-Output verglichen und ergänzt.
6. Schulung: Marketing- und Web-Teams werden auf den neuen Prozess geschult.
7. Periodischer Re-Scan: mindestens quartalsweise, bei Kampagnen-Roll-outs ad hoc.

Diese Sequenz nutzt den Tool-Wert maximal und kompensiert seine Schwächen durch menschliches Urteil.

SIDD führt automatisierte Scans mit etablierten Tools durch und kombiniert sie mit rechtlicher Bewertung – das liefert Ihnen eine vollständige Datenschutz-Diagnose statt eines Tool-Outputs. Unsere Leistungen:

• Cookie-/Tracker-Audit mit professionellem Scanner;
• Konfiguration und Audit von CMPs (Cookiebot, Usercentrics, OneTrust, CCM19);
• DPIA für Hochrisiko-Tracking-Setups;
• Mandate als externer Datenschutzberater oder externer CISO/ISB;
• DSGVO-DPO und EU-Vertretung (DSGVO-DPO, EU-Vertreter);
• Penetrationstests und Schwachstellenscans als Ergänzung zur Datenschutz-Inventarisierung (Penetrationstest, Schwachstellenscan);
• ISO/IEC 27001-Begleitung als Rahmen für laufende Compliance (ISO 27001 / ISMS).

Schreiben Sie uns über das Kontaktformular oder fordern Sie ein Angebot über das Offertformular an. Einen kostenfreien Cookie-Scan Ihrer Hauptdomain liefern wir innerhalb von zwei Arbeitstagen.