Die meisten GDPR-Audits für Websites beginnen mit einem Fragebogen und enden mit einer Bewertung. Das Ergebnis mag offiziell aussehen, hinterlässt den Entwicklern jedoch oft die gleiche Frage: Was genau sollte im Code geändert werden?
Ein technisches Audit hat eine engere und nützlichere Aufgabe. Es dokumentiert, was die Website tatsächlich in einem Browser tut, unter definierten Einwilligungszuständen, und vergleicht dieses Verhalten mit den eigenen Angaben der Website. Es kann eine Google-Anfrage finden, die vor der Einwilligung ausgelöst wurde, ein vergessenes Tracking-Pixel, eine externe Schriftart, ein Formular, das mehr Felder sendet als erwartet, oder einen Ablehnen-Button, der die Benutzeroberfläche ändert, aber nicht das Netzwerk.
Es kann die gesamte Organisation nicht als GDPR-konform zertifizieren. Ein Browser kennt die rechtliche Grundlage des Unternehmens, Verträge, Offline-Prozesse, den Zugriff des Personals oder ob ein angegebener Geschäftszweck legitim ist.
Das richtige Ergebnis ist ein Nachweisbericht, nicht ein magischer Prozentsatz.
Zusammenfassung
- Ein Entwickler kann Netzwerkrequests, Speicher, Skripte, Einbettungen, Formularverhalten, Einwilligungszustände, Sicherheitsheader und Richtlinien-/Laufzeitabweichungen testen.
- Jeder Test muss von einem sauberen Browserprofil ausgehen und die Seite, die Uhrzeit, die Region, den Browser und den Einwilligungszustand aufzeichnen.
- Die Ergebnisse sollten beobachtete Nachweise, technische Interpretationen und Fragen, die eine rechtliche oder organisatorische Überprüfung erfordern, trennen.
- Ablehnen, selektive Einwilligung, Alle akzeptieren, Widerruf und ein wiederkehrender Besuch sind unterschiedliche Anwendungszustände und sollten separat getestet werden.
- Automatisiertes Scannen kann wiederholbares Browserverhalten abdecken. Es kann jedoch keine rechtliche Grundlage nachweisen, jeden Vertrag validieren oder die GDPR-Konformität zertifizieren.
Den Umfang definieren, bevor Sie DevTools öffnen
Ein reproduzierbares Audit beginnt mit einer Seitenliste und einer Zustandsmatrix, nicht mit zufälligem Klicken. Die Startseite allein nutzt selten Kontaktformulare, Videoeinbettungen, Checkout-Tools, Kontobereiche oder Marketing-Landingpages aus.
Wählen Sie repräsentative Seitentypen aus:
- Startseite;
- Kontakt- oder Lead-Formular;
- Artikel mit eingebetteten Medien;
- Service- oder Kampagnen-Landingpage;
- Such-, Anmelde-, Checkout- oder Kontoseite, wo zutreffend;
- eine Seite pro Sprache oder regionaler Version;
- jede Seite, die einen anderen Tag-Manager-Container oder eine Integration lädt.
Für jede Seite planen Sie die gleichen Einwilligungszustände:
| Zustand | Was er beantwortet |
|---|---|
| Frischer Besuch | Was lädt, bevor der Besucher entscheidet? |
| Ablehnen optional | Ändert sich das Verhalten bei Ablehnung von Requests und Speicher? |
| Selektive Einwilligung | Sind Zwecke und Anbieter tatsächlich getrennt? |
| Alle akzeptieren | Welche optionalen Dienste werden aktiv? |
| Widerruf | Kann der Besucher die Entscheidung effektiv rückgängig machen? |
| Wiederkehrender Besuch | Wird die gespeicherte Wahl respektiert, ohne dass es zu einem frühen Ladeblitz kommt? |
Dokumentieren Sie die Testregion, da das Verhalten von Anbietern und Einwilligungsoberflächen je nach Region variieren kann. Dokumentieren Sie den Browser und den Zeitstempel, da sich Skripte von Drittanbietern ändern.
Erfassen Sie das Netzwerk vor der Einwilligung
Die erste Seitenladung ist der wertvollste Test, da optionale Dienste oft initialisiert werden, bevor das Einwilligungswerkzeug dies tut. Verwenden Sie einen sauberen Browserkontext, bewahren Sie das Netzwerkprotokoll, deaktivieren Sie den Cache und interagieren Sie nicht mit der Seite, bis das Laden abgeschlossen ist.
Für jede Anfrage bewahren Sie:
- vollständige Ziel-Domain und -Pfad, mit anonymisierten Geheimnissen und persönlichen Werten;
- Initiator oder Aufrufkette;
- Ressourcentyp;
- Zeitstempel relativ zur Navigation;
- Anfragemethode;
- relevante Anfrage- und Antwortheader;
- ob die Domain Erstanbieter oder Drittanbieter ist;
- welches Seitenkomponente sie zu triggern scheint.
Klassifizieren Sie eine Anfrage nicht nur nach ihrem Domainnamen. Ein CDN kann auf einer Website ein notwendiges Stylesheet und auf einer anderen einen Tracking-Code bereitstellen. Der Nachweis sollte die Anfrage mit ihrem beobachteten Zweck und Initiator verbinden.
Nützliche Kategorien umfassen Analytik, Werbung, Sitzungswiedergabe, Fehlerberichterstattung, Chat, Karten, Video, Schriftarten, A/B-Tests, Zahlung, Anti-Spam, CDN, Tag-Management und unbekannt.
Unbekannt ist ein gültiger Befund. Raten ist es nicht.
Überprüfen Sie den Browserspeicher, nicht nur Cookies
Eine Cookie-Liste übersieht localStorage, sessionStorage, IndexedDB, Caches und über URLs übermittelte Identifikatoren. Dokumentieren Sie den Speicher vor der Interaktion und nach jeder Einwilligungsaktion.
Für jedes Element erfassen Sie:
- Name oder Schlüssel;
- Ursprung;
- Erstellungszustand;
- Ablaufdatum, wo sichtbar;
- Wertform nach Anonymisierung;
- wahrscheinlicher Eigentümer und Initiator;
- beobachtete Änderung zwischen den Einwilligungszuständen.
Vermeiden Sie es, lebende Identifikatoren in den Bericht zu kopieren. Hashen oder anonymisieren Sie Werte, während Sie genügend Struktur beibehalten, um zu zeigen, dass dieselbe Identifikation über Seitenladungen hinweg besteht.
Nach § 25 TDDDG ist die technische Frage breiter gefasst als nur die Existenz eines Browser-Cookies. Die Speicherung von Informationen auf oder der Zugriff auf Informationen von Endgeräten kann andere Mechanismen umfassen. Die rechtliche Bewertung einer Ausnahme erfordert weiterhin Kontext, aber der Entwickler kann das Verhalten präzise dokumentieren.
Beweisen Sie, dass die Einwilligung die Ausführung steuert
Eine Einwilligungsoberfläche funktioniert nur, wenn ihr Zustand ändert, was die Anwendung lädt oder darauf zugreift. Testen Sie das Verhalten, nicht die Beschriftungen der Schaltflächen.
Vergleichen Sie die Anfragen- und Speicher-Sets nach:
- keiner Wahl;
- Ablehnen aller optionalen Zwecke;
- nur Analytik-Einwilligung;
- einer anderen verfügbaren Kategorie;
- Alle akzeptieren;
- Widerruf;
- Neuladen und eine neue Seitennavigation.
Kennzeichnen Sie beobachtbare Abweichungen:
- dieselbe optionale Anfrage erscheint vor der Einwilligung und nach dem Akzeptieren;
- Ablehnen und Akzeptieren erzeugen identisches Verhalten;
- eine deaktivierte Kategorie startet dennoch ihren Anbieter;
- der Widerruf aktualisiert das Banner, aber zukünftige Anfragen gehen weiter;
- optionaler Code lädt kurz, bevor die gespeicherte Ablehnungspräferenz angewendet wird;
- der Einwilligungsnachweis enthält eine Wahl, aber die Anwendung liest sie nie;
- Tags sind auf der Startseite blockiert, feuern jedoch auf einer anderen Vorlage.
Die Cookie-Banner-Richtlinien der deutschen Aufsichtsbehörden besagen, dass einwilligungsabhängige Skripte zunächst blockiert bleiben sollten und erst nach aktiver Einwilligung ausgeführt werden sollten. Das gibt Entwicklern einen direkten Implementierungstest.
Ordnen Sie jeden Dritten einem Bestandteil und einer Offenlegung zu
Ein Domaininventar wird nützlich, wenn es identifiziert, warum die Anfrage existiert und woher sie kommt. Für jeden Dritten ordnen Sie zu:
| Nachweisfeld | Beispiel |
|---|---|
| Anbieter oder Domain | Externer Schriftartenanbieter |
| Initiierende Komponente | Globale Stylesheet |
| Erster beobachteter Zustand | Frischer Besuch, vor der Wahl |
| Daten, die in der Anfrage sichtbar sind | IP-Verbindungsdaten, User-Agent, Referrer je nach Anfrage |
| Offenlegung der Website | Anbieter fehlt in den EN- und PL-Datenschutzerklärungen |
| Technische Abhilfe | Selbst gehostete lizenzierte Schriftdateien und Preconnect entfernen |
| Manuelle Überprüfung | Offenlegung und rechtliche Analyse bestätigen |
Dies verhindert vage Tickets wie “GDPR beheben”. Ein Entwickler erhält eine konkrete Komponente, Anfrage, Zustand und erwartetes Ergebnis.
Externe Schriftarten sind ein gutes Beispiel. Das Audit muss keinen rechtlichen Verstoß erklären, um zu zeigen, dass der Browser des Besuchers einen Dritten vor der Einwilligung kontaktiert. Das Selbst-Hosting der Schriftart kann die Übertragung entfernen und gleichzeitig die Widerstandsfähigkeit und Leistung verbessern.
Testen Sie Formulare und Datenminimierung
Ein Formular-Audit vergleicht die sichtbaren Felder, die übermittelte Nutzlast, das Ziel und die gespeicherten Aufzeichnungen. Übermitteln Sie während des Tests niemals echte persönliche Daten. Verwenden Sie deutlich synthetische Werte und vermeiden Sie es, Nachrichten an echte Mitarbeiter oder externe Workflows ohne Genehmigung auszulösen.
Überprüfen Sie:
- versteckte Felder, die von Plugins oder Marketing-Skripten hinzugefügt wurden;
- vollständige Seiten-URLs und Referrer, die an eine Übermittlung angehängt sind;
- Endpunkte von Formularen Dritter;
- CAPTCHA- und Anti-Spam-Anbieter;
- clientseitige Validierungsnachrichten, die übermittelte Inhalte offenbaren;
- doppelte Kopien in Analytik, E-Mail, CRM und Protokollen;
- Felder, die gesammelt, aber nicht vom angegebenen Workflow verwendet werden;
- ob sensible Werte in GET-Parametern oder im Browserverlauf erscheinen.
Der technische Bericht kann unnötige Felder und unerwartete Ziele identifizieren. Der Geschäftsinhaber muss den Zweck und die erforderliche Aufbewahrung bestätigen.
Vergleichen Sie das Laufzeitverhalten mit jeder Richtlinieneinstellung
Die Datenschutzerklärung sollte das System beschreiben, das derzeit läuft, nicht das System, an das man sich beim letzten Redesign erinnert. Extrahieren Sie Anbieternamen, Zwecke, Aufbewahrungserklärungen und Einwilligungsansprüche aus jeder Sprachversion und vergleichen Sie sie mit dem beobachteten Verhalten.
Achten Sie auf:
- einen aktiven Anbieter, der in der Erklärung fehlt;
- einen zurückgezogenen Anbieter, der weiterhin dokumentiert ist;
- Analytik, die als einwilligungsabhängig beschrieben wird, während sie sofort ausgeführt wird;
- unterschiedliche Anbieterliste in verschiedenen Sprachen;
- defekte Links zur Datenschutz- oder Impressumsseite;
- eine Schnittstelle, die eine Kategorie als “notwendig” bezeichnet, während die Richtlinie sie als optionale Analytik beschreibt;
- Aufbewahrungsfristen, die nicht mit der Konfiguration übereinstimmen;
- keine Erklärung, wie eine Entscheidung geändert werden kann.
Eine Abweichung ist nicht automatisch der Beweis für eine rechtswidrige Verarbeitung. Es ist ein starkes Indiz dafür, dass Implementierung und Dokumentation einer gemeinsamen Überprüfung bedürfen.
Überprüfen Sie Sicherheitszeichen, ohne sie zu übertreiben
Ein öffentlicher Scan kann nützliche Sicherheitsanfälligkeiten finden, aber er kann das gesamte Sicherheitsprogramm nicht sehen. Dokumentieren Sie beobachtbare Kontrollen wie:
- HTTPS und gemischte Inhalte;
- HSTS und Umleitungsverhalten;
- Content Security Policy;
- Schutz vor Einbettungen;
- Referrer-Policy;
- Permissions-Policy;
- Cookie-Flags wie
Secure,HttpOnlyundSameSite; - exponierte Quellkarten, Schlüssel, Debug-Endpunkte oder Stack-Traces;
- öffentliche Verwaltungswege und Softwareversionslecks.
Fehlende Header beweisen allein keinen GDPR-Verstoß. Sie können jedoch auf vermeidbare Exposition hinweisen und die Sicherheitsüberprüfung gemäß Artikel 32 informieren.
Führen Sie keine invasiven Sicherheitstests als Teil eines routinemäßigen Datenschutzscans durch. Port-Scans, Authentifizierungsangriffe, Formularfluten, Exploit-Versuche oder der Zugang zu privaten Bereichen erfordern separate Genehmigungen und einen festgelegten Umfang.
Schreiben Sie Ergebnisse, die Entwickler schließen können
Jedes Ergebnis sollte genügend Beweise enthalten, um es zu reproduzieren und erneut zu testen. Verwenden Sie eine konsistente Struktur:
ID: CONSENT-003
Beobachtet: Analytik-Anfrage 420 ms nach der Navigation in einem sauberen Profil ausgelöst
Seite: /services/
Einwilligungszustand: unberührt
Initiator: /assets/analytics-loader.js
Nachweis: network-before-consent.json, Anfrage 47, Screenshot 02
Wahrscheinliches Problem: optionale Analytik scheint zu starten, bevor eine Benutzerwahl getroffen wird
Quelle: TDDDG §25 und DSK-Einwilligungsrichtlinien
Abhilfe: Loader hinter dem Analytik-Einwilligungszustand sperren
Manuelle Überprüfung: Zweck, Konfiguration und angegebene rechtliche Grundlage bestätigen
Erneuter Test: Anfrage muss vor der Einwilligung und nach Ablehnen abwesend sein
Die Schwere sollte die Exposition und das Vertrauen widerspiegeln, nicht das visuelle Drama. Ein nützliches Modell berücksichtigt, ob persönliche oder Geräteinformationen betroffen sind, wie früh und breit das Verhalten auftritt, wie viele Seiten betroffen sind, ob der Besucher es verhindern kann und wie sicher die Beweise sind.
Was automatisierte Scanner feststellen können und was nicht
Automatisierung sollte beobachtetes Browserverhalten melden und aufhören, bevor sie vorgibt, ein Anwalt zu sein.
| Automatisierter Check kann feststellen | Kann allein nicht feststellen |
|---|---|
| Eine Anfrage trat vor der Einwilligung auf | Die vollständige rechtliche Analyse der Organisation |
| Der Speicher unterschied sich nach dem Akzeptieren | Dass die Formulierung der Einwilligung in jedem Kontext gültig ist |
| Ein Anbieter fehlt im Richtlinientext | Die Inhalte jedes Vertrags oder DPA |
| Ablehnen und Akzeptieren verhielten sich identisch | Die Offline-Verarbeitungsaktivitäten des Unternehmens |
| Eine Widerrufskontrolle wurde nicht gefunden | Dass es nirgendwo einen alternativen gültigen Widerrufsweg gibt |
| Ein Sicherheitsheader fehlt | Dass die gesamte Verarbeitungsumgebung unsicher ist |
Vermeiden Sie eine universelle Konformitätsbewertung. Die Kombination eines fehlenden Headers, einer externen Schriftart und eines ernsthaften Trackers vor der Einwilligung zu “63 % konform” zu machen, schafft Präzision ohne Bedeutung.
Erneut testen nach der Abhilfe
Ein Ergebnis ist nicht geschlossen, wenn sich der Code ändert; es ist geschlossen, wenn das erwartete Browserverhalten beobachtet wird. Wiederholen Sie den ursprünglichen Test mit derselben Seite, demselben Browser, derselben Region, demselben Zustand und derselben Erfassungsmethode.
Bewahren Sie die Beweise vor und nach der Änderung auf. Der endgültige Bericht sollte Folgendes zeigen:
- ursprüngliche Beobachtung;
- implementierte Änderung;
- neuer Vergleich von Anfragen und Speicher;
- verbleibende Einschränkungen;
- Tester und Zeitstempel;
- Version der Audit-Regel oder Methodik.
Dies verwandelt Datenschutzarbeit in gewöhnliche Technik: festgelegtes Verhalten, Nachweise, Änderungen und Regressionstests.
Häufig gestellte Fragen
Kann ein Entwickler ein GDPR-Audit ohne Anwalt durchführen?
Ein Entwickler kann die technische Beweissammlung durchführen und Implementierungsabweichungen identifizieren. Rechtlicher Rat oder ein Datenschutzspezialist sollten Fragen bewerten, die die rechtliche Grundlage, Verträge, risikobehaftete Verarbeitung, Rechte und organisatorischen Kontext betreffen.
Ist ein Cookie-Scanner ausreichend?
Nein. Er kann localStorage, Pixel, Fingerprinting, serverseitige Weiterleitungen, eingebettete Inhalte, Formularziele, Fehler im Einwilligungszustand und Richtlinienabweichungen übersehen. Verwenden Sie Browserinstrumentierung und vergleichen Sie mehrere Zustände.
Sollte das Audit automatisch Akzeptieren klicken?
Es kann dies in einem kontrollierten Test tun, nachdem die unberührten und Ablehnen-Zustände erfasst wurden. Die automatisierte Interaktion muss aufzeichnen, welche Steuerung angeklickt wurde, und das resultierende Verhalten überprüfen, anstatt anzunehmen, dass die Schaltfläche funktioniert hat.
Können wir die Website eines Kunden scannen, ohne Zugriff auf den Code zu haben?
Sie können das öffentliche Browserverhalten beobachten, aber der Codezugriff macht die Abhilfe und die Zuordnung von Initiatoren viel stärker. Holen Sie sich die Genehmigung, bevor Sie Aktionen durchführen, die Formulare übermitteln, in private Bereiche eintreten oder Ladevorgänge erstellen.
Wie oft sollte das Audit durchgeführt werden?
Führen Sie es nach Änderungen an Einwilligungen, Analytik, Marketing, Einbettungen, Formularen oder Bereitstellungen durch und regelmäßig, da sich Skripte von Drittanbietern weiterentwickeln. Marketingseiten mit hohem Änderungsaufwand profitieren von geplanten Regressionstests.
Offizielle Quellen
- GDPR auf EUR-Lex
- TDDDG § 25
- DSK-Richtlinien zu Cookie-Bannern und Einwilligungswerkzeugen
- DSK Telemedienrichtlinien, Version 1.1
- EDPB-Richtlinien 4/2019 zum Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen
Ein nützliches Audit sollte Ihren Entwicklern Nachweise und abschließbare Aufgaben hinterlassen, nicht ein Abzeichen. Prüfen Sie Ihre Startseite kostenlos und sehen Sie die ersten Belege in einer Minute, oder fragen Sie ILF Studio nach einem vollständigen technischen Audit.
