Data-Breach-Meldung nach Art. 33/34 DSGVO im Zusammenspiel mit NIS2 und DORA

Problem in der Praxis

In vielen Organisationen existieren Meldepflichten getrennt voneinander: Der Datenschutz kennt die 72-Stunden-Frist der DSGVO, die IT-Sicherheit kennt NIS2, die Compliance-Funktion im Finanzbereich kennt DORA. Im Vorfall arbeiten diese Funktionen jedoch am selben Ereignis, oft ohne abgestimmten Prozess.

Das führt zu typischen Reibungen. Die Uhr für die DSGVO-Meldung läuft ab Bekanntwerden der Verletzung, also häufig schon, während die forensische Analyse noch läuft und der Sachverhalt unsicher ist. Gleichzeitig fragt eine andere Aufsicht nach einer Frühwarnung in noch kürzerer Frist. Es entsteht Streit darüber, ob überhaupt personenbezogene Daten betroffen sind, ob das Risiko meldepflichtig ist und welche Behörde zuständig ist.

Wenn dann unter Druck entschieden wird, passieren zwei gegenläufige Fehler: Entweder wird zu spät oder gar nicht gemeldet, weil man auf vollständige Klarheit wartet, oder es wird unkoordiniert an mehrere Stellen gemeldet, mit widersprüchlichen Angaben. Beides ist nachweisbar und beides kann teuer werden.

CISO-Einordnung

Der CISO sollte Data-Breach-Meldung nicht als juristische Einzelaufgabe verstehen, sondern als Ausspielung eines Incident-Prozesses in mehrere regulatorische Kanäle. Drei Pflichtenstränge sind dabei zu trennen, auch wenn sie denselben Vorfall betreffen:

• DSGVO (Art. 33/34): Auslöser ist eine Verletzung des Schutzes personenbezogener Daten. Empfänger ist die zuständige Datenschutz-Aufsichtsbehörde, in Deutschland im nichtöffentlichen Bereich die Landesdatenschutzbehörden, für bestimmte Bundes- und Telekommunikations-/Postbereiche die oder der Bundesbeauftragte (BfDI). Frist an die Aufsicht: unverzüglich, möglichst binnen 72 Stunden. Zusätzlich Benachrichtigung Betroffener bei hohem Risiko.
• NIS2 (Richtlinie (EU) 2022/2555): Auslöser ist ein erheblicher Sicherheitsvorfall, unabhängig davon, ob personenbezogene Daten betroffen sind. Empfänger ist die zuständige Behörde beziehungsweise das CSIRT. Die Richtlinie sieht ein gestuftes Modell vor: eine Frühwarnung innerhalb von 24 Stunden, eine Vorfallmeldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats.
• DORA (Verordnung (EU) 2022/2554): Auslöser ist ein schwerwiegender IKT-bezogener Vorfall im Finanzsektor. Empfänger ist die zuständige Finanzaufsicht. DORA definiert eigene Klassifizierungsschwellen und Meldefristen über technische Regulierungs- und Durchführungsstandards; diese sind im Einzelfall gegen den aktuellen Stand zu prüfen und nicht mit den DSGVO-Fristen gleichzusetzen.

Es handelt sich um parallele, nicht um austauschbare Pflichten. Eine NIS2- oder DORA-Meldung ersetzt keine DSGVO-Meldung und umgekehrt. Wer in einem Kanal gemeldet hat, ist in den anderen nicht entlastet.

Umsetzungsperspektive

Die Lösung ist kein viertes Meldeverfahren, sondern ein gemeinsamer Erkennungs- und Triage-Kern, der die einzelnen Pflichten bedient. Bewährt hat sich ein Vorgehen in vier Schritten.

Erstens ein einheitlicher Vorfalleingang. Jeder erkannte Sicherheitsvorfall läuft durch dieselbe Erst-Triage, die parallel drei Fragen stellt: Sind personenbezogene Daten betroffen (DSGVO)? Liegt ein erheblicher Sicherheitsvorfall im NIS2-Sinn vor? Sind wir als Finanzentität mit einem IKT-Vorfall im DORA-Sinn betroffen?

Zweitens eine Trigger-Matrix. Für jede Pflicht werden Auslöser, Frist, Empfänger, interner Entscheider und Meldekanal vorab festgelegt. So muss im Ernstfall nicht recherchiert werden, sondern nur noch der bekannte Pfad gegangen werden. Der kürzeste relevante Frist-Trigger taktet dabei das Krisentempo, nicht der längste.

Drittens ein definierter Zeitpunkt des Bekanntwerdens. Für die DSGVO-Frist ist festzuhalten, wann die Organisation hinreichende Kenntnis von der Verletzung erlangt hat, denn ab diesem Moment läuft die 72-Stunden-Frist. Dieser Zeitpunkt sollte bewusst dokumentiert werden, auch um eine etwaige Verspätung begründen zu können.

Viertens das Konzept der gestuften Meldung. Die DSGVO erlaubt ausdrücklich, Informationen schrittweise nachzureichen, wenn sie nicht zeitgleich bereitgestellt werden können. Eine fristgerechte Erstmeldung mit dem bekannten Sachstand ist daher fast immer besser als eine verspätete vollständige Meldung. Auftragsverarbeiter sind vertraglich so einzubinden, dass sie eine Verletzung unverzüglich an den Verantwortlichen melden, denn ihre Meldekette ist Teil der eigenen Frist.

Typische Fehler

1. Die 72-Stunden-Frist wird als reine Datenschutzaufgabe behandelt, ohne den Incident-Prozess der Security daran zu koppeln.
2. Es wird auf vollständige forensische Klarheit gewartet, statt fristgerecht mit dem bekannten Sachstand zu melden und nachzureichen.
3. NIS2- und DORA-Meldungen werden als Ersatz für die DSGVO-Meldung missverstanden.
4. Der Zeitpunkt des Bekanntwerdens wird nicht festgehalten, sodass Fristbeginn und eine etwaige Verspätung nicht belegbar sind.
5. Auftragsverarbeiter melden zu spät, weil im Vertrag keine eigene unverzügliche Meldepflicht an den Verantwortlichen vereinbart ist.
6. Verletzungen ohne Meldepflicht werden nicht dokumentiert, obwohl die DSGVO eine Dokumentation aller Verletzungen verlangt.

Risiken und Trade-offs

Der zentrale Trade-off liegt zwischen Geschwindigkeit und Genauigkeit. Eine zu frühe Meldung kann unvollständig oder falsch sein, eine zu späte verletzt die Frist. Die DSGVO löst diesen Konflikt zugunsten der Geschwindigkeit auf, indem sie eine fristgerechte, gegebenenfalls vorläufige Meldung und ein Nachreichen vorsieht. Das Risiko verschiebt sich damit von "wir wissen noch nicht genug" zu "wir entscheiden bewusst und dokumentieren den Sachstand".

Ein zweiter Trade-off betrifft die Benachrichtigung der Betroffenen nach Art. 34. Eine Benachrichtigung schafft Transparenz, kann aber auch Verunsicherung, Reputationswirkung und operative Last erzeugen. Sie ist verpflichtend bei voraussichtlich hohem Risiko; die DSGVO sieht jedoch Ausnahmen vor, etwa wenn die betroffenen Daten durch geeignete Maßnahmen wie eine wirksame Verschlüsselung für Unbefugte unzugänglich sind. Ob eine Ausnahme greift, ist eine Einzelfallbewertung und keine pauschale Entlastung.

Ein dritter Punkt ist die Konsistenz über Kanäle hinweg. Widersprüchliche Angaben gegenüber verschiedenen Behörden zum selben Vorfall sind ein eigenständiges Risiko. Ein gemeinsamer Faktenstand, der alle Meldungen speist, ist daher kein Komfort, sondern Risikosteuerung.

Entscheidungspunkte

• Ab welchem internen Ereignis gilt eine Verletzung als "bekannt", und wer stellt diesen Zeitpunkt verbindlich fest?
• Wer entscheidet unter Zeitdruck über das Auslösen der DSGVO-Meldung, und wer über NIS2- und gegebenenfalls DORA-Meldungen?
• Nach welchen Kriterien beurteilen wir das Risiko für die Aufsichtsmeldung und das hohe Risiko für die Betroffenenbenachrichtigung?
• Wie stellen wir einen einzigen, abgestimmten Faktenstand sicher, der alle parallelen Meldungen speist?
• Wie sind Auftragsverarbeiter und kritische Dienstleister vertraglich und operativ in unsere Fristen eingebunden?
• Wann ist die DORA- oder NIS2-Zuordnung im konkreten Fall einschlägig, und wer prüft die jeweils geltenden Schwellen und Fristen?

Praktische Empfehlungen

1. Etablieren Sie einen gemeinsamen Vorfalleingang mit einer Triage, die DSGVO-, NIS2- und DORA-Relevanz parallel prüft.
2. Pflegen Sie eine Trigger-Matrix mit Auslöser, Frist, Empfänger, Entscheider und Kanal je Pflicht und üben Sie sie in Tabletop-Szenarien.
3. Behandeln Sie die kürzeste einschlägige Frist als Taktgeber des Krisenmanagements und melden Sie fristgerecht mit dem bekannten Sachstand.
4. Dokumentieren Sie konsequent den Zeitpunkt des Bekanntwerdens sowie jede Verletzung, auch nicht gemeldete, als Teil der Rechenschaftspflicht.
5. Verankern Sie in Auftragsverarbeitungsverträgen eine unverzügliche Meldepflicht des Auftragsverarbeiters an den Verantwortlichen.
6. Bereiten Sie Melde- und Benachrichtigungstexte als Vorlagen vor, damit unter Zeitdruck nur noch der Sachverhalt einzusetzen ist.
7. Ziehen Sie bei der Risikobewertung und bei der Auslegung der Ausnahmen frühzeitig Datenschutzbeauftragte und Rechtsberatung hinzu.

Relevante Normreferenzen

• DSGVO (Verordnung (EU) 2016/679): Art. 33 (Meldung an die Aufsichtsbehörde, 72-Stunden-Maßgabe, Dokumentationspflicht) und Art. 34 (Benachrichtigung der betroffenen Personen bei hohem Risiko, Ausnahmen); Bezug zu Art. 5 Abs. 1 lit. f und Abs. 2 (Integrität/Vertraulichkeit, Rechenschaftspflicht) sowie Art. 32 (Sicherheit der Verarbeitung).
• NIS2-Richtlinie (Richtlinie (EU) 2022/2555): Art. 23 (gestufte Meldepflichten bei erheblichen Sicherheitsvorfällen).
• DORA (Verordnung (EU) 2022/2554): Meldung schwerwiegender IKT-bezogener Vorfälle im Finanzsektor; konkrete Schwellen und Fristen über begleitende technische Standards.
• ISO/IEC 27001 und ISO/IEC 27701: nur als allgemeine Referenz für das Managementsystem und das Datenschutz-Informationsmanagement; keine Wiedergabe von Control- oder Anforderungslisten.