DSGVO-Datenpanne melden: Wann, wie und an wen

Datenpanne - und jetzt?

Ein Mitarbeiter verschickt eine Excel-Liste mit Kundendaten an den falschen Empfänger. Ein Laptop mit unverschlüsselter Festplatte wird aus dem Auto gestohlen. Ein Hacker erbeutet bei einem Ransomware-Angriff Zugriff auf die Personaldatenbank. Drei völlig unterschiedliche Szenarien, aber alle drei haben eines gemeinsam: Es liegt eine Verletzung des Schutzes personenbezogener Daten vor, umgangssprachlich eine Datenpanne.

Die DSGVO regelt in den Artikeln 33 und 34 sehr genau, was in einem solchen Fall zu tun ist. Die Anforderungen sind klar, die Fristen kurz und die Konsequenzen bei Verstößen empfindlich. Trotzdem herrscht in vielen Unternehmen Unsicherheit: Muss ich das melden? Wem muss ich es melden? Und was passiert, wenn ich es nicht tue?

Dieser Artikel beantwortet diese Fragen systematisch und praxisnah. Er richtet sich an ISBs, IT-Leiter und Geschäftsführer, die im Ernstfall schnell und richtig handeln müssen.

Was ist eine Datenpanne im Sinne der DSGVO?

Artikel 4 Nr. 12 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 oder zum unbefugten Zugang zu personenbezogenen Daten führt, die übermittelt, gespeichert oder auf sonstige Weise verarbeitet wurden.

Das klingt juristisch, ist aber im Kern einfach: Immer wenn personenbezogene Daten in einer Weise betroffen sind, die nicht vorgesehen war, handelt es sich um eine Datenpanne. Die DSGVO unterscheidet dabei drei Kategorien:

Vertraulichkeitsverletzung (Confidentiality Breach)

Unbefugte Personen erhalten Zugang zu personenbezogenen Daten. Das ist die häufigste Form und umfasst:

• Hackerangriffe mit Datenabfluss
• Versehentlicher Versand von Daten an falsche Empfänger
• Offene Zugriffe durch fehlerhafte Berechtigungen
• Datenträger, die in falsche Hände geraten (USB-Sticks, Laptops, Papierakten)
• Mitarbeiter, die auf Daten zugreifen, für die sie nicht autorisiert sind

Integritätsverletzung (Integrity Breach)

Personenbezogene Daten werden unbefugt verändert. Beispiele:

• Manipulation von Kundendaten durch einen Angreifer
• Fehlerhafte Datenmigration, bei der Datensätze vertauscht oder verändert werden
• Ransomware, die Daten verschlüsselt (die Daten werden dadurch verändert)

Verfügbarkeitsverletzung (Availability Breach)

Der Zugang zu personenbezogenen Daten geht verloren, temporär oder dauerhaft:

• Ransomware-Angriff, der Systeme mit personenbezogenen Daten verschlüsselt
• Serverausfall ohne funktionierendes Backup
• Versehentliches Löschen einer Datenbank
• Brand oder Wasserschaden im Serverraum

Ein wichtiger Punkt, der oft übersehen wird: Auch ein vorübergehender Verlust der Verfügbarkeit kann eine meldepflichtige Datenpanne sein. Wenn ein Krankenhaus durch einen Ransomware-Angriff keinen Zugriff mehr auf Patientendaten hat, ist das eine Datenpanne, selbst wenn die Daten nach drei Tagen wiederhergestellt werden. Denn in diesen drei Tagen konnten Patienten möglicherweise nicht angemessen behandelt werden.

Wann ist eine Datenpanne meldepflichtig?

Nicht jede Datenpanne muss der Aufsichtsbehörde gemeldet werden. Artikel 33 DSGVO formuliert die Schwelle so: Eine Meldung ist erforderlich, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen.

Das bedeutet im Umkehrschluss: Im Regelfall ist eine Datenpanne meldepflichtig. Die Nichtmeldung ist die Ausnahme und muss begründet werden können.

Wann besteht kein Risiko?

Die Europäische Datenschutzgruppe (heute EDSA) hat in ihren Leitlinien Szenarien beschrieben, in denen typischerweise kein Risiko besteht:

Verschlüsselte Daten ohne Schlüsselkompromittierung. Wenn ein Laptop gestohlen wird, dessen Festplatte mit einer starken Verschlüsselung geschützt war und der Verschlüsselungsschlüssel nicht kompromittiert wurde, ist das Risiko für die Betroffenen gering. Die Daten sind zwar physisch in fremden Händen, aber praktisch unzugänglich.

Sofortige und vollständige Schadensbegrenzung. Wenn eine E-Mail mit personenbezogenen Daten an den falschen Empfänger geht, dieser Empfänger die E-Mail nachweislich löscht und du sicher sein kannst, dass er die Daten nicht gelesen oder kopiert hat, kann das Risiko als gering eingestuft werden. In der Praxis ist diese Sicherheit allerdings schwer zu erreichen.

Bereits öffentliche Daten. Wenn die betroffenen Daten ohnehin öffentlich zugänglich sind (etwa Geschäftsadressen, die auf der Website stehen), ist das Risiko durch eine Offenlegung geringer als bei vertraulichen Daten.

Wann besteht ein Risiko?

In der Praxis ist die Frage selten, ob ein Risiko besteht, sondern eher, wie hoch es ist. Ein Risiko besteht insbesondere bei:

• Identitätsdiebstahl: Wenn Name, Adresse, Geburtsdatum und Ausweisnummer betroffen sind
• Finanziellem Schaden: Wenn Bankdaten, Kreditkarteninformationen oder Gehaltsdaten offengelegt wurden
• Diskriminierung: Wenn Daten über Gesundheit, Religion, Ethnie oder politische Überzeugung betroffen sind
• Reputationsschaden: Wenn vertrauliche Kommunikation oder kompromittierende Informationen offengelegt wurden
• Physischer Gefährdung: Wenn Standortdaten oder Adressen von schutzbedürftigen Personen betroffen sind

Praxisbeispiele: meldepflichtig oder nicht?

Der letzte Punkt überrascht viele: Der CC/BCC-Fehler beim Newsletter ist eine klassische Datenpanne, die regelmäßig Bußgelder nach sich zieht. E-Mail-Adressen sind personenbezogene Daten, und ihre Offenlegung gegenüber Dritten ist eine Vertraulichkeitsverletzung.

Die 72-Stunden-Frist: Was genau bedeutet das?

Artikel 33 Abs. 1 DSGVO schreibt vor, dass die Meldung unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden der Verletzung erfolgen muss.

Ab wann läuft die Frist?

Die Frist beginnt nicht mit dem Zeitpunkt des Vorfalls, sondern mit dem Zeitpunkt, an dem du Kenntnis davon erlangst. Wenn ein Angriff am Freitag stattfand, aber erst am Montag entdeckt wird, beginnt die 72-Stunden-Frist am Montag.

Kenntnis bedeutet dabei nicht, dass du bereits alle Details kennst. Es reicht, dass du mit hinreichender Sicherheit weißt, dass eine Datenpanne stattgefunden hat. Die Frist beginnt also nicht erst, wenn die forensische Analyse abgeschlossen ist, sondern bereits wenn du den begründeten Verdacht hast.

Ein konkretes Beispiel: Am Dienstagmorgen um 9:00 Uhr meldet dein SIEM-System einen verdächtigen Datenabfluss. Um 10:30 Uhr bestätigt die erste Analyse, dass tatsächlich personenbezogene Daten betroffen sind. Die 72-Stunden-Frist beginnt um 10:30 Uhr und endet am Freitag um 10:30 Uhr.

Was wenn 72 Stunden nicht reichen?

Die DSGVO sieht vor, dass die Meldung auch nach 72 Stunden noch ergänzt werden kann. Artikel 33 Abs. 4 erlaubt eine schrittweise Meldung, wenn nicht alle Informationen gleichzeitig vorliegen. Du meldest zunächst, was du weißt, und reichst weitere Details nach, sobald sie verfügbar sind.

Das ist kein Freibrief, die Meldung zu verzögern. Die erste Meldung muss innerhalb von 72 Stunden rausgehen, auch wenn sie unvollständig ist. Eine verspätete, aber vollständige Meldung ist schlechter als eine rechtzeitige, aber unvollständige Meldung.

Wenn du die 72-Stunden-Frist überschreitest, musst du das begründen. Artikel 33 Abs. 1 Satz 2 verlangt, dass bei verspäteter Meldung eine Begründung für die Verzögerung beigefügt wird. "Wir haben es nicht bemerkt" ist keine akzeptable Begründung, wenn du ein angemessenes Monitoring hättest haben müssen.

Wochenenden und Feiertage

Die 72 Stunden laufen ununterbrochen, Wochenenden und Feiertage sind eingerechnet. Wenn du die Datenpanne am Freitagabend um 18:00 Uhr entdeckst, endet die Frist am Montagabend um 18:00 Uhr. Die Aufsichtsbehörden haben für genau diesen Fall Online-Meldeformulare, die rund um die Uhr zugänglich sind.

Das hat praktische Konsequenzen für deine Organisation: Es muss jemanden geben, der auch am Wochenende erreichbar ist und die Befugnis hat, eine Meldung abzusetzen. Wenn dein Datenschutzbeauftragter im Urlaub ist und niemand die Vertretung hat, ist das ein organisatorisches Versäumnis, das die Aufsichtsbehörde kritisch sehen wird.

Inhalt der Meldung an die Aufsichtsbehörde

Artikel 33 Abs. 3 DSGVO definiert, welche Informationen die Meldung enthalten muss. Die meisten Aufsichtsbehörden stellen Online-Formulare bereit, die diese Punkte abfragen. Trotzdem solltest du wissen, was gefordert wird, damit du die Informationen im Ernstfall schnell zusammentragen kannst.

Pflichtangaben der Meldung

1. Beschreibung der Art der Verletzung Was ist passiert? Vertraulichkeits-, Integritäts- oder Verfügbarkeitsverletzung? Wann wurde der Vorfall entdeckt? Wann hat er vermutlich stattgefunden?

2. Kategorien und ungefähre Anzahl der betroffenen Personen Welche Personengruppen sind betroffen (Kunden, Mitarbeiter, Bewerber, Patienten)? Wie viele Personen sind betroffen oder potenziell betroffen? Eine genaue Zahl ist nicht nötig, eine fundierte Schätzung reicht.

3. Kategorien und ungefähre Anzahl der betroffenen Datensätze Welche Datenarten sind betroffen (Name, Adresse, E-Mail, Gesundheitsdaten, Finanzdaten)? Wie viele Datensätze sind betroffen?

4. Name und Kontaktdaten des Datenschutzbeauftragten Oder einer anderen Kontaktstelle, die weitere Informationen liefern kann.

5. Beschreibung der wahrscheinlichen Folgen Welche Konsequenzen hat die Datenpanne voraussichtlich für die Betroffenen? Risiko von Identitätsdiebstahl, finanziellem Schaden, Rufschädigung?

6. Beschreibung der ergriffenen oder vorgeschlagenen Maßnahmen Was wurde bereits unternommen, um die Datenpanne einzudämmen und ihre Auswirkungen zu minimieren? Welche weiteren Maßnahmen sind geplant?

So meldest du in der Praxis

Die Meldung erfolgt in der Regel über das Online-Portal der zuständigen Landesaufsichtsbehörde. Welche Behörde zuständig ist, richtet sich nach dem Sitz deines Unternehmens:

Die meisten Behörden haben ihre Meldeformulare inzwischen standardisiert und bieten eine Schritt-für-Schritt-Führung durch die erforderlichen Angaben. Du brauchst kein juristisches Gutachten, um eine Meldung abzusetzen. Das Formular ausfüllen, absenden, fertig. Besser eine schnelle, ehrliche Meldung mit Lücken als eine perfekte Meldung nach Ablauf der Frist.

Wann musst du die Betroffenen benachrichtigen?

Neben der Meldung an die Aufsichtsbehörde (Artikel 33) gibt es eine zweite Pflicht: die Benachrichtigung der betroffenen Personen nach Artikel 34 DSGVO. Diese Pflicht greift, wenn die Datenpanne voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat.

Hohes Risiko vs. Risiko

Die Schwelle für die Benachrichtigung der Betroffenen liegt höher als die für die Meldung an die Aufsichtsbehörde:

Ein hohes Risiko liegt typischerweise vor bei:

• Offenlegung von Gesundheitsdaten oder Daten über strafrechtliche Verurteilungen
• Kombination von Daten, die Identitätsdiebstahl ermöglichen (Name + Geburtsdatum + Ausweisnummer)
• Offenlegung von Finanzdaten, die zu unmittelbarem finanziellen Schaden führen können
• Daten von besonders schutzbedürftigen Personen (Kinder, Patienten, Asylbewerber)
• Große Anzahl betroffener Personen in Kombination mit sensiblen Daten

Ausnahmen von der Benachrichtigungspflicht

Artikel 34 Abs. 3 DSGVO sieht drei Ausnahmen vor, bei denen die Benachrichtigung trotz hohem Risiko entfallen kann:

Verschlüsselung oder ähnliche Schutzmaßnahmen. Wenn die Daten durch technische Maßnahmen geschützt waren, die sie für unbefugte Personen unzugänglich machen (etwa starke Verschlüsselung), muss nicht benachrichtigt werden.

Nachträgliche Maßnahmen, die das hohe Risiko beseitigen. Wenn du nach der Datenpanne Maßnahmen ergriffen hast, die sicherstellen, dass das hohe Risiko für die Betroffenen aller Wahrscheinlichkeit nach nicht mehr besteht, kann die Benachrichtigung entfallen. Das ist allerdings ein hoher Standard. "Wir haben das Passwort geändert" reicht nicht, wenn die Daten bereits kopiert wurden.

Unverhältnismäßiger Aufwand. Wenn die individuelle Benachrichtigung einen unverhältnismäßigen Aufwand erfordern würde, kann stattdessen eine öffentliche Bekanntmachung erfolgen. Das betrifft etwa Fälle, in denen Millionen von Personen betroffen sind und keine aktuellen Kontaktdaten vorliegen.

Inhalt der Benachrichtigung

Die Benachrichtigung muss in klarer und einfacher Sprache formuliert sein. Juristische Fachsprache oder verschleiernde Formulierungen sind fehl am Platz. Betroffene müssen verstehen, was passiert ist und was sie tun können.

Die Benachrichtigung muss enthalten:

• Beschreibung der Datenpanne in verständlicher Sprache
• Name und Kontaktdaten des Datenschutzbeauftragten
• Beschreibung der wahrscheinlichen Folgen
• Beschreibung der ergriffenen Gegenmaßnahmen
• Konkrete Empfehlungen, was die Betroffenen selbst tun können (Passwörter ändern, Kontobewegungen überwachen, Ausweisdokumente sperren lassen)

Praxisbeispiel: Benachrichtigungsschreiben

Ein realistisches Benachrichtigungsschreiben nach einem Datenbankeinbruch mit Kundendaten könnte in der Struktur so aussehen:

Betreff: Wichtige Sicherheitsinformation zu deinem Kundenkonto

Inhalt:

• Was ist passiert (am [Datum] haben wir einen unbefugten Zugriff auf unsere Kundendatenbank festgestellt)
• Welche Daten sind betroffen (Name, E-Mail-Adresse, Bestellhistorie; keine Zahlungsdaten)
• Was wir getan haben (Zugang gesperrt, Schwachstelle behoben, Behörde informiert, forensische Untersuchung eingeleitet)
• Was du tun solltest (Passwort ändern falls anderweitig verwendet, aufmerksam bei verdächtigen E-Mails sein)
• Wo du weitere Informationen bekommst (Kontaktdaten des Datenschutzbeauftragten, FAQ-Seite)

Der Ton ist ehrlich und sachlich, nicht beschönigend und nicht panikmachend. Betroffene verdienen Transparenz und konkrete Handlungsempfehlungen, keine PR-Floskeln.

Dokumentationspflicht: auch ohne Meldung

Artikel 33 Abs. 5 DSGVO enthält eine Pflicht, die in der Praxis oft übersehen wird: Jede Verletzung des Schutzes personenbezogener Daten muss dokumentiert werden - unabhängig davon, ob sie meldepflichtig ist oder nicht.

Diese Dokumentation muss die mit der Verletzung zusammenhängenden Fakten, ihre Auswirkungen und die ergriffenen Abhilfemaßnahmen umfassen. Die Aufsichtsbehörde muss anhand dieser Dokumentation überprüfen können, ob du die Meldepflicht korrekt eingehalten hast.

Was dokumentiert werden muss

Für jeden Vorfall, ob meldepflichtig oder nicht, solltest du folgende Informationen festhalten:

Die Begründung bei der Entscheidung gegen eine Meldung ist besonders wichtig. Wenn die Aufsichtsbehörde nachträglich prüft und du keine dokumentierte Risikobewertung vorlegen kannst, wird sie davon ausgehen, dass du die Meldepflicht verletzt hast. Eine saubere Dokumentation mit nachvollziehbarer Begründung schützt dich, auch wenn die Einschätzung im Nachhinein anders bewertet wird.

Das Verzeichnis der Datenpannen

Praktisch bewährt sich ein zentrales Verzeichnis aller Datenpannen, ähnlich dem Verzeichnis der Verarbeitungstätigkeiten. Dieses Verzeichnis kann als einfache Tabelle geführt werden oder als strukturierte Datenbank in deinem ISMS-Tool. ISMS Lite führt dieses Verzeichnis automatisch mit und verknüpft jede Datenpanne mit den zugehörigen Maßnahmen und Meldungen. Das Tool kostet ab 500 Euro pro Jahr oder als Einmalkauf für 2.500 Euro, ohne Seat-Lizenzen oder versteckte Kosten. Entscheidend ist, dass es vollständig, aktuell und für die Aufsichtsbehörde zugänglich ist.

Führe dieses Verzeichnis von Anfang an, nicht erst wenn die Aufsichtsbehörde anklopft. Der Aufwand ist gering, der Nutzen im Prüfungsfall enorm.

Konsequenzen bei Verstößen

Die DSGVO sieht für Verstöße gegen die Meldepflicht empfindliche Bußgelder vor. Artikel 83 Abs. 4 lit. a erlaubt Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes bei Verstößen gegen die Meldepflichten der Artikel 33 und 34.

In der Praxis sind die Bußgelder in Deutschland bisher moderater, aber keineswegs trivial:

Neben den direkten Bußgeldern drohen weitere Konsequenzen:

Anordnungen der Aufsichtsbehörde. Die Behörde kann konkrete Maßnahmen anordnen, etwa die nachträgliche Benachrichtigung der Betroffenen oder Verbesserungen an den technischen Schutzmaßnahmen.

Schadensersatzansprüche. Betroffene können nach Artikel 82 DSGVO Schadensersatz geltend machen, auch für immaterielle Schäden. Robuste technische und organisatorische Maßnahmen (TOMs) mindern sowohl die Eintrittswahrscheinlichkeit als auch die Folgen einer Datenpanne. Die Rechtsprechung zu Schadensersatzansprüchen bei Datenpannen hat sich in den letzten Jahren zunehmend zugunsten der Betroffenen entwickelt.

Reputationsschaden. Datenpannen werden öffentlich bekannt, sei es durch die Betroffenenbenachrichtigung, durch Medienberichterstattung oder durch die Veröffentlichungspraxis mancher Aufsichtsbehörden. Der Vertrauensverlust bei Kunden und Partnern kann schwerer wiegen als das Bußgeld.

Der Zusammenhang mit NIS2

Wenn dein Unternehmen unter NIS2 fällt, hast du bei einem Sicherheitsvorfall mit personenbezogenen Daten eine doppelte Meldepflicht:

Die NIS2-Meldefrist für die Erstmeldung ist kürzer (24 statt 72 Stunden), hat aber einen anderen Fokus: Sie betrifft die Betriebsstörung und die IT-Sicherheit, nicht spezifisch den Datenschutz. Die DSGVO-Meldung fokussiert auf die personenbezogenen Daten und die Risiken für die Betroffenen.

In der Praxis bedeutet das: Bei einem Ransomware-Angriff, der sowohl den Betrieb stört als auch personenbezogene Daten betrifft, meldest du innerhalb von 24 Stunden ans BSI (NIS2) und innerhalb von 72 Stunden an die Datenschutz-Aufsichtsbehörde (DSGVO). Das sind zwei separate Meldungen an zwei verschiedene Behörden mit unterschiedlichem Inhalt.

Bereite dich auf dieses Szenario vor. Wenn du im Ernstfall erst nachschlagen musst, welche Behörde welches Formular hat und welche Fristen gelten, verlierst du wertvolle Stunden. Lege die Kontaktdaten, Meldeportale und Zugangsdaten bereit, bevor du sie brauchst.

Praxisbeispiele: Drei Szenarien im Detail

Szenario 1: Der verlorene USB-Stick

Was passiert ist: Ein Außendienstmitarbeiter verliert einen USB-Stick mit einer Excel-Liste von 340 Kundenkontakten (Name, Firma, E-Mail, Telefonnummer, Angebotssummen).

Risikobewertung: Der USB-Stick ist nicht verschlüsselt. Die Daten umfassen geschäftliche Kontaktdaten und Angebotsinformationen. Ein Finder könnte die Daten lesen und für Phishing oder Wettbewerbsspionage nutzen. Risiko für die Betroffenen: vorhanden, aber kein hohes Risiko (keine besonders sensiblen Datenkategorien, keine Bankdaten).

Ergebnis: Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden: ja. Benachrichtigung der Betroffenen: nein, da kein hohes Risiko. Dokumentation: vollständig, inklusive Begründung für die Nichtbenachrichtigung. Sofortmaßnahme: Verschlüsselungspflicht für alle USB-Sticks einführen.

Szenario 2: Ransomware mit Datenexfiltration

Was passiert ist: Ransomware verschlüsselt die Server des Unternehmens, darunter die Personaldatenbank mit Daten von 85 Mitarbeitern (Name, Adresse, Sozialversicherungsnummer, Gehalt, Bankverbindung, Krankmeldungen) und die Kundendatenbank mit 12.000 Datensätzen. Die Angreifer drohen mit Veröffentlichung und haben als Beweis 50 Datensätze im Darknet gepostet.

Risikobewertung: Bestätigte Exfiltration hochsensibler Daten. Sozialversicherungsnummern und Bankverbindungen ermöglichen Identitätsdiebstahl und finanziellen Betrug. Gesundheitsdaten der Mitarbeiter (Krankmeldungen) sind besondere Kategorien nach Artikel 9. Hohes Risiko für alle Betroffenen.

Ergebnis: Meldung an die Aufsichtsbehörde: ja, sofort. Benachrichtigung der Betroffenen: ja, unverzüglich, sowohl Mitarbeiter als auch Kunden. Konkrete Empfehlungen: Bankverbindungen überwachen, bei der Schufa eine Auskunft anfordern, bei verdächtigen Kontaktaufnahmen misstrauisch sein. Falls NIS2-relevant: zusätzlich Erstmeldung ans BSI innerhalb von 24 Stunden.

Szenario 3: Die fehlgeleitete E-Mail

Was passiert ist: Eine Mitarbeiterin der Personalabteilung verschickt eine Gehaltsübersicht aller 60 Mitarbeiter einer Abteilung versehentlich an einen externen Bewerber statt an die Geschäftsführung.

Risikobewertung: Gehaltsdaten sind vertrauliche personenbezogene Daten. Die Offenlegung gegenüber einem Dritten stellt ein Risiko dar, da die Empfängerin die Daten kennt und möglicherweise weitergeben könnte. Die Mitarbeiterin kontaktiert den Bewerber sofort telefonisch. Dieser bestätigt, die E-Mail gelöscht zu haben, ohne sie zu öffnen. Das Risiko ist damit reduziert, aber nicht vollständig eliminiert, da keine technische Gewissheit besteht.

Ergebnis: Meldung an die Aufsichtsbehörde: ja, da ein Risiko nicht ausgeschlossen werden kann. Die Meldung kann darauf hinweisen, dass der Empfänger die Löschung bestätigt hat. Benachrichtigung der Betroffenen: Grenzfall. Die Aufsichtsbehörde kann bei der Entscheidung helfen, ob eine Benachrichtigung der 60 Mitarbeiter erforderlich ist. Dokumentation: vollständig, inklusive Nachweis der telefonischen Kontaktaufnahme und Löschbestätigung.

So bereitest du dich vor

Die beste Vorbereitung auf eine Datenpanne ist ein Prozess, der greift, bevor die Panik einsetzt. Fünf konkrete Maßnahmen, die du jetzt umsetzen kannst:

Erstens: Meldeprozess definieren. Wer entscheidet, ob eine Datenpanne meldepflichtig ist? Wer setzt die Meldung ab? Wer ist die Vertretung? Der Incident-Response-Plan sollte diese Fragen beantworten. Schreib den Prozess auf, mit Namen, Telefonnummern und Zugangsdaten zu den Meldeportalen.

Zweitens: Vorfallsdokumentation strukturiert anlegen. Im Ernstfall zählt ein klarer Workflow, kein leeres Blatt. ISMS Lite bietet einen strukturierten Incident-Workflow, in dem du die konkreten Fakten erfasst, Fristen automatisch überwacht werden und BSI-konforme Meldungen generiert werden können.

Drittens: Risikobewertungs-Matrix erstellen. Definiere vorab, welche Datenkategorien welches Risikoniveau haben. Kundendaten mit Bankverbindung: hohes Risiko. Geschäftliche E-Mail-Adressen: geringeres Risiko. Diese Matrix beschleunigt die Entscheidung im Ernstfall erheblich.

Viertens: Benachrichtigungsvorlagen vorbereiten. Erstelle Muster-Texte für die Betroffenenbenachrichtigung. Du wirst sie im Ernstfall anpassen müssen, aber die Grundstruktur steht dann schon. Unter Zeitdruck von null einen verständlichen, juristisch korrekten Benachrichtigungstext zu formulieren, ist eine unnötige Belastung.

Fünftens: Den Prozess üben. Spiel ein Szenario in einer Tabletop-Übung durch. Freitagabend, Datenleck entdeckt, Datenschutzbeauftragter im Urlaub. Funktioniert der Prozess? Weiß die Vertretung, was zu tun ist? Hat sie Zugang zum Meldeportal? Solche Übungen kosten zwei Stunden und ersparen im Ernstfall zwei Tage Chaos.

Weiterführende Artikel

• Sicherheitsvorfall erkennen, bewerten und melden – der komplette Ablauf
• Verarbeitungsverzeichnis (VVA) nach Art. 30 DSGVO erstellen
• Technische und organisatorische Maßnahmen (TOMs) dokumentieren
• NIS2-Meldefristen im Überblick: 24h, 72h, 1 Monat – was wann fällig ist
• Incident Response Plan erstellen: Vorlage und Praxisbeispiel

Die DSGVO-Meldepflicht ist kein bürokratisches Monster. Sie ist ein strukturierter Prozess mit klaren Regeln, der bei guter Vorbereitung reibungslos funktioniert. Der Schlüssel liegt nicht in der perfekten Meldung, sondern in der schnellen, ehrlichen und dokumentierten Reaktion.