Ein Ransomware-Angriff trifft Freitagabend um 17:30 Uhr. Das Telefon des IT-Administrators klingelt. Niemand weiß, wen man anrufen soll, was getrennt werden muss oder was den Behörden zu melden ist. Bis Montag hat sich der Schaden vervielfacht, weil jede Stunde der Untätigkeit eine laterale Ausbreitung im Netzwerk ermöglichte.
Dieses Szenario wiederholt sich jede Woche in europäischen KMU. Die Organisationen, die mit minimalem Schaden davonkommen, sind nicht die mit den teuersten Tools — es sind die mit einem Plan.
Warum die meisten KMU keinen Plan haben
Der häufigste Grund ist die Annahme, dass Incident-Response-Planung etwas für Großunternehmen ist. Der zweithäufigste Grund: Man weiß nicht, wo man anfangen soll. Beide Probleme sind lösbar.
NIS2 verlangt für betroffene Unternehmen eine Erstmeldung innerhalb von 24 Stunden an das BSI. Ohne einen vorbereiteten Reaktionsprozess ist die Einhaltung dieser Frist nahezu unmöglich. Aber auch jenseits regulatorischer Anforderungen ist der Business Case klar: Organisationen mit getesteten Incident-Response-Plänen dämmen Sicherheitsverletzungen laut IBMs Cost of a Data Breach Report im Schnitt 74 Tage schneller ein.
Der minimale Incident-Response-Plan
Sie brauchen kein 200-seitiges Dokument. Sie brauchen Antworten auf sechs Fragen — schriftlich, offline zugänglich und vierteljährlich überprüft.
1. Wer entscheidet?
Definieren Sie einen Incident-Response-Verantwortlichen — typischerweise der IT-Manager oder ein externer Sicherheitspartner. Legen Sie fest, wer kritische Entscheidungen autorisiert: Systeme trennen, externe Forensik beauftragen, Kunden benachrichtigen. Während eines aktiven Vorfalls muss die Entscheidungsbefugnis klar und vorab delegiert sein.
2. Wen rufen wir an?
Pflegen Sie eine physische (gedruckte) Kontaktliste:
- Interner Incident-Response-Verantwortlicher
- Externer IT-Sicherheitspartner oder MSSP
- Rechtsanwalt mit Datenschutz-Expertise
- Cyber-Versicherung — Schadenhotline
- BSI-Meldestelle (für NIS2-regulierte Unternehmen)
- Landesdatenschutzbeauftragte (für DSGVO-meldepflichtige Vorfälle)
Während eines Vorfalls können E-Mail und interne Chatsysteme kompromittiert sein. Telefonnummern und Out-of-Band-Kommunikationskanäle müssen vorab dokumentiert sein.
3. Was trennen wir?
Identifizieren Sie vorab, welche Systeme isoliert werden können, ohne den Geschäftsbetrieb vollständig zu stoppen. Kennen Sie Ihre Netzwerksegmentierungspunkte. Wissen Sie, wie Sie externen VPN-Zugriff deaktivieren, OAuth-Tokens widerrufen und alle M365-Sitzungen erzwungen beenden. Das sind keine Entscheidungen, die Sie zum ersten Mal unter Druck treffen wollen.
4. Was sichern wir?
Beweissicherung ist entscheidend für forensische Analyse und rechtliche Verfahren. Spielen Sie keine Rechner neu auf, bevor forensische Images erstellt wurden. Löschen Sie keine Logs. Ändern Sie keine Passwörter kompromittierter Konten, bevor die Anmeldeprotokolle und Audit-Trails gesichert sind. Dokumentieren Sie jede Maßnahme ab dem Moment der Entdeckung.
5. Wen benachrichtigen wir?
Die DSGVO verlangt eine Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden, wenn personenbezogene Daten betroffen sind. NIS2 verlangt eine Meldung innerhalb von 24 Stunden bei erheblichen Vorfällen. Ihr Plan sollte vorformulierte Meldevorlagen enthalten, in die nur noch vorfallspezifische Details eingetragen werden.
6. Wie stellen wir wieder her?
Definieren Sie die Wiederherstellungsreihenfolge: Welche Systeme gehen zuerst online, wie überprüfen Sie deren Integrität, und welche Kriterien gelten für die Entwarnung? Testen Sie Ihren Backup-Wiederherstellungsprozess, bevor Sie ihn brauchen — der schlechteste Zeitpunkt, um festzustellen, dass Ihre Backups korrupt sind, ist während der Wiederherstellung nach einem Ransomware-Angriff.
Den Plan testen
Ein ungetesteter Plan ist eine Hypothese. Führen Sie jährlich eine Tabletop-Übung durch: Versammeln Sie das Response-Team, präsentieren Sie ein Szenario und gehen Sie die Reaktion Schritt für Schritt durch. Sie werden Lücken finden. Genau das ist der Sinn.
Die Übung muss nicht aufwendig sein. Zwei Stunden, ein realistisches Szenario und eine ehrliche Diskussion darüber, was tatsächlich passieren würde, reichen aus. Dokumentieren Sie die Erkenntnisse und aktualisieren Sie den Plan.
Der M365-Bezug
Ihr Microsoft 365-Tenant ist sowohl der wahrscheinlichste Angriffsvektor als auch die wichtigste Beweisquelle. Die Aufbewahrung von Audit-Logs (90 Tage Standard in E3, 180 Tage in E5) bestimmt, wie weit Sie zurückermitteln können. Wenn Sie Business Premium mit 30 Tagen Aufbewahrung nutzen, prüfen Sie, ob das für Ihr Risikoprofil ausreicht.
Conditional Access-Logs, Anmeldeprotokolle und Unified Audit Logs enthalten die forensischen Daten, die Sie benötigen. Stellen Sie sicher, dass sie aktiviert, zugänglich und von mindestens einer Person in Ihrer Organisation lesbar sind.
Beratung buchen, um einen auf Ihre Organisation und M365-Umgebung zugeschnittenen Incident-Response-Plan zu erstellen.