¶ Datenschutzverletzungsregister
Beispielregister: Diese Seite enthält ausschließlich Struktur und einen leeren Mustereintrag. Reale Vorfälle, Personen, Systeme, Behördenreferenzen und forensische Belege gehören in eine geschützte Ablage.
Vollständigkeit: Jede bestätigte Datenschutzverletzung wird dokumentiert – auch wenn sie nicht an die Aufsichtsbehörde gemeldet und keine betroffene Person benachrichtigt wird.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | DSGVO-REG-06-01 |
| Dokumentenart | Leeres Musterregister für Datenschutzverletzungen |
| Wiki.js-Pfad | /DSGVO/06-Datenschutzverletzungen/Datenschutzverletzungsregister |
| Verantwortlich | festzulegende Datenschutzkoordination |
| Fachlich geprüft durch | Datenschutzbeauftragte/r, sofern benannt, Incident Lead, Informationssicherheit und Recht |
| Freigabe durch | Geschäftsführung beziehungsweise dokumentierte befugte Leitung |
| Status | Entwurf – Registersystem, Rechte, Fristen und Vollständigkeitskontrollen nicht organisationsbezogen eingerichtet |
| Version | 1.0 |
| Stand | 09.08.2026 |
| Gültig ab | Nach Anpassung, Rechteprüfung und formaler Freigabe |
| Nächste Prüfung | Quartalsweise sowie nach jedem meldepflichtigen oder wesentlichen Vorfall |
| Schutzklasse | Vertraulich bis streng vertraulich; öffentliche Seite nur Methodik und leere Struktur |
| DSGVO-Bezug | Artikel 5 Absatz 2, 24 und 33 Absatz 5 DSGVO |
| Schnittstellen | Meldeweg, Bewertung, Aufsicht, Betroffene, Kontakte, TOM und Lessons Learned |
Das Register verbindet Sachverhalt, Auswirkungen, Abhilfe und alle Meldeentscheidungen zu einem überprüfbaren Verlauf. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck und Führung
Das Register ermöglicht der Aufsichtsbehörde die Prüfung der Einhaltung von Artikel 33 und unterstützt Fristensteuerung, Konsistenz, Ursachenanalyse und Verbesserung. Es wird zentral, zugriffsbeschränkt, versioniert und ausfallfähig geführt.
Ein ISMS-Incident-Ticket kann verknüpft werden, ersetzt aber nicht die datenschutzrechtlichen Felder und Entscheidungen.
¶ 2. Pflicht- und Steuerungsfelder
| Bereich | Mindestfelder |
|---|---|
| Identifikation | Incident-ID, Titel, Status, Verantwortlicher, Schutzklasse |
| Zeitlinie | Ereignis, Entdeckung, Eingang, Kenntnis, Fristbeginn, Entscheidungen, Meldungen, Abschluss |
| Sachverhalt | Verletzungsart, Ursache, Systeme, Daten, Personen, Empfänger, Dauer und Reichweite |
| Auswirkungen | konkrete Folgen, Wahrscheinlichkeit, Schwere, Unsicherheiten und Risikostufe |
| Abhilfe | Eindämmung, Wiederherstellung, Folgenminderung, Owner und Wirksamkeitsprüfung |
| Aufsicht | Zuständigkeit, Entscheidung, Erstmeldung, Nachmeldung, Referenz und Verspätungsgrund |
| Betroffene | Hochrisikoentscheidung, Ausnahme, Kanal, Versand und Rückläufer |
| Sonstige Pflichten | ISMS, NIS2, Vertrag, Versicherung, Strafverfolgung und Kommunikation – jeweils getrennt |
| Nachweise | geschützte Referenzen, Versionen und Aufbewahrung |
| Abschluss | offene Maßnahmen, Lessons Learned, Review und befugte Schließung |
¶ 3. Statusmodell
Verdacht → in Triage → Verletzung bestätigt / nicht bestätigt → in Bewertung → Meldeentscheidung → Abhilfe und Nachmeldung → Wirksamkeitsprüfung → geschlossen
Eine Schließung ist erst zulässig, wenn Pflichtentscheidungen, Nachweise, offene Maßnahmen und Reviewtermine geklärt sind.
¶ 4. Leeres Register
| Incident-ID | Eingang / Kenntnis | Art und Scope | Personen / Daten | Risiko | Aufsicht | Betroffene | Maßnahmen | Status / Owner | Nachweis / Review |
|---|---|---|---|---|---|---|---|---|---|
| – | – | – | – | – | – | – | Kein realer Eintrag im Muster-Wiki | – | – |
¶ 5. Datenschutz und Beweisschutz
- Zugriff nach Need-to-know und Funktionstrennung,
- keine unnötigen personenbezogenen Originaldaten im Register,
- forensische Belege getrennt, unverändert und nachvollziehbar sichern,
- Protokollierung von Änderungen und Exporten,
- Lösch-, Aufbewahrungs- und Legal-Hold-Regeln festlegen,
- Notfallzugriff und Wiederherstellung regelmäßig testen.
¶ 6. Qualitätskontrolle
- Sind alle bestätigten Datenschutzverletzungen erfasst?
- Sind Zeitstempel, Fristbeginn und Informationsquelle nachvollziehbar?
- Deckt der Sachverhalt Vertraulichkeit, Integrität und Verfügbarkeit ab?
- Sind Artikel-33- und Artikel-34-Entscheidung getrennt begründet?
- Stimmen Meldungsfassungen, Referenzen und Nachmeldungen überein?
- Sind Maßnahmen mit Owner, Frist und Wirksamkeit dokumentiert?
- Enthält das öffentliche Wiki keine sensiblen Originale?
¶ 7. Registerführung im Ereignisverlauf
Ein Registereintrag beginnt bereits, wenn eine Datenschutzverletzung bestätigt ist; die Meldeentscheidung kann zu diesem Zeitpunkt noch offen sein. Der Eintrag wird nicht erst nach Abschluss aus E-Mails rekonstruiert. Jede wesentliche Erkenntnis erhält Zeitstempel, Quelle und bearbeitende Rolle.
| Phase | Was wird fortgeschrieben? | Qualitätsfrage |
|---|---|---|
| Eingang und Triage | Meldung, Entdeckung, erste Fakten, Sofortmaßnahmen | Ist der ursprüngliche Informationsstand unverändert nachvollziehbar? |
| Bestätigung | Personenbezug und Verletzungsart | Wurde Vertraulichkeit, Integrität und Verfügbarkeit geprüft? |
| Bewertung | Folgen, Risiko, hohes Risiko, Unsicherheit | Sind Betroffenen- und Unternehmensrisiko getrennt? |
| Meldung | Behörde, Fassung, Zeitpunkt, Referenz, Nachmeldung | Stimmen Register und tatsächlich übermittelte Fassung überein? |
| Benachrichtigung | Zielgruppe, Inhalt, Kanal, Ausnahmen, Versand | Ist die Kommunikation verständlich und schützt sie vor weiterem Schaden? |
| Abhilfe | Eindämmung, Wiederherstellung, Schutz der Personen | Sind Maßnahmen umgesetzt und nicht nur geplant? |
| Abschluss | Ursachen, offene Maßnahmen, Wirksamkeit und Freigabe | Wurde ein realistischer Nachtest bestanden? |
¶ 7.1 Trennung von Register und Beweisablage
Das Register enthält strukturierte Metadaten und geschützte Referenzen. Original-E-Mails, forensische Images, Zugangsdaten, Ausweiskopien, vollständige Betroffenenlisten und detaillierte Schwachstellen liegen in einer geeigneten Beweis- oder Fallablage. Dadurch bleibt das Register steuerbar, ohne sensible Informationen unnötig zu vervielfältigen.
¶ 7.2 Korrektur und Versionierung
Falsche Angaben werden nicht spurlos überschrieben. Der neue Wert erhält Änderungsgrund, Zeitpunkt und Rolle; der vorherige Entscheidungsstand bleibt nachvollziehbar. Dies ist besonders wichtig für Kenntniszeitpunkt, Anzahl betroffener Personen, Risikostufe und Meldeentscheidung. Eine spätere bessere Erkenntnis macht eine frühere, auf damaligen Fakten beruhende Entscheidung nicht automatisch unvertretbar, muss aber transparent fortgeschrieben werden.
¶ 8. Konsistenz- und Vollständigkeitskontrolle
Mindestens quartalsweise werden Incident-Tickets, Datenschutzmeldungen, Security-Alarme, Supportfälle, Lieferantenmeldungen und das Register stichprobenartig abgeglichen. Ziel ist nicht nur die Zahl der Fälle, sondern das Erkennen fehlender oder verspätet erfasster Verletzungen.
Ein geschlossener Fall wird stichprobenartig rückwärts geprüft: Lässt sich aus Register, Bewertungsakte, Meldungen, Betroffenenkommunikation und Maßnahmen derselbe Ereignisverlauf rekonstruieren? Abweichende Zeitpunkte oder Zahlen werden aufgeklärt. Offene Maßnahmen verbleiben sichtbar, auch wenn die eigentliche Meldung abgeschlossen ist.
¶ 8.1 Kennzahlen
Geeignet sind Zeit von Eingang bis Triage, Zeit bis Kenntnisentscheidung, Anteil unvollständiger Einträge, verspätete Meldungen, stufenweise Nachmeldungen, überfällige Maßnahmen und bestandene Wirksamkeitstests. Eine geringe Zahl gemeldeter Verletzungen beweist kein wirksames Datenschutzmanagement; sie kann auch auf schwache Erkennung oder Meldekultur hinweisen.
¶ 9. Verknüpfte Seiten
- Meldeweg für Datenschutzverletzungen
- Bewertung von Datenschutzverletzungen
- Meldung an die Aufsichtsbehörde
- Benachrichtigung betroffener Personen
- Lessons Learned
- Datenschutzverletzung-Vorlage
- Dokumenten- und Nachweislenkung
- ISMS Incident Response
¶ 10. Offizielle Grundlagen
- DSGVO, insbesondere Artikel 33 Absatz 5 – EUR-Lex
- EDSA-Leitlinien 9/2022 – finale Version 2.0
- EDSA-Leitfaden für kleine Unternehmen: Datenschutzverletzungen
¶ 11. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung bei geschützten Registern, Fristensteuerung, Nachweisen und Wirksamkeitskontrollen
Erstgespräch unter info@smct-management.de vereinbaren
¶ 12. Änderungshistorie
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe |
|---|---|---|---|---|
| 1.0 | 09.08.2026 | Ereignisverlauf, Beweistrennung, Versionierung, Konsistenzkontrolle und Kennzahlen ergänzt | Datenschutzkoordination / Musterrolle | Ausstehend |
| 0.1 | 08.08.2026 | Leeres Musterregister mit Zeitlinie, Sachverhalt, Auswirkungen, Abhilfe, Aufsichts- und Betroffenenentscheidungen, Nachweisen und Statusmodell erstellt | Datenschutzkoordination / Musterrolle | Ausstehend |