Incident Response nach NIS2: Warum KMU jetzt einen IT-Notfall­plan brauchen

Aktualisiert am: 19.08.2026

Ein Incident-Response-Plan regelt, wer bei einem IT-Sicherheits­vorfall was entscheidet und wann gemeldet wird. NIS2 setzt drei Fristen: Frühwarnung ans BSI binnen 24 Stunden, ausführlicher Bericht binnen 72 Stunden, Abschluss­bericht binnen eines Monats. Dieser Beitrag zeigt Melde­kette, Phasenmodelle, typische Fehler und eine Checkliste für KMU.

Was ist Incident Response – und warum reicht ein Backup nicht?

Incident Response (IR) beschreibt den strukturierten Umgang mit IT-Sicherheits­vorfällen: von der Erkennung über die Eindämmung bis zur vollständigen Wiederherstellung und Nachbereitung. Viele KMU verwechseln das mit „wir haben ja Backups“. Doch ein Backup beantwortet keine der Fragen, die das BSI innerhalb von 24 Stunden beantwortet haben will: Was genau ist passiert? Welche Systeme sind betroffen? Welche Daten wurden abgegriffen? Dauert der Angriff noch an?

Ohne einen dokumentierten Prozess stehen Geschäftsführer im Ernstfall vor einem doppelten Problem: Die IT kämpft mit der Wiederherstellung, während gleichzeitig der Meldeprozess ans BSI, die Kommunikation mit Kunden und die Beweissicherung organisiert werden müssen. Unter Zeitdruck passieren dabei die folgenschwersten Fehler.

Die NIS2-Melde­pflichten im Detail

§ 32 BSIG definiert ein dreistufiges Melde­verfahren für erhebliche Sicherheits­vorfälle. „Erheblich“ bedeutet: Der Vorfall hat schwerwiegende Betriebs­störungen verursacht oder kann zu einem finanziellen Schaden führen. Die Schwellen­werte orientieren sich dabei am BSI-Lagebericht und betreffen Ransomware, Datendiebstahl, DDoS mit Geschäfts­ausfall und vergleichbare Szenarien.

Q1 2026: Drei Vorfälle, die zeigen, warum Vorbereitung zählt

Die ersten Monate des Jahres haben geliefert, was Sicherheits­experten seit Langem befürchten: Angriffe, die nicht mit Standard­maßnahmen abgefangen werden können.

DDoS auf die Deutsche Bahn (Februar 2026)

Pro-russische Hacktivisten der Gruppe NoName057(16) legten Buchungs­systeme, App und Anzeige­tafeln lahm. Der Angriff war nicht technisch raffiniert – aber die Auswirkungen waren massiv, weil die Incident-Response-Prozesse auf andere Szenarien ausgelegt waren. Für KMU bedeutet das: Auch „einfache“ Angriffs­formen können das Geschäft lahmlegen, wenn kein Notfall­plan greift.

Signal-Phishing durch russische Staats­hacker (Februar/März 2026)

BSI und Bundes­amt für Verfassungs­schutz warnten im April 2026 gemeinsam vor Phishing-Angriffen über den Messenger Signal. Ziel waren zunächst hochrangige Geheim­dienst­mitarbeiter – doch die Technik ist auf jedes Unternehmen übertragbar. Die Lehre: Ende-zu-Ende-Verschlüsselung schützt nicht vor Social Engineering. Ein Incident-Response-Plan muss auch Kommunikations­kanäle abdecken.

Trivy Supply-Chain-Angriff (März 2026)

75 von 76 Version-Tags des weit verbreiteten Schwachstellen­scanners Trivy wurden kompromittiert. Angreifer stahlen SSH-Keys und Cloud-Credentials über manipulierte Container-Images. Dieser Vorfall zeigt, dass selbst Sicherheits­tools zur Angriffs­fläche werden können. Für KMU, die Open-Source-Komponenten einsetzen, ist ein regelmäßiger Schwachstellen­scan der eigenen Infrastruktur unverzichtbar.

Der Incident-Response-Plan: Fünf Phasen für KMU

Ein IR-Plan muss nicht 200 Seiten haben. Für KMU zählt ein schlanker, erprobter Prozess, der im Ernstfall sofort greift. Die fünf Kern­phasen orientieren sich an ISO 27001 Annex A.5.24–A.5.28 und am BSI-IT-Grundschutz:

Dieselben Schritte nach NIST SP 800-61: sechs Phasen

Das Fünf-Phasen-Mapping oben ordnet die Arbeit den NIS2-Nachweisen zu. Wer den Ablauf feiner schneiden will, nutzt das Modell des NIST Cybersecurity Framework (SP 800-61). Es trennt Beseitigung und Wiederherstellung und passt auch in KMU mit begrenzten Ressourcen.

1. Vorbereitung

Die wichtigste Phase – und die einzige, die vor dem Vorfall stattfindet. Hier wird festgelegt, wer im Ernstfall welche Aufgabe übernimmt, welche Kommunikations­kanäle genutzt werden und welche Tools bereitstehen. Für KMU gehören dazu mindestens ein Incident-Response-Team mit namentlich benannten Verantwort­lichen, ein offline verfügbarer Notfall­kontaktplan und vorbereitete BSI-Melde­formulare.

2. Erkennung und Analyse

Ein Vorfall, der nicht erkannt wird, kann nicht gemeldet werden. Regelmäßige Schwach­stellen­scans und Monitoring bilden die technische Basis. In dieser Phase wird der Vorfall klassifiziert: Handelt es sich um einen Fehlalarm, ein isoliertes Ereignis oder einen erheblichen Sicherheits­vorfall im Sinne von NIS2? Diese Einordnung bestimmt, ob die 24-Stunden-Frist startet.

3. Eindämmung (Containment)

Sobald der Vorfall bestätigt ist, muss die Ausbreitung gestoppt werden. Kurzfristig bedeutet das: betroffene Systeme vom Netz trennen, kompromittierte Zugangsdaten sperren, laterale Bewegung unterbinden. Langfristig: saubere Segmentierung der Netzwerk­bereiche, damit der Angreifer nicht erneut auf kritische Systeme zugreifen kann. Parallel beginnt die forensische Sicherung – Logs, Festplatten­images und Speicher­abbilder müssen beweissicher gesichert werden, bevor Systeme bereinigt werden.

4. Beseitigung (Eradication)

In dieser Phase wird die Ursache des Vorfalls beseitigt: Malware entfernen, Schwach­stellen schließen, kompromittierte Konten zurücksetzen. Wer nur die Symptome behebt und das Einfalls­tor offenlässt, riskiert eine erneute Kompromittierung innerhalb weniger Tage. Eine gründliche Ursachen­analyse ist gleichzeitig die Grundlage für den NIS2-Abschluss­bericht.

5. Wiederherstellung (Recovery)

Systeme werden aus sauberen Backups wiederhergestellt und schrittweise wieder in den Produktiv­betrieb überführt. Dabei ist erhöhte Wachsamkeit geboten: Monitoring intensivieren, alle wieder­hergestellten Systeme auf ver­bleibende Kompromittierung prüfen. Ein Business Continuity Plan definiert, in welcher Reihenfolge Systeme hochgefahren werden.

6. Nachbereitung (Lessons Learned)

Innerhalb von zwei Wochen nach Abschluss der Wieder­herstellung sollte ein strukturiertes Post-Mortem stattfinden. Was wurde erkannt, was nicht? Wo hat der Plan funktioniert, wo gab es Lücken? Die Erkenntnisse fließen in ein aktualisiertes Risiko­register und verbesserte Schutz­maßnahmen ein. Gleichzeitig liefert das Post-Mortem den Inhalt für den NIS2-Abschluss­bericht an das BSI.

Checkliste: Ist Ihr Unternehmen vorbereitet?

Die folgende Checkliste deckt die Mindest­anforderungen ab, die ein KMU für eine NIS2-konforme Incident Response erfüllen sollte. Jeder nicht abgehakte Punkt ist eine potenzielle Compliance-Lücke.

Typische Fehler bei KMU – und wie Sie diese vermeiden

1. Kein dedizierter Ansprech­partner

In vielen KMU ist „die IT“ eine Person, die im Notfall gleichzeitig Systeme wiederherstellen, das BSI informieren und die Geschäftsführung briefen soll. Das funktioniert nicht. Benennen Sie mindestens einen Stellvertreter und legen Sie fest, wer die externe Kommunikation übernimmt.

2. Fehlende Vorab-Registrierung beim BSI

Die Registrierungspflicht nach § 33 BSIG ist seit dem 6. März 2026 in Kraft. Unternehmen, die sich nicht registriert haben, können im Ernstfall nicht ordnungsgemäß melden – und verstoßen damit gleich doppelt gegen das Gesetz.

3. Incident Response nur auf dem Papier

Ein Plan, der nie geübt wurde, versagt im Ernstfall. Tabletop-Übungen – also durchgespielte Szenarien am Konferenz­tisch – kosten wenige Stunden und decken Lücken auf, die in der Theorie nicht sichtbar sind. Das BSI empfiehlt mindestens eine Übung pro Jahr.

4. Keine forensische Beweissicherung

Wer im Panik­modus Systeme neu installiert, zerstört Beweise. Eine einfache Regel hilft: Vor dem Bereinigen immer zuerst ein forensisches Image der betroffenen Systeme erstellen. Das ist auch für den Abschluss­bericht ans BSI und eine mögliche Strafanzeige unverzichtbar.

5. Der Notfall­plan liegt nur digital vor

Der Incident Response Plan liegt als PDF auf dem Datei­server – der bei einem Ransomware-Angriff verschlüsselt ist. Drucken Sie Notfall­kontakte, Eskalations­kette und erste Sofort­maßnahmen aus und hinterlegen Sie sie an mindestens drei physischen Standorten.

6. Die Geschäfts­führung ist nicht in der Melde­kette

NIS2 macht die Geschäfts­führung persönlich verantwortlich. Wenn die Entscheidung über eine BSI-Meldung erst am Montag­morgen im Management-Meeting fällt, ist die 24-Stunden-Frist längst abgelaufen. Binden Sie die Geschäfts­führung in die Melde­kette ein und autorisieren Sie das IR-Team vorab, im Notfall eigenständig zu melden.

Tabletop-Übungen: der Notfall­plan auf dem Prüfstand

Tabletop-Übungen simulieren einen Sicherheits­vorfall am Konferenz­tisch: Geschäfts­führung, IT-Verantwortlicher und gegebenenfalls der externe Dienst­leister spielen ein realistisches Szenario durch – etwa einen Ransomware-Befall an einem Freitag­abend oder einen Phishing-Angriff mit CEO-Fraud.

Diese Übungen decken Lücken auf, die im Dokument unsichtbar bleiben: Wer hat tatsächlich die Berechtigung, Server herunter­zufahren? Ist der Zugang zum BSI-Meldeportal aktuell? Funktioniert der Zugriff auf Offline-Backups? Erfahrungs­gemäß offenbart bereits die erste Übung drei bis fünf kritische Schwach­stellen im Plan.

Externe Unterstützung: Wann lohnt sich ein Dienstleister?

Nicht jedes KMU muss ein eigenes Security Operations Center betreiben. Entscheidend ist, dass die Prozesse stehen und die Zuständigkeiten klar sind. Externe Incident-Response-Retainer – also vorab vereinbarte Bereitschafts­verträge mit IT-Forensik-Dienstleistern – sind für KMU oft die wirtschaftlich sinnvollste Lösung. Der Dienstleister kennt die Umgebung vorab, hat Zugang zu den nötigen Systemen und kann im Ernstfall innerhalb von Stunden reagieren.

Zusätzlich empfiehlt sich ein regelmäßiger externer Schwachstellen­scan, um Angriffs­flächen proaktiv zu identifizieren – bevor sie ausgenutzt werden. Der automatisierte Scan deckt offene Ports, veraltete Software und Fehlkonfigurationen auf, die häufig den Einstiegs­punkt für Ransomware-Gruppen bilden.

Fazit: Vorbereitung entscheidet über das Ergebnis

Ein Ransomware-Angriff um 22:00 Uhr am Freitag wartet nicht auf den nächsten Arbeitstag. Wer dann erst anfängt, Verantwortlich­keiten zu klären und das BSI-Melde­portal zu suchen, hat die 24-Stunden-Frist bereits verloren. Ein dokumentierter, geübter Incident Response Plan ist seit Dezember 2025 gesetzliche Pflicht.

Für KMU muss ein IRP kein 100-seitiges Dokument sein. Entscheidend sind klare Rollen, eine funktionierende Melde­kette, vorbereitete Formulare und jährliche Übungen. In Kombination mit einem ISMS und regelmäßigen Schwach­stellen­scans entsteht ein Sicherheits­niveau, das sowohl dem BSI als auch einer Cyber-Versicherung standhält.

Weiterlesen