DSGVO-Datenpanne in 72 Stunden melden: Workflow + Vorlage\n\n> Key Takeaways\n> - Die 72-Stunden-Frist beginnt mit Kenntniserlangung – nicht mit Abschluss der forensischen Analyse.\n> - Unvollständige Meldungen sind ausdrücklich zulässig; Nachlieferung ist in Art. 33 Abs. 4 DSGVO vorgesehen.\n> - Bei ausschließlich verschlüsselten Daten mit intaktem Schlüssel entfällt die Meldepflicht häufig.\n> - Das interne Melderegister nach Art. 33 Abs. 5 DSGVO ist Pflicht – auch wenn keine externe Meldung erfolgt.\n> - Auftragsverarbeiter (z. B. Microsoft 365, Azure) müssen unverzüglich an Sie melden – prüfen Sie Ihre AVV.\n\n## Die gesetzliche Grundlage: Was Art. 33 DSGVO tatsächlich verlangt\n\nDie meisten KMU-Verantwortlichen kennen die Zahl: 72 Stunden. Was dahintersteckt, ist präziser als es zunächst wirkt. Art. 33 DSGVO verpflichtet den Verantwortlichen zur Meldung an die zuständige Aufsichtsbehörde, wenn eine Verletzung des Schutzes personenbezogener Daten eintritt und voraussichtlich ein Risiko für die Rechte und Freiheiten natürlicher Personen besteht.\n\nDrei Risikoschwellen sind operativ relevant:\n\n1. Kein Risiko – Keine externe Meldepflicht, aber Dokumentationspflicht im internen Register.\n2. Risiko (nicht vernachlässigbar) – Meldung an Aufsichtsbehörde erforderlich (Art. 33 DSGVO).\n3. Hohes Risiko – Zusätzlich Benachrichtigung der betroffenen Personen (Art. 34 DSGVO).\n\nDie Risikoeinschätzung ist kein Bauchgefühl. Die Guidelines 9/2022 des Europäischen Datenschutzausschusses (EDSA) liefern eine strukturierte Methodik mit kategorisierten Beispielszenarien. Wer diese nicht kennt, trifft Fehleinschätzungen in beide Richtungen: entweder wird jeder Vorfall gemeldet (unnötige Behördenkontakte, Ressourcenverschwendung) oder systematisch zu wenig gemeldet (Bußgeldrisiko bis 10 Mio. EUR bzw. 2 % des weltweiten Jahresumsatzes).\n\n## Was zählt überhaupt als Datenschutzverletzung?\n\nEin hartnäckiges Missverständnis: Datenpanne gleich Hackerangriff. Tatsächlich umfasst Art. 4 Nr. 12 DSGVO jede Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung personenbezogener Daten führt – versehentlich oder unrechtmäßig.\n\nKonkrete Beispiele aus dem KMU-Alltag:\n\n- Eine E-Mail mit Kundenliste wird an den falschen Empfänger versendet (Vertraulichkeitsverletzung)\n- Ein Laptop geht auf Dienstreise verloren – Festplatte nicht verschlüsselt (Verfügbarkeits- und Vertraulichkeitsverletzung)\n- Ransomware verschlüsselt Buchhaltungsdaten, kein funktionsfähiges Backup vorhanden (Verfügbarkeitsverletzung)\n- Ein SharePoint-Ordner mit Personalakten wird aus Versehen öffentlich freigegeben (Microsoft-365-Konfigurationsfehler)\n- Ein Azure-AD-Konto wird kompromittiert; der Angreifer hat drei Tage lang Zugriff auf Exchange Online (Vertraulichkeits- und Integritätsverletzung)\n\nNicht meldepflichtig wäre hingegen: Ein verschlüsselter USB-Stick mit intaktem, nicht exponiertem Schlüssel geht verloren. Das Risiko für Betroffene ist in diesem Fall vernachlässigbar – die Aufsichtsbehörde muss nicht informiert werden, das interne Register jedoch schon.\n\n## Der 72-Stunden-Countdown: Wann beginnt die Uhr?\n\nHier liegt die häufigste operative Falle. Die Frist beginnt nicht, wenn Sie Gewissheit haben. Sie beginnt, wenn Sie hinreichend wahrscheinlich Kenntnis davon erlangt haben, dass ein meldepflichtiger Vorfall vorliegt.\n\nPraxisbeispiel: Am Montag um 09:00 Uhr meldet ein Mitarbeiter, er habe eine Phishing-E-Mail erhalten und den Anhang geöffnet. Um 10:30 Uhr stellt Ihr IT-Dienstleister fest, dass Daten möglicherweise abgeflossen sind. Die Frist beginnt um 10:30 Uhr – nicht wenn die forensische Analyse abgeschlossen ist.\n\nDas bedeutet: Parallelbetrieb von Incident Response und Meldungsvorbereitung ist keine Option, sondern rechtliche Pflicht.\n\n### Auftragsverarbeiter im Scope\n\nNutzen Sie Microsoft 365, Azure oder externe SaaS-Dienste? Diese sind Ihre Auftragsverarbeiter. Gemäß Art. 28 i. V. m. Art. 33 Abs. 2 DSGVO müssen sie unverzüglich – also ohne schuldhaftes Zögern, nicht innerhalb von 72 Stunden – an Sie melden, sobald sie selbst Kenntnis erlangen. Prüfen Sie Ihre Auftragsverarbeitungsverträge (AVV): Ist diese Pflicht darin klar verankert? Bei Microsoft 365 ist sie im Microsoft Data Protection Addendum (DPA) geregelt; Benachrichtigungen erfolgen über das Microsoft Service Trust Portal oder das Azure Security Center.\n\n## Schritt-für-Schritt-Workflow: Von der Erkennung zur Meldung\n\n### Phase 1: Erkennung und erste Bewertung (T+0 bis T+4h)\n\nSchritt 1: Vorfall identifizieren und Ticket mit Zeitstempel öffnen\n\nJeder potenzielle Datenschutzvorfall bekommt sofort ein Ticket. Der Zeitstempel ist Ihr Fristbeginn-Dokumentationsnachweis gegenüber der Behörde.\n\n\nVorfall-ID: INC-2026-0523\nErstmeldung: 2026-05-23 10:30 Uhr\nQuelle: Helpdesk-Ticket #4521\nMeldender: Max Mustermann, IT-Abteilung\nVorl. Beschreibung: Phishing-Angriff, möglicher Datenabfluss Exchange Online\nFristablauf: 2026-05-26 10:30 Uhr (72h)\n\n\nSchritt 2: Initiale Triage – Liegt überhaupt eine Datenschutzverletzung vor?\n\nBeantworten Sie vier Fragen:\n1. Sind personenbezogene Daten betroffen?\n2. Liegt eine Verletzung der Vertraulichkeit, Verfügbarkeit oder Integrität vor?\n3. Ist die Verletzung bereits eingetreten oder nur möglich?\n4. Wer könnte Zugriff auf die Daten erlangt haben?\n\nSchritt 3: Sofortmaßnahmen einleiten\n\nKompromittierte Konten sperren (Azure AD: Conditional Access Policy oder direkte Kontodeaktivierung), betroffene Systeme isolieren, Logs sichern. In Wazuh lassen sich DSGVO-relevante Exfiltrationsmuster mit eigenen Regeln abbilden:\n\n```xml\n\n<rule id=\