¶ Datenschutzverletzung-Vorlage
Kein öffentliches Vorfallformular: Diese Seite beschreibt nur die Struktur. Reale Vorfälle, Personen, Systeme, Behördenreferenzen und forensische Nachweise werden ausschließlich in einer geschützten Fallakte geführt.
Aussagegrenze: Eine ausgefüllte Vorlage belegt für sich allein weder eine vollständige Bewertung noch eine erforderliche Meldung, deren Rechtzeitigkeit oder die Wirksamkeit von Abhilfemaßnahmen.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | DSGVO-VOR-09-05 |
| Dokumentenart | Strukturmodell für Datenschutzverletzungen |
| Wiki.js-Pfad | /DSGVO/09-Vorlagen-und-Archiv/Datenschutzverletzung-Vorlage |
| Status | Entwurf – kein realer Vorfall oder Meldevorgang enthalten |
| Version / Stand | 1.0 / 09.08.2026 |
| Schutzklasse | Öffentliches Feldmodell; reale Fallakte streng vertraulich |
| DSGVO-Bezug | Artikel 5 Absatz 2, 24, 33 und 34 DSGVO |
Datenschutzverletzungen zeitnah, entscheidungsfest und geschützt dokumentieren. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Feldgruppen
Incident-ID · Zeitpunkt des Ereignisses · Entdeckung · Kenntnis · Informationsquelle · Sachverhalt · Systeme und Dienste · Datenarten · betroffene Personen und Anzahl · Verletzung von Vertraulichkeit, Integrität oder Verfügbarkeit · Eindämmung · mögliche Folgen · Wahrscheinlichkeit und Schwere · Risikostufe · Artikel-33-Entscheidung mit Begründung · 72-Stunden-Zeitlinie · Nachmeldungen · Artikel-34-Hochrisikoentscheidung mit Begründung · Behörden- und Betroffenenkommunikation · Abhilfemaßnahmen · Wirksamkeitsprüfung · Lessons Learned · Abschlussfreigabe
¶ 1.1 Warum eine Zeitlinie unverzichtbar ist
Die Fallakte trennt mindestens vier Zeitpunkte: das Ereignis, seine Entdeckung, die organisationsseitige Kenntnis und die jeweilige Entscheidung. Diese Zeitpunkte können auseinanderliegen. Nur eine fortgeschriebene Zeitlinie zeigt, wann belastbare Informationen vorlagen, welche Maßnahmen unverzüglich eingeleitet wurden und ob eine Meldung schrittweise ergänzt werden musste.
| Zeitstempel | Beispielhafte Angabe | Bedeutung |
|---|---|---|
| Ereignis | Datei am Montag falsch versandt | technischer oder organisatorischer Beginn |
| Entdeckung | Empfänger meldet den Fehler am Dienstag | erstes Signal |
| Kenntnis | zuständige Organisation kann Verletzung mit hinreichender Sicherheit feststellen | Ausgangspunkt der Fristprüfung |
| Eindämmung | Link gesperrt, Empfänger kontaktiert | unmittelbare Schadensbegrenzung |
| Entscheidung | Meldung ja/nein, Benachrichtigung ja/nein | begründete rechtliche und fachliche Bewertung |
| Abschluss | Maßnahmen geprüft und offene Punkte erledigt | kontrolliertes Fallende |
¶ 2. Sofortbearbeitung und Mindestdatensatz
In den ersten Minuten zählt eine arbeitsfähige Fallstruktur mehr als eine perfekte Beschreibung. Der Mindestdatensatz umfasst Fall-ID, Meldekanal, Zeitpunkt, erreichbare Kontaktperson, vermutete Systeme, erste Eindämmung und verantwortliche Koordination. Unbekannte Werte werden ausdrücklich als „noch zu klären“ markiert; sie bleiben nicht leer.
Danach werden Fakten von Annahmen getrennt. Aussagen wie „vermutlich nur zehn Personen“ erhalten Quelle, Zeitpunkt und Prüfauftrag. Jede neue Erkenntnis ergänzt die bestehende Zeitlinie, ohne frühere Einschätzungen zu überschreiben.
¶ Praxisbeispiel: falsch adressierter Export
Eine Beschäftigte versendet einen Kundendatenexport an eine falsche externe Adresse. Die Vorlage führt durch folgende Fragen:
- Welche Daten und wie viele Personen sind tatsächlich betroffen?
- Konnte der Empfänger die Datei öffnen, weiterleiten oder speichern?
- War die Datei verschlüsselt und war der Schlüssel getrennt übermittelt?
- Hat der Empfänger glaubhaft gelöscht und dies bestätigt?
- Welche möglichen Folgen entstehen den betroffenen Personen?
- Welche Faktoren mindern oder erhöhen Wahrscheinlichkeit und Schwere?
- Ist eine Meldung nach Artikel 33 erforderlich?
- Besteht ein voraussichtlich hohes Risiko und damit eine Prüfung nach Artikel 34?
- Welche technische oder organisatorische Ursache wird dauerhaft behandelt?
¶ 3. Entscheidungs- und Qualitätsregeln
- Der Zeitpunkt der Kenntnis und die zugrunde liegenden Tatsachen werden nachvollziehbar festgehalten.
- Unvollständige Informationen werden gekennzeichnet und fortlaufend ergänzt; Unsicherheit ist kein Grund, die Friststeuerung auszusetzen.
- Die Entscheidungen nach Artikel 33 und Artikel 34 werden getrennt, mit Kriterien, Rolle, Zeitpunkt und Begründung dokumentiert.
- Eine verspätete Meldung enthält eine dokumentierte Begründung; Nachmeldungen bleiben mit der Erstmeldung verknüpft.
- Maßnahmen erhalten Owner, Frist, Status und Wirksamkeitskriterium.
- Kommunikation, Belege und technische Details werden bedarfsgerecht geschützt und nicht im öffentlichen Wiki gespeichert.
¶ Getrennte Entscheidungsvermerke
Die Dokumentation enthält mindestens zwei eigenständige Vermerke:
- Artikel 33: Liegt voraussichtlich ein Risiko für Rechte und Freiheiten vor, das eine Meldung an die zuständige Aufsichtsbehörde erforderlich macht?
- Artikel 34: Liegt voraussichtlich ein hohes Risiko vor, das eine Benachrichtigung betroffener Personen erfordert, oder greift eine dokumentierte Ausnahme?
Beide Vermerke benennen Kriterien, Informationsstand, verantwortliche Rolle, Zeitpunkt, Ergebnis und Begründung. „Keine Meldung“ ist ebenfalls eine nachweispflichtige Entscheidung und darf nicht nur als fehlender Vorgang erscheinen.
¶ 4. Qualitätsgate vor Abschluss
- Sind Kenntniszeitpunkt und 72-Stunden-Zeitpunkt nachvollziehbar?
- Stimmen Vorfallbeschreibung, Risikobewertung und Meldetexte überein?
- Sind alle Nachmeldungen und Rückfragen der Aufsicht verknüpft?
- Wurden betroffene Personen in klarer Sprache und über einen geeigneten Kanal informiert, sofern erforderlich?
- Haben Eindämmung, Wiederherstellung und Ursachenbehandlung jeweils Owner und Status?
- Wurde die Wirksamkeit der dauerhaft vorgesehenen Maßnahmen tatsächlich geprüft?
- Sind VVT, DSFA, TOM, Verträge und Schulungen bei Bedarf aktualisiert?
- Ist die Fallakte vollständig, geschützt und für eine spätere Prüfung auffindbar?
¶ 5. Schutz der Vorfallakte
Forensische Protokolle, Sicherheitslücken, Konten, Kommunikationsdaten und Identitäten können selbst ein erhebliches Risiko darstellen. Die öffentliche Wiki-Seite enthält deshalb ausschließlich das Strukturmodell. Originale liegen in einer zugriffsbeschränkten Vorfallakte; das öffentliche Register führt höchstens freigegebene Metadaten und Referenzen.
Zugriffe und Exporte werden minimiert. Beweise werden gegen unbeabsichtigte Veränderung geschützt. Besonders sensible technische Details werden nur den Rollen bereitgestellt, die sie zur Eindämmung, Bewertung oder Nachweisführung benötigen.
¶ 6. Typische Fehlentscheidungen
| Fehlannahme | Warum sie nicht trägt |
|---|---|
| „Gelöschte E-Mail bedeutet kein Vorfall“ | Kopien, Weiterleitungen oder Kenntnisnahme können nicht ausgeschlossen sein |
| „Wenige Personen bedeuten kein Risiko“ | Art der Daten und mögliche Folgen können schwerer wiegen als die Anzahl |
| „72 Stunden beginnen erst bei vollständiger Ursachenanalyse“ | Friststeuerung und Nachmeldung sind von der vollständigen Analyse zu trennen |
| „Meldung an die Behörde ersetzt Information der Personen“ | Artikel 33 und Artikel 34 verfolgen unterschiedliche Zwecke |
| „Maßnahme umgesetzt, Fall geschlossen“ | Wirkung und systemische Folgemaßnahmen müssen überprüft werden |
¶ 7. Verknüpfte Seiten
- Meldeweg für Datenschutzverletzungen
- Bewertung von Datenschutzverletzungen
- Meldung an die Aufsichtsbehörde
- Benachrichtigung betroffener Personen
- Datenschutzverletzungsregister
- Dokumentenvorlagen
¶ 8. Offizielle Grundlagen
- DSGVO – EUR-Lex
- EDSA-Leitlinien 9/2022 zur Meldung von Datenschutzverletzungen
- Bundesdatenschutzgesetz – geltende Fassung
¶ 9. Weiterführende Informationen von SMCT MANAGEMENT
Geschützte Vorfalldokumentation, Fristensteuerung und Nachweisführung
¶ 10. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 1.0 | 09.08.2026 | Zeitlinie, Sofortbearbeitung, Praxisfall, Entscheidungsvermerke und Abschlussgate ergänzt | Ausstehend |
| 0.1 | 08.08.2026 | Öffentliches Strukturmodell für Datenschutzverletzungen erstellt | Ausstehend |