Artikel 33 DSGVO und Artikel 23 NIS2 starten ihre Meldefristen im Moment des Bekanntwerdens; hier steht, was dieser Moment nach der Lesart des EDSA bedeutet, und was ein Vorfallsregister festhalten muss, damit Sie beweisen können, wann er eingetreten ist.
Artikel 33 DSGVO und Artikel 23 NIS2 starten ihre Meldefristen im Moment des Bekanntwerdens; hier steht, was dieser Moment nach der Lesart des EDSA bedeutet, und was ein Vorfallsregister festhalten muss, damit Sie beweisen können, wann er eingetreten ist.
Art. 33(1) DSGVO lautet: «Im Falle einer Verletzung des Schutzes personenbezogener Daten meldet der Verantwortliche unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde, diese der gemäß Artikel 55 zuständigen Aufsichtsbehörde, es sei denn, dass die Verletzung des Schutzes personenbezogener Daten voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt.»
Der tragende Halbsatz ist «nachdem ihm die Verletzung bekannt wurde». Die Frist beginnt in einem Moment innerhalb Ihrer Organisation, und Monate später kann eine Aufsichtsbehörde oder ein Auditor fragen, wann genau dieser Moment war, und woher Sie das wissen. Ein Ticketsystem beantwortet diese Frage selten. Das Folgende leitet her, was ein Vorfallsregister erfassen muss, damit die Antwort existiert.
Ein Hinweis zur deutschen Fassung dieses Beitrags: Zitate aus DSGVO und NIS-2-Richtlinie folgen den amtlichen deutschen Fassungen auf EUR-Lex, bei der DSGVO in der berichtigten Fassung. Die Leitlinien 9/2022 des Europäischen Datenschutzausschusses (EDSA, englisch EDPB) werden hier in der englischen Originalfassung zitiert.
Zuerst die DSGVO-Uhr. Art. 33(1) enthält zwei Qualifikationen. Die Meldung ist geschuldet, es sei denn, die Verletzung führt «voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen»: Jemand muss dieses Risiko beurteilen, und die Beurteilung läuft gegen die Uhr. Und erfolgt die Meldung nicht binnen 72 Stunden, «so ist ihr eine Begründung für die Verzögerung beizufügen», womit eine verspätete Meldung zu einer Auseinandersetzung über Ihre eigene Chronologie wird. Art. 33(4) mildert nur die inhaltliche Last: Der Verantwortliche kann die Informationen «ohne unangemessene weitere Verzögerung schrittweise zur Verfügung stellen». Art. 33(2) gibt Auftragsverarbeitern ihren eigenen Auslöser: «Wenn dem Auftragsverarbeiter eine Verletzung des Schutzes personenbezogener Daten bekannt wird, meldet er diese dem Verantwortlichen unverzüglich.»
Nichts davon definiert das Bekanntwerden. Am nächsten kommt die Präambel der Verordnung: Erwägungsgrund 87 verlangt die Feststellung, ob Massnahmen getroffen wurden, «um sofort feststellen zu können, ob eine Verletzung des Schutzes personenbezogener Daten aufgetreten ist», und bemisst die Rechtzeitigkeit an Art, Schwere und Folgen der Verletzung. Die Arbeitsdefinition stammt aus den Guidelines 9/2022 des EDSA zur Meldung von Verletzungen (Version 2.0, angenommen am 28. März 2023). Randnummer 31: Ein Verantwortlicher wird sich einer Verletzung bewusst, «when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised».
Der Test hängt an den Fakten des Einzelfalls. Randnummer 34 erlaubt «a short period of investigation» nach einem ersten Hinweis (von einer betroffenen Person, einem Medium oder der eigenen Detektion), während dessen der Verantwortliche «may not be regarded as being 'aware'». Die Untersuchung muss so früh wie möglich beginnen und angemessene Gewissheit herstellen; die detaillierte Forensik darf folgen. Ein Praxisbeispiel zeigt, wie wenig Gewissheit nötig ist: Beim verlorenen USB-Stick mit unverschlüsselten personenbezogenen Daten stellt der Verantwortliche womöglich nie fest, ob jemand auf die Daten zugegriffen hat — der Verfügbarkeitsverletzung wird er sich dennoch bewusst, «when it realised the USB key had been lost». Randnummer 40 schliesst das Schlupfloch: Auf einen ersten Alarm nicht rechtzeitig zu reagieren, wo eine Verletzung tatsächlich eingetreten ist, «could be considered as a failure to notify in accordance with Article 33 GDPR».
Die NIS-2-Richtlinie fährt für wesentliche und wichtige Einrichtungen eine schnellere Kaskade. Art. 23(1) verlangt, das CSIRT oder die zuständige Behörde «unverzüglich» über jeden erheblichen Sicherheitsvorfall zu unterrichten — erheblich ist ein Vorfall nach Art. 23(3), wenn er «schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die betreffende Einrichtung verursacht hat oder verursachen kann» oder andere natürliche oder juristische Personen «durch erhebliche materielle oder immaterielle Schäden» beeinträchtigt hat oder beeinträchtigen kann. Art. 23(4) setzt dann den Fahrplan: eine Frühwarnung «unverzüglich, in jedem Fall aber innerhalb von 24 Stunden nach Kenntnisnahme des erheblichen Sicherheitsvorfalls», in der gegebenenfalls anzugeben ist, ob der Verdacht auf rechtswidrige oder böswillige Handlungen besteht und ob grenzüberschreitende Auswirkungen möglich sind; eine Meldung über den Sicherheitsvorfall «innerhalb von 72 Stunden nach Kenntnisnahme» mit einer ersten Bewertung von Schweregrad und Auswirkungen und, soweit verfügbar, den Kompromittierungsindikatoren; auf Ersuchen ein Zwischenbericht; und ein Abschlussbericht «spätestens einen Monat nach Übermittlung der Meldung des Sicherheitsvorfalls gemäß Buchstabe b» — die Monatsfrist läuft ab der Übermittlung der 72-Stunden-Meldung, nicht ab der Kenntnisnahme. Der Abschlussbericht muss eine ausführliche Beschreibung einschliesslich Schweregrad und Auswirkungen enthalten, «Angaben zur Art der Bedrohung bzw. zugrunde liegenden Ursache, die wahrscheinlich den Sicherheitsvorfall ausgelöst hat», sowie die getroffenen und laufenden Abhilfemassnahmen. NIS2 ist eine Richtlinie; die Pflichten erreichen die Einrichtungen über das nationale Recht, das Art. 23 umsetzt.
Die beiden Regime teilen eine Abhängigkeit. Jede Frist in beiden wird ab einem Moment gemessen, den nur Ihre eigenen Aufzeichnungen belegen können. Ist Ihr Entdeckungszeitpunkt falsch, undokumentiert oder nachträglich rekonstruiert, erbt jedes Argument über die Rechtzeitigkeit Ihrer Meldung diese Schwäche.
Art. 33(5) ist der Absatz, der daraus ein Aufzeichnungsproblem macht statt eines Meldeproblems: «Der Verantwortliche dokumentiert Verletzungen des Schutzes personenbezogener Daten einschließlich aller im Zusammenhang mit der Verletzung des Schutzes personenbezogener Daten stehenden Fakten, ihrer Auswirkungen und der ergriffenen Abhilfemaßnahmen. Diese Dokumentation muss der Aufsichtsbehörde die Überprüfung der Einhaltung der Bestimmungen dieses Artikels ermöglichen.»
Das entscheidende Wort steht im englischen Text: «any» — «the controller shall document any personal data breaches»; die deutsche Fassung sagt schlicht «Verletzungen», ohne Einschränkung auf die gemeldeten. Auch die Verletzung unterhalb der Schwelle, die Sie als voraussichtlich nicht risikoträchtig eingestuft und nie gemeldet haben, erzeugt eine Dokumentationspflicht, und der Massstab steht im selben Satz: genug, damit die Behörde die Einhaltung überprüfen kann — einschliesslich Ihrer Entscheidung, nicht zu melden.
Die EDSA-Leitlinien machen die praktische Form explizit. Randnummer 122 knüpft die Pflicht an den Rechenschaftsgrundsatz des Art. 5(2), hält fest, dass «the supervisory authority can request to see these records», und ergänzt, Verantwortliche «are therefore encouraged to establish an internal register of breaches, regardless of whether they are required to notify or not». Randnummer 123 listet auf, was zu erfassen ist: die Ursachen, den Hergang, die betroffenen personenbezogenen Daten, die Wirkungen und Folgen sowie die ergriffenen Abhilfemassnahmen. Eine Fussnote erlaubt sogar, das Register im Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 zu führen, sofern die Angaben zur Verletzung «can be extracted upon request». Eine Aufbewahrungsfrist für das Register setzt die DSGVO nicht; die bestimmt der Verantwortliche.
Messen Sie ein typisches Ticketsystem an diesem Massstab. Ein Ticket, das eröffnet, bearbeitet, geschlossen und unter drei Monaten neuerer Tickets begraben wurde, hält Fragmente der Fakten, wenig von den Auswirkungen und Abhilfemassnahmen, die ohne Struktur über Kommentare verstreut sind. «Extract upon request» ist genau die Operation, die es nicht unterstützt.
Rückwärts aus den drei Texten abgeleitet, hat ein Registereintrag, der das Gewicht tragen kann, fünf Eigenschaften. Ein diszipliniert geführtes Spreadsheet kann alle fünf halten.
Nichts davon verlangt ein bestimmtes Werkzeug. Was auch immer Ihr Register hält: Der Test ist, ob es diese fünf Dinge mit Zeitstempeln hält, die Sie einem Regulator zeigen würden.
devguard liefert ein Incidents-Modul aus, und das Erste, was darüber zu sagen ist, ist eine Grenze: Es detektiert nichts. Es ingestiert keine Alerts, verbindet sich nicht mit Monitoring und öffnet keine Vorfälle aus Webhooks. Die Wege, die einen Eintrag anlegen, sind das Erstellformular, ein CSV-Import und ein Assistenten-Werkzeug, das handelt, wenn ein Nutzer meldet, dass etwas schiefgegangen ist. In jedem Fall erstellt ein Mensch den Eintrag. Das hat einen realen Preis: Loggt niemand den Vorfall, bleibt das Register stumm, und die Lücke zwischen dem Auslösen Ihres Monitoring-Stacks und dem Anlegen des Eintrags durch eine Person ist vollständig das Problem Ihres Prozesses. Die Begründung folgt der EDSA-Randnummer 41: Die Fähigkeit, eine Verletzung rechtzeitig zu erkennen und anzugehen, ist ein Element Ihrer Sicherheitsmassnahmen nach Art. 32, und diese Fähigkeit lebt bereits in Ihrem Alerting. Das Modul setzt beim Bekanntwerden an und strukturiert alles danach.
Der Eintrag selbst sind die fünf Eigenschaften aus dem vorigen Abschnitt. Wann ein Vorfall geschah und wann er entdeckt wurde, sind mit Absicht getrennte Zeitstempel; das Delta ist das Argument zum Bekanntwerden. Lösung und Abschluss bekommen eigene Zeitstempel, und Ursache und Lessons Learned haben ihren eigenen Platz auf dem Eintrag, geschrieben beim Abschluss. Ein Vorfall durchläuft fünf Status (offen, in Untersuchung, eingedämmt, gelöst, geschlossen) und trägt einen Schweregrad auf einer vierstufigen Skala von niedrig bis kritisch, einer Skala, die existiert, bevor der Vorfall existiert. Der Umfang sind Verknüpfungen: Assets, Risiken, Lieferanten, Behandlungsmassnahmen, Kontrollen und Evidenzen hängen am Eintrag, und jede Verknüpfung trägt, wer sie angelegt hat und wann. Massnahmen im Verlauf sind Timeline-Einträge, die jeweils festhalten, wann die Handlung geschah, wann sie notiert wurde, und von wem.
Markieren Sie einen Vorfall als Verletzung des Schutzes personenbezogener Daten, wird eine 72-Stunden-Meldefrist ab dem Entdeckungszeitpunkt berechnet: das Bekanntwerden verankert an der Entdeckung, gemäss Art. 33. Solange die Frist automatisch berechnet ist, folgt sie Änderungen am Entdeckungszeitpunkt; ein von Hand gesetzter Wert bleibt unangetastet, und das Entfernen der Markierung entfernt die Frist. Sie erscheint als Countdown am Vorfall und im organisationsweiten Fristen-Feed, wo eine ungemeldete Verletzung unabhängig vom Lebenszyklus-Status sichtbar bleibt. Die Daten, an denen Behörde und betroffene Personen benachrichtigt wurden, werden daneben festgehalten (Letzteres für die Benachrichtigung nach Art. 34). Und weil der Massstab des Art. 33(5) lautet, der Aufsichtsbehörde die Überprüfung der Einhaltung zu ermöglichen — die EDSA-Leitlinien formulieren es als die Fähigkeit, die Dokumentation auf Anfrage zu extrahieren —, exportiert das Ganze als PDF mit dem Titel «Complete Incident Register», Breach-Spalte eingeschlossen. [screenshot: incident detail page with the breach block countdown and timeline entries]
Das meiste an einem Vorfallseintrag lässt sich später aus Logs, Chatverläufen und Rechnungen rekonstruieren. Der Moment, in dem Ihr Team angemessene Gewissheit erreicht hat, nicht; er existiert nur, wenn ihn jemand im Moment selbst aufgeschrieben hat. Ich würde diesen einen Zeitstempel als den Grund behandeln, aus dem das Register existiert; alles andere am Eintrag lässt sich notfalls um ihn herum wieder aufbauen. Incident Handling ist ausserdem eine der Kontrollfamilien, die in jedem Framework zugleich auftaucht; wie derselbe Eintrag NIS2, SOC 2 und CRA gemeinsam bedient, steht in ein Kontrollsatz für NIS2, SOC 2 und CRA.
devguards Incidents-Modul ist das oben beschriebene Register, mit Lebenszyklus-Zeitstempeln, Timeline, Verknüpfungen und der Frist nach Artikel 33: devguard.ch/platform.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.