DSGVO-Meldung von Datenpannen: Zeitplan und Schritte

Wenn eine Verletzung des Schutzes personenbezogener Daten auftritt, gibt Ihnen die DSGVO 72 Stunden, um Ihre Aufsichtsbehörde zu benachrichtigen. Nicht 72 Geschäftsstunden — 72 tatsächliche Stunden, Wochenenden und Feiertage eingeschlossen. Das beginnt ab dem Zeitpunkt, an dem Sie von der Verletzung „Kenntnis erlangen”, was der Europäische Datenschutzausschuss (EDSA) definiert als den Zeitpunkt, an dem Sie einen hinreichenden Grad an Sicherheit haben, dass ein Sicherheitsvorfall personenbezogene Daten kompromittiert hat.

Das ist kein großzügiger Zeitrahmen. Es bedeutet, dass Ihr Reaktionsprozess bei Datenpannen nicht mit „lasst uns herausfinden, wer das bearbeitet” oder „planen wir ein Meeting für Montag” beginnen kann. Es muss ein gut einstudiertes Playbook sein, das Ihr Team unter Druck, zu jeder Stunde, mit klaren Rollen und vordefinierten Kommunikationskanälen ausführen kann.

Dieser Leitfaden behandelt die rechtlichen Anforderungen, die praktischen Schritte und die Dokumentation, die SaaS-Unternehmen vorbereiten müssen, bevor eine Datenpanne auftritt.

Was zählt als Verletzung des Schutzes personenbezogener Daten?

Die DSGVO definiert eine Verletzung des Schutzes personenbezogener Daten als „eine Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung von bzw. zum unbefugten Zugang zu personenbezogenen Daten führt, die übermittelt, gespeichert oder auf sonstige Weise verarbeitet wurden.” Dies ist breiter, als die meisten Menschen annehmen. Es beschränkt sich nicht auf Hacking-Vorfälle oder externe Angriffe.

Vertraulichkeitsverletzungen — Unbefugter Zugang zu oder Offenlegung personenbezogener Daten. Ein Mitarbeiter, der ohne geschäftliche Berechtigung auf Kundendatensätze zugreift. Eine E-Mail mit personenbezogenen Daten, die an den falschen Empfänger gesendet wird. Ein falsch konfigurierter API-Endpunkt, der Nutzerdaten offenlegt.

Integritätsverletzungen — Unbefugte Veränderung personenbezogener Daten. Eine Datenbankkorruption, die Kundendatensätze verändert. Ein Softwarefehler, der Benutzereinstellungen mit den Daten eines anderen Benutzers überschreibt.

Verfügbarkeitsverletzungen — Verlust des Zugangs zu personenbezogenen Daten. Ein Ransomware-Angriff, der Ihre Datenbank verschlüsselt. Eine fehlgeschlagene Migration, die Kundendaten für einen längeren Zeitraum unzugänglich macht. Ein Hardwareausfall, der Backups zerstört.

Nicht jeder Sicherheitsvorfall ist eine Verletzung des Schutzes personenbezogener Daten. Ein DDoS-Angriff, der Ausfallzeiten verursacht, aber personenbezogene Daten nicht betrifft, ist keine Datenpanne. Ein fehlgeschlagener Anmeldeversuch ist keine Datenpanne. Aber die Grenze kann subtil sein — wenn ein DDoS-Angriff dazu führt, dass Ihre Überwachungssysteme ausfallen und in diesem Zeitfenster ein unbefugter Zugriff unerkannt bleibt, könnte eine Datenpanne vorliegen.

Das Meldungs-Framework

Die DSGVO schafft ein zweistufiges Meldesystem. Nicht jede Datenpanne löst beide Stufen aus.

Stufe 1: Benachrichtigung der Aufsichtsbehörde (Artikel 33)

Wann erforderlich: Bei jeder Verletzung des Schutzes personenbezogener Daten, es sei denn, die Verletzung führt „voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen.”

In der Praxis: Die Schwelle ist niedrig. Wenn personenbezogene Daten offengelegt, zugänglich gemacht oder verloren wurden und es ein realistisches Szenario gibt, in dem eine betroffene Person geschädigt werden könnte (Identitätsdiebstahl, Diskriminierung, finanzieller Verlust, Reputationsschaden, Verlust der Vertraulichkeit), müssen Sie melden. Die Standardannahme sollte die Meldung sein; verzichten Sie nur auf die Meldung, wenn Sie tatsächlich ein minimales Risiko nachweisen können.

Frist: Innerhalb von 72 Stunden nach Kenntniserlangung. Wenn Sie innerhalb von 72 Stunden nicht alle Details bereitstellen können (was bei komplexen Vorfällen häufig vorkommt), können Sie eine Erstmeldung einreichen und die zusätzlichen Informationen in Phasen nachliefern.

Was in der Meldung enthalten sein muss:

1. Die Art der Verletzung, einschließlich der ungefähren Anzahl der betroffenen Personen und Datensätze
2. Name und Kontaktdaten Ihres DSB oder einer anderen Kontaktstelle
3. Eine Beschreibung der wahrscheinlichen Folgen der Verletzung
4. Eine Beschreibung der ergriffenen oder vorgeschlagenen Maßnahmen zur Behebung der Verletzung, einschließlich Abhilfemaßnahmen

Wie zu melden: Jede Datenschutzbehörde eines EU-Mitgliedstaats hat einen eigenen Meldemechanismus — typischerweise ein Online-Formular auf der Website der Behörde. Wenn Sie in mehreren Mitgliedstaaten tätig sind, melden Sie an die Behörde des Landes, in dem sich Ihre Hauptniederlassung befindet. Wenn Sie unsicher sind, welche Behörde zuständig ist, melden Sie an die Behörde des Landes, in dem die meisten betroffenen Personen ansässig sind.

Stufe 2: Benachrichtigung betroffener Personen (Artikel 34)

Wann erforderlich: Wenn die Verletzung „voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen” darstellt. Dies ist eine höhere Schwelle als Stufe 1. Nicht jede an die Behörde gemeldete Datenpanne erfordert eine individuelle Benachrichtigung.

Hochrisiko-Szenarien umfassen:

• Offenlegung von Finanzdaten (Bankdaten, Zahlungskartennummern)
• Offenlegung von Authentifizierungsdaten (Passwörter, Sicherheitsfragen)
• Offenlegung von Identitätsdokumenten oder nationalen Identifikationsnummern
• Offenlegung von Gesundheits- oder biometrischen Daten
• Offenlegung von Daten, die zu Diskriminierung führen könnten (Rasse, politische Überzeugungen, Religion)
• Großflächige Offenlegung von Daten, die in Kombination Identitätsdiebstahl ermöglichen

Sie müssen betroffene Personen nicht benachrichtigen, wenn:

• Sie eine angemessene Verschlüsselung oder andere Schutzmaßnahmen implementiert hatten, die die Daten unverständlich machen (z. B. die verletzten Daten waren mit einem Schlüssel verschlüsselt, der nicht kompromittiert wurde)
• Sie nachträgliche Maßnahmen ergriffen haben, die sicherstellen, dass das hohe Risiko sich voraussichtlich nicht mehr verwirklicht
• Eine individuelle Benachrichtigung einen unverhältnismäßigen Aufwand erfordern würde (in diesem Fall nehmen Sie stattdessen eine öffentliche Bekanntmachung vor)

Was enthalten sein muss: Die Benachrichtigung muss in klarer, einfacher Sprache verfasst sein und enthalten:

• Die Art der Verletzung
• Die Kontaktdaten des DSB oder der Kontaktstelle
• Die wahrscheinlichen Folgen
• Die ergriffenen oder vorgeschlagenen Maßnahmen, einschließlich Schritte, die die betroffene Person zum Selbstschutz unternehmen kann

Einen Plan zur Reaktion auf Datenpannen aufbauen

Die 72-Stunden-Frist macht eine Vorbereitung im Voraus unerlässlich. So strukturieren Sie Ihren Reaktionsplan:

Rollen und Verantwortlichkeiten definieren

Koordinator für Datenpannen: Eine benannte Person (typischerweise der DSB, CISO oder Leiter der Sicherheit), die den Reaktionsprozess von der Erkennung bis zur Lösung verantwortet.

Incident-Response-Team: Definieren Sie, wer einbezogen werden muss:

• Sicherheits-/Entwicklungsteam (Untersuchung und Eindämmung)
• Rechtsberatung (Meldepflichten, Haftungsbewertung)
• Kommunikation (Benachrichtigung betroffener Personen, öffentliche Stellungnahmen)
• Management (strategische Entscheidungen, Ressourcenzuweisung)
• Customer Success (wenn Kundendaten betroffen sind)

Eskalationswege: Definieren Sie, wie jedes Teammitglied außerhalb der Geschäftszeiten erreichbar ist. Eine Datenpanne um 23 Uhr am Freitag kann nicht bis zum Standup am Montag warten.

Erkennungs- und Meldekanäle einrichten

Interne Meldung: Jeder Mitarbeiter sollte wissen, wie ein vermuteter Datenschutzvorfall gemeldet wird. Erstellen Sie einen dedizierten Kanal — einen Slack-Kanal, einen E-Mail-Alias oder ein Incident-Management-Formular — und stellen Sie sicher, dass dieser kontinuierlich überwacht wird.

Externe Meldung: Ihre Anbieter und Auftragsverarbeiter sollten Sie umgehend benachrichtigen, wenn sie eine Datenpanne erleiden, die Ihre Daten betrifft. Prüfen Sie Ihre AVVs, um sicherzustellen, dass Klauseln zur Meldung von Datenpannen spezifische Zeitrahmen enthalten.

Automatische Erkennung: Implementieren Sie Monitoring für anomale Zugriffsmuster, ungewöhnliche Datenexporte, Spitzen fehlgeschlagener Authentifizierungen und unbefugte Konfigurationsänderungen.

Antwortvorlagen erstellen

Bereiten Sie Vorlagen im Voraus vor für:

• Meldung an die Aufsichtsbehörde (gemäß dem Formularformat der Behörde)
• Benachrichtigungs-E-Mail an betroffene Personen (einfache Sprache, kein Fachjargon)
• Format für interne Statusupdates
• Presseerklärung (für hochkarätige Datenpannen)

Erstellen Sie diese, wenn Sie ruhig sind und klar denken können — nicht während des Chaos eines aktiven Vorfalls.

Den Prozess üben

Führen Sie mindestens jährlich Planspiele durch. Präsentieren Sie ein realistisches Datenpannen-Szenario und gehen Sie den Reaktionsprozess durch:

• Wer wird zuerst benachrichtigt?
• Wie bewerten Sie den Umfang?
• Wer entwirft die Meldung an die Aufsichtsbehörde?
• Wie bestimmen Sie, ob betroffene Personen benachrichtigt werden müssen?
• Was, wenn die Datenpanne einen Auftragsverarbeiter betrifft, nicht Ihre eigenen Systeme?

Diese Übungen decken Lücken in Ihrem Plan auf, bevor es ein echter Vorfall tut.

Der Zeitplan für die Reaktion auf Datenpannen

Stunde 0–4: Erkennung und erste Bewertung

• Bestätigen, dass eine Verletzung des Schutzes personenbezogener Daten aufgetreten ist (vs. ein Sicherheitsvorfall, der keine personenbezogenen Daten betrifft)
• Art der Verletzung identifizieren (Vertraulichkeit, Integrität, Verfügbarkeit)
• Sofortige Eindämmungsmaßnahmen einleiten
• Incident-Response-Team aktivieren
• Datenpannen-Protokoll beginnen

Stunde 4–24: Untersuchung und Scoping

• Feststellen, welche Daten betroffen waren (Typen, Volumen, Kategorien betroffener Personen)
• Identifizieren, wie die Datenpanne aufgetreten ist
• Beurteilen, ob die Datenpanne eingedämmt oder noch andauernd ist
• Risiko für betroffene Personen bewerten
• Meldung an die Aufsichtsbehörde vorbereiten

Stunde 24–48: Entscheidung und Entwurf

• Entscheiden, ob eine Meldung an die Behörde erforderlich ist (im Zweifelsfall melden)
• Entscheiden, ob eine Benachrichtigung betroffener Personen erforderlich ist
• Meldung an die Behörde mit allen erforderlichen Elementen entwerfen
• Benachrichtigung betroffener Personen vorbereiten, falls erforderlich
• Geschäftsleitung unterrichten

Stunde 48–72: Meldung

• Meldung an die Aufsichtsbehörde einreichen (auch wenn unvollständig — Sie können später ergänzen)
• Benachrichtigung an betroffene Personen senden, falls erforderlich
• Alle ergriffenen Maßnahmen und getroffenen Entscheidungen dokumentieren
• Untersuchung und Behebung fortsetzen

Nach dem Vorfall: Lösung und Überprüfung

• Untersuchung abschließen
• Maßnahmen zur Verhinderung einer Wiederholung implementieren
• Ergänzende Informationen an die Aufsichtsbehörde übermitteln, wenn die Erstmeldung unvollständig war
• Nachbereitung des Vorfalls durchführen
• Reaktionsplan auf Basis der gewonnenen Erkenntnisse aktualisieren
• Datenpannen-Register aktualisieren

Das Datenpannen-Register

Artikel 33(5) verlangt, dass Sie alle Verletzungen des Schutzes personenbezogener Daten dokumentieren — nicht nur die, die Sie der Aufsichtsbehörde gemeldet haben. Ihr Datenpannen-Register sollte Folgendes aufzeichnen:

• Die Fakten der Verletzung (was passiert ist, wann, wie)
• Die Auswirkungen (welche Daten betroffen waren, wie viele betroffene Personen)
• Die ergriffenen Abhilfemaßnahmen
• Ihre Risikobewertung und Meldungsentscheidungen (einschließlich der Begründung, wenn Sie sich gegen eine Meldung entschieden haben)

Dieses Register dient als Nachweis Ihrer Rechenschaftspflicht. Wenn eine Aufsichtsbehörde Ihren Umgang mit Datenpannen prüft, wird sie dieses Verzeichnis sehen wollen.

Pflichten des Auftragsverarbeiters bei Datenpannen

Wenn Sie ein Auftragsverarbeiter sind und eine Datenpanne entdecken, die Daten des Verantwortlichen betrifft, verlangt Artikel 33(2), dass Sie den Verantwortlichen „unverzüglich” benachrichtigen. Ihr AVV sollte einen genaueren Zeitrahmen festlegen.

Als Auftragsverarbeiter melden Sie typischerweise nicht direkt an die Aufsichtsbehörde — das ist die Pflicht des Verantwortlichen. Aber Sie müssen:

• Den Verantwortlichen umgehend informieren
• Alle Informationen bereitstellen, die der Verantwortliche für seine Meldung benötigt
• Bei der Untersuchung und Behebung unterstützen
• Die Datenpanne in Ihren eigenen Aufzeichnungen dokumentieren

Wie GRCTrail bei der Reaktion auf Datenpannen hilft

GRCTrail bietet die Infrastruktur für eine organisierte, dokumentierte Reaktion auf Datenpannen:

Vorfall-Tracking. Erfassen Sie Datenpannen mit strukturierten Daten — Art, Umfang, Zeitplan, betroffene Datenkategorien — und verfolgen Sie sie durch Untersuchung, Meldung und Lösung.

Nachweismanagement. Jede Aktion während der Reaktion auf Datenpannen wird mit Zeitstempel versehen und protokolliert. Erstellen Sie einen auditfähigen Nachweis Ihrer Reaktion, ohne nachträglich nach E-Mails und Chat-Nachrichten suchen zu müssen.

Audit-Trail. Weisen Sie gegenüber Aufsichtsbehörden genau nach, was Sie getan haben, wann Sie es getan haben und warum Sie die Entscheidungen getroffen haben, die Sie getroffen haben. Der Rechenschaftsgrundsatz verlangt dokumentierte Nachweise, nicht nur gute Absichten.

Verknüpft mit Ihrem Compliance-Programm. Ihre Reaktion auf Datenpannen ist mit Ihrem VVT, Ihren AVVs und Ihren Risikobewertungen verknüpft. Das Verständnis, welche Verarbeitungstätigkeiten und Anbieter an einer Datenpanne beteiligt sind, ist sofort verfügbar.

Bauen Sie Ihre Fähigkeit zur Reaktion auf Datenpannen auf →

Verwandte Leitfäden

• DSGVO-Compliance-Checkliste — Das vollständige Compliance-Framework
• DSGVO-Bußgelder und Sanktionen — Was Nicht-Compliance kostet
• Datenschutz-Folgenabschätzung (DSFA) — Risiken identifizieren, bevor Datenpannen auftreten
• Auftragsverarbeitungsverträge (AVV) — Meldepflichten des Anbieters bei Datenpannen

Starten Sie mit GRCTrail →