- Die NIS2-Erstmeldung muss innerhalb von 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls beim BSI eingehen.
- Pflichtinhalte sind unter anderem Angaben zum Vorfall, betroffene Dienste, vermutete Ursache und grenzüberschreitende Auswirkungen.
- Ein Vorfall gilt als erheblich, wenn er schwere Betriebsstörungen, finanzielle Verluste oder erhebliche Schäden für Dritte verursachen kann.
- Wer den Meldeprozess mit Vorlagen, Kontaktdaten und klaren Zuständigkeiten vorbereitet, spart im Ernstfall kritische Stunden.
Warum die Erstmeldung so kritisch ist
Ein Ransomware-Angriff legt am Montagmorgen die zentrale Warenwirtschaft lahm. Die IT-Abteilung stellt den Vorfall um 8:14 Uhr fest. Ab genau diesem Zeitpunkt läuft die Uhr: 24 Stunden, um eine erste Meldung an das Bundesamt für Sicherheit in der Informationstechnik (BSI) zu übermitteln. Nicht 24 Arbeitsstunden, sondern 24 Stunden ab Kenntnisnahme - auch wenn der Vorfall am Freitagnachmittag passiert.
Die NIS2-Richtlinie der EU und ihre deutsche Umsetzung im BSI-Gesetz (BSIG) haben die Meldepflichten für Betreiber wesentlicher und wichtiger Einrichtungen deutlich verschärft. Die Erstmeldung ist dabei der erste von drei verpflichtenden Schritten. Sie soll dem BSI ermöglichen, die Lage schnell einzuschätzen und bei Bedarf andere potenziell betroffene Einrichtungen zu warnen.
Das Problem in der Praxis: Wenn der Ernstfall eintritt, herrscht Stress. Systeme sind ausgefallen, die Geschäftsführung will Antworten, Kunden rufen an. Wer sich erst dann fragt, was genau in die Meldung gehört, verliert wertvolle Zeit. Dieser Artikel gibt dir alles an die Hand, was du für eine korrekte und fristgerechte Erstmeldung brauchst.
Wann wird eine NIS2-Meldung fällig?
Nicht jeder IT-Vorfall löst eine Meldepflicht aus. Die NIS2-Richtlinie spricht bewusst von einem erheblichen Sicherheitsvorfall. Die Schwelle liegt also höher als bei einem alltäglichen technischen Problem, aber deutlich niedriger, als viele Unternehmen vermuten.
Definition: Erheblicher Sicherheitsvorfall
Ein Sicherheitsvorfall gilt nach NIS2 als erheblich, wenn mindestens eines der folgenden Kriterien zutrifft:
- Schwere Betriebsstörung: Der Vorfall beeinträchtigt die Erbringung deiner Dienste wesentlich. Bei einem Unternehmen mit rund 100 Mitarbeitenden wäre das beispielsweise der Ausfall des ERP-Systems, der die gesamte Auftragsabwicklung zum Stillstand bringt.
- Finanzielle Verluste: Der Vorfall verursacht oder kann erhebliche finanzielle Schäden verursachen. Eine feste Euro-Grenze gibt es nicht, aber wenn der Schaden in einem spürbaren Verhältnis zum Jahresumsatz steht, ist die Schwelle erreicht.
- Schäden für Dritte: Andere natürliche oder juristische Personen können durch den Vorfall erheblichen materiellen oder immateriellen Schaden erleiden. Ein Datenleak mit Kundendaten fällt klar in diese Kategorie.
Praxisbeispiele: Meldepflichtig oder nicht?
| Szenario | Erheblich? | Begründung |
|---|---|---|
| Ransomware verschlüsselt alle Fileserver | Ja | Schwere Betriebsstörung, potenziell Datenverlust |
| Phishing-Mail öffnet, aber Malware wird vom Endpoint-Schutz geblockt | Nein | Kein tatsächlicher Schaden eingetreten |
| Angreifer exfiltriert Kundendatenbank mit 5.000 Datensätzen | Ja | Erheblicher Schaden für Dritte (personenbezogene Daten) |
| DDoS-Angriff legt Webshop für 6 Stunden lahm | Wahrscheinlich ja | Schwere Betriebsstörung wenn der Webshop ein wesentlicher Dienst ist |
| Fehlkonfiguration ermöglicht unbefugten Zugriff auf internen Testserver ohne produktive Daten | Nein | Keine wesentliche Betriebsstörung, keine sensiblen Daten betroffen |
| Kompromittierung des VPN-Gateways mit potenziellem Zugriff auf das gesamte Netzwerk | Ja | Schwere Betriebsstörung möglich, Ausmaß zunächst unklar |
Im Zweifel gilt: Lieber melden. Das BSI hat wiederholt betont, dass eine Meldung, die sich im Nachhinein als weniger schwerwiegend herausstellt, keine negativen Konsequenzen hat. Eine verspätete oder unterlassene Meldung hingegen schon — die drohenden NIS2-Bußgelder sind empfindlich.
Die drei Meldestufen im Überblick
NIS2 sieht einen gestaffelten Meldeprozess vor. Jede Stufe hat ihren eigenen Zweck, eigene Fristen und eigene inhaltliche Anforderungen.
Stufe 1: Erstmeldung (Frühwarnung)
- Frist: 24 Stunden nach Kenntnisnahme des Vorfalls
- Zweck: Schnelle Lageeinschätzung für das BSI, Warnung anderer Einrichtungen
- Detailgrad: Grundlegende Fakten, keine vollständige Analyse erwartet
Stufe 2: Aktualisierte Bewertung
- Frist: 72 Stunden nach Kenntnisnahme des Vorfalls
- Zweck: Vertiefte Einschätzung auf Basis erster Analyseergebnisse
- Detailgrad: Erste Bewertung von Schwere und Auswirkungen, Indikatoren für eine Kompromittierung (IoCs)
Stufe 3: Abschlussbericht
- Frist: Spätestens 1 Monat nach der Erstmeldung
- Zweck: Vollständige Dokumentation des Vorfalls und der ergriffenen Maßnahmen
- Detailgrad: Ursachenanalyse, Ausmaß, Gegenmaßnahmen, Lessons Learned
Zwischen der aktualisierten Bewertung und dem Abschlussbericht kann das BSI außerdem Zwischenberichte anfordern, insbesondere wenn der Vorfall noch andauert. Die Fristen der Stufen 1 und 2 laufen parallel ab Kenntnisnahme. Die Frist für den Abschlussbericht beginnt mit der Erstmeldung.
Was muss in die Erstmeldung?
Die Erstmeldung ist bewusst als Frühwarnung konzipiert. Du musst nach 24 Stunden nicht jedes Detail kennen. Was du liefern musst, sind die grundlegenden Fakten, die dem BSI eine erste Einschätzung ermöglichen.
Pflichtinhalte der Erstmeldung
1. Angaben zur meldenden Einrichtung
- Vollständiger Name der Einrichtung
- Registrierungsnummer beim BSI (nach erfolgter NIS2-Registrierung)
- Kontaktdaten der benannten Kontaktstelle (Name, E-Mail, Telefon)
- Branche und Sektor
2. Beschreibung des Vorfalls
- Art des Vorfalls (z.B. Ransomware, Datenexfiltration, DDoS, Supply-Chain-Kompromittierung)
- Zeitpunkt der Entdeckung (Datum und Uhrzeit)
- Vermuteter oder bekannter Beginn des Vorfalls, falls abweichend
- Kurze Beschreibung des Vorfallshergangs, soweit zu diesem Zeitpunkt bekannt
3. Betroffene Dienste und Systeme
- Welche eurer Dienste sind beeinträchtigt oder ausgefallen?
- Geschätzte Anzahl betroffener Nutzer oder Kunden
- Geschätzte Auswirkung auf die Diensteerbringung
4. Grenzüberschreitende Auswirkungen
- Sind Dienste in anderen EU-Mitgliedstaaten betroffen?
- Sind Kunden oder Partner in anderen Ländern betroffen?
5. Vermutete Ursache
- Erste Einschätzung zur Ursache (sofern bereits möglich)
- Angabe, ob die Ursache noch unbekannt ist
6. Ergriffene Sofortmaßnahmen
- Welche ersten Gegenmaßnahmen wurden eingeleitet?
- Wurde ein externer Incident-Response-Dienstleister eingeschaltet?
7. Einschätzung der Böswilligkeit
- Ob der Vorfall vermutlich auf eine böswillige Handlung zurückzuführen ist
- Diese Einschätzung darf vorläufig sein
Was du nach 24 Stunden nicht wissen musst
Die Erstmeldung verlangt ausdrücklich keine vollständige Analyse. Folgende Punkte sind für die 72-Stunden-Bewertung oder den Abschlussbericht vorgesehen:
- Exakte Ursachenanalyse (Root Cause)
- Vollständige Liste aller betroffenen Systeme
- Detaillierte forensische Ergebnisse
- Abschließende Schadensbewertung
- Indicators of Compromise (IoCs) im Detail
Du darfst und solltest in der Erstmeldung ehrlich schreiben: "Ursache wird noch untersucht" oder "Ausmaß noch nicht vollständig bekannt". Das BSI erwartet nach 24 Stunden eine schnelle Lagemeldung, keine fertige Analyse.
Mustervorlage für die NIS2-Erstmeldung
Die folgende Vorlage orientiert sich an den Anforderungen der NIS2-Umsetzung im BSIG und den bisherigen Veröffentlichungen des BSI. Passe sie an dein Unternehmen an und halte sie griffbereit.
NIS2-Erstmeldung (Frühwarnung) an das BSI
Meldende Einrichtung
- Name: [Firmenname GmbH]
- BSI-Registrierungsnummer: [NIS2-XXXX-XXXX]
- Sektor: [z.B. Verarbeitendes Gewerbe / Digitale Infrastruktur / ...]
- Kontaktstelle: [Name, E-Mail, Telefon der benannten Meldekontaktstelle]
Vorfallsdaten
- Zeitpunkt der Entdeckung: [TT.MM.JJJJ, HH:MM Uhr]
- Vermuteter Beginn: [TT.MM.JJJJ, HH:MM Uhr / Unbekannt]
- Art des Vorfalls: [Ransomware / Datenexfiltration / DDoS / Unbefugter Zugriff / Sonstiges]
Beschreibung [2-4 Sätze: Was ist passiert? Wie wurde der Vorfall entdeckt? Welche Systeme sind unmittelbar betroffen?]
Beispiel: Am 14.03.2026 um 08:14 Uhr stellte die IT-Abteilung fest, dass mehrere Fileserver verschlüsselt wurden. Die Schadsoftware wurde vermutlich über eine kompromittierte E-Mail eingeschleust. Betroffen sind das ERP-System, der zentrale Fileserver und der E-Mail-Server. Der Angriff wurde durch eine ungewöhnliche Netzwerkaktivität um 03:22 Uhr in der Nacht erstmals sichtbar.
Betroffene Dienste
- [Dienst 1]: [Status: Ausgefallen / Eingeschränkt]
- [Dienst 2]: [Status: Ausgefallen / Eingeschränkt]
- Geschätzte betroffene Nutzer/Kunden: [Anzahl]
Grenzüberschreitende Auswirkungen
- Dienste in anderen EU-Staaten betroffen: [Ja, welche / Nein / Noch nicht bekannt]
- Kunden/Partner in anderen Ländern betroffen: [Ja / Nein / Noch nicht bekannt]
Erste Einschätzung
- Vermutete Ursache: [z.B. Phishing-E-Mail mit Malware-Anhang / Wird noch ermittelt]
- Böswillige Handlung vermutet: [Ja / Nein / Unklar]
Ergriffene Sofortmaßnahmen
- [z.B. Betroffene Systeme vom Netzwerk isoliert]
- [z.B. Externer IR-Dienstleister beauftragt]
- [z.B. Backup-Integrität wird geprüft]
- [z.B. Passwort-Reset für alle administrativen Konten eingeleitet]
Nächste Schritte
- Forensische Analyse läuft, aktualisierte Bewertung erfolgt innerhalb von 72 Stunden
- Kontaktstelle ist unter [Telefon/E-Mail] erreichbar
Diese Vorlage deckt alle Pflichtfelder ab. In einer akuten Stresssituation hilft es enorm, wenn du nur noch die eckigen Klammern ausfüllen musst, statt unter Druck ein Freitextdokument zu formulieren. Tools wie ISMS Lite generieren die BSI-Erstmeldung direkt aus den erfassten Vorfallsdaten, sodass du in der 24-Stunden-Frist nicht bei null anfangen musst.
Wer meldet und wohin?
Die Kontaktstelle
Jede NIS2-pflichtige Einrichtung muss beim BSI eine Kontaktstelle benennen. Diese Person (oder Funktionsstelle) ist der offizielle Ansprechpartner für alle Meldungen. In einem Unternehmen mit rund 100 Mitarbeitenden ist das typischerweise der Informationssicherheitsbeauftragte (ISB) oder der IT-Leiter.
Wichtig: Die Kontaktstelle muss rund um die Uhr erreichbar sein. Das bedeutet nicht, dass der ISB nie schlafen darf, aber es braucht eine Regelung für Vertretung und Rufbereitschaft. Wenn der primäre Ansprechpartner im Urlaub ist oder selbst krank ausfällt, muss ein Vertreter benannt und dem BSI bekannt sein.
Empfehlung für die Praxis:
- Primärkontakt: ISB oder IT-Leiter
- Vertretung: IT-Teamleiter oder externer IT-Sicherheitsdienstleister
- Funktionspostfach einrichten (z.B. sicherheit@firma.de), das mehrere Personen überwachen
- Mobilnummer für Notfälle hinterlegen
Der Meldeweg
Die Erstmeldung geht an das BSI als zentrale Meldestelle. Der genaue Meldeweg wird über ein Meldeportal des BSI abgewickelt, das im Rahmen der NIS2-Umsetzung bereitgestellt wird. Parallel dazu bleibt die Meldung per E-Mail an die bekannten BSI-Kontaktadressen möglich.
Wenn dein Unternehmen zusätzlich der DSGVO unterliegt (und das ist bei personenbezogenen Daten praktisch immer der Fall), kann neben der BSI-Meldung auch eine Meldung an die zuständige Datenschutz-Aufsichtsbehörde erforderlich sein. Die beiden Meldungen haben unterschiedliche Rechtsgrundlagen und ersetzen sich nicht gegenseitig. Bei einem Ransomware-Angriff, der auch Kundendaten betrifft, musst du also möglicherweise an zwei Stellen melden.
Bewertungskriterien: Wann ist ein Vorfall erheblich?
Die Einschätzung, ob ein Vorfall die Meldeschwelle erreicht, ist eine der schwierigsten Entscheidungen im Incident-Response-Prozess. Hier sind die Kriterien, die du systematisch prüfen solltest.
Checkliste zur Erheblichkeitsbewertung
Prüfe jeden der folgenden Punkte. Wenn du mindestens einen mit Ja beantwortest, liegt wahrscheinlich ein meldepflichtiger Vorfall vor:
- Dienstausfall: Ist ein wesentlicher Dienst deiner Einrichtung ausgefallen oder stark beeinträchtigt?
- Dauer: Dauert die Beeinträchtigung voraussichtlich länger als eine tolerierbare Ausfallzeit?
- Betroffene Nutzer: Sind eine erhebliche Anzahl von Nutzern oder Kunden betroffen?
- Datenverlust: Wurden Daten gelöscht, verschlüsselt, verändert oder unbefugt abgerufen?
- Personenbezogene Daten: Sind personenbezogene Daten betroffen?
- Finanzielle Auswirkung: Übersteigt der geschätzte Schaden einen Betrag, der für dein Unternehmen spürbar ist?
- Ausbreitung: Kann sich der Vorfall auf andere Systeme, Dienste oder Einrichtungen ausbreiten?
- Wiederholung: Deutet der Vorfall auf eine systemische Schwachstelle hin, die weitere Angriffe ermöglicht?
Graubereiche und Daumenregeln
In der Praxis gibt es viele Fälle, die nicht eindeutig sind. Folgende Daumenregeln helfen:
- Wenn du mehr als 10 Minuten überlegst, ob du melden musst: Melde. Die Tatsache, dass du unsicher bist, deutet auf eine gewisse Schwere hin.
- Wenn die Geschäftsführung informiert werden muss: Dann ist der Vorfall wahrscheinlich auch meldepflichtig.
- Wenn du einen externen Dienstleister zur Hilfe rufst: Das ist ein starkes Indiz für Erheblichkeit.
- Wenn Backups eingespielt werden müssen: Der Vorfall hat offensichtlich produktive Systeme so stark beeinträchtigt, dass ein Normalbetrieb nicht mehr möglich war.
Vorbereitung: Was du jetzt schon tun kannst
Die beste Zeit, sich auf einen Sicherheitsvorfall vorzubereiten, ist lange bevor er eintritt. Die folgenden Maßnahmen kosten wenig Zeit und sparen im Ernstfall Stunden.
1. Meldevorlage vorbereiten und ablegen
Nimm die Vorlage aus diesem Artikel (oder erstelle eine eigene auf Basis der BSI-Anforderungen) und lege sie so ab, dass sie auch bei einem Systemausfall erreichbar ist. Ein verschlüsselter Fileserver nützt dir nichts, wenn genau dort die Meldevorlage liegt.
Empfehlungen:
- Vorlage ausdrucken und im Incident-Response-Ordner ablegen
- Kopie in einem Cloud-Speicher außerhalb der eigenen Infrastruktur
- Vorlage auf dem Mobiltelefon des ISB verfügbar machen
2. Kontaktdaten aktuell halten
Stelle sicher, dass folgende Kontaktdaten jederzeit griffbereit sind:
- BSI-Meldeportal (URL und Zugangsdaten)
- Telefonnummer der BSI-Meldestelle für Notfälle
- Kontaktdaten des externen IR-Dienstleisters (falls vorhanden)
- Kontaktdaten der zuständigen Datenschutz-Aufsichtsbehörde
- Interne Eskalationskette: Wer informiert wen?
3. Zuständigkeiten klären
Definiere vorab und schriftlich:
- Wer entscheidet, ob ein Vorfall als erheblich eingestuft wird?
- Wer füllt die Meldung aus?
- Wer gibt die Meldung frei (Vier-Augen-Prinzip)?
- Wer übermittelt die Meldung ans BSI?
- Wer informiert die Geschäftsführung?
- Wer kümmert sich um die parallele DSGVO-Meldung?
In einem 100-Mitarbeitenden-Unternehmen könnte das so aussehen: Der IT-Leiter entdeckt den Vorfall und eskaliert an den ISB. Der ISB bewertet die Erheblichkeit, füllt die Erstmeldung aus und stimmt sich kurz mit der Geschäftsführung ab. Anschließend übermittelt der ISB die Meldung ans BSI und beauftragt parallel den Datenschutzbeauftragten mit der Prüfung einer DSGVO-Meldung.
4. Testlauf durchführen
Mindestens einmal jährlich solltest du den Meldeprozess als Tabletop-Übung durchspielen. Simuliere einen Vorfall und lass das Team die Erstmeldung tatsächlich ausfüllen. Dabei zeigen sich die typischen Schwachstellen: Wo hakt es? Welche Informationen fehlen? Wie lange dauert es, bis die Meldung fertig ist?
5. Zeitstempel dokumentieren
Ab dem Moment, in dem ein Verdacht auf einen erheblichen Vorfall besteht, solltest du konsequent Zeitstempel notieren — ein strukturierter Ablauf zum Sicherheitsvorfall erkennen und melden hilft dabei. Wann wurde was entdeckt? Wann wurde wer informiert? Wann wurde welche Maßnahme eingeleitet? Diese Dokumentation brauchst du nicht nur für die Meldung, sondern auch für die spätere forensische Aufarbeitung und den Abschlussbericht.
6. Erreichbarkeit außerhalb der Geschäftszeiten sicherstellen
Ein Angriff richtet sich nicht nach deinen Bürozeiten. Kläre, wie die Kontaktstelle auch abends und am Wochenende reagieren kann. Ein einfaches Rufbereitschaftsmodell, bei dem wochenweise zwischen zwei bis drei Personen rotiert wird, reicht für viele mittelständische Unternehmen aus.
Häufige Fehler bei der Erstmeldung
Aus der Praxis lassen sich einige typische Fehler identifizieren, die du vermeiden solltest:
Zu spät melden, weil man erst alles klären will. Die 24-Stunden-Frist beginnt mit der Kenntnisnahme, nicht mit dem Abschluss der Analyse. Melde mit dem, was du weißt, und liefere Details in der 72-Stunden-Bewertung nach.
Fristbeginn falsch berechnen. Die Frist beginnt, wenn die Einrichtung Kenntnis erlangt. Das ist der Zeitpunkt, an dem eine Person mit Entscheidungsbefugnis oder eine zuständige Stelle (z.B. SOC, IT-Leitung) den Vorfall als potenziell erheblich erkennt. Nicht erst, wenn die Geschäftsführung informiert wurde.
Meldung intern endlos abstimmen. Im Ernstfall läuft die Uhr. Eine kurze Freigabe durch die Geschäftsführung ist sinnvoll, aber ein dreistufiger Genehmigungsprozess mit Rechtsabteilung, PR und Vorstand kostet Zeit, die du nicht hast. Kläre diesen Prozess vorher.
Keine Kopie aufbewahren. Sichere immer eine Kopie der übermittelten Meldung mit Zeitstempel. Du brauchst sie für die Folgemeldungen und als Nachweis der fristgerechten Meldung.
DSGVO-Meldung vergessen. Wenn personenbezogene Daten betroffen sind, reicht die BSI-Meldung allein nicht aus. Die Meldung an die Datenschutz-Aufsichtsbehörde läuft über einen eigenen Kanal mit eigenen Fristen (72 Stunden nach DSGVO Art. 33).
Wie ISMS Lite den Meldeprozess unterstützt
Wenn mitten in der Nacht der Pager klingelt, willst du nicht erst Vorlagen suchen und Fristen berechnen. ISMS Lite nimmt dir genau diese mechanische Arbeit ab, damit du dich auf die eigentliche Incident Response konzentrieren kannst.
Incident-Modul mit Live-Countdown
Sobald du in ISMS Lite einen Sicherheitsvorfall anlegst und als potenziell erheblich markierst, starten automatisch drei Countdown-Timer:
- 24h-Timer für die Erstmeldung (Frühwarnung)
- 72h-Timer für die aktualisierte Bewertung
- 30-Tage-Timer für den Abschlussbericht
Die Timer laufen in Echtzeit und sind im Dashboard sofort sichtbar. Wenn eine Frist näher rückt, erhältst du Benachrichtigungen per E-Mail und im System. So behältst du auch dann den Überblick, wenn parallel die technische Aufarbeitung läuft.
KI-generierte Erstmeldung
ISMS Lite kann aus den Vorfallsdaten, die du während der Incident Response ohnehin erfasst, einen Entwurf der BSI-Erstmeldung generieren. Du trägst die bekannten Fakten in strukturierte Felder ein (Art des Vorfalls, betroffene Systeme, Zeitpunkt der Entdeckung, erste Maßnahmen) und das System erstellt daraus einen meldungsfertigen Text, der alle Pflichtfelder abdeckt.
Das spart dir unter Druck die Formulierungsarbeit und stellt sicher, dass kein Pflichtfeld vergessen wird. Du prüfst den Entwurf, passt ihn bei Bedarf an und gibst ihn frei.
Zentrale Dokumentation
Alle Informationen zum Vorfall, von der ersten Erkennung über die Meldungen bis zum Abschlussbericht, liegen an einem Ort. Das erleichtert nicht nur die Folgemeldungen, sondern auch die spätere Aufarbeitung und den Nachweis gegenüber Prüfern, dass der Meldeprozess fristgerecht und vollständig durchlaufen wurde.
Vorbereitung im Normalbetrieb
Auch außerhalb eines aktiven Vorfalls unterstützt dich ISMS Lite bei der Vorbereitung. Die Kontaktdaten der BSI-Meldestelle, der internen Eskalationskette und externer Dienstleister sind im System hinterlegt. Die Meldevorlage ist jederzeit abrufbar. Und mit der integrierten Übungsfunktion kannst du den Meldeprozess regelmäßig testen, ohne dass eine echte Meldung ans BSI geht.
So gehst du jetzt vor
Die NIS2-Meldepflicht ist kein Papiertiger. Die Bußgelder für verspätete oder unterlassene Meldungen können empfindlich ausfallen, und auch die persönliche Haftung der Geschäftsleitung ist ein Thema. Aber die eigentliche Motivation sollte eine andere sein: Ein gut vorbereiteter Meldeprozess ist Teil einer funktionierenden Incident Response. Und die schützt nicht nur vor Bußgeldern, sondern vor den realen Schäden eines Sicherheitsvorfalls.
Deine nächsten Schritte:
- Prüfe, ob dein Unternehmen NIS2-pflichtig ist. Falls ja, stelle sicher, dass die Registrierung beim BSI erfolgt ist und eine Kontaktstelle benannt wurde.
- Bereite die Meldevorlage vor. Nimm die Vorlage aus diesem Artikel als Ausgangspunkt und passe sie an dein Unternehmen an. Drucke sie aus und lege sie offline zugänglich ab.
- Kläre die Zuständigkeiten. Wer entscheidet, wer meldet, wer gibt frei? Schreibe es auf und kommuniziere es im Team.
- Führe einen Testlauf durch. Simuliere einen Vorfall und fülle die Meldung unter Zeitdruck aus.
- Richte die technische Unterstützung ein. Ein Tool wie ISMS Lite mit automatischen Countdowns und Meldevorlagen nimmt dir im Ernstfall die mechanische Arbeit ab.
Weiterführende Artikel
- NIS2-Meldefristen im Überblick: 24h, 72h, 1 Monat – was wann fällig ist
- Sicherheitsvorfall erkennen, bewerten und melden – der komplette Ablauf
- Incident Response Plan erstellen: Vorlage und Praxisbeispiel
- NIS2 für den Mittelstand: Was du wissen musst und was jetzt zu tun ist
- NIS2-Bußgelder: Wer haftet und wie hoch sind die Strafen?
Die 24-Stunden-Frist klingt knapp, ist aber machbar, wenn du vorbereitet bist. Und genau darum geht es: Nicht erst im Ernstfall anfangen zu planen, sondern jetzt die Grundlagen schaffen, damit im Ernstfall alles sitzt.
