Wie Incident-Handling im KMU realistisch aussieht

Stand: 18.09.2026 · ComplyCheck-Redaktion · Keine Rechtsberatung iSd RDG § 2.

Was die Richtlinie konkret verlangt

Art. 21 Abs. 2 lit. b NIS2, in Deutschland § 30 Abs. 2 Nr. 2 BSIG, verpflichtet zur „Bewältigung von Sicherheitsvorfällen". Was Richtlinie und BSIG nicht sagen:

• Keine bestimmten Tools.
• Keine konkreten Reaktions-Zeiten.
• Keine 24/7-Pflicht.

Was die Richtlinie indirekt erwartet, über Art. 21 Abs. 1 (geeignete und verhältnismäßige Maßnahmen unter Berücksichtigung des Stands der Technik, Sicherheitsniveau dem Risiko angemessen) und Art. 23 (Meldekette mit 24h-Frist, in Deutschland § 32 Abs. 1 BSIG: frühe Erstmeldung binnen 24 Stunden und Meldung binnen 72 Stunden nach Kenntniserlangung, Abschlussmeldung spätestens einen Monat nach der 72-Stunden-Meldung):

• Ein dokumentierter, geprobter Prozess.
• Klare Rollen und Eskalations-Wege.
• Detection-Fähigkeit, die zumindest häufige Vorfälle erkennt.
• 24h-Frist-Einhaltung, was bedeutet, dass die Triage-Fähigkeit auch außerhalb der Geschäfts-Zeiten greifen muss.

Die sechs Phasen des Incident-Handlings

Die folgende Sechs-Phasen-Gliederung ist in der Praxis verbreitet und eignet sich als Aufbau für ein Playbook. Die aktuelle NIST SP 800-61 Rev. 3 (April 2025) folgt nicht mehr einem eigenen Phasenmodell, sondern ordnet Incident Response den Funktionen des NIST Cybersecurity Framework 2.0 zu (Govern, Identify, Protect, Detect, Respond, Recover).

Phase 1: Vorbereitung

Maßnahmen, die vor dem ersten Vorfall stehen:

• Incident-Response-Playbook mit Rollen und Eskalations-Pfaden.
• Eskalations-Matrix mit Erreichbarkeit (Telefon, E-Mail, Backup).
• BSI-Meldeportal-Zugang vorbereitet und getestet.
• Notfall-Kommunikations-Kanäle (Out-of-Band, wenn Office-365 kompromittiert sein könnte).
• Pre-Approved-Lieferanten (Forensiker, Krisen-Kommunikation, Rechtsbeistand) mit Rahmen-Verträgen.
• Backup-Strategie + getestete Recovery-Verfahren.

Phase 2: Detection

Erkennen, dass etwas nicht stimmt:

• EDR-Lösung auf allen Endpunkten (Microsoft Defender, CrowdStrike, SentinelOne, Sophos Intercept X, …). Diese generieren die meisten Initial-Alerts.
• Cloud-SIEM-Light für Mail, Identitäts-Plattform, Cloud-Drives, viele Vorfälle werden im Identitäts-Layer zuerst sichtbar (Impossible Travel, Mass-Download, ungewöhnliche OAuth-Zustimmungen).
• Hinweise aus extern: Kunden-Beschwerden, Lieferanten-Warnungen, ISP-Meldungen.
• CSIRT-Warnungen von BSI/CERT-Bund, KMU sollten zumindest die freien Warn-Newsletter abonnieren.

Phase 3: Eindämmung

Den laufenden Schaden begrenzen:

• Konto-Sperren bei kompromittierten Identitäten.
• Endpunkt-Isolierung über EDR.
• Netz-Segmentierung aktivieren bei Ausbreitung.
• Externe Verbindungen kappen (Firewall-Block, VPN-Pause).

Triage-Faustregel: erst eindämmen, dann analysieren. Forensik kann am isolierten System weiter laufen.

Phase 4: Bereinigung

Den Angreifer aus dem System entfernen:

• Kompromittierte Systeme neu installiert oder vom letzten sauberen Backup wiederhergestellt.
• Persistenz-Mechanismen (Scheduled Tasks, Services, Cron-Jobs) entfernt.
• Kompromittierte Credentials rotiert.
• Falls relevant: Hash-Wechsel im AD/Entra ID, KRBTGT-Reset.

Phase 5: Wiederherstellung

Den Geschäfts-Betrieb wieder hochfahren:

• Systeme schrittweise zurück in Produktion.
• Monitoring intensiviert für die ersten Tage.
• Kunden-Information, wenn die Geschäfts-Beziehung betroffen war.

Phase 6: Lessons Learned

Den Vorfall systematisch auswerten:

• Was war die Root Cause?
• Welche Detections haben gegriffen, welche nicht?
• Welche Maßnahmen verhindern eine Wiederholung?
• Update des Playbooks, der Detection-Regeln, der Schulungs-Inhalte.

Diese Phase wird leicht übersprungen, obwohl sie zeigt, ob die Organisation aus Vorfällen lernt.

Tooling für 50-200 Mitarbeitende: was reicht

Drei Tool-Klassen sind mittelstandstauglich und decken einen großen Teil der Detection-Anforderungen ab:

Tool-Klasse 1: EDR

Microsoft Defender for Business (in Microsoft 365 Business Premium enthalten, auch einzeln lizenzierbar), CrowdStrike Falcon Go, SentinelOne Singularity, Sophos Intercept X. Kosten: Endpunkte × Preis je Endpunkt und Monat laut Preisliste bzw. Angebot. Liefert einen Großteil der relevanten Alerts.

Tool-Klasse 2: Cloud-SIEM-Light / XDR

Microsoft Defender XDR, Crowdstrike Falcon Insight, SentinelOne Singularity XDR. Korreliert EDR-Daten mit Cloud-Identitäts-Events und Mail-Events. Wesentlich für die Detection von Identitäts-Kompromittierungen.

Tool-Klasse 3: Bereitschafts-Dienst (Managed Detection & Response)

Wer kein eigenes 24/7-SOC betreiben kann (typisch für 50-200-MA-Unternehmen), nimmt ein Managed Detection & Response (MDR)-Angebot: externer Dienstleister monitort die Alerts 24/7 und löst Eskalationen aus. Kosten: Endpunkte × MDR-Preis je Endpunkt und Monat laut Angebot, zusätzlich zur EDR-Lizenz. Anbieter: alle EDR-Hersteller bieten MDR-Tier, plus spezialisierte Dienstleister.

Alternative für sehr kleine Setups: Bereitschafts-Telefon im IT-Team mit klaren Eskalations-Regeln. Funktioniert, hat aber höhere Latenz als ein MDR.

Vier Templates als Grundausstattung

Template 1: Incident-Response-Playbook

Ein Dokument von 15-30 Seiten mit:

• Definition was als „Incident" gilt vs. was als „Event".
• Schweregrade (z.B. P1 Krise, P2 Hoch, P3 Mittel, P4 Niedrig).
• Eskalations-Matrix mit Rollen und Erreichbarkeit.
• Phase-spezifische Aktivitäten und Verantwortliche.
• Meldekette-Trigger (ab welchem Schweregrad ans BSI).
• Vorlagen für interne und externe Kommunikation.
• Liste der Pre-Approved-Lieferanten.

Template 2: Eskalations-Matrix

Eine Tabelle: wer macht was, wann, wie erreichbar:

Template 3: Erst-Reaktions-Checkliste

Eine ein-seitige Checkliste für die ersten 60 Minuten:

• Verdacht dokumentieren (was, wann, wo, wer hat es gemeldet).
• Schweregrad initial schätzen.
• Eskalations-Matrix aktivieren.
• Detection-Daten sammeln (EDR-Alerts, Logs, Auffälligkeiten).
• Eindämmungs-Maßnahmen entscheiden (Konto sperren, Endpoint isolieren, Netz trennen).
• Forensik-Sicherung starten (RAM-Dump, Image, Logs).
• Meldekette-Trigger prüfen (ist das ein erheblicher Vorfall iSd Art. 23?).

Template 4: Meldekette-Mustertexte

Mustertexte für die drei fristgebundenen Meldungen nach § 32 Abs. 1 BSIG (frühe Erstmeldung, Meldung, Abschlussmeldung), ergänzt um Vorlagen für die Zwischenmeldung auf Ersuchen des BSI (Nr. 3) und die Fortschrittsmeldung bei noch andauerndem Vorfall (§ 32 Abs. 2). Inhalte siehe Artikel „Welche Fristen gelten bei NIS2-Incident-Meldungen?".

Tabletop-Übungen: was sie leisten

Tabletop-Übungen sind moderierte Diskussions-Simulationen anhand eines konkreten Szenarios. Sie testen Prozesse, nicht Technik.

Beispiel-Szenarien:

• Ransomware: Mitarbeiter meldet, dass mehrere Dateien plötzlich „.locked"-Endung haben. EDR-Alert über Verschlüsselungs-Aktivität.
• BEC: Buchhaltung meldet eine ungewöhnliche Überweisungs-Anfrage des Geschäfts-Führers.
• Lieferanten-Vorfall: Ein wichtiger Cloud-Lieferant meldet einen Daten-Abfluss.
• OT-Vorfall: Bei einem Maschinenbauer fällt eine Produktions-Linie aus, IT-Team vermutet Cyber-Angriff.

Frequenz: NIS2 und BSIG schreiben keine Übungsfrequenz vor. Eine mindestens jährliche Übung ist eine sinnvolle Empfehlung, bei höherem Risikoprofil auch häufiger. Ergebnis-Dokumentation: Findings + Maßnahmen mit Fristen; sie belegt gegenüber dem BSI, dass die Maßnahmen nach § 30 BSIG gelebt werden.

FAQ

Brauchen wir ein 24/7-SOC, um NIS2-konform zu sein?

Nicht zwingend. Die Richtlinie verlangt geeignete und verhältnismäßige Maßnahmen; für die meisten KMU reicht eine Kombination aus EDR, Cloud-SIEM-Light und einem Bereitschafts-Dienst oder MDR-Vertrag. Ob sich ein eigenes 24/7-SOC rechnet, hängt von Endpunktzahl, Risikoprofil und Personal ab. Wichtig ist, dass die frühe Erstmeldung binnen 24 Stunden nach § 32 Abs. 1 Satz 1 Nr. 1 BSIG (Art. 23 Abs. 4 lit. a NIS2) auch nachts und am Wochenende erfüllbar bleibt.

Wie aktuell muss das Incident-Response-Playbook sein?

Mindestens jährlich überprüfen und bei wesentlichen Änderungen aktualisieren. Wesentliche Änderungen sind: neue Schweregrad-Definitionen, neue Lieferanten-Beziehungen, neue regulatorische Anforderungen, geänderte Eskalations-Wege durch Organisations-Änderungen. Das Datum der letzten Überprüfung gehört deshalb sichtbar ins Dokument.

Was, wenn ein Vorfall die eigene Kommunikations-Infrastruktur betrifft?

Hier sind Out-of-Band-Kanäle essenziell. Wenn Microsoft 365 kompromittiert ist, kann das Incident-Team nicht per Outlook kommunizieren. Empfehlung: WhatsApp-Gruppe, separate Mobile-Nummern, Signal-Gruppe, vorab eingerichtet, regelmäßig getestet.

Ist ein Tabletop ohne externe Moderation ausreichend?

Initial ja, der erste Tabletop kann intern moderiert werden. Ab dem zweiten Jahr ist eine externe Moderation empfehlenswert, weil sie unbequeme Fragen stellt und Betriebs-Blindheit aufdeckt. Externe Moderation bieten viele IT-Sicherheits-Dienstleister an; die Kosten ergeben sich aus Moderationstagen × Tagessatz laut Angebot.

Wie tief muss die Forensik bei einem KMU-Vorfall gehen?

Tief genug, um Root Cause, Ausmaß und Persistenz zu verstehen, nicht zwingend, um den Angreifer zu identifizieren. Praktisch heißt das: RAM-Image und Disk-Image der kompromittierten Systeme sichern, relevante Logs sammeln, Persistenz-Mechanismen ausschließen. Für KMU ist es oft sinnvoll, einen externen Forensik-Dienstleister mit Rahmen-Vertrag zu haben: Konditionen und Reaktionszeiten sind dann vorab geklärt und müssen nicht mitten im Vorfall verhandelt werden.