Wie Incident-Handling im KMU realistisch aussieht

Stand: 2026-05-16 · ComplyCheck-Redaktion · Keine Rechtsberatung iSd RDG § 2.

Was die Richtlinie konkret verlangt

Art. 21 Abs. 2 Lit. b NIS2 verpflichtet zur „Bewältigung von Sicherheits-Vorfällen". Was die Richtlinie nicht sagt:

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

Was die Richtlinie indirekt erwartet — über Art. 21 Abs. 1 („Stand der Technik, verhältnismäßig zum Risiko") und Art. 23 (Meldekette mit 24h-Frist):

• 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 Phasen-Struktur ist seit den 90er Jahren etabliert und in NIST SP 800-61r3, BSI-IT-Grundschutz und ENISA-Empfehlungen weitgehend einheitlich:

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 häufig übersprungen — und ist im Audit oft das, was am meisten zum Reife-Grad sagt.

Tooling für 50-200 Mitarbeitende — was reicht

Drei Tool-Klassen sind Mittelstand-tauglich und decken 80 % der Detection-Anforderungen:

Tool-Klasse 1 — EDR

Microsoft Defender for Business (im M365-Bundle), CrowdStrike Falcon Go, SentinelOne Singularity, Sophos Intercept X. Kosten: 5-15 Euro pro Endpunkt und Monat. Liefert die Mehrzahl der relevanten Alerts.

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

Microsoft Defender XDR (im M365 Business Premium enthalten), Crowdstrike Falcon Insight, SentinelOne Singularity XDR. Korrelliert 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: 15-40 Euro pro Endpunkt pro Monat zusätzlich. 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, die 80 % abdecken

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

Drei Mustertexte für die drei NIS2-Meldestufen. 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: mindestens jährlich, bei kritischen Sektoren halbjährlich. Ergebnis-Dokumentation: Findings + Maßnahmen mit Fristen. Audit-relevant.

FAQ

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

Nicht zwingend. Die Richtlinie fordert „verhältnismäßig zum Risiko" — für die meisten KMU reicht eine Kombination aus EDR, Cloud-SIEM-Light und einem Bereitschafts-Dienst oder MDR-Vertrag. Ein eigenes 24/7-SOC ist erst ab 500+ Endpunkten oder besonderen Risiko-Profilen wirtschaftlich. Wichtig ist, dass die 24h-Meldepflicht aus Art. 23 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. Im Audit ist das letzte Update-Datum eine Standard-Stichprobe.

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. Bei einigen Krankenhaus-Vorfällen 2024 hat genau das den Unterschied gemacht zwischen 4 und 14 Tagen Wiederanlauf.

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 Moderatoren bieten viele IT-Sicherheits-Dienstleister an, Kosten typischerweise 2.000-5.000 Euro pro Tag.

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 — die Stundensätze sind im akuten Fall ohne Vorab-Vertrag deutlich höher.