Der Fall CenterPoint Energy zeigt, wie schnell aus einer technischen Schwachstelle eine juristische Krise wird. Der US-Energieversorger bestätigte kürzlich, dass ein Angreifer über eine ungeschützte öffentliche API rund 7,49 Millionen Kundendatensätze abgegriffen hat, weil schlicht Rate Limiting und eine Web Application Firewall fehlten. Für deutsche IT-Abteilungen ist das kein exotisches US-Problem, sondern ein Blick in den Spiegel: Genau solche Fehlkonfigurationen lösen hierzulande die DSGVO Meldepflicht Datenpanne aus, und dafür bleiben nur 72 Stunden. Wer als Sysadmin nicht weiß, welche Informationen er in dieser Zeit liefern muss, gefährdet nicht nur die Frist, sondern auch das Unternehmen.
Was zählt überhaupt als Datenpanne im Sinne der DSGVO?
Art. 4 Nr. 12 DSGVO definiert eine Datenpanne als Verletzung des Schutzes personenbezogener Daten, die zu Vernichtung, Verlust, Veränderung oder unbefugter Offenlegung von beziehungsweise unbefugtem Zugang zu Daten führt. Das ist bewusst weit gefasst. Deshalb zählt nicht nur der klassische Datenklau, sondern auch ein verschlüsselter Fileserver durch Ransomware, ein falsch konfigurierter SharePoint-Freigabelink oder ein verlorenes, unverschlüsseltes Notebook. Entscheidend ist allein, ob personenbezogene Daten betroffen sind – unabhängig davon, ob ein Angreifer aktiv eingebrochen ist oder ein Mitarbeiter versehentlich eine Excel-Liste an den falschen Verteiler geschickt hat.
Die 72-Stunden-Frist: Wann beginnt sie und wer löst sie aus?
Die Frist beginnt nicht erst, wenn die Datenpanne bestätigt ist, sondern sobald der Verantwortliche Kenntnis davon hat. Genau das ist in der Praxis die größte Falle: Bereits ein begründeter Verdacht, etwa durch einen ungewöhnlichen Alert in Microsoft Defender oder einen Anruf des Datenschutzbeauftragten, kann als Kenntniserlangung gelten. Deshalb sollte die interne Meldekette so aufgebaut sein, dass ein Vorfall aus dem SOC oder von einem Sysadmin sofort und ohne Umwege bei der Geschäftsführung und dem Datenschutzbeauftragten landet. Wer erst tagelang intern klärt, ob es sich „wirklich“ um eine meldepflichtige Panne handelt, verliert wertvolle Stunden der ohnehin knappen Frist.
Meldung an die Aufsichtsbehörde vs. Benachrichtigung der Betroffenen
Art. 33 DSGVO verpflichtet zur Meldung an die zuständige Aufsichtsbehörde, sobald ein Risiko für die Rechte und Freiheiten der betroffenen Personen besteht. Art. 34 DSGVO geht einen Schritt weiter: Betroffene selbst müssen informiert werden, wenn ein hohes Risiko vorliegt, etwa bei gestohlenen Sozialversicherungsnummern oder Zugangsdaten wie im CenterPoint-Fall. Der Unterschied liegt also in der Schwere des Risikos. Allerdings gilt: Im Zweifel lieber melden. Eine unterlassene Meldung wiegt aufsichtsrechtlich deutlich schwerer als eine Meldung, die sich im Nachhinein als nicht zwingend notwendig herausstellt.
Die Rolle der IT: Welche technischen Infos müssen innerhalb von Stunden vorliegen?
Der Datenschutzbeauftragte kann nur so gut melden, wie die IT liefert. Sysadmins müssen daher innerhalb weniger Stunden folgende Punkte beantworten können:
- Welche Systeme sind betroffen und seit wann?
- Welche Kategorien personenbezogener Daten liegen auf diesen Systemen?
- Wie viele Datensätze beziehungsweise Personen sind mutmaßlich betroffen?
- Wie kam der Angreifer rein – Ursache und Einfallstor?
- Wurden Daten tatsächlich exfiltriert oder nur eingesehen?
Für einen strukturierten Ablauf lohnt sich ein Blick in den bestehenden Incident Response Plan für Sysadmins, denn die technische Analyse nach einem Datenleck und die DSGVO-Meldung laufen zeitlich parallel und müssen ineinandergreifen.
Typische Auslöser in Microsoft-Umgebungen
In der Praxis entstehen die meisten meldepflichtigen Vorfälle nicht durch spektakuläre Zero-Days, sondern durch bekannte Schwachstellen im eigenen Setup:
Kompromittierte Entra-ID-Konten
Ein Phishing-Login ohne MFA reicht oft aus, um Zugriff auf Postfächer und Freigaben zu bekommen. Die Sign-in- und Audit-Logs lassen sich schnell auslesen:
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '[email protected]'" | Select-Object CreatedDateTime, IpAddress, StatusExchange-Postfächer und Exfiltration per E-Mail
Massenweiterleitungen oder ungewöhnliche Exportaktivitäten lassen sich über das Unified Audit Log prüfen:
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) -Operations "MailItemsAccessed","New-InboxRule"SharePoint/OneDrive-Exfiltration
Öffentlich geteilte Links ohne Ablaufdatum sind ein Klassiker. Prüfe regelmäßig anonyme Freigaben und Downloadaktivitäten über den Audit-Log-Suchindex in Purview.
Fehlkonfigurationen in Azure
Offene Storage-Container, fehlende Netzwerkbeschränkungen oder – wie bei CenterPoint Energy – APIs ohne Rate Limiting und WAF sind häufige Ursachen. Genau solche Konfigurationsfehler lassen sich mit regelmäßigen Reviews vermeiden, wie auch im Artikel Thema Datensicherheit: Das sollte man wissen beschrieben.
Checkliste: Erste 24 Stunden nach Verdacht auf eine meldepflichtige Datenpanne
- Vorfall dokumentieren: Zeitstempel, betroffene Systeme, erste Beobachtungen.
- Datenschutzbeauftragten und Geschäftsführung sofort informieren.
- Betroffene Systeme isolieren, ohne Beweise zu zerstören.
- Relevante Logs sichern (Entra ID, Exchange, SharePoint, Firewall, Azure Activity Log).
- Umfang grob abschätzen: Anzahl Datensätze, Datenkategorien, Risiko für Betroffene.
- Externe Forensik-Unterstützung anfordern, falls intern keine Kapazität besteht.
- Fristuhr für die 72 Stunden intern sichtbar machen, zum Beispiel im Ticketsystem.
Bußgeldrisiken bei verspäteter oder unterlassener Meldung
Verspätete oder unterlassene Meldungen zählen zu den Verstößen, die eigenständig sanktioniert werden – unabhängig vom eigentlichen Datenleck. Der CenterPoint-Fall zeigt zudem, wie schnell aus einem technischen Vorfall zusätzlich zivilrechtliche Konsequenzen entstehen: Bereits kurz nach Bekanntwerden wurden in den USA mehrere Sammelklagen eingereicht. In Deutschland drohen bei Verstößen gegen die Meldepflicht Bußgelder nach Art. 83 DSGVO, die sich zusätzlich zu möglichen Bußgeldern für die eigentliche Datenpanne addieren können.
Schnittstelle IT, Datenschutzbeauftragter und Geschäftsführung
Damit die Frist eingehalten wird, braucht es klare Zuständigkeiten. Der Datenschutzbeauftragte bewertet das Risiko und entscheidet über die Meldung, die Geschäftsführung trägt die Gesamtverantwortung, und die IT liefert die technischen Fakten. Deshalb sollte diese Schnittstelle nicht erst im Ernstfall entstehen, sondern vorher als Prozess definiert sein. Wer bereits regulatorische Anforderungen wie NIS2 umsetzt, kann diese Struktur meist direkt mitnutzen – mehr dazu im Beitrag NIS 2 und Cloud-Dienste.
Vorlage: Meldeformular und technische Dokumentation für den Ernstfall
Ein einsatzbereites Template sollte mindestens folgende Felder enthalten: Zeitpunkt der Entdeckung, Zeitpunkt der Kenntniserlangung, betroffene Systeme, Datenkategorien, geschätzte Anzahl Betroffener, Ursache, bereits ergriffene Maßnahmen sowie geplante Folgemaßnahmen. Trage diese Felder direkt in dein Ticketsystem oder deine Incident-Response-Dokumentation ein, damit im Ernstfall keine Zeit mit dem Aufbau einer Vorlage verloren geht. Auch der Fall des Chaos Computer Clubs rund um das Numa-Datenleck zeigt, wie wichtig eine saubere Dokumentation großer Datenbestände von Anfang an ist.
Fazit
Die DSGVO Meldepflicht Datenpanne ist kein reines Compliance-Thema, sondern hängt direkt an der technischen Reaktionsfähigkeit deiner IT. Wer Logs, Zuständigkeiten und Meldewege vorher klärt, kann die 72-Stunden-Frist realistisch einhalten. Integriere die Meldepflicht deshalb fest in deinen bestehenden Incident-Response-Plan, statt sie als separaten juristischen Prozess zu behandeln. Weitere Hintergründe zu regulatorischen Anforderungen findest du auch im Artikel IT-Sicherheitsgesetzgebung in Deutschland: Der Fokus auf KRITIS. Details zum CenterPoint-Vorfall liefert der Originalbericht von BleepingComputer, weitere rechtliche Details zur Meldepflicht bietet die Microsoft-Dokumentation zur DSGVO.
FAQ
Was zählt als meldepflichtige Datenpanne nach DSGVO?
Jede Verletzung des Schutzes personenbezogener Daten, die zu Verlust, Veränderung oder unbefugtem Zugriff führt und ein Risiko für Betroffene darstellt – unabhängig davon, ob sie durch einen Angriff oder ein internes Versehen entsteht.
Ab wann läuft die 72-Stunden-Frist?
Ab dem Zeitpunkt, an dem der Verantwortliche Kenntnis von der Datenpanne erlangt – bereits ein begründeter Verdacht kann dafür ausreichen.
Muss jede Datenpanne der Aufsichtsbehörde gemeldet werden?
Nein, nur wenn ein Risiko für die Rechte und Freiheiten der betroffenen Personen besteht. Bei geringem Risiko kann die Meldung entfallen, im Zweifel ist eine Meldung aber die sicherere Wahl.
Was passiert bei verspäteter Meldung einer Datenpanne?
Es drohen eigenständige Bußgelder nach Art. 83 DSGVO, zusätzlich zu möglichen Sanktionen für die eigentliche Datenpanne selbst.