die 72-Stunden-Frist praktisch umsetzen
Die DSGVO verlangt, dass eine meldepflichtige Datenschutzverletzung binnen 72 Stunden nach Bekanntwerden an die zuständige Aufsichtsbehörde gemeldet wird. Diese Frist klingt in der Theorie klar, wird in der Praxis aber schnell zum Problem, wenn ein Unternehmen erst am Wochenende ein IT-Team zusammentrommeln muss, um überhaupt herauszufinden, welche Daten in welchem Umfang betroffen sind. Wer den Meldeprozess vorher definiert und die technischen Voraussetzungen für eine schnelle Umfangsbestimmung schafft, verwandelt eine Krisensituation in einen abarbeitbaren Ablaufplan.
Inhaltsverzeichnis
- 1. Was als meldepflichtige Datenschutzverletzung gilt
- 2. Die 72-Stunden-Frist im Detail
- 3. Umfangsbestimmung eines Vorfalls technisch angehen
- 4. Wann zusätzlich Betroffene informiert werden müssen
- 5. Logging als Voraussetzung für eine schnelle Meldung
- 6. Der Unterschied zwischen der DSGVO-Meldung und allgemeinem Incident-Response
- 7. Interne Meldewege und die Rolle des Datenschutzbeauftragten
- 8. Dokumentationspflicht besteht auch ohne Meldung
- 9. Bußgeldrisiko bei verspäteter oder unterlassener Meldung
- 10. Zusammenfassung
- 11. FAQ
1. Was als meldepflichtige Datenschutzverletzung gilt
Eine Datenschutzverletzung im Sinne der DSGVO liegt vor, wenn personenbezogene Daten unbefugt offengelegt, verändert, gelöscht oder unzugänglich gemacht werden, unabhängig davon, ob dies durch einen externen Angriff, einen internen Fehler oder ein technisches Versagen ausgelöst wurde. Ein falsch versendeter E-Mail-Anhang mit Kundendaten fällt ebenso darunter wie ein kompromittierter Datenbankserver oder ein verschlüsselnder Ransomware-Angriff, der Daten zwar nicht stiehlt, aber unzugänglich macht.
Meldepflichtig an die Aufsichtsbehörde ist eine solche Verletzung nach Artikel 33 DSGVO immer dann, wenn ein Risiko für die Rechte und Freiheiten der betroffenen Personen besteht. Nicht meldepflichtig sind Fälle, in denen dieses Risiko nachweislich ausgeschlossen werden kann, etwa weil die betroffenen Daten durchgehend stark verschlüsselt waren und der Schlüssel nachweislich nicht kompromittiert wurde. Diese Ausnahme wird in der Praxis eng ausgelegt und darf nicht als Standardargument missbraucht werden, um eine Meldung zu vermeiden.
2. Die 72-Stunden-Frist im Detail
Die Frist beginnt nicht erst, wenn das Ausmaß eines Vorfalls vollständig geklärt ist, sondern bereits in dem Moment, in dem der Verantwortliche Kenntnis von der Verletzung erlangt hat. Diese Kenntnis liegt vor, sobald eine hinreichende Gewissheit besteht, dass ein sicherheitsrelevantes Ereignis zu einer Kompromittierung personenbezogener Daten geführt hat, nicht erst nach Abschluss der vollständigen forensischen Aufarbeitung.
Da eine vollständige Aufklärung innerhalb von drei Tagen selten möglich ist, sieht Artikel 33 Absatz 4 DSGVO ausdrücklich vor, dass eine Meldung in Phasen erfolgen darf. Die erste Meldung innerhalb der Frist kann vorläufige Informationen enthalten und muss ausdrücklich als solche gekennzeichnet werden, gefolgt von ergänzenden Meldungen, sobald weitere Erkenntnisse vorliegen. Diese Möglichkeit nimmt den Druck, sofort alle Details liefern zu müssen, verlangt aber trotzdem eine fristgerechte erste Meldung.
3. Umfangsbestimmung eines Vorfalls technisch angehen
Die zentrale Frage jeder Meldung lautet, welche Kategorien von Daten und wie viele betroffene Personen konkret betroffen sind. Ohne aussagekräftige Logs lässt sich diese Frage innerhalb von 72 Stunden kaum verlässlich beantworten, weshalb die technische Vorbereitung bereits lange vor einem Vorfall beginnen muss, nicht erst während der Krise.
Ein Zugriffslog, das protokolliert, welcher Account wann auf welche Tabellen oder Datensätze zugegriffen hat, erlaubt es, im Ernstfall gezielt einzugrenzen, welche Datensätze ein kompromittierter Account tatsächlich gelesen oder verändert hat. Ohne ein solches Log bleibt oft nur die pessimistische Annahme, dass sämtliche für den Account theoretisch erreichbaren Daten betroffen sein könnten, was die Meldung unnötig ausweitet und im schlimmsten Fall sogar ungenauer macht.
# Beispiel: Umfang eines Datenbankzugriffs anhand strukturierter Access-Logs eingrenzen
# Voraussetzung: jede Anwendung schreibt Zugriffe im JSON-Format nach /var/log/app/access.log
# Alle Zugriffe des kompromittierten Service-Accounts im relevanten Zeitfenster
jq -c 'select(.account == "svc-reporting" and
(.timestamp >= "2026-08-01T00:00:00Z") and
(.timestamp <= "2026-08-03T12:00:00Z"))' \
/var/log/app/access.log > incident-scope.jsonl
# Betroffene Tabellen und Anzahl der gelesenen Datensätze zusammenfassen
jq -s 'group_by(.table) | map({table: .[0].table, records: length})' \
incident-scope.jsonl
# Ergebnis liefert die Grundlage für die Kategorien- und Umfangsangabe
# in der Meldung nach Art. 33 Abs. 3 DSGVO
4. Wann zusätzlich Betroffene informiert werden müssen
Artikel 34 DSGVO verlangt eine zusätzliche, direkte Benachrichtigung der betroffenen Personen, sobald die Verletzung voraussichtlich ein hohes Risiko für deren Rechte und Freiheiten zur Folge hat. Diese Schwelle liegt bewusst höher als bei der Meldung an die Aufsichtsbehörde, sodass nicht jede meldepflichtige Verletzung automatisch auch eine Betroffenenbenachrichtigung nach sich zieht.
Ein hohes Risiko liegt typischerweise vor, wenn besonders sensible Datenkategorien betroffen sind, etwa Gesundheitsdaten, Zugangsdaten in Klartext oder Zahlungsinformationen, die einen unmittelbaren Missbrauch wie Identitätsdiebstahl oder finanziellen Schaden ermöglichen. Die Benachrichtigung kann entfallen, wenn der Verantwortliche nachweisen kann, dass angemessene Schutzmaßnahmen wie eine starke Verschlüsselung die Daten für Unbefugte unverständlich gemacht haben, oder wenn die Benachrichtigung einen unverhältnismäßigen Aufwand bedeuten würde und stattdessen eine öffentliche Mitteilung erfolgt.
5. Logging als Voraussetzung für eine schnelle Meldung
Ein Unternehmen, das erst im laufenden Vorfall entscheidet, welche Systeme überhaupt Logs schreiben sollen, verliert wertvolle Zeit innerhalb der 72-Stunden-Frist. Sinnvoll ist es, bereits im Vorfeld festzulegen, welche Systeme personenbezogene Daten verarbeiten, und für genau diese Systeme ein Mindestmaß an Zugriffs- und Änderungsprotokollierung dauerhaft zu aktivieren.
Wichtig ist dabei nicht nur, dass geloggt wird, sondern auch, dass die Logs selbst manipulationssicher aufbewahrt und über einen ausreichenden Zeitraum vorgehalten werden, üblicherweise mehrere Monate. Ein Angreifer, der Zugriff auf ein System erlangt, versucht häufig gezielt, die eigenen Spuren im Log zu löschen. Zentrale, vom kompromittierten System getrennte Log-Speicherung verhindert genau das und liefert im Ernstfall die verlässliche Datenbasis für die Umfangsbestimmung.
6. Der Unterschied zwischen der DSGVO-Meldung und allgemeinem Incident-Response
Allgemeines Incident-Response konzentriert sich primär auf die technische Eindämmung eines Vorfalls, also darauf, einen Angreifer aus dem System zu entfernen, die Ursache zu beheben und den Normalbetrieb wiederherzustellen. Diese technischen Schritte laufen unabhängig davon ab, ob personenbezogene Daten betroffen sind oder nicht, und folgen eigenen, meist rein technischen Prioritäten.
Der DSGVO-Meldeprozess ist ein rechtlicher Compliance-Prozess, der parallel zum technischen Incident-Response laufen muss, aber eigene Fristen, eigene Verantwortlichkeiten und eigene Dokumentationsanforderungen hat. Ein Unternehmen, das beide Prozesse vermischt und die Meldefrist erst nach vollständigem Abschluss der technischen Aufarbeitung startet, verpasst die 72-Stunden-Frist fast zwangsläufig, da eine vollständige technische Aufklärung oft deutlich länger dauert.
7. Interne Meldewege und die Rolle des Datenschutzbeauftragten
Damit die 72-Stunden-Frist überhaupt eingehalten werden kann, muss innerhalb des Unternehmens ein klarer, jederzeit erreichbarer Meldeweg existieren, über den jeder Mitarbeiter einen Verdacht auf eine Datenschutzverletzung sofort an die richtige Stelle weiterleiten kann. Diese Stelle ist üblicherweise der Datenschutzbeauftragte, der die rechtliche Bewertung vornimmt und über die Notwendigkeit einer Meldung entscheidet.
In der Praxis bewährt sich ein fest definiertes Eskalationsteam aus Datenschutzbeauftragtem, IT-Sicherheitsverantwortlichem und Geschäftsführung, das innerhalb weniger Stunden nach Bekanntwerden eines Verdachtsfalls zusammentritt. Ohne eine solche vorab definierte Struktur verstreicht wertvolle Zeit allein damit, herauszufinden, wer überhaupt zuständig ist und wer die Meldung an die Aufsichtsbehörde formal absetzen darf.
8. Dokumentationspflicht besteht auch ohne Meldung
Selbst wenn ein Verantwortlicher zu dem Schluss kommt, dass eine Verletzung kein Risiko für die betroffenen Personen darstellt und deshalb nicht gemeldet werden muss, verlangt Artikel 33 Absatz 5 DSGVO trotzdem eine interne Dokumentation jeder Datenschutzverletzung, einschließlich der Tatsachen, ihrer Auswirkungen und der ergriffenen Abhilfemaßnahmen.
Diese Dokumentation dient der Aufsichtsbehörde als Nachweis, dass die Einschätzung, keine Meldung vorzunehmen, sorgfältig und begründet erfolgt ist, nicht als bequeme Ausrede zur Vermeidung von Aufwand. Fehlt diese Dokumentation, kann die Aufsichtsbehörde bei einer späteren Prüfung nicht mehr nachvollziehen, ob die Entscheidung gegen eine Meldung tatsächlich sachlich gerechtfertigt war.
9. Bußgeldrisiko bei verspäteter oder unterlassener Meldung
Ein Verstoß gegen die Meldepflicht selbst, unabhängig vom eigentlichen Sicherheitsvorfall, kann nach Artikel 83 Absatz 4 DSGVO mit einem Bußgeld von bis zu zehn Millionen Euro oder zwei Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist. Aufsichtsbehörden bewerten dabei nicht nur, ob überhaupt gemeldet wurde, sondern auch, ob die Meldung fristgerecht und inhaltlich angemessen war.
In der Praxis wirkt sich eine erkennbar sorgfältige, fristgerechte Meldung mit nachvollziehbarer Dokumentation der getroffenen Gegenmaßnahmen bußgeldmindernd aus, selbst wenn der zugrunde liegende Vorfall selbst schwerwiegend war. Ein Unternehmen, das den Meldeprozess vorher durchdacht und geübt hat, steht bei der Bewertung durch die Aufsichtsbehörde in aller Regel deutlich besser da als eines, das erst im Ernstfall improvisiert.
| Phase | Frist | Verantwortlich | Ergebnis |
|---|---|---|---|
| Kenntniserlangung | Startpunkt der Frist | IT-Sicherheit / Monitoring | Verdacht auf Datenschutzverletzung bestätigt |
| Interne Eskalation | innerhalb weniger Stunden | Datenschutzbeauftragter, Geschäftsführung | Entscheidung über Meldepflicht |
| Meldung an Aufsichtsbehörde | binnen 72 Stunden | Datenschutzbeauftragter | formale Meldung nach Art. 33 DSGVO |
| Betroffenenbenachrichtigung | unverzüglich bei hohem Risiko | Datenschutzbeauftragter, Kommunikation | direkte Information nach Art. 34 DSGVO |
| Interne Dokumentation | laufend, auch ohne Meldung | Datenschutzbeauftragter | Nachweis nach Art. 33 Abs. 5 DSGVO |
Mironsoft
Security-Audits, OWASP-konforme Härtung und sichere Architektur
Anwendungen, die einem echten Angriffsversuch tatsächlich standhalten?
Wir prüfen bestehende Anwendungen auf klassische OWASP-Schwachstellen, unsichere Authentifizierung und fehlende Input-Validierung und bauen daraus eine Architektur, die Angriffsflächen strukturell reduziert statt nur einzelne Symptome zu flicken.
Security-Audit
OWASP Top 10, Auth-Flows und Input-Validierung systematisch auf Schwachstellen prüfen.
Sichere Architektur
Rate-Limiting, Verschlüsselung und Zugriffskontrollen von Grund auf richtig aufbauen.
Incident-Vorbereitung
Logging, Monitoring und Reaktionsprozesse für den Ernstfall etablieren.
10. Zusammenfassung
DSGVO-Meldeprozess: Das Wichtigste auf einen Blick
Fristbeginn
Die 72-Stunden-Frist startet mit hinreichender Kenntnis, nicht erst nach vollständiger Aufklärung.
Technische Basis
Aussagekräftige Zugriffslogs ermöglichen erst eine schnelle, präzise Umfangsbestimmung.
Zusätzliche Pflicht
Bei hohem Risiko müssen Betroffene zusätzlich direkt nach Art. 34 DSGVO informiert werden.
Bußgeldrisiko
Nicht nur der Vorfall selbst, auch eine verspätete Meldung wird eigenständig sanktioniert.