DSGVO Artikel 32 & Website-Sicherheit: Was 'geeignete technische Maßnahmen' wirklich verlangen

Artikel 32(1) verpflichtet Verantwortliche und Auftragsverarbeiter, technische und organisatorische Maßnahmen umzusetzen, um ein dem Risiko "angemessenes" Schutzniveau zu gewährleisten — unter Berücksichtigung des Stands der Technik, der Implementierungskosten sowie Art, Umfang und Zwecke der Verarbeitung. Vier nicht abschließende Beispiele werden genannt: Pseudonymisierung und Verschlüsselung personenbezogener Daten; die Fähigkeit, auf Dauer die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Verarbeitungssysteme sicherzustellen; die Fähigkeit, nach einem Vorfall die Verfügbarkeit und den Zugang zeitnah wiederherzustellen; sowie ein Verfahren zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit der Maßnahmen.

Beachten Sie, was auf dieser Liste fehlt: keine Erwähnung von HTTPS, keine Erwähnung von HTTP-Headern, keine Erwähnung von Cookie-Flags. Artikel 32 ist bewusst technologieneutral und risikobasiert — er nennt das geforderte Ergebnis (Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit), ohne einen konkreten Mechanismus vorzuschreiben, weil dasselbe Gesetz sowohl für eine fünfseitige Broschüren-Website als auch für ein Patientenportal eines Krankenhauses gelten muss.

Sie sind die konkrete Umsetzung von "Vertraulichkeit ... der Verarbeitungssysteme" für den häufigsten Fall: eine Website, die personenbezogene Daten überträgt (ein Kontaktformular, ein Login, ein Checkout, sogar nur eine IP-Adresse in einem Server-Log) zwischen dem Browser eines Besuchers und Ihrem Server. Verschlüsselung bei der Übertragung — HTTPS mit gültigem Zertifikat, kein Zurückfallen auf einfaches HTTP — ist der grundlegende Mechanismus für dieses Ergebnis und kommt der expliziten Nennung im Wortlaut von Artikel 32 selbst ("Verschlüsselung personenbezogener Daten") am nächsten.

HTTP-Sicherheits-Header liegen weiter vom Gesetzestext entfernt, werden aber von Sicherheitsleitfäden (OWASP, Browser-Anbieter, nationale Cybersicherheitsbehörden) allgemein als Standard-Maßnahmen mit geringen Kosten behandelt, die verbreitete Angriffsklassen reduzieren — Clickjacking, MIME-Sniffing, Protokoll-Downgrade —, die sonst die Vertraulichkeit oder Integrität eines Verarbeitungssystems gefährden würden. Eine Aufsichtsbehörde, die einen Vorfall untersucht, wird nicht "Ihnen fehlte ein Content-Security-Policy-Header" als alleinige Feststellung anführen, aber ein Muster fehlender Grundhärtung ist genau das, worauf bei der Bewertung, ob Maßnahmen "geeignet" waren, verwiesen wird.

Nicht namentlich, und die Cookie-Regeln selbst stammen größtenteils aus der ePrivacy-Richtlinie (Einwilligung, Zweckoffenlegung) statt direkt aus der DSGVO. Sobald ein Cookie jedoch eine Sitzungskennung oder personenbezogene Daten enthält, gelten die Vertraulichkeits- und Integritätspflichten aus Artikel 32 für dieses Cookie genauso wie für jede andere Übertragung oder Speicherung personenbezogener Daten. Das Secure-Flag verhindert, dass ein Cookie über einfaches HTTP gesendet wird; HttpOnly blockiert clientseitige Skripte (einschließlich eingeschleuster bösartiger Skripte) am Auslesen; SameSite begrenzt die Anfälligkeit für Cross-Site-Request-Forgery. Fehlen alle drei, wird nicht nur "Sicherheit" im Abstrakten geschwächt — es wird genau die Vertraulichkeitsgarantie geschwächt, die Artikel 32 für jedes Cookie mit personenbezogenen Daten verlangt.

Diese drei DNS-Einträge authentifizieren E-Mails, die von Ihrer Domain gesendet werden, und erschweren es, überzeugende Phishing-E-Mails zu versenden, die scheinbar von Ihnen stammen. Der DSGVO-Bezug ist indirekt, aber real: Kontaktformulare, Betroffenenanfragen und Verletzungsmeldungen laufen typischerweise über E-Mail, und eine leicht zu fälschende Domain lässt sich leichter für Social-Engineering-Angriffe auf Ihre eigenen Mitarbeitenden oder Kunden nutzen — Angriffe, die häufig genau der Art von Sicherheitsvorfall vorausgehen, die Artikel 32 eigentlich verhindern soll.

Keiner der drei ist von außen vollständig zuverlässig auffindbar. SPF und DMARC liegen an vorhersehbaren DNS-Orten (ein TXT-Eintrag auf der Domain und einer unter `_dmarc.<domain>`), sodass sie direkt geprüft werden können. DKIM hat keinen einzigen Standardort — er hängt von einem Selektor ab, den der jeweilige E-Mail-Versanddienst wählt —, sodass jede externe DKIM-Prüfung notwendigerweise eine bestmögliche Suche nach gängigen Selektoren ist, keine endgültige Feststellung der Abwesenheit.

Nein, und diese so zu behandeln würde überbewerten, was eine Konfigurationsprüfung tatsächlich leisten kann. Die Einhaltung von Artikel 32 ist eine dokumentierte, risikobasierte Entscheidung — sie verlangt, dass Sie das Risiko Ihrer konkreten Verarbeitung tatsächlich bewertet und Maßnahmen gewählt haben, die diesem Risiko angemessen sind, nicht nur ein grünes Häkchen neben einer festen Liste technischer Einstellungen. Ein Blog mit fünf Mitarbeitenden und eine Website, die besondere Kategorien von Gesundheitsdaten verarbeitet, stehen vor sehr unterschiedlichen "Angemessenheits"-Maßstäben, selbst wenn beide dieselbe Header-Prüfung bestehen.

Wofür eine Konfigurationsprüfung tatsächlich nützlich ist: die Lücke zwischen "wir sind davon ausgegangen, dass das korrekt eingerichtet ist" und "wir haben es überprüft" zu schließen. Fehlende HTTPS-Durchsetzung, fehlende Sicherheits-Header oder nicht authentifizierte E-Mail für eine Domain, die personenbezogene Daten verarbeitet, sind genau die Art von vermeidbaren, leicht behebbaren Lücken, die sich bei keiner Risikobewertung als "angemessen" rechtfertigen lassen — sie auszuschließen ist daher ein sinnvoller erster Schritt, nicht die gesamte Übung.

Die oben behandelten Bereiche — HTTPS/TLS, Standard-Sicherheits-Header, Cookie-Flags und SPF/DMARC/DKIM — sind alle von außen aus Sicht eines Browsers oder eines DNS-Resolvers beobachtbar, was sie für eine automatisierte Prüfung geeignet macht, die in Sekunden läuft, statt für ein manuelles Audit. Was eine solche Prüfung nicht leisten kann, ist die Bewertung Ihrer internen Risikodokumentation, Ihrer Zugangskontrollen oder Ihres Incident-Response-Prozesses — das sind organisatorische Maßnahmen nach Artikel 32, die auf ihre eigene Weise bewertet werden müssen, typischerweise mit rechtlichem oder DSB-Input statt mit einem Scanner.