Handlungsleitfaden: Datenschutz-, Sicherheits- und Google-Empfehlungen für behördliche Webseiten

Stand: 2026-06-07

Zielgruppe: Betreiber offizieller Webseiten deutscher Behörden, Körperschaften, kommunaler Einrichtungen und sonstiger öffentlicher Stellen. Der Leitfaden bündelt Empfehlungen und Prüfkriterien aus amtlichen Quellen in Deutschland und der EU sowie aus Google-Empfehlungen, weil Google für Auffindbarkeit, Nutzererfahrung und technische Qualität besonders relevant ist.

Hinweis: Der Bericht ist ein technischer und organisatorischer Handlungsleitfaden, keine Rechtsberatung. Für konkrete Behördenangebote müssen Landesrecht, behördliche Datenschutzbeauftragte, Vergaberecht, Barrierefreiheitsrecht, Akten-/Archivrecht und ggf. Fachrecht zusätzlich geprüft werden.

1. Kurzfassung / Executive Summary

Für Behörden-Webseiten ergeben sich aus den Quellen fünf Kernprinzipien:

1. Datensparsamkeit und Zweckbindung vor Tool-Komfort

• Keine Tracking-, Marketing-, Karten-, Video-, Schrift-, CDN- oder Social-Media-Dienste einbinden, nur weil sie bequem sind.
• Wenn Drittanbieter unvermeidbar sind: Rechtsgrundlage, Auftragsverarbeitung/gemeinsame Verantwortlichkeit, Drittlandtransfer, Löschfristen und technische Einbindung dokumentieren.

1. Einwilligung nur dort einsetzen, wo sie wirklich erforderlich und tragfähig ist

• Für Cookies und ähnliche Technologien ist nach DSK/TDDDG grundsätzlich eine Einwilligung nötig, wenn Informationen im Endgerät gespeichert oder ausgelesen werden und keine enge technische Erforderlichkeit greift.
• Einwilligung muss freiwillig, informiert, granular, aktiv, vorab und jederzeit ebenso einfach widerrufbar sein.
• Scrollen, Weitersurfen, vorausgewählte Häkchen oder manipulative Banner sind keine belastbare Einwilligung.

1. Behörden sollten möglichst ohne nicht notwendiges Tracking auskommen

• Webanalyse nur datenschutzfreundlich, vorzugsweise selbst gehostet oder mit anonymisierter/kurzfristiger Protokollierung.
• Keine Werbeprofile, Retargeting, Lookalike Audiences oder Nutzerprofilbildung für behördliche Pflichtinformationen.
• Bei Google Analytics, Google Tag Manager, Google Fonts, Maps, YouTube oder reCAPTCHA: besonders strenge Prüfung, weil Drittanbieter, Drittlandtransfer, Endgerätezugriff und Transparenzpflichten zusammentreffen können.

1. Sicherheit ist Datenschutz

• Durchgehend HTTPS/TLS nach BSI-Mindeststandard, keine Mixed-Content-Ressourcen.
• Sichere Webserver und Webanwendungen nach BSI IT-Grundschutz APP.3.1/APP.3.2.
• Security Header, sichere Cookies, Patchmanagement, Logging-Konzept, Schwachstellenscans und Notfallprozesse.

1. Google-relevante Qualität ist Teil amtlicher Nutzbarkeit

• Behördeninformationen müssen auffindbar, crawlbar, mobil nutzbar, schnell, barrierearm und semantisch sauber sein.
• Core Web Vitals, HTTPS, Mobile-First, strukturierte Daten und Safe-Browsing-Sauberkeit sollten automatisiert überwacht werden.

2. Quellenbasis und Geltungslogik über Bund und Länder

2.1 Zentrale deutsche Datenschutzquellen

Die wichtigste länderübergreifende Quelle ist die Datenschutzkonferenz (DSK). In ihr arbeiten die unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder zusammen. Für einen Leitfaden über alle Bundesländer hinweg ist die DSK deshalb besonders relevant: Sie bündelt die gemeinsame Aufsichtslinie.

Wichtige DSK-Quellen:

• Datenschutzkonferenz, Orientierungshilfen: https://www.datenschutzkonferenz-online.de/orientierungshilfen.html
• DSK, Orientierungshilfe der Aufsichtsbehörden für Anbieter:innen von digitalen Diensten: https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf
• DSK, Orientierungshilfe der Aufsichtsbehörden für Anbieter von Telemedien, Version 1.1: https://www.datenschutzkonferenz-online.de/media/oh/20221205_oh_Telemedien_2021_Version_1_1_Vorlage_104_DSK_final.pdf
• Bundesbeauftragte/r für den Datenschutz und die Informationsfreiheit (BfDI): https://www.bfdi.bund.de/DE/Home/home_node.html

2.2 Landesdatenschutzaufsichten, die bei landesspezifischen Fragen einzubeziehen sind

Die folgende Matrix ist für die operative Zuständigkeit wichtig. Für viele Webseitenfragen ist die DSK-Orientierung der gemeinsame Kern; bei landesbehördlichen Sonderfällen, Beschwerden, Prüfkatalogen oder Veröffentlichungen der jeweiligen Aufsicht sollte zusätzlich die zuständige Landesbehörde herangezogen werden.

2.3 BSI und IT-Sicherheitsquellen

• BSI, Mindeststandard zur Verwendung von Transport Layer Security (TLS), Version 2.3: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Mindeststandards/Mindeststandard_BSI_TLS_Version_2_3.pdf?__blob=publicationFile&v=4
• BSI, Empfehlungen zu Webanwendungen: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Webanwendungen/webanwendungen_node.html
• BSI IT-Grundschutz, APP.3.1 Webanwendungen und Webservices: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/06_APP_Anwendungen/APP_3_1_Webanwendungen_und_Webservices_Edition_2023.pdf?__blob=publicationFile&v=3
• BSI IT-Grundschutz, APP.3.2 Webserver: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/06_APP_Anwendungen/APP_3_2_Webserver_Edition_2023.pdf?__blob=publicationFile&v=3

2.4 EU-/europäische Quellen

• EDPB, Guidelines 05/2020 on consent under Regulation 2016/679: https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf
• EDPB, Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive: https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf
• EDPB, e-Privacy topic page: https://www.edpb.europa.eu/our-work-tools/our-documents/topic/e-privacy_en
• EDPS, Data Protection and Privacy Tools: https://www.edps.europa.eu/data-protection/technology-monitoring/data-protection-and-privacy-tools_en
• EU/EDPS Website Evidence Collector über Interoperable Europe: https://interoperable-europe.ec.europa.eu/collection/free-and-open-source-software/solution/website-evidence-collector
• ENISA, Privacy and data protection by design: https://www.enisa.europa.eu/publications/privacy-and-data-protection-by-design

2.5 Google-Quellen

• Google Search Central, SEO Starter Guide: https://developers.google.com/search/docs/fundamentals/seo-starter-guide
• Google Search Central, Page Experience: https://developers.google.com/search/docs/appearance/page-experience
• Google Search Central, Core Web Vitals: https://developers.google.com/search/docs/appearance/core-web-vitals
• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Why HTTPS matters: https://web.dev/articles/why-https-matters
• Google Search Central, Mobile-first indexing: https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
• Google Search Central, Structured Data introduction: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
• Google Tag Platform, Consent: https://developers.google.com/tag-platform/security/guides/consent
• Google Tag Platform, Consent Mode concepts: https://developers.google.com/tag-platform/security/concepts/consent-mode
• Google Search Central, Security issues: https://developers.google.com/search/docs/monitor-debug/security
• Google Safe Browsing: https://safebrowsing.google.com/

3. Datenschutz-Handlungsfelder für Behörden-Webseiten

3.1 Inventarisierung aller Datenverarbeitungen

Handlungsempfehlung:

• Jede Website braucht ein aktuelles Verzeichnis der eingesetzten Komponenten:
• CMS, Hosting, CDN, Reverse Proxy, WAF
• Cookies, Local Storage, Session Storage, IndexedDB
• Webanalyse, Tag Manager, A/B-Testing
• Karten, Videos, Schriftarten, Captchas, Chatbots, Newsletter, Formularanbieter
• Social-Media-Plugins, Share-Buttons, eingebettete Feeds
• externe JavaScript-, CSS-, Bild-, Font- und API-Ressourcen
• Serverlogs, Fachverfahrensschnittstellen, Formularverarbeitung, Uploads
• Für jede Komponente dokumentieren:
• Zweck
• Rechtsgrundlage
• technisch erforderlich ja/nein
• personenbezogene Datenarten
• Empfänger/Dienstleister
• Auftragsverarbeitung oder gemeinsame Verantwortlichkeit
• Drittlandtransfer
• Speicher-/Löschfrist
• Einwilligungsstatus und Widerrufsmöglichkeit
• technische Prüfmethode

Automatisierbar:

• Headless-Crawl über alle Seiten mit Playwright/Puppeteer.
• Erfassung aller Netzwerkrequests vor Consent, nach Ablehnung, nach Zustimmung.
• Erfassung von Cookies, LocalStorage, SessionStorage, IndexedDB je Consent-Zustand.
• Abgleich externer Domains gegen Allow-/Denylisten.
• Screenshot und DOM-Snapshot von Consent-Bannern.
• Export als JSON/CSV für Datenschutzakte.

3.2 Cookies und ähnliche Technologien nach DSK/TDDDG/ePrivacy

Kernaussage aus DSK und EDPB:

• Das Speichern von Informationen auf Endgeräten und der Zugriff auf Informationen aus Endgeräten ist grundsätzlich einwilligungsbedürftig, sofern keine gesetzliche Ausnahme greift.
• Die Einwilligungsfrage ist unabhängig davon, ob das Cookie selbst bereits personenbezogene Daten enthält. Entscheidend ist der Endgerätezugriff; Folgeverarbeitungen personenbezogener Daten unterliegen zusätzlich der DSGVO.
• Nicht nur klassische Cookies sind relevant, sondern auch Local Storage, Session Storage, Tracking Pixel, Fingerprinting, eindeutige IDs, SDKs, Tags und ähnliche Technologien.

Handlungsempfehlung:

• Nur technisch erforderliche Cookies ohne Einwilligung setzen.
• Statistik-, Komfort-, Marketing-, Social-Media- und Drittanbieter-Cookies standardmäßig blockieren, bis eine wirksame Einwilligung vorliegt.
• Behörden sollten Marketing-Kategorien in der Regel gar nicht einsetzen.
• Technisch erforderliche Cookies restriktiv setzen: Secure, HttpOnly, SameSite=Lax/Strict, kurze Laufzeit.
• Consent-Protokollierung datensparsam gestalten; keine unnötige Nutzerprofilbildung durch das Consent-System selbst.

Automatisierbar:

• Vor Einwilligung: prüfen, ob nur notwendige Cookies gesetzt werden.
• Nach Ablehnung: prüfen, ob keine Analyse-/Marketing-/Drittanbieter-Cookies vorhanden sind.
• Nach Zustimmung: prüfen, ob nur freigegebene Kategorien aktiv werden.
• Cookie-Attribute prüfen: Secure, HttpOnly, SameSite, Domain, Path, Max-Age/Expires.
• Laufzeiten gegen definierte Policy prüfen.
• Endgerätezugriff ohne Cookie erfassen: localStorage, sessionStorage, indexedDB, Cache API.
• Fingerprinting-Indikatoren erkennen: Canvas, AudioContext, WebGL, Battery, extensive device APIs.

3.3 Consent-Banner / Einwilligungsmanagement

Kernaussage aus DSK/EDPB:

• Einwilligung muss freiwillig, spezifisch, informiert und unmissverständlich sein.
• Es bedarf einer aktiven Handlung.
• Scrollen oder Weitersurfen ist nicht ausreichend.
• Widerruf muss ebenso einfach sein wie die Erteilung.
• Ablehnen darf nicht schwieriger, versteckter oder nachteiliger sein als Akzeptieren.
• Granularität ist erforderlich, wenn unterschiedliche Zwecke/Dienste vorliegen.

Handlungsempfehlung:

• Erste Ebene des Banners:
• klare, kurze Information über Zwecke
• gleichwertige Buttons: „Alle akzeptieren“, „Alle ablehnen“, „Einstellungen“
• keine farbliche oder räumliche Manipulation zugunsten von Akzeptieren
• kein vorausgewähltes Opt-in für nicht notwendige Zwecke
• Zweite Ebene:
• Zwecke einzeln oder in klaren Kategorien
• Anbieter/Drittanbieter sichtbar
• kurze Erklärung zu Datenarten, Empfängern, Drittlandtransfer, Speicherdauer
• direkte Speichern-Schaltfläche
• Widerruf:
• dauerhaft erreichbarer Link, z. B. „Datenschutzeinstellungen“ im Footer
• Widerruf ohne Login, ohne Medienbruch, ohne komplizierte Navigation
• Nachweis:
• Consent-Version, Zeit, gewählte Kategorien und Informationsstand dokumentieren, aber datensparsam.

Automatisierbar:

• UI-Prüfung per Playwright:
• Existieren Ablehnen, Akzeptieren, Einstellungen auf erster Ebene?
• Sind Buttons ähnlich sichtbar und erreichbar?
• Sind nicht notwendige Optionen standardmäßig aus?
• Wird ohne Klick kein optionaler Dienst geladen?
• Funktioniert Widerruf über Footer?
• Textprüfung:
• Pflichtbegriffe und Anbieterlisten vorhanden?
• Abweichungen zwischen Banner und Datenschutzerklärung erkennen.
• Regressionstest:
• Consent-Banner darf Hauptinhalt nicht dauerhaft blockieren, wenn Ablehnung möglich sein muss.

3.4 Webanalyse

Handlungsempfehlung für Behörden:

• Vorrangig datenschutzfreundliche, selbst gehostete oder streng konfigurierte Analyse verwenden.
• Keine personenbezogene Reichweitenmessung für behördliche Informationsangebote, sofern nicht zwingend erforderlich.
• IP-Adressen kürzen/anonymisieren, kurze Speicherfristen, keine seitenübergreifenden IDs.
• Kein Retargeting, keine Werbenetzwerkverknüpfung, keine demografischen Berichte, keine User-ID-Funktion.
• Bei Google Analytics oder vergleichbaren Drittanbietern:
• Einwilligung vor Aktivierung einholen.
• Google Consent Mode korrekt vor Tag-Auslösung setzen.
• Auftrags-/Drittland-/Transferfragen prüfen.
• Datenschutzhinweise präzise und aktuell halten.

Automatisierbar:

• Erkennung von Analyse-Tags: google-analytics.com, googletagmanager.com, gtag, matomo, plausible, etracker usw.
• Vor Consent: keine Analyse-Requests und keine Analyse-Cookies.
• Nach Ablehnung: weiterhin keine Analyse-Requests/Cookies.
• Nach Zustimmung: nur erwartete Requests.
• Prüfung, ob Consent-Default vor gtag/config/event gesetzt wird.
• Prüfung auf Consent Mode v2 Parameter: analytics_storage, ad_storage, ad_user_data, ad_personalization.
• Query-Parameter und Payloads stichprobenartig auf personenbezogene Daten prüfen.

3.5 Google-Dienste: besonders relevante Risikofelder

Google ist aus zwei Gründen zentral: Einerseits gibt Google wichtige technische Qualitätsanforderungen für Suche und Nutzererfahrung vor; andererseits sind eingebundene Google-Dienste datenschutzrechtlich sensibel.

3.5.1 Google Analytics / Google Tag Manager

Empfehlung:

• Für Behörden nur einsetzen, wenn fachlich wirklich erforderlich und datenschutzrechtlich freigegeben.
• Tags standardmäßig blockieren; Consent Mode allein ersetzt nicht automatisch eine Rechtsgrundlage.
• GTM darf nicht zum Schatten-CMS werden. Jede Tag-Änderung braucht Freigabeprozess.

Automatisierbare Checks:

• GTM/GA4 vorhanden?
• Requests vor Consent?
• Cookies _ga, _gid, _gcl_* vor Consent?
• dataLayer consent default vorhanden und vor Google config gesetzt?
• ad_user_data/ad_personalization im EWR default denied?
• Container-Version dokumentiert?

3.5.2 Google Fonts

Empfehlung:

• Schriftarten lokal hosten oder Systemfonts verwenden.
• Keine direkte Einbindung von fonts.googleapis.com/fonts.gstatic.com, wenn dadurch Nutzer-IP/Requestdaten an Google übertragen werden, ohne dass dies zwingend erforderlich ist.

Automatisierbare Checks:

• CSS/HTML nach fonts.googleapis.com und fonts.gstatic.com scannen.
• Netzwerkrequests zu Google Fonts erkennen.
• Ersatz: lokale Font-Dateien mit korrektem Caching und Lizenzdokumentation.

3.5.3 Google Maps

Empfehlung:

• Karten nur laden, wenn sie für den Dienst erforderlich sind.
• Besser: statische/lokale Alternativen oder datenschutzfreundliche Kartenanbieter prüfen.
• Wenn eingebettet: Zwei-Klick-Lösung oder Consent vor Laden.

Automatisierbare Checks:

• maps.googleapis.com, google.com/maps, gstatic Maps Ressourcen erkennen.
• Vor Consent/Aktivierung keine Maps-Requests.
• Ersatzlink zur Kartenansicht ohne automatisches Laden prüfen.

3.5.4 YouTube

Empfehlung:

• Videos nicht ungefragt laden.
• privacy-enhanced mode ist hilfreich, aber nicht allein ausreichend; vor dem Laden prüfen, ob personenbezogene Daten übertragen werden.
• Zwei-Klick-Lösung mit Vorschaubild lokal hosten.

Automatisierbare Checks:

• youtube.com, youtube-nocookie.com, ytimg.com Requests vor Aktivierung erkennen.
• iframe erst nach Klick/Consent vorhanden?
• Datenschutzhinweis in Video-Platzhalter vorhanden?

3.5.5 reCAPTCHA

Empfehlung:

• Für Behörden besonders kritisch prüfen, weil reCAPTCHA umfangreiche Signale verarbeiten kann.
• Alternativen bevorzugen: serverseitige Rate Limits, Honeypot, einfache barrierearme Challenge, Friendly Captcha/andere EU-konforme Lösungen, sofern geprüft.
• Falls Google reCAPTCHA: Rechtsgrundlage, Transparenz, Drittlandtransfer und Barrierefreiheit prüfen.

Automatisierbare Checks:

• Erkennung von google.com/recaptcha, gstatic.com/recaptcha.
• Wird reCAPTCHA bereits beim Seitenaufruf geladen oder erst bei Formularinteraktion?
• Funktioniert Formular barrierearm?

3.6 Drittinhalte, CDN, Social Plugins und externe Ressourcen

Handlungsempfehlung:

• Keine unnötigen externen Ressourcen auf Behörden-Webseiten.
• Social Share Buttons als reine Links statt aktiver Plugins.
• Externe Skripte nur mit dokumentiertem Zweck, Integritätsprüfung, Freigabe und Monitoring.
• Wo möglich: Subresource Integrity (SRI), CSP und lokale Auslieferung.
• CDN-Nutzung mit Datenschutz-/Sicherheitsprüfung, Auftragsverarbeitung und Protokollierungsbewertung.

Automatisierbar:

• Alle externen Domains erfassen und klassifizieren.
• Neue externe Domains als CI-Fehler behandeln, bis freigegeben.
• SRI-Prüfung für externe Skripte/CSS.
• CSP-Verstöße sammeln.
• Social Plugins erkennen: facebook, instagram, x/twitter, tiktok, linkedin usw.

3.7 Kontaktformulare, Online-Anträge, Newsletter

Handlungsempfehlung:

• Nur erforderliche Pflichtfelder.
• Pflicht/optional klar kennzeichnen.
• TLS und sichere Formularverarbeitung.
• Keine sensiblen Daten per unsicherer E-Mail weiterleiten.
• Uploads sicher prüfen: Dateityp, Größe, Malware, Speicherort, Zugriffsschutz.
• Bestätigungsmails ohne unnötige personenbezogene Daten.
• Newsletter nur mit Double-Opt-In und Protokollierung; bei Behörden kritisch prüfen, ob Newsletter-Tracking nötig ist.

Automatisierbar:

• Formularfelder inventarisieren.
• Pflichtfelder gegen Datenminimierungs-Policy prüfen.
• Autocomplete und input types prüfen.
• CSRF-Schutz testen.
• File Upload Hardening testen.
• Keine GET-Übertragung personenbezogener Daten.
• Sicherheitsheader und TLS auf Formularseiten erzwingen.

3.8 Datenschutzerklärung und Impressum / Anbieterkennzeichnung

Handlungsempfehlung:

• Datenschutzerklärung leicht auffindbar von jeder Seite.
• Inhalte müssen mit tatsächlicher Technik übereinstimmen.
• Für Behörden klar benennen:
• Verantwortlicher
• Datenschutzbeauftragte/r
• Zwecke/Rechtsgrundlagen
• Empfänger/Dienstleister
• Drittlandtransfers
• Speicherdauer
• Betroffenenrechte
• Beschwerderecht bei Aufsichtsbehörde
• konkrete Hinweise zu Cookies, Analyse, Formularen, Logfiles, Drittinhalten
• Impressum/Anbieterkennzeichnung getrennt oder klar mit Datenschutz verlinkt.

Automatisierbar:

• Footer-Link auf Datenschutz/Impressum auf allen Seiten prüfen.
• Datenschutzerklärung gegen tatsächliche Requests/Cookies abgleichen.
• Anbieterlisten aus CMP gegen externe Domains abgleichen.
• Stand/Version erkennen.
• Dead Links in Datenschutztexten prüfen.

3.9 Serverlogs und Protokollierung

Handlungsempfehlung:

• Protokollierung nur für Sicherheit/Betrieb in angemessenem Umfang.
• IP-Adressen, User-Agent, Referrer, Zeitstempel und angefragte URL sind personenbezogen oder personenbeziehbar zu behandeln.
• Kurze Löschfristen, Rollen-/Rechtekonzept, Zweckbindung.
• Keine unnötige Zusammenführung mit Analyseprofilen.
• Referrer können sensible Daten enthalten; Query-Parameter mit personenbezogenen Daten vermeiden.

Automatisierbar:

• Server-/Proxy-Konfiguration auf Logfelder prüfen.
• Retention prüfen.
• URLs mit personenbezogenen Query-Parametern erkennen.
• Referrer-Policy prüfen.

4. Sicherheits-Handlungsfelder nach BSI

4.1 TLS/HTTPS

Handlungsempfehlung:

• HTTPS für alle Seiten und Subdomains.
• HTTP leitet sauber auf HTTPS um.
• Zertifikate gültig, automatisch erneuert, richtige SANs.
• TLS-Konfiguration am BSI-Mindeststandard orientieren.
• Keine alten Protokolle und schwachen Cipher Suites.
• HSTS aktivieren, nach Testphase mit ausreichender max-age; optional preload nur nach sorgfältiger Prüfung.

Automatisierbar:

• HTTP->HTTPS Redirect.
• TLS-Versionen und Cipher Suites prüfen.
• Zertifikatskette, Ablaufdatum, Hostname, OCSP/Stapling prüfen.
• HSTS Header prüfen.
• Mixed Content Crawl.

4.2 HTTP Security Header

BSI APP.3.1 nennt restriktive HTTP-Header und sichere Cookie-Attribute als Anforderungen/Empfehlungen für Webanwendungen.

Empfohlene Header:

• Strict-Transport-Security
• Content-Security-Policy
• X-Content-Type-Options: nosniff
• Referrer-Policy
• Permissions-Policy
• X-Frame-Options oder frame-ancestors in CSP
• Cache-Control für personenbezogene Bereiche

Automatisierbar:

• Header jeder URL prüfen.
• CSP auf unsafe-inline/unsafe-eval/wildcards untersuchen.
• Frame-Schutz testen.
• Referrer-Policy gegen Mindeststandard prüfen.
• Permissions-Policy auf unnötig erlaubte APIs prüfen.

4.3 Sichere Webanwendungen

Handlungsempfehlung:

• Secure Software Development Lifecycle.
• Eingabevalidierung, Ausgabekodierung, CSRF-Schutz, Authentisierung, Autorisierung.
• Adminbereiche schützen: MFA, IP-/VPN-Beschränkung, Rate Limiting.
• Patchmanagement für CMS, Plugins, Frameworks.
• Keine Debug-Ausgaben, keine Versionslecks.
• Regelmäßige Schwachstellenscans und Penetrationstests bei kritischen Angeboten.

Automatisierbar:

• Dependency- und CVE-Scans.
• CMS-/Plugin-Versionserkennung, soweit möglich.
• OWASP ZAP Baseline Scan.
• Security.txt prüfen.
• Fehlerseiten und Header auf Versionslecks prüfen.
• Adminpfade erkennen und Schutz prüfen.

4.4 Sichere Cookies

Handlungsempfehlung:

• Session-Cookies: Secure, HttpOnly, SameSite=Lax oder Strict.
• Kurze Lebensdauer; Rotation nach Login.
• Keine personenbezogenen Daten im Cookie-Wert.
• __Host- oder __Secure-Präfixe nutzen, wo passend.

Automatisierbar:

• Cookie-Attributprüfung.
• Entropie und Klartextinhalt stichprobenartig prüfen.
• Domainweite Cookies vermeiden, wenn nicht nötig.

4.5 Malware, Defacement und Safe Browsing

Handlungsempfehlung:

• Google Search Console und Safe Browsing überwachen.
• Integritätsmonitoring für ausgelieferte Dateien.
• Incident-Prozess für kompromittierte Webseiten.
• Externe Skripte reduzieren.

Automatisierbar:

• Safe Browsing API gegen wichtige URLs.
• Search Console Security Issues.
• Hash-Monitoring statischer Assets.
• Defacement-Erkennung.
• Unerwartete Redirects erkennen.

5. Google-Handlungsfelder für Auffindbarkeit und Qualität

5.1 Crawlability und Indexierbarkeit

Handlungsempfehlung:

• Wichtige Behördeninformationen öffentlich crawlbar machen.
• robots.txt, noindex und X-Robots-Tag bewusst einsetzen.
• XML-Sitemap bereitstellen und aktuell halten.
• Sprechende URLs, konsistente Canonicals, keine unnötigen Redirect-Ketten.
• Wichtige Inhalte nicht ausschließlich über JavaScript, Suche, Login oder Formularinteraktion zugänglich machen.

Automatisierbar:

• robots.txt und Sitemap validieren.
• noindex/X-Robots-Tag prüfen.
• Statuscodes und Redirect-Ketten crawlen.
• Canonical-Konsistenz prüfen.
• Gerendertes HTML gegen Roh-HTML vergleichen.

5.2 Page Experience und Core Web Vitals

Google-relevante Zielwerte:

• LCP <= 2,5 Sekunden
• INP <= 200 ms
• CLS <= 0,1

Handlungsempfehlung:

• Mobile und Desktop getrennt betrachten.
• Behördenportale müssen auch bei schwachen Netzen nutzbar sein.
• Bilder optimieren, Caching nutzen, render-blocking Ressourcen reduzieren.
• Cookie-Banner dürfen Layout und Interaktion nicht unnötig verschlechtern.

Automatisierbar:

• Lighthouse CI.
• PageSpeed Insights API.
• Chrome UX Report API.
• Performance Budgets in CI/CD.
• Messung pro URL-Gruppe: Startseite, Fachseite, Formular, Suche, Pressemitteilung.

5.3 Mobile-First und responsive Nutzbarkeit

Handlungsempfehlung:

• Responsive Design bevorzugen.
• Mobile Version muss dieselben relevanten Inhalte, Metadaten, strukturierten Daten und Links enthalten wie Desktop.
• Keine blockierten CSS/JS/Bildressourcen.

Automatisierbar:

• Viewport-Meta prüfen.
• Playwright-Tests in mehreren Breakpoints.
• Desktop/Mobile DOM- und Content-Parität prüfen.
• Lighthouse Mobile Audits.

5.4 Strukturierte Daten

Handlungsempfehlung:

• JSON-LD verwenden, wo sinnvoll.
• Markup muss sichtbaren Inhalten entsprechen.
• Für Behörden relevant:
• GovernmentOrganization / GovernmentOffice, soweit passend
• BreadcrumbList
• Article/NewsArticle für Pressemitteilungen
• Event für öffentliche Termine
• JobPosting für Stellenausschreibungen
• FAQPage nur, wenn Google-Richtlinien erfüllt und Inhalt tatsächlich FAQ ist

Automatisierbar:

• JSON-LD extrahieren und validieren.
• Schema.org-Typen und Pflichtfelder prüfen.
• Rich Results Test / Search Console Enhancement Reports nutzen.
• Markup gegen sichtbaren Text abgleichen.

5.5 Barrierefreiheit als Qualitäts- und Behördenpflicht

Google/web.dev empfiehlt Accessibility-Prüfungen; für Behörden sind zusätzlich BITV 2.0, WCAG und EN 301 549 maßgeblich.

Handlungsempfehlung:

• Semantisches HTML.
• Tastaturbedienbarkeit.
• ausreichende Kontraste.
• Labels und Fehlermeldungen für Formulare.
• Alt-Texte für informative Bilder.
• Fokus sichtbar.
• PDFs separat barrierefrei prüfen.

Automatisierbar:

• axe-core.
• Lighthouse Accessibility.
• Pa11y.
• PDF Accessibility Checks, soweit möglich.
• Manuelle Tastatur-/Screenreader-Stichproben ergänzen.

6. Automatisierte Prüfpipeline

6.1 Zielarchitektur

Ein automatisierter Behörden-Webseiten-Scanner sollte mindestens fünf Zustände pro URL testen:

1. Erstaufruf ohne Consent
2. Nach „Alle ablehnen“
3. Nach granularer Auswahl nur notwendiger Dienste
4. Nach Zustimmung zu Statistik
5. Nach „Alle akzeptieren“

Für jeden Zustand erfassen:

• Netzwerkrequests
• Cookies
• Storage
• DOM/HTML
• Screenshots
• Security Header
• TLS-Status
• Lighthouse/axe-Ergebnisse
• externe Domains
• Konsolenfehler
• Redirects und Statuscodes

6.2 Empfohlene Tools

Open Source / automatisierbar:

• Playwright oder Puppeteer: Browserautomation, Consent-Flows, Screenshots, Netzwerkrequests
• Lighthouse CI: Performance, SEO, Best Practices, Accessibility
• axe-core / pa11y: Accessibility
• OWASP ZAP Baseline: Websicherheits-Basistest
• testssl.sh oder sslyze: TLS-Prüfung
• Mozilla Observatory oder SecurityHeaders-artige Prüfungen: Header/CSP
• Google PageSpeed Insights API: Lab-/Felddaten
• Chrome UX Report API: reale Core-Web-Vitals-Daten
• Google Safe Browsing API: Malware/Phishing-Status
• Google Search Console API: Indexierung, Sitemaps, Security Issues, Core Web Vitals
• EDPS/EU Website Evidence Collector: technische Beweissammlung zu Webtracking/Cookies

6.3 Beispiel-Prüfregeln

6.4 Scoring-Vorschlag

Für Behörden sollte kein reiner Prozent-Score ohne Kontext genutzt werden. Sinnvoller ist ein Ampelmodell:

• Rot / kritisch:
• optionale Tracker vor Consent
• kein HTTPS oder ungültiges Zertifikat
• Malware/Safe-Browsing-Warnung
• personenbezogene Daten in URLs
• Kontaktformular unsicher
• fehlende Datenschutzerklärung
• Orange / hoch:
• manipulativer Consent-Flow
• Drittanbieter nicht erklärt
• fehlende Security Header
• Google Fonts/Maps/YouTube ohne Schutz
• erhebliche Barrierefreiheitsprobleme
• Gelb / mittel:
• Performanceprobleme
• SEO-/Strukturmängel
• unvollständige Sitemaps
• kleinere Cookie-Attributmängel
• Grün:
• keine kritischen/hohen Befunde, Dokumentation vollständig

Wichtig für SaferPage-/Behördenkommunikation: technische-only Befunde neutral als „Hinweise“ formulieren, nicht rufschädigend als „riskant“.

7. Muster-Handlungsplan für Webseitenbetreiber

Phase 1: Sofortmaßnahmen, 1–2 Wochen

1. Vollständige externe Ressourcenliste erstellen.
2. Alle Tracker vor Consent blockieren.
3. Google Fonts lokal hosten oder entfernen.
4. YouTube/Maps/Social Plugins auf Zwei-Klick-Lösung umstellen.
5. HTTPS, Zertifikate und Mixed Content prüfen.
6. Datenschutzerklärung mit tatsächlicher Technik abgleichen.
7. Ablehnen/Widerruf im Consent-Banner prüfen.

Phase 2: Härtung, 1–2 Monate

1. Security Header und CSP einführen.
2. Cookie-Attribute härten.
3. Webanalyse datenschutzfreundlich konfigurieren oder ersetzen.
4. Auftragsverarbeitungs- und Drittlandtransfer-Dokumentation aktualisieren.
5. Lighthouse/PageSpeed/axe in CI integrieren.
6. BSI-Grundschutz-Anforderungen für Webserver/Webanwendungen abgleichen.
7. Formularsicherheit und Uploads prüfen.

Phase 3: Dauerbetrieb

1. Monatlicher Crawl aller öffentlichen Seiten.
2. Monitoring auf neue Drittanbieter-Domains.
3. Quartalsweise Datenschutz-/Consent-Regressionstests.
4. Security-Patchprozess und Schwachstellenscans.
5. Search Console / Safe Browsing Monitoring.
6. Jährliche manuelle Barrierefreiheits- und Datenschutz-Stichprobe.
7. Änderungsprozess: neue Tools nur nach Datenschutz-/Sicherheitsfreigabe.

8. Prüfkatalog für einen automatisierten Behörden-Webseiten-Scanner

Datenschutz / Consent

• [ ] Datenschutzerklärung von jeder Seite erreichbar
• [ ] Impressum/Anbieterkennzeichnung erreichbar
• [ ] Consent-Banner erscheint, wenn optionale Dienste vorhanden sind
• [ ] Akzeptieren und Ablehnen gleichwertig erreichbar
• [ ] Einstellungen erreichbar
• [ ] keine optionalen Zwecke vorausgewählt
• [ ] keine optionalen Cookies vor Consent
• [ ] keine optionalen Requests vor Consent
• [ ] Ablehnung verhindert optionale Dienste dauerhaft
• [ ] Widerruf einfach erreichbar
• [ ] Banner-Informationen stimmen mit Datenschutzerklärung überein
• [ ] externe Domains sind dokumentiert
• [ ] keine personenbezogenen Daten in URL-Parametern

Google-/Drittanbieter

• [ ] keine Google Analytics/GTM Requests vor Consent
• [ ] Consent Mode korrekt initialisiert, falls Google Tags genutzt werden
• [ ] keine Google Ads/Marketing-Tags auf Behördenpflichtseiten ohne besonderen Grund
• [ ] keine Remote-Google-Fonts oder nur mit Freigabe/Schutz
• [ ] Maps/YouTube erst nach Aktivierung
• [ ] reCAPTCHA kritisch geprüft oder ersetzt
• [ ] Social Plugins nur als Links/Zwei-Klick

Sicherheit

• [ ] HTTPS überall
• [ ] HTTP leitet auf HTTPS um
• [ ] TLS-Konfiguration nach Mindeststandard
• [ ] Zertifikat gültig und nicht bald ablaufend
• [ ] kein Mixed Content
• [ ] HSTS vorhanden
• [ ] CSP vorhanden und nicht zu permissiv
• [ ] X-Content-Type-Options vorhanden
• [ ] Referrer-Policy vorhanden
• [ ] Permissions-Policy vorhanden
• [ ] Session-Cookies Secure/HttpOnly/SameSite
• [ ] keine Versionslecks
• [ ] keine Google Safe Browsing Warnung

Google Search / UX

• [ ] robots.txt erreichbar und plausibel
• [ ] sitemap.xml erreichbar und gültig
• [ ] wichtige Seiten indexierbar
• [ ] Canonicals plausibel
• [ ] Title und Meta Description vorhanden
• [ ] genau eine sinnvolle H1 pro Seite oder klare Heading-Struktur
• [ ] mobile Darstellung funktionsfähig
• [ ] Core Web Vitals im Zielbereich oder Maßnahmenplan vorhanden
• [ ] strukturierte Daten valide, falls vorhanden

Barrierefreiheit

• [ ] axe/Lighthouse ohne kritische Fehler
• [ ] Formulare haben Labels
• [ ] Bilder haben sinnvolle Alt-Texte oder sind dekorativ markiert
• [ ] Kontrast ausreichend
• [ ] Tastaturbedienbarkeit stichprobenartig geprüft
• [ ] Fokus sichtbar
• [ ] PDFs separat geprüft

9. Priorisierte Empfehlungen speziell für offizielle Behörden-Webseiten

1. Standardmäßig keine Marketing- oder Retargeting-Technik.
2. Google Analytics nur in Ausnahmefällen und nur mit wirksamem Consent; besser datenschutzfreundliche Alternativen.
3. Google Fonts lokal hosten.
4. YouTube/Maps nur mit Zwei-Klick-/Consent-Lösung oder datenschutzfreundlicher Alternative.
5. Consent-Banner mit gleichwertigem Ablehnen auf erster Ebene.
6. Datenschutzerklärung technisch automatisch gegen echte Requests/Cookies abgleichen.
7. BSI-konforme TLS- und Webserverhärtung als Mindeststandard.
8. CSP und Security Header konsequent einführen.
9. Barrierefreiheit nicht nur manuell-projektbezogen, sondern kontinuierlich automatisiert plus Stichproben prüfen.
10. Google Search Console, Core Web Vitals und Safe Browsing überwachen, damit amtliche Informationen zuverlässig auffindbar bleiben.

10. Umsetzungsidee für ein automatisiertes Prüfprodukt

Ein Scanner für Behörden-Webseiten sollte Berichte so formulieren, dass Betreiber handeln können und keine unnötig rufschädigenden Bewertungen entstehen.

Empfohlene Reportstruktur je Befund:

• Kategorie: Datenschutz / Sicherheit / Google / Barrierefreiheit
• Schweregrad: kritisch, hoch, mittel, niedrig, Hinweis
• Beobachtung: technisch konkret
• Warum relevant: Quelle + kurze Begründung
• Handlungsempfehlung: konkrete Maßnahme
• Automatisch erhobene Evidenz: URL, Zeitpunkt, Request/Cookie/Header/Screenshot
• Quelle: amtliche/Google-URL

Beispiel:

Kategorie: Datenschutz Schweregrad: hoch Beobachtung: Beim Erstaufruf von https://beispiel.de wird ein Request zu https://www.google-analytics.com/... ausgelöst und ein _ga-Cookie gesetzt, bevor eine Einwilligung erteilt wurde. Warum relevant: DSK-Orientierungshilfen sehen für nicht erforderliches Speichern/Auslesen auf Endgeräten und nachfolgende Trackingverarbeitung grundsätzlich eine vorherige Einwilligung vor. Handlungsempfehlung: GA4/GTM standardmäßig blockieren; Consent Mode default vor dem ersten Google-Tag auf denied setzen; erst nach aktiver Zustimmung analytics_storage=granted setzen. Evidenz: HAR-Datei, Cookie-Snapshot, Screenshot des Banners. Quelle: DSK OH Digitale Dienste; Google Consent Mode Dokumentation.

11. Quellenverzeichnis

Datenschutz Deutschland

1. Datenschutzkonferenz, Orientierungshilfen: https://www.datenschutzkonferenz-online.de/orientierungshilfen.html
2. DSK, Orientierungshilfe der Aufsichtsbehörden für Anbieter:innen von digitalen Diensten: https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf
3. DSK, Orientierungshilfe der Aufsichtsbehörden für Anbieter von Telemedien, Version 1.1: https://www.datenschutzkonferenz-online.de/media/oh/20221205_oh_Telemedien_2021_Version_1_1_Vorlage_104_DSK_final.pdf
4. BfDI: https://www.bfdi.bund.de/DE/Home/home_node.html

BSI / Sicherheit

1. BSI, Mindeststandard TLS Version 2.3: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Mindeststandards/Mindeststandard_BSI_TLS_Version_2_3.pdf?__blob=publicationFile&v=4
2. BSI, Webanwendungen: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Webanwendungen/webanwendungen_node.html
3. BSI IT-Grundschutz APP.3.1 Webanwendungen und Webservices: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/06_APP_Anwendungen/APP_3_1_Webanwendungen_und_Webservices_Edition_2023.pdf?__blob=publicationFile&v=3
4. BSI IT-Grundschutz APP.3.2 Webserver: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/06_APP_Anwendungen/APP_3_2_Webserver_Edition_2023.pdf?__blob=publicationFile&v=3

EU / Europa

1. EDPB, Guidelines 05/2020 on consent under Regulation 2016/679: https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf
2. EDPB, Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive: https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf
3. EDPB e-Privacy topic: https://www.edpb.europa.eu/our-work-tools/our-documents/topic/e-privacy_en
4. EDPS Data Protection and Privacy Tools: https://www.edps.europa.eu/data-protection/technology-monitoring/data-protection-and-privacy-tools_en
5. EU Website Evidence Collector: https://interoperable-europe.ec.europa.eu/collection/free-and-open-source-software/solution/website-evidence-collector
6. ENISA, Privacy and data protection by design: https://www.enisa.europa.eu/publications/privacy-and-data-protection-by-design

Google

1. Google Search Central, SEO Starter Guide: https://developers.google.com/search/docs/fundamentals/seo-starter-guide
2. Google Search Central, Page Experience: https://developers.google.com/search/docs/appearance/page-experience
3. Google Search Central, Core Web Vitals: https://developers.google.com/search/docs/appearance/core-web-vitals
4. web.dev, Web Vitals: https://web.dev/articles/vitals
5. web.dev, Why HTTPS matters: https://web.dev/articles/why-https-matters
6. Google Search Central, Mobile-first indexing: https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
7. Google Search Central, Structured Data: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
8. Google Tag Platform, Consent guide: https://developers.google.com/tag-platform/security/guides/consent
9. Google Tag Platform, Consent Mode concepts: https://developers.google.com/tag-platform/security/concepts/consent-mode
10. Google Search Central, Security issues: https://developers.google.com/search/docs/monitor-debug/security
11. Google Safe Browsing: https://safebrowsing.google.com/

Ergänzung zur Recherche: vertiefende Quellen und zusätzliche Prüfkriterien

Stand: 2026-06-07

Diese Ergänzung vertieft den bereits gespeicherten Handlungsleitfaden. Schwerpunkt sind zusätzliche amtliche Quellen, konkretere Google-/BfDI-/DSK-Hinweise und weitere Automatisierungsregeln für einen Webseiten-Scanner.

1. Zusätzliche BfDI-/DSK-Quellen

1.1 BfDI: Cookies und andere Tracking-Technologien

Quelle: https://www.bfdi.bund.de/DE/Buerger/Inhalte/Telemedien/Cookies.html

Wesentliche Aussage:

• Der BfDI unterscheidet zwischen technisch notwendigen und technisch nicht notwendigen Tracking-Technologien.
• Für technisch nicht notwendige Cookies/Tracking-Technologien ist nach EuGH „Planet49“ und deutschem Digitale-Dienste-Datenschutz-Gesetz/TDDDG eine Einwilligung erforderlich.
• Tracking-Technologien zur Analyse des Surfverhaltens oder zur Personalisierung von Onlinewerbung sind technisch nicht notwendig und deshalb einwilligungsbedürftig.
• Technisch notwendige Cookies dürfen ohne Einwilligung gesetzt werden; Betreiber müssen Nutzer aber informieren und die technische Notwendigkeit nachweisen können.
• Beispiele technisch notwendiger Cookies: Warenkorb, Spracheinstellung, Angriffsschutz.

Zusätzliche Prüfpunkte:

• Kann der Betreiber für jedes „notwendige“ Cookie eine technische Notwendigkeit begründen?
• Werden Statistik-/Analyse-Cookies fälschlich als „notwendig“ klassifiziert?
• Werden Local Storage und Session Storage genauso geprüft wie Cookies?
• Werden Third-Party-Cookies gesondert ausgewiesen?

1.2 BfDI: Digitale Dienste und Zuständigkeiten

Quelle: https://www.bfdi.bund.de/DE/Buerger/Inhalte/Telemedien/Telemedien.html

Wesentliche Aussage:

• Der BfDI behandelt Webseiten, Apps und weitere digitale Dienste im Kontext des Datenschutzes.
• Für Behörden ist wichtig, die zuständige Aufsicht korrekt zu bestimmen: Bundesbehörden fallen typischerweise in die Zuständigkeit des BfDI; Landes-/Kommunalbehörden in die jeweilige Landesaufsicht.

Zusätzliche Prüfpunkte:

• Datenschutzerklärung nennt die richtige Datenschutzaufsicht.
• Bei Landes-/Kommunalbehörden wird nicht irrtümlich der BfDI als Beschwerdestelle genannt, wenn eine Landesaufsicht zuständig ist.
• Verantwortlicher und Datenschutzbeauftragter sind eindeutig benannt.

1.3 BfDI: Matomo

Quelle: https://www.bfdi.bund.de/DE/Fachthemen/Inhalte/Telemedien/Matomo.html

Wesentliche Aussage:

• Der BfDI bewertet Matomo als grundsätzlich einwilligungsbedürftig, auch wenn es datensparsam konfiguriert werden kann.
• Matomo kann ein eindeutiges Merkmal per Cookie oder Parameter setzen, Skripte ausliefern und Informationen aus der Endeinrichtung erheben.
• Der Zugriff auf Endeinrichtungen eröffnet § 25 TDDDG; der Zugriff ist nach BfDI nicht unbedingt erforderlich, um den ausdrücklich gewünschten digitalen Dienst bereitzustellen.
• IP-Adressen können in Serverlogs der Matomo-Instanz und des Webservers im Klartext vorliegen; ein Personenbezug kann durch Abgleich wiederhergestellt werden.

Konsequenz für Behörden:

• Matomo nicht automatisch als „consentfrei“ einstufen.
• Wenn Matomo eingesetzt wird, muss entweder eine sehr spezifische Ausnahme sauber begründet werden oder eine wirksame Einwilligung vorliegen.
• Selbst gehostet bedeutet nicht automatisch anonym oder einwilligungsfrei.

Zusätzliche Prüfpunkte:

• Erkennung von matomo.js, piwik.js, _pk_id, _pk_ses, mtm_consent, cid, uid, config_id.
• Prüfung, ob Matomo vor Consent geladen wird.
• Prüfung, ob cookieless Matomo trotzdem Fingerprinting-/Wiedererkennungsmerkmale nutzt.
• Prüfung der IP-Anonymisierung und Log-Retention.
• Prüfung, ob Matomo-Daten mit Webserverlogs zusammenführbar sind.

1.4 BfDI: Personenbezogenes Webtracking nur mit Einwilligung

Quelle: https://www.bfdi.bund.de/SharedDocs/Pressemitteilungen/DE/2019/26_WebtrackingEinwilligung.html

Wesentliche Aussage:

• Wenn eingebundene Dritt-Dienste die erhobenen Daten auch für eigene Zwecke nutzen, muss der Webseitenbetreiber eine explizite Einwilligung einholen.
• Der BfDI nennt Google Analytics als Beispiel für ein Angebot, das rechtlich zwingend eine Einwilligung erfordern kann.
• Einfache Informationen über Cookie-Banner oder voraktivierte Kästchen reichen nicht.
• Betreiber sollen prüfen, welche Dritt-Inhalte und Tracking-Mechanismen eingebunden sind, und diese notfalls deaktivieren, bis ein datenschutzkonformer Einsatz sichergestellt ist.

Zusätzliche Prüfpunkte:

• Externe Dienstleister mit Eigennutzung identifizieren: Google, Meta, TikTok, X, LinkedIn, YouTube, Karten, Captcha, CDN/Tag-Manager.
• Voraktivierte Checkboxen oder standardmäßig aktive optionale Kategorien erkennen.
• Prüfen, ob Drittanbieter vor Consent Daten erhalten.

1.5 DSK: Hinweise zum Einsatz von Google Analytics

Quelle: https://www.bfdi.bund.de/SharedDocs/Downloads/DE/DSK/DSKBeschluessePositionspapiere/99DSK_Google-Analytics.pdf?__blob=publicationFile&v=3

Wesentliche Aussage:

• Die DSK weist darauf hin, dass beim Einsatz von Google Analytics immer personenbezogene Daten der Nutzer verarbeitet werden.
• Google Analytics ist nach DSK keine bloße Statistikfunktion und in der Regel nicht auf berechtigtes Interesse stützbar.
• Ein rechtmäßiger Einsatz ist regelmäßig nur aufgrund einer wirksamen Einwilligung möglich.
• Einwilligung muss die konkrete Verarbeitung durch Google Analytics und Übermittlungen an Google erfassen.
• Google muss ausdrücklich als Empfänger genannt werden.
• Vor aktiver Einwilligung dürfen keine Daten erhoben und keine Elemente von Google-Websites nachgeladen werden.
• Ein Google-Browser-Add-on reicht nicht als Widerrufsmöglichkeit; Widerruf muss so einfach sein wie Einwilligung.
• IP-Kürzung ist nur eine zusätzliche Schutzmaßnahme und macht die Verarbeitung nicht anonym.

Zusätzliche Prüfpunkte für Google Analytics:

• Wird Google ausdrücklich im Banner und in der Datenschutzerklärung genannt?
• Werden eigene Zwecke von Google, Profilbildung und Verknüpfung mit Google-Konten transparent gemacht?
• Werden Google-Elemente bereits vor Consent nachgeladen?
• Ist ein Widerruf direkt auf der Website möglich, ohne Browser-Add-on?
• Wird IP-Anonymisierung erwähnt und technisch geprüft?
• Ist GA4/Google Signals/Ads Linking/Remarketing deaktiviert, sofern nicht ausdrücklich freigegeben?

2. Barrierefreiheit als behördliche Pflicht und Google-Qualitätsfaktor

2.1 BITV 2.0

Quelle: https://www.gesetze-im-internet.de/bitv_2_0/

Wesentliche Aussage:

• Die BITV 2.0 regelt barrierefreie Informationstechnik nach dem Behindertengleichstellungsgesetz.
• Für öffentliche Stellen sind u.a. anwendbare Standards, Erklärung zur Barrierefreiheit, Überwachungsverfahren und Berichterstattung relevant.

Zusätzliche Handlungsempfehlungen:

• Jede Behörden-Webseite braucht eine Erklärung zur Barrierefreiheit.
• Ein Feedback-Mechanismus für Barrieren sollte leicht auffindbar sein.
• Barrierefreiheit muss redaktionelle Inhalte, PDFs, Formulare, Karten, Videos und eingebettete Dienste umfassen.

2.2 BFIT-Bund

Quelle: https://www.bfit-bund.de/DE/Home/home_node.html

Wesentliche Aussage:

• Die Überwachungsstelle des Bundes prüft unabhängig die Barrierefreiheit digitaler Angebote öffentlicher Stellen des Bundes.
• Digitale Barrierefreiheit umfasst technische und redaktionell-inhaltliche Anforderungen.

Zusätzliche Prüfpunkte:

• Erklärung zur Barrierefreiheit vorhanden.
• Feedback-Mechanismus vorhanden.
• Leichte Sprache und Deutsche Gebärdensprache, wo rechtlich erforderlich.
• PDFs und Downloads in Stichproben prüfen.
• Videos: Untertitel, Transkript, Audiodeskription je nach Inhalt.

3. Zusätzliche Google-Quellen und konkrete technische Prüfpunkte

3.1 robots.txt

Quelle: https://developers.google.com/search/docs/crawling-indexing/robots/intro

Prüfpunkte:

• robots.txt erreichbar unter /robots.txt.
• Keine versehentliche Blockade wichtiger Behördeninhalte.
• Keine sensiblen URLs in robots.txt als „versteckte“ Zugriffskontrolle verwenden.
• Sitemap-Verweise in robots.txt vorhanden und gültig.

3.2 Sitemaps

Quelle: https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview

Prüfpunkte:

• sitemap.xml erreichbar.
• Nur kanonische 200-URLs enthalten.
• lastmod plausibel.
• Keine noindex-URLs in Sitemap.
• Sitemap-Index bei großen Portalen.

3.3 Canonical URLs

Quelle: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

Prüfpunkte:

• Jede indexierbare Seite hat plausible Canonical-URL.
• Canonical verwendet HTTPS und bevorzugte Hostvariante.
• Canonical zeigt nicht auf 404/redirect/noindex.
• Desktop/Mobile/AMP-Varianten konsistent.

3.4 Title Links und Snippets

Quellen:

• https://developers.google.com/search/docs/appearance/title-link
• https://developers.google.com/search/docs/appearance/snippet

Prüfpunkte:

• Aussagekräftiger Title pro Seite, Behörde und Thema klar erkennbar.
• Keine generischen Titel wie „Startseite“ oder „Untitled“.
• Meta Description für wichtige Seiten vorhanden und informativ.
• Snippet-relevante Inhalte nicht nur als Bild/PDF ohne HTML-Kontext.

3.5 Breadcrumbs, Site Names und Favicons

Quellen:

• https://developers.google.com/search/docs/appearance/structured-data/breadcrumb
• https://developers.google.com/search/docs/appearance/site-names
• https://developers.google.com/search/docs/appearance/favicon-in-search

Prüfpunkte:

• BreadcrumbList-JSON-LD für tiefe Behördenportale.
• Site Name bzw. Organization-Markup konsistent.
• Favicon technisch gültig und crawlbar.
• Keine widersprüchlichen Behördennamen in Markup, Title und sichtbarem Header.

3.6 PageSpeed Insights API und CrUX API

Quellen:

• https://developers.google.com/speed/docs/insights/v5/get-started
• https://developer.chrome.com/docs/crux/api

Prüfpunkte:

• PageSpeed Insights API regelmäßig für repräsentative URLs ausführen.
• CrUX API nutzen, wenn genügend Felddaten vorhanden sind.
• Getrennte Bewertung für mobile und desktop.
• Core-Web-Vitals-Monitoring in Zeitreihe speichern.

3.7 Google Consent Mode v2 / Tag Manager Consent

Quellen:

• https://developers.google.com/tag-platform/security/guides/consent
• https://developers.google.com/tag-platform/security/concepts/consent-mode
• https://support.google.com/google-ads/answer/10000067
• https://support.google.com/tagmanager/answer/10718549

Prüfpunkte:

• Consent default wird gesetzt, bevor Google-Tags feuern.
• Im EWR/UK/Schweiz sind insbesondere ad_storage, analytics_storage, ad_user_data und ad_personalization korrekt auf denied, bis Consent vorliegt.
• Consent update erfolgt erst nach aktiver Nutzerentscheidung.
• GTM Consent Overview aktiv nutzen.
• Keine Tags umgehen das Consent-System durch Custom HTML oder direkte Einbindung.

Wichtige Einordnung:

• Consent Mode ist eine technische Steuerungsmöglichkeit, ersetzt aber nicht die rechtliche Prüfung.
• Für Behörden ist besonders wichtig: Auch „cookieless pings“ oder modellierte Messung können datenschutzrechtlich relevant sein und müssen dokumentiert werden.

3.8 Google reCAPTCHA

Quelle: https://cloud.google.com/security/products/recaptcha

Handlungsempfehlung:

• reCAPTCHA nur einsetzen, wenn mildere Mittel nicht ausreichen.
• Datenschutz, Barrierefreiheit und Drittland-/Google-Verarbeitung prüfen.
• Alternativen bevorzugen: Honeypot, Rate Limiting, serverseitige Spam-Erkennung, barrierearme Aufgaben, datenschutzfreundlichere Captcha-Anbieter.

Prüfpunkte:

• Lädt reCAPTCHA bereits beim Seitenaufruf oder erst bei Formularinteraktion?
• Werden google.com/recaptcha und gstatic-Ressourcen vor Consent geladen?
• Ist das Formular ohne unzumutbare Hürde nutzbar?
• Sind Datenschutzhinweise konkret?

3.9 Google Maps Platform

Quelle: https://cloud.google.com/maps-platform/terms

Handlungsempfehlung:

• Karten bei Behörden nur einsetzen, wenn Mehrwert klar ist.
• Zwei-Klick-/Consent-Lösung oder statischer Kartenausschnitt mit Link prüfen.
• OpenStreetMap/amtliche Kartenalternativen datenschutzrechtlich vergleichen.

Prüfpunkte:

• Keine Maps-Requests vor Aktivierung.
• API Keys nicht offen missbrauchbar; Referrer-Restriktionen aktiv.
• Datenschutzerklärung benennt Google Maps konkret.

3.10 Google Fonts Privacy FAQ

Quelle: https://developers.google.com/fonts/faq/privacy

Handlungsempfehlung:

• Trotz Google-Hinweisen zur Fonts-API sollten deutsche Behörden Remote-Fonts vermeiden, weil ein externer Request an Google beim Seitenaufruf unnötig ist.
• Lokal hosten ist technisch einfach und minimiert Drittanbieterkommunikation.

Prüfpunkte:

• Keine Requests an fonts.googleapis.com und fonts.gstatic.com.
• Font-Dateien lokal gecacht und lizenziert.
• Keine Layout-Shifts durch Font-Laden.

4. Zusätzliche BSI-/Sicherheitsprüfungen

Über den ersten Bericht hinaus sollten Behörden-Webseiten auch diese Prüfbereiche aufnehmen:

4.1 DNS und Domain-Sicherheit

Prüfpunkte:

• DNSSEC für Hauptdomains prüfen.
• CAA-Records setzen, um Zertifikatsaussteller zu begrenzen.
• SPF, DKIM, DMARC für E-Mail-Domains, besonders wenn Formulare oder Behördenkommunikation Mails versenden.
• Subdomain-Takeover-Prüfung bei CNAMEs auf externe Dienste.

4.2 Security.txt

Prüfpunkte:

• /.well-known/security.txt vorhanden.
• Kontaktadresse aktuell.
• Verschlüsselungs-/Policy-Hinweise, falls vorhanden.

4.3 CSP vertiefen

Prüfpunkte:

• Keine Wildcards in script-src für kritische Seiten.
• Kein unsafe-eval.
• unsafe-inline nur mit Nonce/Hash-Strategie oder begründetem Übergangsplan.
• frame-ancestors statt nur X-Frame-Options.
• report-uri/report-to für Monitoring.

4.4 Formular- und Fachverfahrensschnittstellen

Prüfpunkte:

• CSRF-Schutz.
• Rate Limiting.
• Uploads mit Malwareprüfung.
• Keine personenbezogenen Daten in GET-URLs.
• Session-Fixation-Schutz.
• Fehlertexte ohne interne Details.
• Fachverfahrens-APIs nicht öffentlich enumerierbar.

5. Landesübergreifende Operationalisierung

Für „über alle Bundesländer hinweg“ sollte der Leitfaden zweistufig arbeiten:

1. Bundesweit gemeinsamer Mindeststandard

• DSK-Orientierungshilfen
• DSGVO/TDDDG/ePrivacy
• BSI-Mindeststandard/IT-Grundschutz
• BITV/WCAG/EN 301 549
• Google Search/UX/Security-Empfehlungen

1. Landes-/Trägerspezifische Ergänzung

• richtige Datenschutzaufsicht
• Landesdatenschutzgesetz
• landeseigene Barrierefreiheits-/E-Government-Vorgaben
• IT-Dienstleister des Landes
• Styleguide/Designsystem des Landes
• zentrale Consent-/Analytics-Vorgaben des Landesportals

Automatisierbarer Zusatzcheck:

• Scanner fragt Betreiberprofil ab: Bund, Land, Kommune, Körperschaft, Schule, Hochschule, Gericht, öffentlich-rechtlicher Rundfunk, Kirche.
• Daraus wird die zuständige Aufsicht und der passende Pflichtenkatalog gewählt.

6. Zusätzliche Quellenliste

1. BfDI, Cookies und andere Tracking-Technologien: https://www.bfdi.bund.de/DE/Buerger/Inhalte/Telemedien/Cookies.html
2. BfDI, Digitale Dienste und Zuständigkeiten: https://www.bfdi.bund.de/DE/Buerger/Inhalte/Telemedien/Telemedien.html
3. BfDI, Matomo: https://www.bfdi.bund.de/DE/Fachthemen/Inhalte/Telemedien/Matomo.html
4. BfDI, Personenbezogenes Webtracking nur mit Einwilligung: https://www.bfdi.bund.de/SharedDocs/Pressemitteilungen/DE/2019/26_WebtrackingEinwilligung.html
5. DSK/BfDI, Hinweise zum Einsatz von Google Analytics: https://www.bfdi.bund.de/SharedDocs/Downloads/DE/DSK/DSKBeschluessePositionspapiere/99DSK_Google-Analytics.pdf?__blob=publicationFile&v=3
6. BITV 2.0: https://www.gesetze-im-internet.de/bitv_2_0/
7. BFIT-Bund: https://www.bfit-bund.de/DE/Home/home_node.html
8. Google robots.txt: https://developers.google.com/search/docs/crawling-indexing/robots/intro
9. Google Sitemaps: https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview
10. Google Canonical URLs: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
11. Google Title Links: https://developers.google.com/search/docs/appearance/title-link
12. Google Snippets: https://developers.google.com/search/docs/appearance/snippet
13. Google Breadcrumb structured data: https://developers.google.com/search/docs/appearance/structured-data/breadcrumb
14. Google Site Names: https://developers.google.com/search/docs/appearance/site-names
15. Google Favicons: https://developers.google.com/search/docs/appearance/favicon-in-search
16. PageSpeed Insights API: https://developers.google.com/speed/docs/insights/v5/get-started
17. Chrome UX Report API: https://developer.chrome.com/docs/crux/api
18. Google Ads Consent Mode / EU user consent: https://support.google.com/google-ads/answer/10000067
19. Google Tag Manager Consent: https://support.google.com/tagmanager/answer/10718549
20. Google reCAPTCHA: https://cloud.google.com/security/products/recaptcha
21. Google Maps Platform Terms: https://cloud.google.com/maps-platform/terms
22. Google Fonts Privacy FAQ: https://developers.google.com/fonts/faq/privacy

Prüfkatalog: Serverebene vs. Seitenebene bei Behörden-Webseiten

Stand: 2026-06-07

Zweck: Diese Ergänzung trennt klar, welche Datenschutz-, Sicherheits-, Google- und Barrierefreiheitsanforderungen auf Server-/Infrastrukturebene und welche auf Seiten-/Frontend-/Inhaltsebene zu beachten sind. Viele reale Datenschutzprobleme entstehen gerade an der Schnittstelle: Ein Tracking-Skript ist Seitenebene, aber die Serverlogs, CSP, TLS, Proxy-Header und Cookie-Attribute sind Serverebene.

1. Grundmodell

Serverebene

Serverebene bedeutet: Alles, was durch Hosting, DNS, Webserver, Reverse Proxy, CDN, TLS, HTTP-Header, Serverlogs, CMS-/Backend-Konfiguration, Deployment, Mailversand, APIs und technische Infrastruktur bestimmt wird.

Typische Verantwortliche:

• IT-Betrieb / Hosting
• kommunaler oder Landes-IT-Dienstleister
• DevOps / Systemadministration
• CMS-Betrieb
• IT-Sicherheitsbeauftragte
• Datenschutzbeauftragte bei Log-/Dienstleisterfragen

Typische technische Beweise:

• DNS Records
• TLS Scan
• HTTP Header
• Cookie Header
• Serverlog-Konfiguration
• Webserver-/Proxy-Konfiguration
• Security-Scan
• WAF/CDN-Konfiguration
• Deployment-/CMS-Versionen

Seitenebene

Seitenebene bedeutet: Alles, was durch HTML, CSS, JavaScript, eingebettete Drittinhalte, Consent-Banner, redaktionelle Inhalte, Datenschutzerklärung, Formulare, strukturierte Daten, Barrierefreiheit und UX bestimmt wird.

Typische Verantwortliche:

• Webredaktion
• Webentwicklung / Frontend
• CMS-Administratoren
• Datenschutzkoordination
• Kommunikationsabteilung
• Fachämter/Fachbereiche
• externe Agenturen

Typische technische Beweise:

• DOM/HTML
• gerenderte Seite
• JavaScript-Ausführung
• Netzwerkrequests im Browser
• Cookie-/Storage-Snapshots vor/nach Consent
• Screenshots
• Formularfelder
• Datenschutzerklärung/Inhaltsseiten
• Lighthouse/axe-Ergebnisse

2. Matrix: Was gehört wohin?

3. Serverebene: Anforderungen und Handlungsempfehlungen

3.1 DNS und Domainverwaltung

Zu beachten:

• DNSSEC für Behörden- und Subdomains prüfen/aktivieren, sofern vom Betreiber/Registrar unterstützt.
• CAA Records setzen, damit nur freigegebene Zertifizierungsstellen Zertifikate ausstellen dürfen.
• Subdomain-Takeover vermeiden: keine verwaisten CNAMEs auf nicht mehr genutzte externe Dienste.
• Einheitliche kanonische Hostvariante: z.B. www oder non-www, aber nicht beides unkontrolliert.
• Mail-Sicherheit für Behördenkommunikation: SPF, DKIM, DMARC.

Automatisierte Prüfung:

• dig/nslookup für A/AAAA/CNAME/MX/TXT/CAA.
• DNSSEC-Validierung.
• Subdomain-Liste gegen bekannte Takeover-Dienste prüfen.
• DMARC Policy mindestens p=quarantine oder p=reject als Zielbild; Übergangsphasen dokumentieren.

3.2 TLS und HTTPS

Zu beachten:

• HTTPS überall, auch für Subdomains und Formular-/Downloadbereiche.
• HTTP muss sauber auf HTTPS weiterleiten.
• Zertifikat gültig, vollständige Chain, richtiger Hostname, automatische Erneuerung.
• TLS-Konfiguration nach BSI-Mindeststandard.
• Keine veralteten Protokolle oder schwachen Cipher.
• HSTS aktivieren; preload nur nach kontrollierter Prüfung aller Subdomains.

Automatisierte Prüfung:

• testssl.sh oder sslyze.
• Zertifikatsablauf überwachen.
• Redirect-Ketten messen.
• Mixed Content im Browser erkennen.

3.3 HTTP Security Header

Zu beachten:

• Strict-Transport-Security.
• Content-Security-Policy, möglichst restriktiv.
• X-Content-Type-Options: nosniff.
• Referrer-Policy, z.B. strict-origin-when-cross-origin oder restriktiver.
• Permissions-Policy, um unnötige Browser-APIs zu deaktivieren.
• frame-ancestors in CSP gegen Clickjacking.
• Cache-Control für personenbezogene oder interne Bereiche.

Automatisierte Prüfung:

• Header je URL erfassen.
• CSP auf unsafe-inline, unsafe-eval, Wildcards und fremde Script-Quellen prüfen.
• Prüfen, ob Security Header auch auf Fehlerseiten, Weiterleitungen und PDF-/Downloadantworten konsistent sind.

3.4 Serverlogs und Protokolldaten

Zu beachten:

• IP-Adressen, User-Agent, Referrer, Zeitstempel und URLs sind personenbezogen oder personenbeziehbar zu behandeln.
• Logzwecke definieren: Betrieb, Sicherheit, Fehleranalyse.
• Speicherfristen kurz und dokumentiert.
• Zugriff nur für berechtigte Administratoren.
• Keine Zusammenführung mit Webanalyseprofilen.
• Query-Parameter mit personenbezogenen Daten vermeiden, weil sie in Logs landen.

Automatisierte Prüfung:

• Konfigurationsprüfung: Welche Felder werden geloggt?
• Retention-Konfiguration prüfen.
• Crawl auf URLs mit E-Mail-Adressen, Namen, Aktenzeichen, Telefonnummern, Tokens oder Formularinhalten in Query-Parametern.
• Referrer-Policy prüfen, um Datenabfluss an Dritte zu reduzieren.

3.5 Hosting, CDN, Reverse Proxy, WAF

Zu beachten:

• Hosting-Dienstleister datenschutzrechtlich dokumentieren: AVV, Unterauftragnehmer, Standort, Zugriffsmöglichkeiten.
• CDN/WAF kann personenbezogene Zugriffsdaten verarbeiten; für Behörden besonders dokumentationspflichtig.
• Serverstandorte und Drittlandtransfer prüfen.
• Caching darf keine personenbezogenen Seiten öffentlich ausliefern.

Automatisierte Prüfung:

• IP/ASN/Hosting-Provider ermitteln.
• Response Header auf CDN/WAF-Indikatoren prüfen.
• Cache-Control für personalisierte Seiten testen.
• Externe Dienstleisterliste gegen Datenschutzerklärung abgleichen.

3.6 Backend, CMS, APIs und Updates

Zu beachten:

• CMS, Plugins, Frameworks aktuell halten.
• Adminbereiche absichern: MFA, starke Passwörter, IP-/VPN-Beschränkung, Rate Limiting.
• Keine Debug-Ausgaben und Versionslecks.
• APIs mit Authentisierung, Autorisierung, Rate Limits und Logging-Konzept.
• Uploads sicher speichern und prüfen.

Automatisierte Prüfung:

• Versionsfingerprinting, soweit rechtlich/vertraglich zulässig.
• CVE-/Dependency-Scan.
• Adminpfade erkennen und Schutz prüfen.
• OWASP ZAP Baseline Scan.
• Upload-Endpunkte auf Dateityp/Größe/Content-Type prüfen.

3.7 Server-seitiges Tracking / Tagging

Zu beachten:

• Server-side Tagging ist nicht automatisch datenschutzfreundlich.
• Auch wenn Browser-Cookies reduziert werden, können serverseitig personenbezogene Daten an Google/Meta/andere weitergeleitet werden.
• Consent-Signale müssen serverseitig korrekt berücksichtigt werden.

Automatisierte Prüfung:

• Browserseitig sind serverseitige Weiterleitungen schwerer sichtbar; daher Konfigurationsprüfung nötig.
• Auffällige First-Party-Endpunkte wie /collect, /gtm, /analytics, /events erfassen.
• Payloads prüfen, ob IDs, IP, User-Agent, Consent-Signale weitergegeben werden.

4. Seitenebene: Anforderungen und Handlungsempfehlungen

4.1 Consent-Banner und Einwilligungslogik

Zu beachten:

• Gleichwertige Optionen: Akzeptieren, Ablehnen, Einstellungen.
• Keine optionalen Dienste vor Einwilligung.
• Keine vorausgewählten optionalen Kategorien.
• Granularität nach Zwecken/Diensten.
• Widerruf dauerhaft erreichbar und so einfach wie Erteilung.
• Datenschutzerklärung und Impressum dürfen durch Banner nicht blockiert werden.

Automatisierte Prüfung:

• Playwright-Test für Erstaufruf, Ablehnung, Zustimmung, Widerruf.
• Screenshots und DOM-Snapshots des Banners.
• Network- und Cookie-Snapshots in jedem Consent-Zustand.
• UI-Test: Ablehnen-Button sichtbar, nicht versteckt, nicht deutlich nachteilig gestaltet.

4.2 Cookies, Local Storage und Browser APIs

Zu beachten:

• Seiten-JavaScript kann Cookies und Storage setzen, unabhängig vom Server.
• Tracking kann auch ohne Cookies über Local Storage, Session Storage, IndexedDB oder Fingerprinting laufen.

Automatisierte Prüfung:

• document.cookie, localStorage, sessionStorage, IndexedDB vor/nach Consent erfassen.
• Nutzung von Canvas/WebGL/AudioContext/FingerprintJS-artigen Mustern erkennen.
• Optionale Speicherzugriffe nach Ablehnung verhindern.

4.3 Externe Skripte, Fonts, Maps, Videos, Captchas

Zu beachten:

• Jeder externe Request kann personenbezogene Daten offenbaren, mindestens IP-Adresse, Browserdaten, Referrer, Zeit.
• Google Fonts lokal hosten.
• YouTube/Maps erst nach Klick/Consent.
• reCAPTCHA nur nach strenger Prüfung oder durch datenschutzfreundlichere Alternativen ersetzen.
• Social Plugins vermeiden; stattdessen reine Links oder Zwei-Klick-Lösung.

Automatisierte Prüfung:

• Netzwerkrequests zu Drittanbietern erfassen.
• Externe Domains klassifizieren: Google, Meta, X, YouTube, Fonts, CDN, Karten, Captcha.
• Vor Consent/Ablehnung dürfen optionale Drittanbieter nicht geladen werden.
• HTML nach iframes, script src, link href, img src scannen.

4.4 Webanalyse und Tag Manager

Zu beachten:

• Google Analytics, Google Tag Manager und Matomo sind regelmäßig einwilligungsbedürftig.
• GTM kann neue Tags ausspielen, ohne dass der HTML-Code geändert wird; deshalb braucht es Governance.
• Ein Consent Mode ersetzt nicht die Rechtsgrundlage.

Automatisierte Prüfung:

• GA4/GTM/Matomo-Signaturen erkennen.
• gtag consent default muss vor config/event kommen.
• dataLayer Events prüfen.
• Keine _ga/_gid/_gcl/_pk Cookies vor Consent.
• Nach Widerruf keine weiteren Analyse-Requests.

4.5 Formulare und Nutzerinteraktion

Zu beachten:

• Nur notwendige Pflichtfelder.
• Klare Datenschutzhinweise am Formular, insbesondere bei sensiblen Anliegen.
• Keine personenbezogenen Daten in GET-Parametern.
• Labels, Fehlermeldungen, Autocomplete und Barrierefreiheit.
• Uploads: Hinweise zu Dateitypen, Größe, Verarbeitung, Speicherdauer.

Automatisierte Prüfung:

• Formularfelder inventarisieren und Pflichtfelder zählen.
• GET-Formulare mit personenbezogenen Feldern erkennen.
• Labels/aria-labels prüfen.
• CSRF-Token vorhanden?
• Fehlermeldungen ohne personenbezogene Daten in URL.

4.6 Datenschutzerklärung und Impressum

Zu beachten:

• Von jeder Seite erreichbar.
• Tatsächliche Technik muss mit Text übereinstimmen.
• Google, Matomo, Karten, Videos, Captchas, CDN, Hosting, Formulare, Logs konkret benennen.
• Richtige Datenschutzaufsicht nennen.
• Speicherdauer und Rechtsgrundlagen konkret statt generisch.

Automatisierte Prüfung:

• Footer-Links auf Datenschutz/Impressum crawlen.
• Text der Datenschutzerklärung gegen erkannte Cookies, Dienste und Domains abgleichen.
• Zuständige Aufsicht anhand Betreiberprofil prüfen.
• Dead Links in Datenschutztexten prüfen.

4.7 Google Search / Inhalte / Struktur

Zu beachten:

• Wichtige amtliche Informationen müssen auffindbar, indexierbar und verständlich sein.
• Mobile-First: mobile Seite muss inhaltlich vollständig sein.
• Strukturierte Daten nur wahrheitsgemäß und passend.
• Title, Meta Description, H1 und Breadcrumbs verbessern Auffindbarkeit.

Automatisierte Prüfung:

• Title/H1/Meta Description pro URL.
• Canonical, noindex, robots meta.
• Strukturierte Daten JSON-LD validieren.
• Mobile/Desktop-Inhaltsparität prüfen.
• Sitemap-Abgleich.

4.8 Barrierefreiheit und redaktionelle Qualität

Zu beachten:

• Behördenseiten müssen barrierefrei sein; das ist nicht nur Design, sondern auch Inhalt.
• Formulare, PDFs, Videos, Karten und Cookie-Banner sind typische Problemstellen.

Automatisierte Prüfung:

• axe-core/Lighthouse.
• Überschriftenstruktur.
• Alt-Texte.
• Farbkontraste.
• Tastaturbedienbarkeit.
• Fokusreihenfolge.
• Erklärung zur Barrierefreiheit und Feedbackmechanismus.

5. Schnittstellenfälle: Wo Server- und Seitenebene zusammenwirken

5.1 Cookies

• Serverebene: Set-Cookie Header, Secure, HttpOnly, SameSite, Domain, Path, Lebensdauer.
• Seitenebene: JavaScript-Cookies, Consent-Kategorie, Bannerlogik.
• Scanner muss beide erfassen.

5.2 Referrer und externe Links

• Serverebene: Referrer-Policy Header.
• Seitenebene: Links, eingebettete Ressourcen, noreferrer/noopener.
• Risiko: personenbezogene URLs oder Suchbegriffe werden an Dritte übertragen.

5.3 Content-Security-Policy

• Serverebene: CSP Header setzen.
• Seitenebene: tatsächlich benötigte Quellen reduzieren.
• Risiko: Zu lockere CSP wegen ungeordneter Drittanbieter-Einbindungen.

5.4 Consent und serverseitige Weiterleitung

• Serverebene: serverseitiges Tagging, Proxy, Logfile-Analytics.
• Seitenebene: Banner und Consent-Signal.
• Risiko: Banner zeigt Ablehnung, Server leitet trotzdem Events weiter.

5.5 Formulare

• Serverebene: POST-Verarbeitung, Mailversand, Speicherung, CSRF, Uploadprüfung.
• Seitenebene: Felder, Labels, Datenschutzhinweise, GET/POST, Validierung.
• Risiko: Seite wirkt korrekt, Backend leitet Daten unsicher weiter.

6. Rollen- und Verantwortlichkeitsmatrix

7. Minimaler automatisierter Prüfablauf getrennt nach Ebenen

Server-Scan

1. DNS: A/AAAA/CNAME/MX/TXT/CAA/DNSSEC.
2. TLS: Zertifikat, Protokolle, Cipher, Ablauf.
3. HTTP: Redirects, HSTS, Header, Statuscodes.
4. Cookies aus Response Headern.
5. Security: security.txt, Admin-Leaks, Versionslecks.
6. Safe Browsing / Malwarestatus.
7. Optional: CMS-/Dependency-/CVE-Scan.

Seiten-Scan

1. Headless Browser ohne Consent.
2. Cookies/Storage/Requests/Screenshot erfassen.
3. Consent „Ablehnen“ klicken und erneut erfassen.
4. Consent „Akzeptieren“ klicken und erneut erfassen.
5. Widerruf testen.
6. DOM prüfen: externe Skripte, iframes, Formulare, Datenschutzlinks.
7. Lighthouse/axe für Performance, SEO, Accessibility.
8. Datenschutzerklärung gegen echte Dienste abgleichen.

8. Empfohlene Berichtsdarstellung

Jeder Befund sollte eine Ebene ausweisen:

• Ebene: Server / Seite / Schnittstelle
• Kategorie: Datenschutz / Sicherheit / Google / Barrierefreiheit
• Beobachtung
• Evidenz
• Handlungsempfehlung
• Verantwortliche Rolle
• Quelle

Beispiel Serverbefund:

Ebene: Server Kategorie: Sicherheit/Datenschutz Beobachtung: Session-Cookie wird ohne SameSite-Attribut gesetzt. Evidenz: Set-Cookie: SESSION=...; Secure; HttpOnly Handlungsempfehlung: SameSite=Lax oder Strict setzen; fachliche Auswirkungen testen. Verantwortlich: IT-Betrieb/CMS-Betrieb. Quelle: BSI APP.3.1 Webanwendungen und Webservices.

Beispiel Seitenbefund:

Ebene: Seite Kategorie: Datenschutz/Google Beobachtung: fonts.googleapis.com wird beim Erstaufruf geladen. Evidenz: Browser-HAR Request vor Consent. Handlungsempfehlung: Schrift lokal hosten oder Systemfont verwenden. Verantwortlich: Frontend/Webagentur. Quelle: BfDI Cookies/Tracking, DSK digitale Dienste, Google Fonts FAQ.

Beispiel Schnittstellenbefund:

Ebene: Schnittstelle Kategorie: Datenschutz/Consent Beobachtung: Banner-Ablehnung verhindert Google Analytics im Browser, aber ein First-Party-Endpunkt /collect erhält weiterhin Nutzungsereignisse. Evidenz: POST /collect nach Ablehnung mit Client-ID. Handlungsempfehlung: serverseitiges Tracking an Consent-Signal koppeln und bei Ablehnung deaktivieren. Verantwortlich: IT-Betrieb + Frontend + Datenschutz. Quelle: DSK Telemedien/digitale Dienste, Google Consent Mode Dokumentation.

Bußgeld- und Sanktionsrisiken bei Nicht-Einhaltung

Stand: 2026-06-07

Zweck: Diese Ergänzung ordnet die zuvor beschriebenen Server-, Seiten- und Schnittstellenanforderungen danach ein, ob bei Nicht-Einhaltung typischerweise ein Bußgeld-/Sanktionsrisiko entstehen kann. Die Einordnung ist risikoorientiert und ersetzt keine juristische Einzelfallprüfung. Gerade bei öffentlichen Stellen können je nach Bundesland Sonderregeln gelten; manche Landesdatenschutzgesetze beschränken oder modifizieren Geldbußen gegen öffentliche Stellen. Trotzdem können Datenschutzaufsichten Anordnungen, Verwarnungen, Untersagungen, Prüfungen und Reputationsfolgen auslösen.

Wichtige Rechtsgrundlagen/Quellen:

• Art. 83 DSGVO, Allgemeine Bedingungen für die Verhängung von Geldbußen: https://dsgvo-gesetz.de/art-83-dsgvo/
• Art. 58 DSGVO, Befugnisse der Aufsichtsbehörden: https://dsgvo-gesetz.de/art-58-dsgvo/
• § 25 TDDDG, Schutz der Privatsphäre bei Endeinrichtungen: https://www.gesetze-im-internet.de/ttdsg/__25.html
• § 28 TDDDG, Bußgeldvorschriften: https://www.gesetze-im-internet.de/ttdsg/__28.html
• § 5 DDG, Allgemeine Informationspflichten: https://www.gesetze-im-internet.de/ddg/__5.html
• § 33 DDG, Bußgeldvorschriften: https://www.gesetze-im-internet.de/ddg/__33.html
• § 12a BGG, Barrierefreie Informationstechnik: https://www.gesetze-im-internet.de/bgg/__12a.html
• § 12b BGG, Erklärung zur Barrierefreiheit: https://www.gesetze-im-internet.de/bgg/__12b.html
• § 130 OWiG, Verletzung der Aufsichtspflicht in Betrieben und Unternehmen: https://www.gesetze-im-internet.de/owig_1968/__130.html
• EDPB Guidelines 04/2022 on the calculation of administrative fines under the GDPR: https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-042022-calculation-administrative-fines-under_en

1. Grundsatz: Was kann Bußgeldrisiken auslösen?

Bußgeldrelevant sind vor allem Verstöße gegen:

1. DSGVO-Grundsätze und Rechtmäßigkeit

• Verarbeitung ohne Rechtsgrundlage.
• Verstoß gegen Transparenz, Zweckbindung, Datenminimierung, Speicherbegrenzung.
• Fehlende oder unwirksame Einwilligung.
• Unzulässige Drittlandübermittlung.

1. Betroffenenrechte und Informationspflichten

• unvollständige Datenschutzerklärung.
• falsche oder fehlende Angaben zu Verantwortlichem, Rechtsgrundlagen, Empfängern, Speicherdauer, Betroffenenrechten, Aufsicht.
• fehlende oder nicht bearbeitete Auskunfts-/Lösch-/Widerspruchsprozesse.

1. Technische und organisatorische Maßnahmen

• unzureichende Sicherheit nach Art. 32 DSGVO.
• fehlendes Patchmanagement, unsichere Formulare, unsichere Zugänge, fehlerhafte Logik.
• Datenschutzverletzungen durch technische Mängel.

1. Cookies/Endgerätezugriff

• nicht notwendige Cookies, Local Storage, Tracking-Pixel oder Fingerprinting ohne vorherige wirksame Einwilligung nach § 25 TDDDG/ePrivacy.

1. Auftragsverarbeitung/Dienstleister

• fehlende AV-Verträge.
• unkontrollierte Unterauftragnehmer.
• unzulässige Übermittlung an Drittanbieter.

1. Impressums-/Informationspflichten

• fehlende oder falsche Anbieterkennzeichnung nach DDG kann separat bußgeldbewehrt sein.

Nicht jeder technische Mangel führt automatisch zu einem Bußgeld. Manche Punkte sind eher „Compliance-/Qualitäts-/Google-/BSI-Hinweise“. Bußgeldrelevant wird es typischerweise, wenn personenbezogene Daten betroffen sind, gesetzliche Informationspflichten verletzt werden, Endgeräte ohne Einwilligung ausgelesen werden, Sicherheitsmängel zu Risiken oder Vorfällen führen oder behördliche Anordnungen ignoriert werden.

2. Bußgeldrisiko-Matrix nach Ebene

3. Serverebene: bußgeldrelevante Punkte

3.1 Kein HTTPS oder unsichere Übertragung

Warum bußgeldrelevant:

• Wenn personenbezogene Daten über Kontaktformulare, Anträge, Suchanfragen mit Personenbezug oder Logins übertragen werden, ist fehlendes HTTPS regelmäßig ein Verstoß gegen angemessene technische und organisatorische Maßnahmen nach Art. 32 DSGVO.
• Besonders kritisch bei Gesundheits-, Sozial-, Melde-, Bau-, Steuer-, Ausländer-, Schul- oder sonstigen sensiblen Verwaltungsdaten.

Prüfung:

• HTTP erreichbar?
• Formularseiten nur per HTTPS?
• Mixed Content?
• HSTS?
• TLS-Version/Cipher nach BSI-Mindeststandard?

Risiko: sehr hoch bei Formularen/Login/Anträgen; mittel bei rein statischen Informationsseiten.

3.2 Unsichere Session- und Auth-Cookies

Warum bußgeldrelevant:

• Fehlende Secure-/HttpOnly-/SameSite-Attribute können Sessiondiebstahl, CSRF oder ungewollte Übertragung begünstigen.
• Bei personenbezogenen Backend-/Nutzerkonten ist das Art.-32-DSGVO-relevant.

Prüfung:

• Set-Cookie Header erfassen.
• Session-Cookies ohne Secure auf HTTPS-Seiten markieren.
• HttpOnly bei Session-Cookies verlangen.
• SameSite=Lax/Strict prüfen; None nur mit Secure und Begründung.

Risiko: hoch.

3.3 Serverlogs ohne Konzept

Warum bußgeldrelevant:

• IP-Adressen, Zeitstempel, URLs, Referrer und User-Agent können personenbezogen sein.
• Ohne Zweck, Rechtsgrundlage, Löschfrist und Zugriffskontrolle drohen Verstöße gegen Art. 5, 6 und 32 DSGVO.

Prüfung:

• Welche Felder werden geloggt?
• Wie lange werden Logs aufbewahrt?
• Wer hat Zugriff?
• Enthalten URLs personenbezogene Query-Parameter?
• Werden Logs mit Analyse- oder Matomo-Daten zusammengeführt?

Risiko: mittel bis hoch; sehr hoch bei sensiblen URLs oder langer Speicherung ohne Zweck.

3.4 Hoster, CDN, WAF, CMP und sonstige Dienstleister ohne AVV

Warum bußgeldrelevant:

• Dienstleister, die personenbezogene Daten im Auftrag verarbeiten, benötigen regelmäßig einen Vertrag nach Art. 28 DSGVO.
• Bei gemeinsam Verantwortlichen kann Art. 26 DSGVO relevant sein.
• Bei Drittlandtransfers zusätzlich Art. 44 ff. DSGVO.

Prüfung:

• Externe Dienstleister aus DNS/Header/Requests erkennen.
• AVV/Joint-Controller-Dokumentation abfragen.
• Drittlandtransfer prüfen.
• Unterauftragnehmer dokumentieren.

Risiko: hoch.

3.5 Ungepatchtes CMS, Plugins, Adminzugänge

Warum bußgeldrelevant:

• Sicherheitsmängel können zu Datenschutzverletzungen führen.
• Art. 32 DSGVO verlangt ein dem Risiko angemessenes Schutzniveau.
• Bei Datenabfluss können Meldepflichten nach Art. 33/34 DSGVO entstehen.

Prüfung:

• CMS-/Plugin-Versionen.
• Adminpfade, MFA, Rate Limiting.
• bekannte CVEs.
• Upload-Endpunkte.
• Sicherheitsupdates/Release-Stand.

Risiko: hoch bis sehr hoch.

3.6 Serverseitiges Tracking / server-side Tagging

Warum bußgeldrelevant:

• Server-side Tagging kann personenbezogene Ereignisse trotz Browser-Consent-Ablehnung an Dritte weitergeben.
• Nutzer können die Verarbeitung schwerer erkennen; Transparenz- und Einwilligungsrisiko.

Prüfung:

• First-Party-Endpunkte wie /collect, /events, /gtm, /analytics.
• Payloads nach IDs, Consent-Signalen, User-Agent/IP-Weiterleitung.
• Abgleich mit CMP-Entscheidung.

Risiko: sehr hoch, wenn trotz Ablehnung übermittelt wird.

4. Seitenebene: bußgeldrelevante Punkte

4.1 Tracking und Cookies vor Einwilligung

Warum bußgeldrelevant:

• § 25 TDDDG verlangt für nicht notwendiges Speichern/Auslesen auf Endeinrichtungen grundsätzlich vorherige Einwilligung.
• Nachfolgende Verarbeitung personenbezogener Daten benötigt zusätzlich eine DSGVO-Rechtsgrundlage.

Typische Verstöße:

• _ga, _gid, _gcl, _fbp, _pk_id vor Consent.
• LocalStorage-ID vor Consent.
• Tracking-Pixel beim Erstaufruf.
• Fingerprinting-Skripte ohne Einwilligung.

Risiko: sehr hoch.

4.2 Unwirksames Consent-Banner

Warum bußgeldrelevant:

• Wenn die Einwilligung unwirksam ist, fehlt für die anschließende Verarbeitung oft die Rechtsgrundlage.

Typische Verstöße:

• kein Ablehnen auf erster Ebene.
• Ablehnen deutlich schwieriger als Akzeptieren.
• vorangekreuzte optionale Kategorien.
• Scrollen/Weitersurfen gilt als Zustimmung.
• unklare Zwecke wie „Nutzererlebnis verbessern“ ohne konkrete Anbieter/Daten.
• Widerruf versteckt oder nur über Browser-Add-on.

Risiko: hoch bis sehr hoch.

4.3 Google Analytics / Google Tag Manager

Warum bußgeldrelevant:

• DSK/BfDI sehen Google Analytics regelmäßig als einwilligungsbedürftig an.
• Google muss als Empfänger genannt werden.
• Vor Einwilligung dürfen keine Daten erhoben und keine Google-Elemente nachgeladen werden.
• IP-Kürzung macht die Verarbeitung nicht anonym.

Prüfung:

• GA/GTM Requests vor Consent.
• Google Cookies vor Consent.
• Consent Mode default vor config/event.
• Google als Empfänger und eigene Zwecke transparent beschrieben.
• Widerruf auf Website möglich.

Risiko: sehr hoch bei Laden vor Consent; hoch bei unvollständiger Transparenz.

4.4 Matomo

Warum bußgeldrelevant:

• BfDI bewertet Matomo grundsätzlich als einwilligungsbedürftig, weil Skript/Cookie/Parameter und Endeinrichtungszugriff nicht unbedingt erforderlich sind.
• Personenbezug kann über IP, IDs und Logabgleich entstehen.

Prüfung:

• matomo.js/piwik.js vor Consent.
• _pk_* Cookies.
• cookieless Fingerprinting/Config-ID.
• IP-/Log-Konzept.

Risiko: hoch, wenn ohne Consent oder ohne tragfähige Ausnahme.

4.5 Remote Fonts, Maps, YouTube, reCAPTCHA, Social Plugins

Warum bußgeldrelevant:

• Externe Ressourcen übertragen mindestens IP-Adresse, User-Agent, Referrer und Zeitpunkt an Dritte.
• Bei Google/anderen Drittanbietern können eigene Zwecke, Drittlandtransfer und Endeinrichtungszugriff hinzukommen.

Typische Bewertung:

• Google Fonts remote: mittel bis hoch; leicht vermeidbar durch lokales Hosting.
• YouTube/Maps vor Aktivierung: hoch.
• reCAPTCHA pauschal auf allen Formularseiten: hoch, besonders wegen Umfang/Barrierefreiheit/Alternativen.
• Social Plugins: hoch, wenn Daten beim Seitenaufruf fließen.

Prüfung:

• Netzwerkrequests vor Consent.
• iframes/scripts/img/link-Tags zu Drittanbietern.
• Zwei-Klick-Lösung.
• Datenschutzerklärung nennt Anbieter konkret.

4.6 Datenschutzerklärung falsch oder unvollständig

Warum bußgeldrelevant:

• Art. 12/13 DSGVO verlangen transparente Informationen.
• Ein generischer Text, der die tatsächlichen Dienste nicht nennt, ist riskant.

Typische Verstöße:

• Google/Matomo/CMP/CDN/Hoster/Formulare fehlen.
• Rechtsgrundlagen unkonkret oder falsch.
• Speicherdauer fehlt.
• Empfänger/Drittlandtransfer fehlt.
• falsche Aufsichtsbehörde.
• Datenschutzbeauftragter fehlt, obwohl erforderlich.

Risiko: hoch.

4.7 Formulare mit übermäßigen oder unsicheren Daten

Warum bußgeldrelevant:

• Datenminimierung, Zweckbindung, Integrität und Vertraulichkeit.

Typische Verstöße:

• unnötige Pflichtfelder.
• sensible Daten ohne besonderen Schutz.
• Übermittlung per GET.
• personenbezogene Daten in Bestätigungsmails im Klartext.
• fehlende Hinweise zur Verarbeitung.

Risiko: mittel bis sehr hoch je nach Datenkategorie.

5. Punkte mit eher geringem direktem Bußgeldrisiko, aber hoher Betriebs-/Qualitätsrelevanz

Diese Punkte lösen für sich genommen normalerweise kein Datenschutzbußgeld aus, können aber mittelbar relevant werden oder behördliche Qualitätsanforderungen verletzen:

• fehlende oder schlechte Meta Description.
• schlechte Core Web Vitals.
• fehlende strukturierte Daten.
• unvollständige Sitemap.
• nicht optimale Breadcrumbs.
• fehlendes Favicon.
• langsame Seiten ohne Personenbezug.

Aber: Wenn schlechte Technik dazu führt, dass Datenschutzinformationen nicht erreichbar sind, Formulare fehlerhaft arbeiten, Cookie-Banner nicht bedienbar sind oder Barrierefreiheitsanforderungen verletzt werden, kann daraus ein rechtliches oder aufsichtsrelevantes Problem werden.

6. Barrierefreiheit: Bußgeld oder andere Sanktionen?

Für öffentliche Stellen ist Barrierefreiheit eine Pflicht. Der Schwerpunkt liegt häufig nicht auf DSGVO-Bußgeldern, sondern auf:

• Überwachungsverfahren.
• Beanstandungen.
• Verpflichtung zur Nachbesserung.
• Feedback-/Durchsetzungsverfahren.
• Reputations- und Vergaberisiken.
• fachaufsichtlichen Folgen.

Bußgeldrisiko im engeren Datenschutzsinne entsteht eher, wenn Barrierefreiheitsmängel Datenschutzrechte praktisch verhindern, z.B.:

• Consent-Banner ist per Tastatur/Screenreader nicht bedienbar.
• Datenschutzerklärung ist nicht erreichbar.
• Betroffenenrechtsformular ist nicht nutzbar.
• Captcha schließt Menschen aus und zwingt zu unnötigen Drittanbieterdiensten.

Risiko: niedrig bis mittel als Datenschutzbußgeld, aber hoch als Behördenpflicht/Compliance-Thema.

7. Priorisierte Bußgeld-Checkliste für den Scanner

Kritisch / sehr hohes Bußgeldrisiko

• [ ] Kontakt-/Antragsformular ohne HTTPS.
• [ ] Google Analytics/GTM/Ads/Meta Pixel vor Consent.
• [ ] Tracking-Cookies oder Tracking-Storage vor Consent.
• [ ] serverseitiges Tracking trotz Ablehnung.
• [ ] Drittanbieterübermittlung sensibler Daten.
• [ ] personenbezogene Daten in URL-Parametern, die an Dritte/Logs gehen.
• [ ] ungepatchtes CMS mit bekanntem Datenabflussrisiko.
• [ ] fehlender AVV/Drittlandprüfung bei zentralen Dienstleistern.
• [ ] Datenschutzerklärung fehlt vollständig.

Hoches Bußgeldrisiko

• [ ] Consent-Banner ohne gleichwertiges Ablehnen.
• [ ] vorangekreuzte optionale Einwilligungen.
• [ ] Matomo ohne Consent oder tragfähige Ausnahme.
• [ ] YouTube/Maps/reCAPTCHA vor Aktivierung.
• [ ] Session-Cookies ohne sichere Attribute.
• [ ] Serverlogs ohne Lösch-/Zugriffskonzept.
• [ ] Datenschutzerklärung nennt tatsächliche Dienste nicht.
• [ ] falsche Rechtsgrundlagen für Tracking/Webanalyse.

Mittleres Bußgeldrisiko

• [ ] Google Fonts remote ohne Notwendigkeit/Transparenz.
• [ ] unvollständiges Impressum/Anbieterkennzeichnung.
• [ ] zu lange Cookie-Laufzeiten.
• [ ] Referrer-Policy fehlt bei personenbezogenen URLs.
• [ ] unnötige Pflichtfelder in Formularen.
• [ ] CDN/WAF nicht transparent dokumentiert.

Eher kein Bußgeld, aber Handlungsbedarf

• [ ] schlechte Core Web Vitals.
• [ ] fehlende strukturierte Daten.
• [ ] unvollständige Sitemap.
• [ ] suboptimale Titles/Meta Descriptions.
• [ ] fehlendes Favicon.

8. Berichtsdarstellung für Bußgeldrisiken

Jeder Befund sollte nicht pauschal „Bußgeld droht“ sagen, sondern sauber abstufen:

• Bußgeldbezug: ja / möglich / mittelbar / nein.
• Rechtsbereich: DSGVO / TDDDG / DDG / BGG-BITV / BSI-Stand der Technik / Google-Qualität.
• Risiko: sehr hoch / hoch / mittel / niedrig.
• Begründung: konkrete Verarbeitung oder Pflichtverletzung.
• Evidenz: Request, Cookie, Header, Screenshot, Textstelle, Konfigurationsauszug.
• Sofortmaßnahme.
• Verantwortliche Ebene: Server / Seite / Schnittstelle.

Beispiel:

Ebene: Seite Bußgeldbezug: ja, möglich bis hoch Rechtsbereich: § 25 TDDDG, Art. 6/7/13 DSGVO Beobachtung: Beim Erstaufruf wird _ga gesetzt und ein Request an google-analytics.com gesendet, bevor der Nutzer eine Einwilligung erteilt. Evidenz: HAR Request, Cookie-Snapshot, Screenshot des Banners. Empfehlung: GA/GTM blockieren, bis aktive Einwilligung vorliegt; Consent Mode default vor Tag-Auslösung auf denied setzen; Datenschutzerklärung aktualisieren.

Beispiel:

Ebene: Server Bußgeldbezug: ja, möglich bis sehr hoch Rechtsbereich: Art. 32 DSGVO Beobachtung: Kontaktformular ist über HTTP erreichbar und übermittelt Name, E-Mail-Adresse und Nachricht unverschlüsselt. Evidenz: URL, HTTP-Status, Formularmethode, Netzwerkprotokoll. Empfehlung: HTTPS erzwingen, HSTS aktivieren, HTTP auf HTTPS weiterleiten, Formular-Endpunkt nur per HTTPS akzeptieren.

9. Wichtig für Behörden

Bei Behörden muss der Report sprachlich vorsichtig sein:

• Nicht automatisch „Bußgeld sicher“ schreiben.
• Besser: „Bußgeld-/Sanktionsrisiko“, „aufsichtsrechtlich relevant“, „kann eine Anordnung/Prüfung auslösen“.
• Technische-only Befunde als „Hinweise“ bezeichnen, sofern keine klare Datenschutzverletzung vorliegt.
• Bei öffentlichen Stellen zusätzlich angeben: „Bußgeldfähigkeit kann landesrechtlich abweichen; unabhängig davon besteht Nachbesserungs- und Anordnungsrisiko.“

Weitere europäische Behördenquellen zu Webseiten, Cookies, Tracking, Analytics und Sicherheit

Stand: 2026-06-07

Diese Ergänzung erweitert den Leitfaden um Quellen anderer europäischer Datenschutz- und Cybersicherheitsbehörden. Ziel ist nicht, deutsches Recht durch ausländische Leitlinien zu ersetzen, sondern typische europäische Aufsichtslinien sichtbar zu machen. Für deutsche Behörden bleiben DSK/BfDI/Landesaufsichten, DSGVO, TDDDG, BSI und BITV maßgeblich. Die europäischen Quellen sind aber wertvoll, weil sie konkrete Prüfkriterien zu Cookies, Analytics, Consent-Bannern, Google-Diensten, Tracking und Websicherheit liefern.

1. Frankreich: CNIL

1.1 Cookies und andere Tracker

Quelle: CNIL, Cookies and other tracking devices: the CNIL publishes new guidelines https://www.cnil.fr/en/cookies-and-other-tracking-devices-cnil-publishes-new-guidelines

Kernaussagen:

• Tracker, die nicht strikt erforderlich sind, benötigen grundsätzlich eine Einwilligung.
• Nutzer müssen Einwilligung genauso leicht verweigern können wie sie erteilt werden kann.
• Bloßes Weitersurfen reicht nicht als Einwilligung.
• Einwilligung muss nachweisbar sein.
• Nutzer müssen ihre Entscheidung jederzeit widerrufen können.

Relevanz für unseren Prüfkatalog:

• Stützt die DSK-Linie zu gleichwertigem „Ablehnen“ und „Akzeptieren“.
• Sehr relevant für Cookie-Banner-UI-Prüfungen.
• Automatisierbar durch Button-/Flow-Tests: Akzeptieren, Ablehnen, Einstellungen, Widerruf.

1.2 Analytics auf Webseiten und Apps

Quelle: CNIL, Sheet n°16: Use analytics on your websites and applications https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications

Kernaussagen:

• Analytics kann unter engen Voraussetzungen ohne Einwilligung möglich sein, wenn es ausschließlich zur anonymen/statistischen Messung der eigenen Website/App dient und stark begrenzt ist.
• Die CNIL nennt Bedingungen wie beschränkte Zwecke, keine seitenübergreifende Verfolgung, begrenzte Speicherfristen, keine Weitergabe/Verknüpfung und keine Re-Identifikation.
• Für viele marktübliche Drittanbieter-Analytics und Werbefunktionen bleibt Einwilligung erforderlich.

Relevanz für unseren Prüfkatalog:

• Gute Quelle für eine Ausnahmeprüfung bei rein interner Reichweitenmessung.
• Für deutsche Behörden vorsichtig verwenden: BfDI bewertet Matomo grundsätzlich einwilligungsbedürftig; eine CNIL-Ausnahme ist kein automatischer Freibrief in Deutschland.

Automatisierbare Prüfpunkte:

• Wird Analytics nur auf eigener Domain betrieben?
• Gibt es eindeutige Nutzer-IDs oder seitenübergreifendes Tracking?
• Werden Daten an Dritte gesendet?
• Speicherfristen und IP-Anonymisierung prüfen.
• Wird das Analyse-Tool mit Werbe-/Profilingfunktionen kombiniert?

2. Vereinigtes Königreich: ICO

Quelle: ICO, Cookies and similar technologies https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/cookies-and-similar-technologies/

Kernaussagen:

• Cookies und ähnliche Technologien benötigen im UK-Kontext nach PECR grundsätzlich klare und umfassende Informationen sowie Consent, sofern sie nicht strikt erforderlich sind.
• Analytics-Cookies sind nach ICO typischerweise nicht „strictly necessary“.
• Consent muss aktiv, informiert und frei gewählt sein.
• Cookie-Walls und manipulative Gestaltung sind kritisch.
• Auch ähnliche Technologien jenseits klassischer Cookies sind erfasst.

Relevanz für unseren Prüfkatalog:

• Bestätigt, dass Analyse-Cookies nicht automatisch technisch notwendig sind.
• Unterstützt Prüfung von Local Storage, Pixeln und Fingerprinting.
• Gute Vergleichsquelle für Banner- und Analytics-Tests.

Automatisierbare Prüfpunkte:

• Werden Analytics-Cookies als „notwendig“ klassifiziert?
• Sind ähnliche Technologien im Scanner enthalten: LocalStorage, SessionStorage, IndexedDB, Pixel, Fingerprinting?
• Ist Consent aktiv und granular?

3. Spanien: AEPD

Quelle: AEPD, Guide on the use of cookies https://www.aepd.es/guides/guide-on-use-of-cookies.pdf

Kernaussagen:

• Die spanische Datenschutzaufsicht beschreibt detailliert Informationspflichten, Consent-Anforderungen und Ausnahmen für technische Cookies.
• Cookie-Banner müssen klare Informationen, Akzeptieren/Ablehnen und Konfigurationsmöglichkeiten bieten.
• Die AEPD behandelt ebenfalls Analytics- und Werbe-Cookies als einwilligungsrelevant, sofern keine strenge Ausnahme greift.

Relevanz für unseren Prüfkatalog:

• Nützlich für UI- und Textanforderungen an Cookie-Banner.
• Unterstützt die Einstufung von „Ablehnen“ als echte, sichtbare Auswahl.
• Hilfreich für granulare Zweck-/Anbieterlisten.

Automatisierbare Prüfpunkte:

• Erste Banner-Ebene: klare Information + Akzeptieren + Ablehnen + Einstellungen.
• Zweite Ebene: Zweckkategorien und Anbieter.
• Keine voraktivierten optionalen Kategorien.
• Nach Ablehnung keine optionalen Cookies/Requests.

4. Italien: Garante per la protezione dei dati personali

Quelle: Garante, Linee guida cookie e altri strumenti di tracciamento https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9677876

Kernaussagen:

• Garante behandelt Cookies und andere Tracking-Instrumente umfassend.
• Technische Cookies unterscheiden sich von Profiling-/Tracking-Cookies.
• Einwilligungsbanner müssen echte Wahlmöglichkeiten bieten.
• Scrollen allein ist keine gültige Einwilligung, sofern es nicht in einem sehr spezifischen technischen Prozess eine eindeutige aktive Handlung bildet.
• Nutzer müssen Einstellungen ändern und Einwilligungen widerrufen können.

Relevanz für unseren Prüfkatalog:

• Bestätigt die europäische Linie gegen „Scrollen = Consent“.
• Unterstützt Prüfung von Profiling-Cookies, Drittanbieter-Cookies und Widerruf.

Automatisierbare Prüfpunkte:

• Keine Zustimmung durch Scroll/Weiternutzung.
• Widerruf dauerhaft erreichbar.
• Profiling-/Marketing-Cookies nur nach Consent.
• Drittanbieter klar ausgewiesen.

5. Irland: Data Protection Commission (DPC)

Quelle: DPC, Guidance on cookies and other tracking technologies https://www.dataprotection.ie/en/dpc-guidance/guidance-cookies-and-other-tracking-technologies

Kernaussagen:

• Cookies und Tracking-Technologien benötigen klare Informationen und gültige Einwilligung, sofern sie nicht notwendig sind.
• Pre-checked boxes, implizite Zustimmung und unklare Banner sind problematisch.
• Cookie-Laufzeiten, Zweckbindung und Drittanbieter müssen transparent sein.
• Analytics und Marketing sind besonders zu prüfen.

Relevanz für unseren Prüfkatalog:

• Irland ist wegen vieler großer Tech-Unternehmen als Sitzland relevant.
• Gute Vergleichsquelle für Google-/Meta-/Drittanbieterfälle.

Automatisierbare Prüfpunkte:

• Pre-checked boxes erkennen.
• Cookie-Laufzeiten und Zweckbindung prüfen.
• Drittanbieter-/Vendor-Liste gegen echte Requests abgleichen.

6. Frankreich: ANSSI / Cyber.gouv.fr zu TLS

Quelle: ANSSI/Cyber.gouv.fr, Recommandations de sécurité relatives à TLS https://messervices.cyber.gouv.fr/guides/recommandations-de-securite-relatives-tls

Kernaussagen:

• TLS-Konfiguration muss dem Stand der Technik entsprechen.
• Veraltete Protokolle und schwache Cipher Suites sind zu vermeiden.
• Zertifikate, Schlüssel, Protokollversionen und Konfigurationen müssen regelmäßig geprüft werden.

Relevanz für unseren Prüfkatalog:

• Ergänzt BSI-Mindeststandard TLS mit einer weiteren europäischen Cybersecurity-Quelle.
• Besonders relevant für Serverebene.

Automatisierbare Prüfpunkte:

• TLS-Versionen.
• Cipher Suites.
• Zertifikatskette und Ablauf.
• HSTS.
• Schwache Algorithmen/Protokolle.

7. Einordnung: Europäische Gemeinsamkeiten

Über die genannten Behörden hinweg zeigen sich gemeinsame Mindestlinien:

1. Nicht notwendige Cookies und Tracker brauchen vorherige wirksame Einwilligung.
2. Analytics ist meist nicht technisch notwendig; Ausnahmen sind eng und müssen technisch streng begrenzt sein.
3. Ablehnen muss real, sichtbar und einfach möglich sein.
4. Scrollen, Weitersurfen und voraktivierte Optionen sind keine belastbare Einwilligung.
5. Widerruf muss einfach und dauerhaft erreichbar sein.
6. Drittanbieter und eigene Zwecke der Drittanbieter müssen transparent sein.
7. Cookie-/Tracking-Prüfung muss auch Local Storage, Pixel, Fingerprinting und SDK-/Tag-Technologien erfassen.
8. TLS und Webserver-Sicherheit sind Datenschutz-Basisschutz.

8. Zusätzliche europäische Quellenliste

• CNIL, Cookies and other tracking devices: https://www.cnil.fr/en/cookies-and-other-tracking-devices-cnil-publishes-new-guidelines
• CNIL, Use analytics on your websites and applications: https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications
• ICO, Cookies and similar technologies: https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/cookies-and-similar-technologies/
• AEPD, Guide on the use of cookies: https://www.aepd.es/guides/guide-on-use-of-cookies.pdf
• Garante, Cookie and other tracking tools guidelines: https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9677876
• DPC Ireland, Guidance on cookies and other tracking technologies: https://www.dataprotection.ie/en/dpc-guidance/guidance-cookies-and-other-tracking-technologies
• ANSSI/Cyber.gouv.fr, TLS security recommendations: https://messervices.cyber.gouv.fr/guides/recommandations-de-securite-relatives-tls

9. Konsequenz für den Scanner

Der Scanner sollte neben den deutschen Quellen eine Spalte „europäische Vergleichslinie“ führen. Diese Spalte kann insbesondere bei Cookie-/Consent- und Analytics-Befunden hilfreich sein:

• Wenn ein Befund von DSK/BfDI und zusätzlich CNIL/ICO/AEPD/Garante/DPC gestützt wird, ist die europäische Aufsichtslinie stark.
• Wenn eine ausländische Behörde eine engere Ausnahme erlaubt, z.B. CNIL bei stark begrenzter Analytics-Messung, muss der Report klar sagen: „Für Deutschland nicht automatisch übertragbar; anhand DSK/BfDI/TDDDG gesondert prüfen.“
• Für Behörden-Webseiten sollte die strengere, datensparsamere Variante als Zielbild gelten.

Zusätzliche Behördenquellen aus den USA und China: praktische Tipps für Behörden-Webseiten

Stand: 2026-06-07

Diese Ergänzung nimmt außereuropäische Behördenquellen auf. Sie sind für deutsche Behörden-Webseiten nicht unmittelbar maßgeblich, liefern aber nützliche Vergleichslinien und technische Best Practices. Für den Handlungsleitfaden sollten sie als zusätzliche „Good Practice“-Quellen verwendet werden, nicht als Ersatz für DSGVO, TDDDG, DSK/BfDI, Landesaufsichten, BSI und BITV.

1. USA: Datenschutz, Tracking, Security und Accessibility

1.1 Federal Trade Commission (FTC): Privacy & Security

Quellen:

• FTC, Privacy and Security: https://www.ftc.gov/business-guidance/privacy-security
• FTC, Data Security: https://www.ftc.gov/business-guidance/privacy-security/data-security
• FTC, Protecting Personal Information: A Guide for Business: https://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-business-0
• FTC Consumer Advice, How Websites and Apps Collect and Use Your Information: https://consumer.ftc.gov/articles/how-websites-apps-collect-use-your-information

Kernaussagen:

• Organisationen sollen nur personenbezogene Informationen erheben, die sie wirklich benötigen.
• Datenschutz- und Sicherheitsversprechen müssen wahr, klar und einhaltbar sein.
• Sensible Daten brauchen besondere Schutzmaßnahmen.
• Daten sollten nur so lange aufbewahrt werden, wie es einen legitimen Zweck gibt.
• Dienstleister müssen kontrolliert werden.
• Sicherheit muss organisatorisch und technisch umgesetzt werden: Zugriffsbeschränkung, Verschlüsselung, sichere Entwicklung, Patchmanagement, Monitoring.

Relevanz für deutsche Behörden-Webseiten:

• Sehr gut als zusätzliche Best-Practice-Quelle für Datenminimierung, Transparenz und Security-by-Design.
• Besonders nützlich bei Datenschutzerklärung: Was versprochen wird, muss technisch stimmen.
• Unterstützt die Empfehlung, Tracking, Drittanbieter und Datenerhebung auf Behörden-Webseiten strikt zu minimieren.

Automatisierbare Prüfpunkte:

• Stimmt Datenschutzerklärung mit tatsächlich beobachteten Requests/Cookies/Formularen überein?
• Werden Daten erhoben, die für den Dienst nicht plausibel nötig sind?
• Gibt es klare Löschfristen?
• Werden Drittanbieter und Dienstleister erkennbar genannt?
• Sind sensible Formularbereiche besonders geschützt?

1.2 NIST Privacy Framework und Cybersecurity Framework

Quellen:

• NIST Privacy Framework: https://www.nist.gov/privacy-framework
• NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
• NIST SP 800-63B, Digital Identity Guidelines / Authentication and Lifecycle Management: https://pages.nist.gov/800-63-3/sp800-63b.html

Kernaussagen:

• Datenschutzrisiken sollen systematisch identifiziert, gesteuert und überwacht werden.
• Cybersecurity soll nach Funktionen wie Identify, Protect, Detect, Respond, Recover organisiert werden.
• Authentisierung, Passwörter, Sessions und MFA müssen risikoorientiert gestaltet werden.

Relevanz für deutsche Behörden-Webseiten:

• Gute Struktur für Governance und dauerhaften Betrieb.
• Hilfreich, um Scanner-Ergebnisse in Risikomanagement zu überführen.
• Nützlich für Login-/Bürgerkonto-/Adminbereiche.

Automatisierbare Prüfpunkte:

• Asset- und Dienstleisterinventar vorhanden?
• Admin-/Loginbereiche MFA- und Rate-Limit-fähig?
• Session-Cookies sicher?
• Sicherheitsmonitoring und Incident-Prozess vorhanden?
• Wiederkehrende Scans und Patchmanagement dokumentiert?

1.3 CISA: Cyber Essentials, Secure by Design, Known Exploited Vulnerabilities

Quellen:

• CISA Cyber Essentials: https://www.cisa.gov/resources-tools/resources/cyber-essentials
• CISA Secure by Design: https://www.cisa.gov/securebydesign
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Kernaussagen:

• Sicherheitsmaßnahmen sollen nicht nur reaktiv sein, sondern in Design, Betrieb und Lieferkette verankert werden.
• Bekannte aktiv ausgenutzte Schwachstellen müssen priorisiert gepatcht werden.
• Verantwortlichkeiten, Konfigurationshärtung, Updates, MFA und Incident Response sind Kernbestandteile.

Relevanz für deutsche Behörden-Webseiten:

• Ergänzt BSI-Grundschutz und BSI-Mindeststandards um internationale operative Cybersecurity-Praxis.
• Besonders relevant für Serverebene: CMS, Plugins, Frameworks, Webserver, Reverse Proxy, Adminzugänge.

Automatisierbare Prüfpunkte:

• CMS/Plugin/Framework-Versionen gegen bekannte CVEs und KEV-Katalog prüfen.
• Adminbereiche mit MFA/Rate-Limit/IP-Schutz.
• Security Header und sichere Defaults.
• Wiederkehrende Schwachstellenscans.
• Patch-SLA für kritische Schwachstellen.

1.4 Digital.gov / U.S. Web Design System

Quellen:

• U.S. Web Design System, Developer documentation: https://designsystem.digital.gov/documentation/developers/
• Digital.gov: https://digital.gov/

Kernaussagen:

• Öffentliche digitale Dienste sollen konsistent, nutzerfreundlich, zugänglich und wartbar gebaut werden.
• Designsysteme helfen bei Accessibility, responsiver Umsetzung und wiederverwendbaren Komponenten.

Relevanz für deutsche Behörden-Webseiten:

• Gute Vergleichsquelle für Behörden-UX, Komponentenqualität und Barrierefreiheit.
• Unterstützt die Empfehlung, Consent-Banner, Formulare, Navigation und Fehlermeldungen als geprüfte Komponenten zu standardisieren.

Automatisierbare Prüfpunkte:

• Komponentenbasierte Tests für Formulare, Buttons, Modals, Alerts, Navigation.
• Accessibility-Regressionstests für Standardkomponenten.
• Mobile/responsive Tests.

1.5 ADA.gov / U.S. Department of Justice: Web Accessibility

Quelle:

• ADA.gov, Guidance on Web Accessibility and the ADA: https://www.ada.gov/resources/web-guidance/

Kernaussagen:

• Websites öffentlicher Einrichtungen und Unternehmen müssen für Menschen mit Behinderungen zugänglich sein.
• Häufige Barrieren sind fehlende Alternativtexte, schlechte Kontraste, fehlende Tastaturbedienbarkeit, unbeschriftete Formulare und unzugängliche PDFs.

Relevanz für deutsche Behörden-Webseiten:

• Ergänzt BITV/WCAG/BFIT als internationale Accessibility-Quelle.
• Sehr hilfreich für praktische Scanner-Regeln zu Formularen, PDFs und Tastaturbedienbarkeit.

Automatisierbare Prüfpunkte:

• Alt-Texte, Labels, Kontraste, Tastaturfokus, ARIA-Fehler.
• PDF-Stichproben.
• Cookie-Banner und Captchas müssen barrierefrei bedienbar sein.

2. China: Datenschutz, Cybersecurity und Apps/Webdienste

Wichtige Einordnung:

• China hat ein anderes Rechts- und Aufsichtsmodell als EU/Deutschland.
• Für deutsche Behörden-Webseiten sind chinesische Regeln normalerweise nicht direkt maßgeblich.
• Nützlich sind sie als Vergleich bei Datenminimierung, Einwilligung, App-/Webdienst-Transparenz, Cybersecurity und Datenlokalisierungs-/Transferfragen.
• Chinesische Quellen fokussieren häufig stärker auf Apps, Plattformen, kritische Informationsinfrastruktur und nationale Cybersicherheit. Viele Prinzipien sind aber auf Webdienste übertragbar.

2.1 Personal Information Protection Law (PIPL)

Quelle:

• National People’s Congress, Personal Information Protection Law of the PRC: http://en.npc.gov.cn.cdurl.cn/2021-12/29/c_694559.htm

Kernaussagen:

• Verarbeitung personenbezogener Informationen braucht eine Rechtsgrundlage bzw. Einwilligung in relevanten Fällen.
• Verarbeitung soll klaren, vernünftigen Zwecken dienen und auf das notwendige Minimum beschränkt sein.
• Transparenz über Zweck, Methode, Kategorien personenbezogener Informationen, Aufbewahrungsdauer und Rechte der Betroffenen.
• Separate Einwilligung kann für sensible personenbezogene Informationen, Weitergabe, öffentliche Offenlegung oder grenzüberschreitende Übermittlung erforderlich sein.

Relevanz für deutsche Behörden-Webseiten:

• Stützt als Vergleich die Prinzipien Datenminimierung, Zweckbindung, Transparenz und besondere Sensibilität bei Drittlandtransfer.
• Für Webseiten mit China-Bezug oder chinesischen Nutzern kann zusätzliche rechtliche Prüfung erforderlich sein.

Automatisierbare Prüfpunkte:

• Zwecke und Datenkategorien in Datenschutzerklärung klar genannt?
• Werden sensible Daten in Formularen erhoben?
• Werden Daten an Drittanbieter oder ins Ausland übertragen?
• Gibt es unnötige Pflichtfelder?

2.2 Cybersecurity Law der VR China

Quelle:

• Chinese Government / laws and regulations archive, Cybersecurity Law: https://english.www.gov.cn/archive/lawsregulations/201911/20/content_WS5ed8856ec6d0b3f0e9499913.html

Kernaussagen:

• Netzwerkbetreiber müssen technische und organisatorische Sicherheitsmaßnahmen treffen.
• Schutz vor Störungen, Zerstörung, unbefugtem Zugriff, Datenleckage und Datenverlust.
• Sicherheitsmanagement, Protokollierung, Backup und Incident Response sind wichtige Pflichten.

Relevanz für deutsche Behörden-Webseiten:

• Vergleichbar mit Art. 32 DSGVO/BSI-Grundschutz: Webserver- und Anwendungsbetrieb brauchen Sicherheitsmanagement.
• Besonders nützlich für Serverebene: Logging, Backup, Zugriffsschutz, Incident Response.

Automatisierbare Prüfpunkte:

• Zugriffskontrollen und Adminschutz.
• Patchmanagement.
• Backup-/Recovery-Konzept.
• Sicherheitslogs mit Zweck und Schutz.
• Schwachstellenscans.

2.3 CAC: Provisions on the Scope of Necessary Personal Information for Common Types of Mobile Internet Applications

Quellen:

• Gov.cn, Regelung zu notwendiger personenbezogener Information bei App-Typen: https://www.gov.cn/zhengce/zhengceku/2021-03/23/content_5595088.htm
• CAC Veröffentlichung: https://www.cac.gov.cn/2021-03/22/c_1617990997054277.htm

Kernaussagen:

• Dienste sollen nur die personenbezogenen Informationen erheben, die für den jeweiligen Dienst notwendig sind.
• Nutzer sollen Basisfunktionen nicht verlieren, wenn sie nicht notwendige Informationen nicht bereitstellen, soweit diese für die Basisfunktion nicht erforderlich sind.
• Obwohl die Quelle Apps betrifft, ist das Prinzip für Webseitenformulare und Behördenportale sehr relevant.

Relevanz für deutsche Behörden-Webseiten:

• Sehr nützlich als zusätzlicher Datenminimierungsmaßstab für Formulare und Online-Anträge.
• Unterstützt die Prüfung, ob Pflichtfelder wirklich für die konkrete Verwaltungsleistung erforderlich sind.

Automatisierbare Prüfpunkte:

• Pflichtfelder nach Diensttyp klassifizieren.
• Optionale vs. notwendige Felder trennen.
• Formulare mit übermäßigen Datenfeldern markieren.
• Keine Blockade der Basisinformation durch nicht notwendige Angaben.

2.4 CAC: Security Assessment Measures for Cross-border Data Transfer

Quelle:

• CAC, Measures for Security Assessment of Cross-border Data Transfer: https://www.cac.gov.cn/2022-07/07/c_1658811536396503.htm

Kernaussagen:

• Grenzüberschreitende Datenübermittlung kann besondere Prüfung und Sicherheitsbewertung erfordern.
• Relevante Faktoren sind Menge/Sensibilität der Daten, Empfänger, Risiken und Schutzmaßnahmen.

Relevanz für deutsche Behörden-Webseiten:

• Nicht direkt auf deutsche Behörden übertragbar, aber als Vergleich sehr passend für Google-/US-Drittanbieter, CDN, Analytics, Maps, reCAPTCHA und Cloud-Dienste.
• Unterstützt die Empfehlung: Drittlandtransfer im Scanner ausdrücklich ausweisen.

Automatisierbare Prüfpunkte:

• Externe Domains nach Land/Provider/ASN klassifizieren.
• Drittlandtransfer-Risiko im Befund ausweisen.
• Dienstleister-/Transferdokumentation abfragen.
• Besondere Warnung bei sensiblen Formularseiten mit Drittanbieterrequests.

3. US/China-Vergleich: Welche Tipps sind für uns praktisch verwertbar?

3.1 Für Serverebene

Zusätzliche Tipps aus US/China-Quellen:

• Schwachstellen mit aktiver Ausnutzung priorisieren, nicht nur CVSS-Werte betrachten (CISA KEV).
• Security-by-Design als Beschaffungs- und Entwicklungsanforderung festlegen (CISA Secure by Design).
• Datenschutz- und Sicherheitsversprechen regelmäßig technisch verifizieren (FTC).
• Authentisierung und Sessions risikoorientiert prüfen (NIST SP 800-63B).
• Protokollierung, Backup und Incident Response als Pflichtbestandteile des Webbetriebs behandeln (China Cybersecurity Law als Vergleich, BSI als deutsche Hauptquelle).

Ergänzende automatisierte Checks:

• KEV/CVE-Abgleich für CMS, Plugins, Frameworks.
• Admin-Login: MFA, Rate-Limit, Session Cookie, Passwortpolicy.
• Backup-/Restore-Prozess zumindest organisatorisch abfragen.
• Sicherheitsversprechen in Datenschutzerklärung gegen reale TLS/Header/Cookie-Konfiguration prüfen.

3.2 Für Seitenebene

Zusätzliche Tipps aus US/China-Quellen:

• Datenschutzhinweise müssen nicht nur vorhanden, sondern wahr und technisch konsistent sein (FTC).
• Datenminimierung bei Formularen streng anwenden (PIPL/CAC-App-Regeln als Vergleich, DSGVO als Hauptquelle).
• Barrierefreiheit von Formularen, PDFs, Cookie-Bannern und Captchas besonders prüfen (ADA.gov als Vergleich, BITV als Hauptquelle).
• Keine Basisinformationen von unnötigen Datenangaben oder Tracking-Einwilligungen abhängig machen.

Ergänzende automatisierte Checks:

• Datenschutzerklärung vs. technische Evidenz: externe Requests, Cookies, Formulare, Logs.
• Formular-Pflichtfelder gegen Zweckkatalog.
• Captcha-Barrierefreiheit und Drittanbieterlast.
• Cookie-Banner darf Datenschutz-/Impressum-/Basisinformationen nicht blockieren.

3.3 Für Bußgeld-/Sanktionsbewertung

US/China-Quellen sollten nicht als deutsche Bußgeldgrundlage genannt werden. Sinnvolle Verwendung im Report:

• „zusätzliche internationale Behörden-Best-Practice“.
• „stützt den Stand-der-Technik-/Good-Practice-Charakter“.
• „hilft bei der Risikobewertung, ersetzt aber keine DSGVO/TDDDG/BSI-Prüfung“.

Beispiel-Formulierung:

„Der Befund ist nach deutscher Rechtslage anhand DSGVO/TDDDG zu bewerten. Zusätzlich entspricht die empfohlene Maßnahme internationalen Behörden-Best-Practices, u.a. FTC/NIST/CISA bzw. PIPL/CAC-Vorgaben zu Datenminimierung, Transparenz und Sicherheitsmanagement.“

4. Zusätzliche Quellenliste USA/China

USA:

• FTC Privacy and Security: https://www.ftc.gov/business-guidance/privacy-security
• FTC Data Security: https://www.ftc.gov/business-guidance/privacy-security/data-security
• FTC Protecting Personal Information: https://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-business-0
• FTC, How Websites and Apps Collect and Use Your Information: https://consumer.ftc.gov/articles/how-websites-apps-collect-use-your-information
• NIST Privacy Framework: https://www.nist.gov/privacy-framework
• NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
• NIST SP 800-63B: https://pages.nist.gov/800-63-3/sp800-63b.html
• CISA Cyber Essentials: https://www.cisa.gov/resources-tools/resources/cyber-essentials
• CISA Secure by Design: https://www.cisa.gov/securebydesign
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• U.S. Web Design System: https://designsystem.digital.gov/documentation/developers/
• ADA.gov Web Accessibility Guidance: https://www.ada.gov/resources/web-guidance/

China:

• PRC Personal Information Protection Law: http://en.npc.gov.cn.cdurl.cn/2021-12/29/c_694559.htm
• PRC Cybersecurity Law: https://english.www.gov.cn/archive/lawsregulations/201911/20/content_WS5ed8856ec6d0b3f0e9499913.html
• Gov.cn/CAC necessary personal information for apps: https://www.gov.cn/zhengce/zhengceku/2021-03/23/content_5595088.htm
• CAC publication on necessary personal information for apps: https://www.cac.gov.cn/2021-03/22/c_1617990997054277.htm
• CAC cross-border data transfer security assessment measures: https://www.cac.gov.cn/2022-07/07/c_1658811536396503.htm