Datenpanne melden: Flussdiagramm zur 72-Stunden-Frist der DSGVO

Was ist datenpanne melden: flussdiagramm zur 72-stunden-frist der dsgvo?

Eine Verletzung des Schutzes personenbezogener Daten (umgangssprachlich Datenpanne) ist jede Sicherheitsverletzung, die dazu führt, dass personenbezogene Daten vernichtet, verloren, verändert, unbefugt offengelegt oder unbefugt eingesehen werden, ob versehentlich oder vorsätzlich. Die meisten sind keine Cyberangriffe. Es sind die E-Mail an den falschen Empfänger, die Tabelle mit dem vergessenen ausgeblendeten Tabellenblatt, der im Zug liegengebliebene Laptop, das für alle geöffnete Laufwerk, das Backup, das sich als nicht wiederherstellbar erweist. Der Prozess unten wird von einem Verdacht ausgelöst und nicht von einer bestätigten Feststellung, denn die gesetzliche Uhr beginnt zu laufen, sobald die Organisation Kenntnis davon erlangt, dass eine Verletzung vorliegen könnte, und nicht erst, wenn sie die Untersuchung abschließt.

Dies ist bewusst kein Prozess zur Reaktion auf Sicherheitsvorfälle. Detektion, Forensik, Beweissicherung, Beseitigung und der Nachweis sauberer Systeme gehören dorthin und liegen bei der IT-Sicherheit; hier erscheinen sie als ein einziger Eindämmungsschritt und als Übergabe der Abhilfemaßnahmen zurück an die Sicherheit. Ist die Datenpanne ein Cyberangriff, lassen Sie beide Prozesse laufen: Die technische Reaktion stellt die Landschaft wieder her und sichert sie, während dieses Diagramm daneben an seiner eigenen Frist arbeitet und eine andere Frage beantwortet, wer muss bis wann informiert werden, und was schreiben Sie auf, wenn die Antwort niemand lautet. Es ist ebenso wenig IT-Incident-Management, das mit der Wiederherstellung des Dienstes endet, und nicht der Prozess für Auskunftsersuchen, bei dem Betroffene ihre eigenen Daten anfordern, statt dass die Organisation sie verliert.

Zwei Entscheidungen tragen das rechtliche Gewicht und werden regelmäßig verwechselt. Die Meldung an die Aufsichtsbehörde ist nach Art. 33 DSGVO der Regelfall: Sie ist erforderlich, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Die Benachrichtigung der betroffenen Personen nach Art. 34 DSGVO ist eine eigene und höhere Schwelle: Sie greift nur, wenn voraussichtlich ein hohes Risiko besteht. Eine Datenpanne kann also ohne Weiteres meldepflichtig sein, ohne dass die Betroffenen je etwas erfahren. Das Dritte, was Teams übersehen: Beide Zweige laufen zusammen. Jede Verletzung kommt in das interne Verzeichnis, auch die, gegen deren Meldung Sie sich entschieden haben, samt der Begründung dieser Entscheidung.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Fünf Rollenbahnen mit einem Verantwortlichen für jeden Schritt (Meldende Person, IT-Sicherheit, Datenschutzbeauftragter, Recht, Kommunikation) über fünf Phasenspalten: Meldung, Bewertung und Eindämmung, Meldeentscheidung, Benachrichtigung sowie Dokumentation und Nachbereitung.
• Die Meldephase: „Mögliche Datenpanne festgestellt“ und „Über den Meldeweg melden“ in der Bahn der meldenden Person, danach erfasst die IT-Sicherheit die Meldung und startet die Zeitschiene, damit steht der Kenntniszeitpunkt fest, ab dem die 72-Stunden-Frist läuft.
• Ersteinschätzung und Eindämmung in der Bahn der IT-Sicherheit, gefolgt von der Entscheidung „Personenbezogene Daten betroffen?“ beim Datenschutzbeauftragten, deren Nein-Zweig den Fall nur als Sicherheitsvorfall schließt, statt ihn durch die gesamte Meldestrecke zu ziehen.
• „Schwere und Risiko für Betroffene bewerten“ beim Datenschutzbeauftragten, danach bestimmt die Bahn Recht, welche Meldepflichten tatsächlich gelten, bevor die Entscheidung „Meldepflichtig an die Aufsichtsbehörde?“ fällt.
• Der Zweig Meldepflichtig führt über „Meldung entwerfen und rechtlich prüfen“ und „Aufsichtsbehörde binnen 72 Stunden melden“; der Zweig Nicht meldepflichtig führt stattdessen auf „Gründe gegen eine Meldung dokumentieren“. Die Entscheidung ist also in beide Richtungen belegt.
• Eine gesonderte Entscheidung „Hohes Risiko für Betroffene?“, die die Kommunikation die Benachrichtigung der Betroffenen entwerfen und versenden lässt, danach der Eintrag ins Verzeichnis, den beide Zweige erreichen, die Abhilfemaßnahmen der IT-Sicherheit, die Nachbereitung und das Schließen der Vorfallakte.

Wann Sie diese Vorlage verwenden sollten

• Sie schreiben oder überarbeiten ein Verfahren für Datenpannen und brauchen eine Seite, die zeigt, wer bewertet, wer entscheidet und wer meldet.
• Sie wollen die Frage der Meldepflicht vorab geklärt haben, damit freitags um 17 Uhr niemand darüber streitet, ob die Frist bereits läuft.
• Sie führen eine Übung durch und wollen die 72-Stunden-Strecke durchgängig testen, einschließlich der Entwurfs- und Freigabeschritte, die den größten Teil der Zeit verbrauchen.
• Sie schulen Beschäftigte darauf, was wo zu melden ist, denn der erste Schritt fast jeder realen Datenpanne ist eine normale Mitarbeiterin, der etwas auffällt.
• Ein Auditor oder ein Kunde verlangt den Nachweis eines dokumentierten Verfahrens für Datenpannen (das Diagramm belegt das Verfahren, es belegt für sich genommen keine Konformität).

So funktioniert es

1. Benennen Sie die Rollen und den Meldeweg

   Ersetzen Sie die fünf Bahnen durch die Rollen, die es bei Ihnen wirklich gibt. Kleinere Organisationen haben keinen eigenen Datenschutzbeauftragten und führen diese Bahn mit Recht oder einer Datenschutzkoordination zusammen; andere ergänzen eine externe Kanzlei oder den Cyberversicherer. Tragen Sie dann den tatsächlichen Meldeweg in „Über den Meldeweg melden“ ein: ein Postfach, ein Formular, eine Telefonnummer, und die Regel, dass bei Verdacht gemeldet und nicht erst selbst ermittelt wird.

2. Legen Sie Ihre Aufsichtsbehörden und Fristen fest

   Bearbeiten Sie „Geltende Meldepflichten bestimmen“ und benennen Sie die für Sie zuständige Aufsichtsbehörde: in Deutschland die Landesbehörde am Sitz Ihrer Niederlassung, bei grenzüberschreitender Verarbeitung Ihre federführende Behörde. Ergänzen Sie branchenspezifische Regime, unter die Sie fallen, etwa NIS2, DORA oder § 8b BSIG; die laufen mit eigenen, teils deutlich kürzeren Uhren. Nehmen Sie vertragliche Informationsfristen gegenüber Kunden dazu, die häufig kürzer sind als die gesetzlichen.

3. Schreiben Sie Ihre Risikokriterien auf

   Hängen Sie eigene Kriterien an „Schwere und Risiko für Betroffene bewerten“: Art und Sensibilität der Daten, Zahl der Betroffenen und Datensätze, wie leicht Personen identifizierbar sind, ob die Daten verschlüsselt oder anderweitig unbrauchbar waren, ob besonders schutzbedürftige Personen betroffen sind, sowie Schwere und Eintrittswahrscheinlichkeit des Schadens. Vorab geschriebene Kriterien sind das, was beide Entscheidungen im Nachhinein verteidigbar macht.

4. Weisen Sie die beiden Entscheidungen und die Freigabe zu

   Halten Sie im Diagramm fest, wer „Meldepflichtig an die Aufsichtsbehörde?“ und „Hohes Risiko für Betroffene?“ verantwortet, wer die Einreichung bei der Behörde freigeben darf und wer den Wortlaut an die Betroffenen genehmigt. Ergänzen Sie für jede Rolle eine Vertretung. Datenpannen warten nicht auf das Ende des Jahresurlaubs.

5. Setzen Sie interne Zwischenfristen innerhalb der 72 Stunden

   Rechnen Sie von der Frist rückwärts und geben Sie den Zwischenschritten Zielzeiten: wann der Datenschutzbeauftragte die Bewertung vorliegen haben muss, wann der Entwurf bei Recht sein muss, wann die Freigabe geschlossen ist. Die gesetzliche Frist ist die äußere Grenze und nicht der Plan. Verbraucht werden die Stunden in Entwurf und Abstimmung.

6. Verweisen Sie auf Ihr echtes Verzeichnis und versionieren Sie das Diagramm

   Verknüpfen Sie „Vorfall im Verzeichnis dokumentieren“ mit dem Verzeichnis, das Sie tatsächlich führen, und listen Sie die Pflichtfelder auf: die Tatsachen der Verletzung, ihre Auswirkungen, die ergriffenen Abhilfemaßnahmen und die Begründung jeder Meldeentscheidung, gerade auch der ablehnenden. Geben Sie das Diagramm anschließend an Datenschutz, Recht, IT-Sicherheit und Kommunikation zur Freigabe und bewahren Sie die freigegebene Fassung auf, damit das geübte Verfahren dem veröffentlichten entspricht.

Häufig gestellte Fragen

Wann beginnt die 72-Stunden-Frist für die Meldung einer Datenpanne?

Nach Art. 33 DSGVO meldet der Verantwortliche eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt geworden ist. Kenntnis bedeutet eine hinreichende Gewissheit, dass ein Sicherheitsvorfall zu einer Beeinträchtigung personenbezogener Daten geführt hat; eine kurze Phase der ersten Verifizierung ist anerkannt, die Uhr lässt sich aber nicht dadurch anhalten, dass die Untersuchung ausgedehnt wird. Die 72 Stunden sind Kalenderstunden und keine Arbeitsstunden: Wochenenden und Feiertage liegen im Fenster. Deshalb steht in diesem Diagramm „Meldung erfassen und Zeitschiene starten“ ganz vorn und hält fest, wer wann was gemeldet hat.

Worin unterscheidet sich die Meldung an die Behörde von der Benachrichtigung der Betroffenen?

Es sind zwei getrennte Prüfungen mit unterschiedlichen Schwellen. Deshalb zeichnet das Diagramm zwei Entscheidungen und nicht eine. Die Aufsichtsbehörde ist nach Art. 33 DSGVO zu unterrichten, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen; die Meldung ist damit faktisch der Regelfall. Die betroffenen Personen sind nach Art. 34 DSGVO nur zu benachrichtigen, wenn voraussichtlich ein hohes Risiko besteht, und es gibt anerkannte Ausnahmen, etwa wenn die Daten verschlüsselt und unverständlich bleiben oder wenn nachträgliche Maßnahmen das hohe Risiko unwahrscheinlich machen. Eine Datenpanne kann also der Behörde gemeldet und den Betroffenen nie mitgeteilt werden.

Müssen wir eine Datenpanne dokumentieren, die wir nicht gemeldet haben?

Ja. Art. 33 Abs. 5 DSGVO verpflichtet den Verantwortlichen, jede Verletzung des Schutzes personenbezogener Daten zu dokumentieren (einschließlich der Tatsachen, ihrer Auswirkungen und der ergriffenen Abhilfemaßnahmen) unabhängig davon, ob gemeldet wurde. In der Praxis ist die Dokumentation einer nicht gemeldeten Verletzung die wichtigere, denn sie ist der einzige Beleg dafür, dass die Entscheidung begründet und nicht bequem war. Deshalb führt der Zweig Nicht meldepflichtig in diesem Diagramm über „Gründe gegen eine Meldung dokumentieren“, und beide Zweige laufen im Verzeichnis zusammen.

Wie unterscheidet sich das von einem Prozess zur Reaktion auf Sicherheitsvorfälle?

Ein Incident-Response-Prozess dreht sich um den Angreifer und die IT-Landschaft: detektieren, triagieren, Beweise sichern, eindämmen, beseitigen, Sauberkeit nachweisen, Dienst wiederherstellen. Dieser Prozess dreht sich um die Menschen, deren Daten betroffen sind, und um die daraus folgenden Pflichten; ausgelöst wird er von jeder Verletzung personenbezogener Daten, auch von solchen ganz ohne Angreifer wie einer fehlgeleiteten E-Mail oder einem nicht wiederherstellbaren Backup. Beide überschneiden sich bei der Eindämmung und beim Meldezweig; bei einem Cyberangriff lassen Sie sie parallel laufen, wobei die Sicherheit die technische Spur führt und der Datenschutzbeauftragte diese hier.

Was gilt, wenn wir Auftragsverarbeiter und nicht Verantwortlicher sind?

Ein Auftragsverarbeiter meldet weder der Aufsichtsbehörde noch den Betroffenen. Er hat den Verantwortlichen nach Art. 33 Abs. 2 DSGVO unverzüglich zu informieren, nachdem ihm die Verletzung bekannt wurde; der Verantwortliche führt danach die Bewertung und beide Meldeentscheidungen. Wenn das Ihre Rolle ist, kürzen Sie das Diagramm an der Entscheidung „Meldepflichtig an die Aufsichtsbehörde?“, ersetzen Sie sie durch Ihre Meldung an den Verantwortlichen und prüfen Sie Ihre Verträge: Auftragsverarbeitungsverträge setzen regelmäßig eine feste interne Frist, die deutlich kürzer ist als die 72 Stunden des Verantwortlichen.