DSGVO Art.33: Meldung an die Datenschutzbehörde innerhalb von 72 Stunden
Was eine Datenschutzverletzung darstellt, der Meldeprozess an die Behörde, die 72-Stunden-Frist und wie Sie Erkennung und Berichterstattung automatisieren.
DSGVO Art.33 ist eindeutig: Im Falle einer Verletzung des Schutzes personenbezogener Daten muss der Verantwortliche die Aufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden benachrichtigen. Nicht 72 Stunden nach Abschluss der Untersuchung. Nicht 72 Stunden nach dem Krisenmeeting. 72 Stunden nach dem Bekanntwerden. Diese Frist ist eine technische und organisatorische Herausforderung, die viele unterschätzen.
Was stellt eine Datenschutzverletzung gemäß DSGVO dar?
Art.4(12) definiert die Verletzung des Schutzes personenbezogener Daten als "eine Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung von personenbezogenen Daten führt". In der Praxis drei Typen:
-
Vertraulichkeitsverletzung: Unbefugter Zugriff auf personenbezogene Daten. Beispiel: Kundendatenbank im Internet exponiert, E-Mail an falschen Empfänger, Kompromittierung durch einen Angreifer.
-
Integritätsverletzung: Unbefugte Änderung der Daten. Beispiel: Ransomware verschlüsselt eine Patientendatenbank, böswillige Änderung von HR-Datensätzen.
-
Verfügbarkeitsverletzung: Verlust des Zugangs zu Daten. Beispiel: Serverausfall ohne Backup, DDoS-Angriff, der Daten unzugänglich macht, versehentliche Zerstörung.
Wichtiger Punkt: Nicht jede Datenschutzverletzung ist meldepflichtig. Art.33 verlangt die Meldung, es sei denn, "die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt". Waren die Daten mit einem robusten Algorithmus verschlüsselt und der Schlüssel nicht kompromittiert, kann das Risiko als null betrachtet werden. Diese Bewertung muss jedoch dokumentiert werden.
Der Meldeprozess an die Aufsichtsbehörde
Die Meldung erfolgt bei der zuständigen Datenschutzbehörde. Das Formular verlangt:
-
Art der Verletzung: Typ (Vertraulichkeit/Integrität/Verfügbarkeit), Ursache, Angriffsvektor
-
Datenkategorien: Welche Daten sind betroffen (Identität, Kontakt, Finanzen, Gesundheit etc.)
-
Anzahl betroffener Personen: Schätzung, wenn die genaue Zahl nicht bekannt ist
-
Wahrscheinliche Folgen: Mögliche Auswirkungen auf die Betroffenen (Identitätsdiebstahl, finanzieller Verlust etc.)
-
Ergriffene Maßnahmen: Eindämmungs-, Behebungs- und Präventionsmaßnahmen
-
DSB-Kontakt: Kontaktdaten des Datenschutzbeauftragten
Die Meldung kann in zwei Stufen erfolgen: Eine erste Meldung innerhalb von 72 Stunden mit den verfügbaren Informationen, dann eine ergänzende Meldung, wenn die Untersuchung neue Details ergibt. Die Aufsichtsbehörden akzeptieren diesen Phasenansatz ausdrücklich.
Die 72-Stunden-Herausforderung
Betrachten wir den realistischen Zeitplan:
-
T+0h: Verletzung erkannt. Die 72-Stunden-Uhr beginnt hier, nicht als der Angriff stattfand, sondern als Sie davon Kenntnis erlangten.
-
T+0 bis T+6h: Vorfallbestätigung, erste Umfangsbewertung, Identifizierung betroffener Daten
-
T+6 bis T+24h: Technische Untersuchung (erste Forensik), Schätzung der betroffenen Personen, Risikobewertung
-
T+24 bis T+48h: Erstellung des Meldeberichts, rechtliche und DSB-Validierung
-
T+48 bis T+72h: Einreichung bei der Aufsichtsbehörde, Benachrichtigung der Betroffenen falls erforderlich (Art.34)
Der Engpass ist fast immer derselbe: die Erkennung. Bei einer durchschnittlichen Verweildauer von 194 Tagen (IBM 2025) verfehlen die meisten Organisationen die 72-Stunden-Frist, weil sie die Verletzung nicht rechtzeitig erkennen, nicht weil sie den Bericht nicht schnell genug erstellen können.
Benachrichtigung der Betroffenen (Art.34)
Wenn die Verletzung "voraussichtlich ein hohes Risiko für die Rechte und Freiheiten" darstellt, müssen Sie auch die betroffenen Personen benachrichtigen. In klarer, verständlicher Sprache, mit Erklärung:
-
Art der Verletzung
-
Betroffene Daten
-
Wahrscheinliche Folgen
-
Ergriffene Maßnahmen und Empfehlungen (Passwort ändern, Bankkonten überwachen etc.)
Ausnahme: Die Benachrichtigung der Betroffenen ist nicht erforderlich, wenn die Daten verschlüsselt waren, Maßnahmen das Risiko beseitigten oder sie einen unverhältnismäßigen Aufwand erfordern würde (in diesem Fall öffentliche Mitteilung).
Sanktionen bei unterlassener Meldung
Der Verstoß gegen Art.33 wird nach Art.83(4) sanktioniert: Bußgeld bis zu 10 Mio. € oder 2 % des weltweiten Umsatzes. In der Praxis ahnden Datenschutzbehörden regelmäßig Meldeversäumnisse. Aktuelle Beispiele:
-
Krankenhausgruppe: 800 000 € für verspätete Meldung und unzureichende Sicherheitsmaßnahmen
-
Telekommunikationsanbieter: 300 000 € für unterlassene Meldung innerhalb von 72 Stunden
-
Startup: 150 000 € für unterlassene Meldung trotz eines Datenlecks von 500 000 Konten
Die Aufsichtsbehörden prüfen zwei Dinge: Haben Sie fristgerecht gemeldet? Und hatten Sie angemessene Sicherheitsmaßnahmen zur Erkennung der Verletzung?
Wie ThreatClaw Erkennung und Berichterstattung automatisiert
ThreatClaw adressiert das Problem von beiden Seiten:
Automatische Erkennung personenbezogener Daten
-
Identifizierung von Flüssen personenbezogener Daten in Ihrer Infrastruktur
-
Automatische Datenklassifizierung (Identität, Finanzen, Gesundheit) durch Datenbank- und Flussanalyse
-
Echtzeit-Alerting bei exponierten personenbezogenen Daten (öffentlicher S3-Bucket, Datenbank ohne Authentifizierung, API ohne Zugriffskontrolle)
Verletzungserkennung
-
Kontinuierliches Monitoring der Zugriffe auf Datenbanken mit personenbezogenen Daten
-
Exfiltrationserkennung (abnormales Abfragevolumen, Transfers an ungewöhnliche Ziele)
-
Korrelation mit Kompromittierungsindikatoren (stammt der Zugriff von einem kompromittierten Konto?)
Art.33-Berichtsgenerierung
-
Vorab ausgefüllter Bericht im erforderlichen Format innerhalb von 15 Minuten nach Erkennung
-
Automatische Umfangsschätzung (betroffene Tabellen, Datensatzanzahl, Datenkategorien)
-
Technische Vorfallschronologie
-
Der DSB erhält ein komplettes Paket zur Validierung, nicht einen rohen Alarm zur Untersuchung
Was früher 24-48 Stunden manuelle Untersuchung dauerte, ist in 15 Minuten verfügbar. Die 72 Stunden werden zu einer komfortablen Frist statt eines Wettlaufs gegen die Zeit.
Die Verzahnung mit NIS2
Wenn Ihre Organisation auch unter NIS2 fällt, haben Sie eine doppelte Meldepflicht. NIS2 Art.23 verlangt eine CSIRT-Meldung innerhalb von 24 Stunden (strenger als die DSGVO). ThreatClaw generiert beide Berichte gleichzeitig, das Format für die Datenschutzbehörde (DSGVO Art.33) und das CSIRT-Format (NIS2 Art.23).
FAQ
Ist eine E-Mail an den falschen Empfänger eine meldepflichtige Verletzung?
Es kommt darauf an. Wenn die E-Mail sensible personenbezogene Daten enthält (Gesundheit, Finanzen) und der Empfänger kein vertrauenswürdiger Dritter ist, ja, es handelt sich wahrscheinlich um eine meldepflichtige Vertraulichkeitsverletzung. Ist es eine interne E-Mail mit einem Vornamen, ist das Risiko minimal. Dokumentieren Sie den Vorfall in jedem Fall in Ihrem Verletzungsverzeichnis (Art.33(5)-Pflicht), auch wenn Sie die Behörde nicht benachrichtigen.
Gilt die 72-Stunden-Frist auch an Wochenenden und Feiertagen?
Ja, ausnahmslos. 72 Kalenderstunden, nicht Geschäftsstunden. Deshalb sind kontinuierliches Monitoring und automatisierte Erkennung unerlässlich, Datenschutzverletzungen wählen ihren Zeitpunkt nicht.
Was passiert, wenn ich die 72 Stunden überschreite?
Sie müssen trotzdem melden und die Gründe für die Verzögerung erläutern (Art.33(1)). Eine begründete Verzögerung (komplexe Untersuchung, groß angelegter Vorfall) wird günstiger bewertet als eine vollständige Unterlassung der Meldung. Aber die Aufsichtsbehörden schätzen fristgerechte Compliance, sie ist ein Faktor bei der Bußgeldberechnung.
Muss ich die Behörde benachrichtigen, wenn die Daten verschlüsselt waren?
Wenn die Verschlüsselung robust ist (AES-256, Schlüssel nicht kompromittiert) und die exfiltrierten Daten unverwertbar sind, ist das Risiko für die Betroffenen null und eine Meldung ist nicht erforderlich. Sie müssen jedoch diese Bewertung dokumentieren. Wenn Sie den geringsten Zweifel an der Verschlüsselungsstärke haben oder der Schlüssel kompromittiert sein könnte, melden Sie. Aufsichtsbehörden bevorzugen eine "vorsorgliche" Meldung gegenüber einer ungerechtfertigten Nichtmeldung.
Verwandte Artikel
Eine rohe Liste aus IPs, Domains und Hashes ist leicht zu finden und nahezu wertlos. Der Wert liegt in der Auswahl des richtigen Feeds und in seinem Betrieb: Lizenz, Korroboration, Alterung und die Regel, die verhindert, dass Sie Ihr eigenes CDN blockieren.
Eine CVE erscheint, das Security-Advisory ist öffentlich, aber es existiert noch kein Nuclei-Template. So schreiben Sie ein sauberes: von der Tatsache ausgehen, die Matcher bauen und vor allem beweisen, dass es auf einem verwundbaren Ziel auslöst, ohne bei einem gepatchten Alarm zu schlagen.
Ein Bericht beschreibt eine Angriffstechnik oder die Ausnutzung einer CVE. Sie wollen sie in Ihren Logs erkennen. So schreiben Sie eine Sigma-Regel, die auf das echte Verhalten auslöst, ohne das SOC mit Fehlalarmen zu überfluten, und wie Sie es beweisen.
Sie erhalten eine Malware-Probe (ein DFIR-Einsatz, eine Sandbox, ein Feed. Sie wollen die ganze Familie in Ihrem Bestand erkennen. So schreiben Sie eine YARA-Regel, die die Bedrohung fängt, ohne bei legitimer Software auszulösen) und wie Sie es beweisen.