Ein Verletzungsregister hält fest, was bei einer Verletzung des Schutzes personenbezogener Daten geschehen ist, welche Folgen möglich waren und wie der Verantwortliche reagiert hat. Artikel 33 Absatz 5 DSGVO verlangt diese Dokumentation für alle solchen Verletzungen, auch wenn keine Meldung an die Aufsichtsbehörde erforderlich ist. Ein bestimmter Name, eine Software oder ein amtliches Formular ist dafür nicht vorgeschrieben. Wer eine Vorlage übernimmt, sollte besonders den Unterschied zwischen einem Dokumentationsfeld und einer gesetzlichen Meldeschwelle prüfen. Ein intern festgelegter Eskalationswert, etwa eine erwartete Schadenshöhe, kann für die Arbeit hilfreich sein; er ersetzt nicht die rechtliche Risikoprognose für die Rechte und Freiheiten natürlicher Personen. Auch ein Fall unterhalb einer internen Schadensgrenze kann meldepflichtig sein. Umgekehrt ist eine hohe technische Ausfallzeit ohne betroffene personenbezogene Daten keine Datenschutzverletzung im Sinne dieses Artikels. Das folgende Muster bietet eine Arbeitsstruktur. Ob ein Ereignis meldepflichtig ist, müssen Sie anhand der tatsächlichen Risiken beurteilen; ein ausgefülltes Formular nimmt Ihnen diese Entscheidung nicht ab.
Wichtige Punkte
- Zuerst klären, ob ein Sicherheitsereignis überhaupt personenbezogene Daten und deren Vertraulichkeit, Integrität oder Verfügbarkeit betrifft. Nicht jeder IT-Ausfall ist eine Datenschutzverletzung.
- Jede festgestellte Verletzung mit ihren Fakten, Auswirkungen und Abhilfemaßnahmen dokumentieren. Auch eine begründete Entscheidung gegen die Behördenmeldung gehört nachvollziehbar in den Vorgang.
- Der Verantwortliche meldet der zuständigen Aufsicht unverzüglich und möglichst binnen 72 Stunden nach Kenntnis, außer die Verletzung führt voraussichtlich nicht zu einem Risiko für Rechte und Freiheiten. Bei späterer Meldung ist die Verzögerung zu begründen.
- Bei voraussichtlich hohem Risiko ist gesondert zu prüfen, ob Betroffene nach Artikel 34 informiert werden müssen. Die Behördenmeldung ersetzt diese Prüfung nicht.
- Ein Auftragsverarbeiter informiert den Verantwortlichen nach Artikel 33 Absatz 2 unverzüglich; die Entscheidung des Verantwortlichen beginnt nicht erst, wenn sein Datenschutzbeauftragter das Formular öffnet.
Was gehört in das Register und was nur ins IT-Ticket?
Ein defekter Drucker ohne Bezug zu personenbezogenen Daten ist ein IT-Vorfall, keine Datenschutzverletzung nach Artikel 4 Nummer 12 DSGVO. Wird dagegen eine Kundendatei versehentlich öffentlich zugänglich, eine Personalakte verändert oder ein Datensystem durch einen Angriff unzugänglich, kann eine Verletzung der Vertraulichkeit, Integrität oder Verfügbarkeit vorliegen. Unzugängliche Daten sind also nicht automatisch ausgenommen, nur weil niemand sie gelesen hat. Erfassen Sie auch Verdachtsmeldungen zunächst im internen Eingangskanal; kennzeichnen Sie nach Prüfung, ob sich eine personenbezogene Datenschutzverletzung bestätigt hat. So wird das Register nicht mit beliebigen Systemstörungen vermischt, ohne frühe Hinweise zu verlieren.
Die Dokumentation nach Artikel 33 Absatz 5 betrifft den Verantwortlichen. Ein Auftragsverarbeiter braucht eine zuverlässige interne Erfassung, um seinen Kunden unverzüglich informieren und vertragliche Nachweise liefern zu können. Er darf einen Vorfall im Kundensystem nicht deshalb zurückhalten, weil die Risikobewertung noch unvollständig ist. Bei gemeinsamer Verantwortlichkeit oder mehreren betroffenen Kunden muss geklärt sein, wer welche Daten, Entscheidungen und Zeitpunkte festhält. Das Verzeichnis der Verarbeitungstätigkeiten hilft, Systeme und Datenkategorien zuzuordnen, erfüllt aber nicht die Vorfalldokumentation.
Muster als Arbeitsblatt
Die Felder gehen teilweise über den Mindestwortlaut des Artikels 33 Absatz 5 hinaus. Sie helfen, Fakten, Folgen und Maßnahmen später nachvollziehbar zu verbinden. Tragen Sie Unbekanntes zunächst als ‘offen’ ein und ergänzen Sie es mit Datum und Quelle, statt Zahlen zu erfinden. Entfernen Sie unnötige personenbezogene Details aus frei zugänglichen Tickets; ein eingeschränktes, versioniertes Fallregister ist sicherer.
VORFALLAKTE – ARTIKEL 33 ABSATZ 5 DSGVO
Fallkennung: [ ]
Interner Eingang: [Datum/Uhrzeit/Quelle]
Kenntnis des Verantwortlichen: [Datum/Uhrzeit/Begründung]
Bearbeitung und Freigabe: [Rolle/Datum]
1. Sachverhalt
System/Verarbeitung: [ ]
Ereignis und Entdeckung: [ ]
Vertraulichkeit / Integrität / Verfügbarkeit: [ ]
Bestätigte Fakten / noch offene Fragen: [ ]
2. Betroffenheit und Auswirkungen
Daten- und Personengruppen; ungefähre Zahl, soweit bekannt: [ ]
Mögliche Folgen und Risikofaktoren: [ ]
Begrenzende Umstände und Nachweise: [ ]
3. Maßnahmen
Sofortige Eindämmung: [ ]
Abhilfe und Wiederherstellung: [ ]
Weitere Sicherheitsmaßnahmen: [ ]
4. Entscheidungen und Kommunikation
Aufsicht: Meldung ja/nein, Begründung, Zeitpunkt, Aktenzeichen: [ ]
Bei Meldung nach 72 Stunden: Grund der Verzögerung: [ ]
Betroffene: Benachrichtigung ja/nein, Art.-34-Begründung: [ ]
Kunden/Verantwortliche und weitere Adressaten: [ ]
Ergänzende Meldung / Abschluss / erneute Bewertung: [ ]
Das Muster ist eine redaktionelle Vorlage. Der Gesetzestext verlangt Fakten, Auswirkungen und Abhilfemaßnahmen; die weiteren Felder dienen der begründeten Entscheidung und internen Steuerung. Ein Feld ‘Schweregrad niedrig’ allein erklärt kein Risiko. Schreiben Sie, welche Daten betroffen waren, wie leicht Personen identifizierbar sind, wer Zugriff hatte und welche Nachteile tatsächlich denkbar sind. Bei unklaren Zahlen dokumentieren Sie Ihre Schätzung und deren Grundlage. Die Vorlage sollte zu Ihrem internen Verfahren für Datenpannen passen, statt ein paralleles Schattenregister zu schaffen.
Den Zeitpunkt der Kenntnis sauber bestimmen
Die Meldefrist ist kein bloßes Ziel für die interne Bearbeitung. Artikel 33 Absatz 1 verlangt eine Meldung ohne unangemessene Verzögerung und, wenn möglich, binnen 72 Stunden, nachdem der Verantwortliche von der Verletzung Kenntnis erlangt hat. Die EDSA-Leitlinien erläutern, dass hinreichende Gewissheit über eine Verletzung personenbezogener Daten entscheidend ist. Ein bloßer Alarm kann noch eine Prüfung erfordern; absichtliches Zuwarten bis zu einer vollständigen forensischen Analyse verschiebt den Beginn dagegen nicht beliebig. Halten Sie daher den ersten Hinweis, den Zeitpunkt hinreichender Gewissheit und die Gründe für die Einordnung getrennt fest.
Beispiel: Am Montag bemerkt ein Administrator ungewöhnliche Zugriffe; zunächst ist unklar, ob Testdaten betroffen sind. Am Dienstag belegt ein Log, dass ein fremdes Konto echte Kundendaten heruntergeladen hat. Notieren Sie beide Zeitpunkte und die Information, die aus dem Verdacht eine bestätigte Verletzung machte. Wenn der Verantwortliche bereits am Montag ausreichende Gewissheit hatte, darf er Dienstag nicht als Fristbeginn deklarieren. Ein Dienstleister kann zudem früher Kenntnis haben als der Verantwortliche; sein Meldeweg muss deshalb unverzüglich funktionieren. Die Anforderungen an den Auftragsverarbeiter sind Teil dieser organisatorischen Vorbereitung. Die separate Erläuterung der 72-Stunden-Meldepflicht hilft, die Meldung vom Register zu unterscheiden.
Risikoentscheidung statt Ampel ohne Begründung
Die Behördenmeldung entfällt nur, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Das ist eine begründete Prognose, keine Kategorie ‘klein’ nach Unternehmensgröße. Relevante Faktoren sind Art und Sensibilität der Daten, Zahl der Betroffenen, Identifizierbarkeit, mögliche Folgen, wer Zugriff hatte, Dauer der Exposition und wirksame Schutzmaßnahmen. Ein intern falsch adressiertes Dokument, das nachweislich ungelesen gelöscht wurde, kann anders zu beurteilen sein als eine frei abrufbare Datei. Doch ‘Empfänger um Löschung gebeten’ ist nicht dasselbe wie belegte Löschung; bewerten Sie die verbleibende Unsicherheit.
Verschlüsselung kann die Auswirkungen stark begrenzen, wenn der Schlüssel getrennt und sicher ist. Dokumentieren Sie Algorithmus oder Schutzkonzept nur so weit nötig, Zustand des Geräts, Schlüsselkontrolle und verfügbare Backups. Ein verschlüsselter Laptop mit verlorenem Schlüssel kann weiter ein Verfügbarkeitsrisiko bergen; ein Backup mindert dieses Risiko. Prüfen Sie die Umstände insgesamt. Bei verändertem Kenntnisstand wird der Eintrag aktualisiert und die Meldeentscheidung erneut geprüft. Verknüpfen Sie die Fallakte mit den Sicherheitsmaßnahmen nach Artikel 32, die aus dem Vorfall angepasst werden.
Halten Sie Behördenmeldung und Benachrichtigung Betroffener auseinander. Artikel 34 knüpft grundsätzlich an ein voraussichtlich hohes Risiko an; seine Ausnahmen und Alternativen sind eigenständig zu prüfen. Es kann eine Behördenmeldung erforderlich sein, ohne dass Betroffene direkt informiert werden müssen. Umgekehrt gehört die Artikel-34-Prüfung ausdrücklich in die Akte, damit ein bloßes ‘Aufsicht informiert’ nicht als abschließende Kommunikationsentscheidung erscheint. Für den Wortlaut einer Behördenmeldung ist das Meldungsmuster der passendere Ausgangspunkt als dieses interne Register.
Arbeiten mit unvollständigen Informationen
Die ersten Stunden nach einer Verletzung liefern selten eine vollständige Zahl betroffener Datensätze. Artikel 33 Absatz 4 erlaubt, Informationen schrittweise und ohne unangemessene weitere Verzögerung nachzureichen, wenn sie nicht zugleich mit der Meldung geliefert werden können. Dokumentieren Sie, was Sie zum Meldezeitpunkt wussten, was noch geprüft wird und wann die nächste Ergänzung erfolgt. Eine Schätzung muss als solche erkennbar sein. Wird die 72-Stunden-Grenze überschritten, erklären Sie die Verzögerung in der Meldung; ein Registervermerk allein ersetzt diese Begründung gegenüber der Behörde nicht.
Eine einfache Zuständigkeitskette verhindert Leerlauf: Beschäftigte und Dienstleister melden Verdachtsfälle an einen erreichbaren Kanal; die zuständige Stelle sichert Beweise und zieht Fachbereich, IT-Sicherheit und Datenschutz hinzu; der Verantwortliche trifft die Risiko- und Meldeentscheidung. Außerhalb der Bürozeiten braucht es eine erreichbare Vertretung. Wer den Datenschutzbeauftragten einbezieht, sollte dessen Beratung dokumentieren, ohne ihm die Verantwortung des Verantwortlichen zuzuschieben. Der Eskalationsweg kann auch in einer IT-Nutzungsrichtlinie erläutert werden. Ein abgestimmter Eskalationsweg ist hilfreicher als eine scheinbar rechtssichere starre 24-Stunden-Dienstleisterfrist; vereinbaren Sie intern kurze Kommunikationswege, ohne die gesetzliche Formulierung ‘unverzüglich’ zu ersetzen.
Registerführung, Zugriff und Aufbewahrung
Bewahren Sie den Eintrag so auf, dass Entscheidungen später überprüft werden können. Versionen sollten zeigen, welche Fakten wann bekannt wurden und wer eine Schlussfolgerung änderte. Trennen Sie das knappe Register von sensiblen Belegen wie Logdateien, betroffenen Listen oder Kommunikationsentwürfen; verlinken Sie diese mit Zugriffsbeschränkung. Nicht jede Person, die den Vorfall technisch behebt, braucht Gesundheits- oder Personaldaten der Betroffenen. Sichern Sie Integrität und Wiederauffindbarkeit, auch wenn ein beteiligtes System ausfällt.
Die DSGVO nennt in Artikel 33 Absatz 5 keine einheitliche Aufbewahrungsdauer für das Register. Definieren Sie eine dokumentierte Frist anhand des Nachweiszwecks, möglicher weiterer Pflichten und der Datenminimierung. Ein pauschales ‘immer drei Jahre’ lässt sich aus diesem Absatz nicht ableiten. Löschen oder reduzieren Sie Detailbelege, wenn sie nicht mehr erforderlich sind, ohne die Nachprüfbarkeit des Falls zu zerstören. Stimmen Sie dies mit Ihrem Löschkonzept ab; ein Tool-Vergleich ersetzt die Fristentscheidung nicht.
Nutzen Sie das Register auch für Ursachenanalyse: Wenn wiederholt E-Mails an falsche Adressaten gehen, prüfen Sie Adressvorschläge, Vier-Augen-Freigaben oder Schulung. Bei wiederkehrenden Zugriffspannen können Rollenrechte oder Protokollierung die Ursache sein. Leiten Sie aus einem Fall konkrete Maßnahmen mit Verantwortlichen und Prüftermin ab. Das verbessert die Praxis, ohne zu behaupten, ein sauber geführtes Register garantiere eine mildere Sanktion. Die Aufsichtsbehörde kann anhand der Dokumentation kontrollieren, ob Artikel 33 eingehalten wurde; welche weiteren Folgen ein Verstoß hat, hängt vom konkreten Verfahren ab. Die Übersicht zu DSGVO-Bußgeldern zeigt den allgemeinen Sanktionsrahmen, aber kein Registereintrag garantiert ein bestimmtes Ergebnis.
Drei Situationen für die praktische Einordnung
Fehlversand an einen vertrauten Empfänger. Eine Beschäftigte schickt eine Rechnung an den falschen Kunden. Erfassen Sie Art der Angaben, Empfänger, Zeitpunkt, Rückmeldung und ob eine Weitergabe wahrscheinlich ist. Bitten Sie um Löschung und dokumentieren Sie die Antwort. Die bloße Bitte macht das Risiko nicht automatisch unwahrscheinlich. Eine Rechnung mit nur geschäftlichen Kontaktdaten kann anders zu beurteilen sein als ein Dokument mit Kontodaten oder Gesundheitsinformationen. Der Eintrag sollte zeigen, warum Sie trotz der Unsicherheit melden oder nicht melden.
Ransomware mit verfügbarer Sicherung. Ein Angriff verschlüsselt eine Datenbank. Selbst wenn die Wiederherstellung aus einem Backup gelingt, prüfen Sie, ob Daten zuvor abgeflossen sind und ob Menschen durch die Unterbrechung Schaden erleiden können. Ein Krankenhaus- oder Pflegesystem hat eine andere Risikolage als ein internes Archiv ohne zeitkritische Funktion. Notieren Sie Wiederherstellungszeit, Umfang, forensische Erkenntnisse und verbleibende Ungewissheit. Die Aussage ‘Backup vorhanden’ allein beantwortet weder die Vertraulichkeits- noch die Verfügbarkeitsfrage.
Öffentliches Testsystem mit Echtdaten. Eine Entwicklerin entdeckt, dass ein vermeintlicher Testdatensatz echte Adressen enthält und ohne Anmeldung erreichbar ist. Ermitteln Sie, seit wann die Seite erreichbar war, ob Zugriffslogs vorliegen, welche Suchmaschinen oder Dritte die Seite aufrufen konnten und wann sie abgeschaltet wurde. Fehlen Logs, halten Sie diese Lücke offen, statt aus fehlenden Nachweisen auf fehlenden Zugriff zu schließen. Prüfen Sie auch, ob die Datenschutz-Folgenabschätzung oder die Entwicklungsfreigabe für das zugrunde liegende Verfahren angepasst werden muss. Diese Beispiele liefern keine automatischen Meldeergebnisse; ihr Nutzen liegt in den überprüfbaren Fragen.
Übergabe zwischen Teams und Dienstleistern
Ein Register wird oft von Datenschutz, IT und Kundenbetreuung gleichzeitig benutzt. Definieren Sie deshalb ein gemeinsames Fallkennzeichen und halten Sie fest, wer die erste Meldung entgegennimmt, wer technische Belege sichert und wer die externe Kommunikation freigibt. Bei einem Dienstleister mit mehreren betroffenen Kunden braucht jeder Verantwortliche die für seine eigene Risikobewertung nötigen Fakten; eine allgemeine Rundmail ‘wir prüfen einen Vorfall’ kann als erster Hinweis sinnvoll sein, ersetzt aber keine nachgereichten konkreten Angaben. Für interne Teams genügt es nicht, nach Schichtende auf den nächsten Arbeitstag zu verweisen, wenn eine meldepflichtige Verletzung bekannt ist.
Vereinbaren Sie einen sicheren Kanal für Belege. Eine ungeschützte E-Mail mit der vollständigen betroffenen Kundenliste kann selbst ein weiterer Vorfall werden. Geben Sie zunächst Kategorien und Schätzwerte weiter und stellen Sie Detaildateien nur den Personen zur Verfügung, die sie für die Prüfung brauchen. Protokollieren Sie Nachfragen und Antworten mit Zeitstempel. Gerade wenn die erste Einschätzung später korrigiert wird, ist diese Chronologie wertvoller als ein überschriebenes Endformular. Auch das Muster für technische und organisatorische Maßnahmen sollte nach einem realen Vorfall mit den tatsächlich geänderten Kontrollen abgeglichen werden.
FAQ
Muss jeder IT-Vorfall ins Verletzungsregister?
Nein. Die Pflicht aus Artikel 33 Absatz 5 bezieht sich auf Verletzungen des Schutzes personenbezogener Daten. Erfassen Sie Verdachtsfälle zunächst intern und dokumentieren Sie die Einstufung. Eine bestätigte Verletzung gehört auch dann ins Register, wenn sie voraussichtlich kein Risiko begründet und nicht gemeldet wird.
Sind 72 Stunden eine interne Bearbeitungsfrist?
Nein. Der Verantwortliche muss eine meldepflichtige Verletzung ohne unangemessene Verzögerung und möglichst binnen 72 Stunden nach Kenntnis der Aufsicht melden. Ist die Meldung später, muss die Verzögerung begründet werden. Die interne Prüfung sollte schneller sein; sie darf den Fristbeginn nicht künstlich verschieben.
Muss ein Auftragsverarbeiter selbst die Behörde informieren?
Nach der Grundregel des Artikels 33 Absatz 2 informiert er den Verantwortlichen unverzüglich, sobald ihm eine Verletzung bekannt wird. Der Verantwortliche prüft und erfüllt seine eigene Behördenmeldepflicht. Ein Dienstleister kann daneben für eigene Verarbeitungen selbst Verantwortlicher sein; diese getrennte Rolle ist für jeden Datenstrom zu prüfen.
Wie lange bleibt eine Fallakte erhalten?
Artikel 33 Absatz 5 enthält keine feste Jahreszahl. Legen Sie eine nachvollziehbare Dauer für die Dokumentation und gegebenenfalls kürzere Zeiten für sensible Anlagen fest. Prüfen Sie besondere gesetzliche oder vertragliche Aufbewahrungspflichten, den Nachweiszweck und Datenminimierung; ersetzen Sie diese Prüfung nicht durch eine allgemeine Musterfrist.
Reicht die Vorlage als Behördenmeldung?
Nein. Das Register ist eine interne Dokumentation. Die Meldung nach Artikel 33 Absatz 3 braucht bestimmte Informationen über Art der Verletzung, Kontakt, wahrscheinliche Folgen und Maßnahmen. Nutzen Sie den zuständigen Meldeweg der Aufsicht, reichen Sie fehlende Angaben erforderlichenfalls nach und halten Sie Abgabe und Ergänzung im Register fest.
Primärquellen: Artikel 4, 32–34 DSGVO auf EUR-Lex, EDSA-Leitlinien 9/2022 zur Meldung von Datenschutzverletzungen und die BfDI-Info 6 zu Art. 33 und 34 (Bundesverwaltung).