Kernthese
Viele Unternehmen haben bereits einen IT-Support-Prozess. Tickets werden angelegt, Prioritäten gesetzt, Lösungen dokumentiert. Das Problem liegt nicht darin, dass dieser Prozess fehlt. Das Problem liegt darin, dass er beim Übergang zum Sicherheitsereignis die falschen Felder hat — und die Meldebewertungskette nach §32 BSIG damit nicht beginnen kann.
Die 24-Stunden-Frist für die Frühmeldung beginnt mit der Kenntniserlangung. Nicht mit dem Beginn der Behebung. Nicht mit der Eskalation. Nicht mit der Entscheidung, ob es ernst ist. Das erste Ticket ist deshalb häufig der Ort, an dem dieser Zeitpunkt nachvollziehbar festgehalten werden muss — sofern ein erheblicher Sicherheitsvorfall vorliegt.
Ausgangspunkt
Eine IT-Störung ist nicht automatisch eine NIS2-Meldepflicht
Ein Drucker fällt aus. Ein Server reagiert nicht. Eine Applikation lädt langsam. Das ist IT-Alltag — kein Sicherheitsvorfall. NIS2 greift nicht bei jeder Betriebsunterbrechung, sondern wenn ein erheblicher Sicherheitsvorfall vorliegt. Die Unterscheidung ist keine Formalität. Sie ist die erste operative Entscheidung, die ein Unternehmen im Vorfall treffen muss.
Das Problem: Viele IT-Support-Tickets landen zunächst ohne Sicherheitsklassifikation. Hardwaredefekt, Bedienfehler, Netzwerkinstabilität — alles gleich behandelt, gleich priorisiert, gleich eskaliert. Das funktioniert für den Betrieb. Für §32 BSIG funktioniert es nicht.
Kein NIS2-Bezug
Technische Störung ohne Sicherheitsbezug
Hardwaredefekt, einzelner Systemausfall durch bekannte Ursache, Bedienfehler ohne Datenbezug, planmäßige Wartungsunterbrechung. Diese Ereignisse können intern priorisiert werden ohne NIS2-Meldebewertung.
Trotzdem prüfen: Liegt eine unbekannte Ursache vor? Könnten Daten betroffen sein? Gibt es einen Dritten im System?
Prüfen
Störung mit unklarem Sicherheitsbezug
Unbekannte Ursache, ungewöhnliches Systemverhalten, mehrere Systeme gleichzeitig betroffen, Auffälligkeit in Logs oder Zugriffsprotokollen. Hier beginnt die NIS2-Relevanzprüfung.
Die Bewertung „unklar" ist kein Versagen — sie ist der korrekte Ausgangspunkt für die strukturierte Einordnung.
NIS2-Relevant
Sicherheitsereignis mit Prüfpflicht
Böswillige Handlung, Ransomware, Datenzugriff durch Unbefugte, kompromittierter Account, externe Manipulation, erhebliche Betriebsunterbrechung durch Sicherheitsursache. Hier startet zwingend die Meldebewertung.
Ab diesem Punkt läuft die Uhr für §32 BSIG. Die Kenntniserlangung ist dokumentiert.
Erheblichkeitsschwelle
Wann ein Sicherheitsereignis NIS2-relevant wird
§32 BSIG verlangt die Meldung erheblicher Sicherheitsvorfälle. Erheblich bedeutet nicht katastrophal. Ein Vorfall ist erheblich, wenn er eine der folgenden Eigenschaften hat — und das Unternehmen muss diese Einordnung aktiv vornehmen und dokumentieren.
Zentrale Dienste
Dienste, die für den Betrieb, Kunden oder den betroffenen Sektor wesentlich sind, sind beeinträchtigt oder ausgefallen.
Prüfen
Datenbezug
Personenbezogene, vertrauliche oder betriebsrelevante Daten sind betroffen, abgeflossen oder zugänglich geworden.
Starkes Signal
Kundenwirkung
Kunden können Leistungen nicht abrufen, sind informiert oder müssen informiert werden, Vertragspflichten sind berührt.
Starkes Signal
Lieferantenwirkung
Ein Vorfall beim Lieferanten wirkt auf das eigene System zurück, oder ein Vorfall im eigenen Betrieb hat Auswirkung auf Lieferanten oder Subdienstleister.
Prüfen
Böswillige Handlung
Es gibt Hinweise auf Angriff, Manipulation, unbefugten Zugriff, Malware oder Social Engineering als Ursache.
Starkes Signal
Betriebsunterbrechung
Der Betrieb ist erheblich unterbrochen — nicht einzelne Funktionen, sondern wesentliche Abläufe sind für einen relevanten Zeitraum nicht verfügbar.
Prüfen
Wichtig zur Schwellenwertprüfung
Kein einzelnes Merkmal ist automatisch gleichbedeutend mit Meldepflicht. Die Einordnung erfordert eine Gesamtbetrachtung. Ein Vorfall, der zunächst klein wirkt, kann in der Bewertung erheblich werden. Die Einordnung muss deshalb kontinuierlich aktualisiert werden — nicht einmalig beim ersten Ticket.
Incident Intake
Was im bestehenden Ticket stehen muss — ab dem ersten Moment
Das erste IT-Ticket ist der Startpunkt der Meldebewertungskette. Es muss nicht sofort vollständig sein. Aber sechs Felder müssen von Beginn an geführt werden — weil sie die Grundlage für jede spätere Compliance-Entscheidung bilden.
ServiceNow, Jira Service Management, OTRS und vergleichbare ITSM-Systeme können diese Felder als strukturierte Pflichtfelder abbilden. Das erfordert keine eigene Compliance-Plattform — nur die richtigen Felder im richtigen Moment.
T-01
Kenntniserlangung
incident.awareness_time
Wann wurde das Ereignis erstmals wahrgenommen — nicht wann das Ticket angelegt wurde?
T-02
Betroffene Systeme
incident.affected_assets
Welche Systeme, Dienste, Standorte oder Benutzergruppen sind betroffen oder könnten betroffen sein?
T-03
Erste Wirkung
incident.initial_impact
Was ist die erkennbare Auswirkung? Betrieb, Daten, Kunden, externe Wirkung — auch wenn noch unklar?
T-04
Owner
incident.owner
Wer ist fachlich verantwortlich für die Bewertung und Eskalation dieses Vorgangs?
T-05
Sofortmaßnahmen
incident.immediate_actions
Welche Maßnahmen wurden sofort eingeleitet — Isolation, Sperrung, Backup, Information?
T-06
Nächste Bewertung
incident.next_review
Bis wann wird die Meldebewertung durchgeführt — konkret, nicht „so bald wie möglich"?
Fristenkritisch
T-01 Kenntniserlangung ist das wichtigste Feld. Die 24-Stunden-Frist beginnt nicht mit der technischen Behebung, sondern mit der Kenntniserlangung eines erheblichen Sicherheitsvorfalls. Das erste Ticket ist deshalb häufig der Ort, an dem dieser Zeitpunkt festgehalten werden muss. Fehlt das Feld, fehlt der dokumentierte Beginn der gesetzlichen Frist.
Compliance-Schritt
Die Meldebewertung: strukturierte Entscheidung mit Nachweis
Die Meldebewertung ist keine nachträgliche Dokumentation. Sie ist ein aktiver Entscheidungsschritt, der für sich selbst einen Nachweis erzeugen muss — unabhängig davon, ob das Ergebnis Ja oder Nein ist. Ein Unternehmen, das begründet nicht meldet, kann später nachvollziehbar zeigen, dass eine Bewertung stattgefunden hat.
Fünf Felder müssen in der Meldebewertung geführt werden:
Erheblichkeit
Erheblich / Nicht erheblich / In Bewertung
Liegt ein erheblicher Sicherheitsvorfall vor? Die Entscheidung muss explizit und mit Datum und Entscheider dokumentiert werden — auch bei „Nein" und „Noch unklar".
Erheblichkeit ist eine Statusentscheidung, keine Eigenschaft. Sie muss gesetzt werden.
Meldepflicht
Meldepflichtig / Nicht meldepflichtig / In Bewertung
Falls erheblich: Ist das Unternehmen als betroffene Einrichtung nach §28 BSIG meldepflichtig? Welche Meldeart gilt — §32 Abs. 1 oder §32 Abs. 2 BSIG?
Ein Unternehmen, das selbst nicht NIS2-pflichtig ist, aber Dienste für eine betroffene Einrichtung erbringt, kann trotzdem kommunikationspflichtig gegenüber seinem Auftraggeber sein.
Begründung
Dokumentierte Begründung — immer, nicht nur bei Ja
Warum wurde die Entscheidung so getroffen? Welche Faktoren haben die Erheblichkeitsschwelle erfüllt oder nicht erfüllt? Welche Quellen — Logs, Systemberichte, externe Information — wurden herangezogen?
Die Begründung ist der eigentliche Compliance-Nachweis. Nicht die Entscheidung allein.
Entscheider
Person und Rolle, die die Bewertung vorgenommen hat
Wer hat die Meldebewertung durchgeführt und freigegeben? ISB, IT-Leitung, Compliance, Geschäftsführung? Bei erheblichen Vorfällen muss die Entscheidung auf Managementebene dokumentiert sein.
Bei §38-relevantem Vorfall: Ist die Geschäftsführung informiert und die Entscheidung dokumentiert?
Nachweisquelle
Verweis auf den Arbeitsstand im Nachweisregister
Wo liegt der Nachweis der Meldebewertung? EVID-02, IR-01, Ticket-ID, Dateiablage. Der Nachweis muss auffindbar, aktuell und vollständig sein.
Checkliste: Ticket-ID mit T-01 bis T-06, Meldebewertungsprotokoll IR-01, Entscheidung mit Datum und Entscheider, Ablageort.
Entscheidung: Ja
Was passiert, wenn die Meldebewertung „erheblich" ergibt
Die Entscheidung „erheblich und meldepflichtig" startet vier parallele Arbeitsstände. Sie müssen nicht nacheinander, sondern gleichzeitig aufgebaut werden — weil die Fristen nach §32 BSIG keine sequenzielle Bearbeitung erlauben.
Entscheidung: Erheblicher Sicherheitsvorfall — meldepflichtig
Sofort — innerhalb 24 Stunden
FRM-01 Frühmeldung an BSI — Zeitpunkt, Systeme, erste Wirkungseinschätzung
Geschäftsführung informieren, Entscheidung dokumentieren und Wiedervorlage setzen
Kommunikation intern sperren — keine unkontrollierten Informationen nach außen
Fortlaufend — bis Abschluss
FRM-02 Vorfallakte führen — Zeitstempel, Systeme, Maßnahmen, Entscheidungen
Kundenkommunikation prüfen — vertragliche oder gesetzliche Informationspflichten
FRM-03 Lessons Learned nach Abschluss — was hat funktioniert, was muss angepasst werden
1
FRM-01 · Frühmeldung
Erste strukturierte Meldung an das BSI innerhalb von 24 Stunden nach Kenntniserlangung. Enthält Zeitpunkt, betroffene Systeme, vorläufige Wirkungseinschätzung und Einrichtungstyp. Keine vollständige Analyse erforderlich — eine begründete Einschätzung des bekannten Stands.
FRM-01-FRÜHMELDUNG
2
FRM-02 · Vorfallakte fortführen
Vollständiger Vorfallbericht innerhalb von 72 Stunden. Zeitstrahl, betroffene Systeme, Ursache (soweit bekannt), Betriebswirkung, ergriffene Maßnahmen, aktueller Stand. Fortlaufend aktualisiert bis Vorfallabschluss.
FRM-02-VORFALLAKTE
3
GOV-01 · Kenntnisnahme der Geschäftsführung, falls erforderlich
Bei erheblichen Vorfällen mit Kundenwirkung, wesentlichem Restrisiko oder geschäftlicher Entscheidungsrelevanz: GOV-01 zur dokumentierten Kenntnisnahme der Geschäftsführung nutzen. §38 BSIG verlangt nicht nur Information, sondern eine nachvollziehbar dokumentierte Befassung der Geschäftsführung.
GOV-01-LEITUNGSSICHT
4
FRM-03 · Lessons Learned
Nach Vorfallabschluss: Was hat der Incident über Lücken im Prozess, fehlende Nachweise, schwache Kontrollen oder unbekannte Risiken offengelegt? Die Lessons Learned schließen den Vorgang und erzeugen die Grundlage für Prozessverbesserung.
FRM-03-LESSONS-LEARNED
Entscheidung: Nein
Was passiert, wenn die Meldebewertung „nicht erheblich" ergibt
Eine begründete Nichtmeldung ist kein Compliance-Versagen. Sie ist selbst ein Nachweis — vorausgesetzt, die Entscheidung ist dokumentiert, datiert, mit Entscheider versehen und im Nachweisregister abgelegt.
Entscheidung: Kein erheblicher Sicherheitsvorfall — keine Meldepflicht
Sofort
Entscheidung mit Datum, Entscheider und Begründung dokumentieren
Begründung: welche Erheblichkeitskriterien wurden geprüft und warum nicht erfüllt
Vorgang als „Nicht meldepflichtig" im Ticket schließen — nicht still verwerfen
Fortlaufend
Wiedervorlage setzen — Vorfälle können sich nachträglich als erheblicher herausstellen
Monitoring aktivieren: Gibt es Folgeauffälligkeiten, die die Einordnung revidieren?
Nachweis ins EVID-02 überführen — Nichtmeldung ist nachweisbar, nicht unsichtbar
Nachweislogik
Ein Prüfer oder Auditor fragt nicht nur, ob gemeldet wurde. Er fragt, ob eine Meldebewertung stattgefunden hat. Eine dokumentierte „Nein"-Entscheidung mit Begründung zeigt, dass das Unternehmen den Prozess beherrscht — und nicht ignoriert.
Ticket mit T-01 bis T-06 vollständig geführt und abgeschlossen
Meldebewertungs-Feld: „Nicht erheblich" mit Datum und Entscheider
Begründung: geprüfte Kriterien, Ergebnis der Prüfung, Quellen
Wiedervorlage gesetzt mit konkretem Datum
Eintrag in EVID-02 Nachweisregister angelegt
Bei Kundenwirkung: geprüft, ob vertragliche Informationspflichten bestehen
Häufige Fragen zur Meldebewertung nach §32 BSIG
Die Frist beginnt mit der Kenntniserlangung — dem Zeitpunkt, zu dem das Unternehmen erstmals von dem Ereignis erfahren hat. Nicht mit dem Beginn der Behebung, nicht mit der Eskalation, nicht mit der Entscheidung, ob das Ereignis ernst ist. Deshalb ist das Feld T-01 Kenntniserlangung das wichtigste Feld im ersten Ticket.
Die Frist beginnt mit dem Zeitpunkt, zu dem das Unternehmen Kenntnis von der Erheblichkeit erlangt hat — nicht mit dem ursprünglichen Ereignis. Eine nachträgliche Revision der Meldebewertung ist möglich und muss dokumentiert werden. Deshalb ist die Wiedervorlage auch bei einer Nein-Entscheidung Pflicht.
Nein. Die Geschäftsführung sollte nach §38 BSIG befasst werden, wenn der Vorfall erheblich ist, Kundenwirkung entsteht, eine Meldung nach §32 erfolgt oder ein wesentliches Restrisiko offenbleibt. Die Entscheidung über Information, Kenntnisnahme und Wiedervorlage gehört selbst in den Meldebewertungs-Schritt — als explizites Feld, nicht als nachträgliche Eskalation.
ServiceNow, Jira Service Management, OTRS und vergleichbare Systeme können die Pflichtfelder abbilden. Entscheidend ist nicht das System, sondern ob Kenntniserlangung, Sicherheitsbezug, Wirkung, Owner und Meldebewertungs-Entscheidung als strukturierte Pflichtfelder geführt werden — nicht als Freitextnotizen.
Die Frühmeldung nach §32 Abs. 1 BSIG erfolgt innerhalb von 24 Stunden und enthält eine erste Einschätzung — keine abschließende Analyse. Der Vorfallbericht erfolgt innerhalb von 72 Stunden und enthält vollständige Informationen zu Ursache, Wirkung und Maßnahmen. Beide sind separate Meldepflichten, die aufeinander aufbauen.
Lessons Learned nach einem erheblichen Vorfall ist keine freiwillige Qualitätsmaßnahme. §30 BSIG verlangt Wirksamkeit der Sicherheitsmaßnahmen — und Wirksamkeit entsteht aus der Auswertung tatsächlicher Ereignisse. FRM-03 Lessons Learned schließt den Vorgang und erzeugt die Grundlage für Prozessverbesserung und Nachweisführung.
NIS2 angewandt · Nächster Schritt
Meldebewertung strukturiert vorbereiten
Der NIS2-Arbeitsplatz enthält Meldebewertungsprotokoll, Vorfallakte, Frühmeldungsvorlage und die dokumentierte Befassung der Geschäftsführung — als prüffähige Arbeitsstände für den Ernstfall.