Bei einer meldepflichtigen Datenpanne verlangt Art. 33 DSGVO die Meldung an die Aufsichtsbehörde binnen 72 Stunden. Der häufigste Fehler in der Praxis betrifft nicht das Melden selbst, sondern den Fristbeginn: Die Uhr läuft nicht erst ab der internen Meldekette, sondern sobald das Unternehmen als Verantwortlicher mit hinreichender Gewissheit Kenntnis von der Panne hat — zugerechnet wird die Kenntnis der Stelle, die den Vorfall bemerkt. Wird ein Notebook mit Kundendaten am Freitagabend gestohlen und der Diebstahl sofort bemerkt, läuft die Frist ab Freitagabend — auch wenn der Datenschutzkoordinator erst am Montag informiert wird. Wie Art. 33 DSGVO die Meldepflicht konstruiert und was in den ersten Stunden zählt, zeigt diese Lektion.
Die 72-Stunden-Frist beginnt bei Kenntnis — nicht bei Klärung
Art. 33 Abs. 1 DSGVO verpflichtet den Verantwortlichen, eine Datenpanne der zuständigen Aufsichtsbehörde zu melden — und zwar „unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden der Verletzung". Bekanntwerden ist der Schlüsselbegriff: Der Europäische Datenschutzausschuss (EDSA), also das Gremium der EU-Datenschutzbehörden, hat in seiner Leitlinie 9/2022 klargestellt, dass die Frist beginnt, sobald der Verantwortliche hinreichend sicher weiß, dass eine Verletzung eingetreten ist — nicht erst, wenn er alle Details kennt.
Vereinfacht gesagt: Die Frist wartet nicht auf die vollständige Aufklärung. Wer meldet, was er weiß — und nachmeldet, was er später herausfindet — handelt richtig. Wer wartet, bis alles geklärt ist, handelt zu spät.
Das Gesetz kennt die Realität und erlaubt ausdrücklich eine stufenweise Meldung: Eine erste, unvollständige Meldung fristet dann die Aufsichtsbehörde, spätere Ergänzungen können „ohne unangemessene Verzögerung" nachgereicht werden (Art. 33 Abs. 4 DSGVO). Kommt die Meldung trotzdem nach 72 Stunden, muss der Verantwortliche die Verzögerung schriftlich begründen. Die Verspätung selbst ist ein eigenständiger Bußgeldtatbestand nach Art. 83 Abs. 4 DSGVO — und Verstöße gegen die Meldepflicht gehören zu den in der Aufsichtspraxis häufig geahndeten Tatbeständen.
Ein Hinweis zur Rechtsfortentwicklung: Der EU-Digital-Omnibus-Vorschlag (EU-Kommission, vorgestellt am 19. November 2025) sieht vor, die Art.-33-Frist auf 96 Stunden zu verlängern und die Meldepflicht auf Vorfälle mit „hohem Risiko" zu beschränken. Das Gesetzgebungsverfahren läuft — aktuell gilt die 72-Stunden-Frist für alle risikobehafteten Pannen unverändert; die Änderung ist einzuplanen, aber nicht vorzuziehen (Quelle:).
!
Wie ernst die Behörden
die Meldepflicht nehmen
Den deutschen Aufsichtsbehörden wurden 2025 über 10.000 Datenpannen gemeldet — häufigste Ursache war der Fehlversand von Dokumenten. Das höchste deutsche Bußgeld des Jahres verhängte die BfDI mit 45 Millionen Euro gegen Vodafone (u. a. Mängel bei Authentifizierung und Auftragsverarbeitung). Meldepflicht und deren Verletzung sind also kein theoretisches Risiko.
Nicht jede Panne löst eine Meldepflicht aus — die Schwellenwert-Bewertung
Ob eine Datenpanne gemeldet werden muss, hängt von einer Risikoeinschätzung ab. Die DSGVO unterscheidet drei Lagen, die über die Pflichten entscheiden:
Risikolage | Beispiel | Meldung an Behörde | Betroffene benachrichtigen |
|---|---|---|---|
Risiko | VerschlĂĽsseltes Notebook gestohlen, SchlĂĽssel sicher | nein (aber Dokumentation Pflicht) | nein |
Risiko | Kundenliste mit Namen und Adressen verloren, begrenzter Schaden | ja, binnen 72 h | nein |
hohes Risiko | Gesundheitsdaten, Zugangsdaten, Finanzdaten offengelegt | ja, binnen 72 h | ja, unverzĂĽglich |
(Quelle: Art. 33, 34 DSGVO;; EDSA Leitlinie 9/2022)
Risiko bedeutet nach dem EDSA: Es besteht eine realistische Möglichkeit, dass Betroffene einen Schaden erleiden — Diskriminierung, Identitätsdiebstahl, finanzieller Schaden, Rufschaden, Verlust der Kontrolle über eigene Daten. Die Schwere und die Wahrscheinlichkeit des Schadens spielen beide eine Rolle. Vereinfacht: Je sensibler die Daten und je mehr Personen betroffen, desto eher wird aus einem Risiko ein hohes Risiko.
Was nicht gilt: die stille Hoffnung, dass nichts passiert. Art. 33 Abs. 1 DSGVO macht die Meldung zum Regelfall — gemeldet wird, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko. Die Ausnahme ist zu begründen, nicht die Meldung. Und wer sich auf sie beruft, muss die Einschätzung nach Art. 33 Abs. 5 dokumentieren, damit die Aufsicht sie nachprüfen kann. Fehlender Nachweis eines Zugriffs ist deshalb kein Argument gegen die Meldung, sondern der Normalfall in den ersten Stunden.
Die Benachrichtigung der Betroffenen verlangt klare Sprache,
keine Juristenprosa
Liegt ein hohes Risiko vor, greift Art. 34 DSGVO: Die betroffenen Personen sind „unverzüglich" zu informieren. Weder das Gesetz noch der EDSA schreiben eine konkrete Frist in Stunden vor — aber die Praxis der Aufsichtsbehörden orientiert sich an „so schnell wie möglich nach der Risikobewertung".
Der Inhalt der Betroffeneninformation ist gesetzlich vorgegeben (Art. 34 Abs. 2 DSGVO):
„Klare und einfache Sprache" — so steht es wörtlich im Gesetz. Keine Haftungsausschlüsse, keine Minimierung, keine Bitte um Verständnis. Das Schreiben ist kein PR-Text, sondern ein Handlungsimpuls für Menschen, die möglicherweise Schaden nehmen.
Die Aufsicht kennt die Ausnahmen von der Benachrichtigungspflicht (Art. 34 Abs. 3 DSGVO): Wenn geeignete technische Maßnahmen die Daten unlesbar gemacht hatten — etwa vollständige Verschlüsselung — entfällt die Pflicht. Ebenso, wenn nachträgliche Maßnahmen das hohe Risiko ausräumen, oder wenn die individuelle Benachrichtigung unverhältnismäßigen Aufwand erzeugt. Im letzteren Fall tritt eine öffentliche Bekanntmachung an die Stelle — wie im Apfelkiste-Urteil geschehen, wo 19.000 Betroffene nicht mehr individuell identifizierbar waren (Quelle:).
Der Melde-Workflow:
Schritt fĂĽr Schritt in 72 Stunden
Kein Unternehmen kann im Ernstfall einen Meldeprozess von Grund auf neu erfinden. Was zählt, ist, was vor dem Vorfall vorbereitet wurde. Der Ablauf:
Schritt
Eindämmen (Stunden 0–2)
Vorgang stoppen: Zugriff sperren, betroffene Systeme isolieren, Datenfluss unterbrechen. Gleichzeitig: Zeitstempel festhalten. Wann wurde die Panne entdeckt? Wer hat sie gemeldet?
Schritt
Bewerten (Stunden 2–6)
Welche Datenkategorien sind betroffen? Wie viele Personen? Sind besondere Kategorien (Gesundheit, Finanzen, Zugangsdaten) dabei? Was ist das schlimmste realistische Szenario für die Betroffenen? Dieser Schritt erfordert das Urteil des Koordinators — und im Zweifel sofortigen Einbezug des Datenschutzbeauftragten.
Schritt
Dokumentieren (parallel)
Hergang, Beteiligte, Zeitlinie, Entscheidungen — schriftlich festhalten. Das Pannen-Register (s.u.) beginnt hier.
Schritt
Entscheiden (Stunden 4–8)
Ist die Panne meldepflichtig? Falls ja: Wer meldet an welche Behörde? Ist Betroffenenbenachrichtigung nötig? Wer kommuniziert intern mit der Leitung?
Schritt
Melden (spätestens Stunde 60–70)
Meldung über das Online-Formular der zuständigen Aufsichtsbehörde einreichen. In Deutschland ist jedes Bundesland für die privaten Unternehmen in seinem Gebiet zuständig (z. B. für bayerische Unternehmen). Eine vorläufige Meldung ist besser als keine — Ergänzungen können nachgereicht werden.
Schritt
Nacharbeit (nach Abschluss)
Ursachenanalyse, technische und organisatorische Maßnahmen (TOM) verbessern, Schulungskonzept anpassen, Pannen-Register vervollständigen.
Was die Meldung enthalten muss —
und was die Behörde prüft
Art. 33 Abs. 3 DSGVO listet den Mindestinhalt jeder Meldung auf:
Die Aufsichtsbehörde bewertet nicht nur den Vorfall selbst, sondern auch, wie die Organisation reagiert hat. Eine vollständige, strukturierte Meldung — auch wenn sie zeitlich knapp ist — zeigt Professionalität. Eine lückenhafte Meldung, gefolgt von Nachfragen der Behörde, verstärkt den Eindruck, dass kein funktionierendes Datenschutzmanagementsystem vorhanden ist.
Das österreichische Gericht (OGH, 24.03.2023, 6 Ob 242/22i) hat in einem Fall mit 24.000 offengelegten PCR-Testergebnissen festgestellt: Das Auskunftsrecht nach Art. 15 DSGVO umfasst auch das Recht, zu erfahren, ob man von einer bestimmten Datenpanne betroffen war — selbst wenn der Verantwortliche die Panne nicht als solche eingestuft hatte (Quelle:). Wer Betroffene nicht informiert, schreibt ihnen damit das Recht zu, aktiv nachzufragen — und das mit juristischen Konsequenzen.
Das Pannen-Register:
Pflicht für alle —
auch für die Fälle, die niemand meldet
Meldung an die Behörde, Betroffenenbenachrichtigung — das sind die sichtbaren Pflichten. Die unsichtbare, aber bei Audits entscheidende ist das interne Pannen-Register nach Art. 33 Abs. 5 DSGVO.
Es erfasst alle Datenpannen — auch die, bei denen kein Risiko vorlag und deshalb keine Meldung erfolgte. Mit anderen Worten: Das Register ist vollständiger als die Meldung an die Behörde. Wer meint, eine Panne intern lösen zu können, weil kein Risiko besteht, muss sie trotzdem dokumentieren — und dokumentieren, warum er sie nicht gemeldet hat.
Pflichtfelder des Registers:
Bei einer Prüfung durch die Aufsichtsbehörde ist das Register vorzulegen. Ein fehlendes Register ist kein kleines Versäumnis — es fehlt dann der Nachweis, dass der Verantwortliche überhaupt in der Lage ist, Pannen systematisch zu erfassen und zu bewerten
Die Leitung einbeziehen — Entscheidung liegt nicht beim Koordinator allein
Datenpannen sind Chefsache. Nicht weil der Koordinator die Kompetenz fehlt — sondern weil die rechtliche Verantwortung beim Verantwortlichen im Sinne der DSGVO liegt, und das ist die Geschäftsführung, nicht das Datenschutzteam.
Was das für die Praxis bedeutet: Der Koordinator stellt die Risikobewertung auf, bereitet die Meldung vor, kommuniziert mit der Aufsichtsbehörde — aber die Entscheidung, ob gemeldet wird und ob Betroffene informiert werden, muss mit der Leitung abgestimmt sein. Das ist keine Bürokratie; es ist Haftungsverteilung. Eine Meldung ohne Wissen der Leitung kann intern zum Problem werden. Eine unterlassene Meldung mit Wissen der Leitung wird zum externen Problem.
Die interne Meldekette muss deshalb vor dem Ernstfall definiert sein: Wer meldet dem Koordinator? Der Koordinator meldet wem? Wer informiert die Geschäftsführung? In welcher Frist? Das Konzept des Incident-Response-Plans — definiere kritische Komponenten, Single Points of Failure, klare Verantwortlichkeiten — gilt auch für Datenpannen (; Quelle im Vault:).
!
Praktisch heiĂźt das
Im Datenschutzkonzept des Unternehmens steht, welche Position die Meldung abzeichnet. Im Ernstfall ist das nicht der Moment, diese Frage zu klären.
Am Ende entscheidet das Tempo — und die Vorbereitung
Zurück zum gestohlenen Notebook vom Freitagabend. Am Montagmorgen um 7:43 Uhr sind bereits über 60 Stunden verstrichen — bis zum Ende der 72-Stunden-Frist bleiben nur noch rund zehn Stunden. Wenn jetzt eine vorbereitete Meldevorlage, ein befüllbares Pannen-Register und eine klare Meldekette existieren, ist das machbar. Wenn nicht, wird es sehr eng.
Die wichtigste Lektion aus Art. 33 DSGVO ist nicht juristischer, sondern organisatorischer Natur: Meldepflicht funktioniert nur, wenn die Vorbereitung vor dem Vorfall stattfindet — nicht danach.
- OGH 6 Ob 242/22i (24.03.2023) — Auskunftsrecht bei Datenpanne (Volltext, RIS)
- Cisco: „What Is an Incident Response Plan?"
- EDSA, Leitlinien 9/2022 zu Datenpannenmeldungen, Version 2.0 (Oktober 2024)
- GDD Praxishilfe: Checkliste Meldung von Datenschutzverletzungen nach Art. 33/34 DSGVO (Januar 2025)
- LDA Bayern: Datenpanne melden (Online-Formular)
- MKM LEGAL: Der Digital Omnibus (Dezember 2025)
- Datenschutzbeauftragter Hamburg: Data-Breach-Meldungen nach Art. 33 DSGVO (2023)

