- NIS2 verlangt Erstmeldung innerhalb von 24 Stunden und vollständige Meldung innerhalb von 72 Stunden. Ohne dokumentierte Richtlinie schaffst du diese Fristen nicht.
- Die Richtlinie muss die vier Phasen abdecken: Vorbereitung, Erkennung und Analyse, Eindämmung und Beseitigung, Nachbereitung.
- Klare Eskalationsstufen und Entscheidungsbefugnisse sind entscheidend. Im Ernstfall darf es keine Diskussion darüber geben, wer was entscheiden darf.
- Kommunikation nach innen und außen muss vorab geregelt sein: Wer informiert Kunden, Behörden, Presse? Wer gibt technische Details frei?
- Lessons Learned nach jedem Vorfall sind Pflicht. Ohne systematische Nachbereitung wiederholen sich dieselben Fehler.
Warum du eine Incident-Response-Richtlinie brauchst
Sicherheitsvorfälle sind keine Frage des Ob, sondern des Wann. Jedes Unternehmen, das IT nutzt, wird früher oder später mit einem Vorfall konfrontiert: Ransomware, Phishing-Angriff, Datenleck, kompromittierte Zugangsdaten, DDoS-Attacke oder ein simpler menschlicher Fehler, der sensible Daten exponiert.
Der Unterschied zwischen einem beherrschbaren Vorfall und einer Katastrophe liegt selten an der Technik. Er liegt an der Vorbereitung. Unternehmen, die einen dokumentierten, eingeübten Prozess für Sicherheitsvorfälle haben, reagieren schneller, koordinierter und mit weniger Schaden als solche, die im Ernstfall improvisieren müssen.
Die Incident-Response-Richtlinie ist dieses Dokument. Sie definiert, was ein Sicherheitsvorfall ist, wer in welcher Rolle handelt, welche Schritte in welcher Reihenfolge ablaufen, wann und an wen eskaliert wird, welche Meldepflichten bestehen und wie die Nachbereitung sicherstellt, dass das Unternehmen aus dem Vorfall lernt.
Aus Compliance-Sicht ist die Richtlinie ebenfalls unverzichtbar. ISO 27001 widmet dem Thema gleich mehrere Controls: A.5.24 (Incident Management Planning), A.5.25 (Assessment of Information Security Events), A.5.26 (Response to Information Security Incidents) und A.5.27 (Learning from Information Security Incidents). NIS2 geht mit den Meldefristen in Artikel 23 noch weiter und setzt enge Zeitfenster, die ohne vorbereitete Prozesse kaum einzuhalten sind.
Die vier Phasen der Incident Response
Das international anerkannte Framework für Incident Response stammt vom NIST (SP 800-61) und unterteilt den Prozess in vier Phasen. Deine Richtlinie sollte alle vier Phasen adressieren.
Phase 1: Vorbereitung
Die Vorbereitung findet vor dem Vorfall statt und bildet das Fundament für alles Weitere. In der Richtlinie definierst du hier:
Incident-Response-Team (IRT): Wer gehört zum Team? Typischerweise IT-Leitung, Systemadministratoren, ISB, Datenschutzbeauftragter, Geschäftsführung, Kommunikation/PR und bei Bedarf externe Spezialisten (Forensik-Dienstleister, Rechtsanwalt). Jedes Mitglied hat eine definierte Rolle und einen Stellvertreter.
Erreichbarkeit: Kontaktlisten mit aktuellen Telefonnummern, E-Mail-Adressen und alternativen Kommunikationskanälen (was, wenn die E-Mail kompromittiert ist?). Die Kontaktliste muss auch offline verfügbar sein, ausgedruckt und an einem bekannten Ort hinterlegt.
Werkzeuge und Infrastruktur: Welche technischen Werkzeuge stehen für die Analyse zur Verfügung? Forensik-Software, Log-Analyse-Tools, isolierte Untersuchungsumgebung, sichere Kommunikationskanäle für das IRT.
Verträge mit externen Dienstleistern: Wenn dein Unternehmen keine eigene Forensik-Kapazität hat (was bei den meisten Mittelständlern der Fall ist), muss vorab ein Rahmenvertrag mit einem spezialisierten Dienstleister bestehen. Im Ernstfall hast du keine Zeit, Angebote einzuholen und Verträge zu verhandeln.
Übungen: Die Richtlinie legt fest, dass das IRT regelmäßig übt. Tabletop-Übungen (Planspiele) mindestens jährlich, praktische Übungen bei Bedarf. Nur ein Team, das geübt hat, funktioniert unter Druck.
Phase 2: Erkennung und Analyse
Nicht jede Anomalie ist ein Sicherheitsvorfall, und nicht jeder Sicherheitsvorfall ist eine Krise. Die Richtlinie muss definieren, wie Ereignisse erkannt, bewertet und klassifiziert werden.
Definition: Was ist ein Sicherheitsvorfall? Die Richtlinie braucht eine klare Definition. Ein Sicherheitsvorfall ist jedes Ereignis, das die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen oder Informationssystemen tatsächlich oder potenziell beeinträchtigt. Dazu gehören erfolgreiche und versuchte Angriffe, technische Ausfälle mit Sicherheitsrelevanz und menschliche Fehler mit Datenexposition.
Erkennungsquellen: Woher kommen die Meldungen? SIEM-Alarme, Antivirus-Warnungen, Firewall-Logs, Meldungen von Mitarbeitenden, Hinweise von Kunden oder Partnern, Berichte von externen Sicherheitsforschern, Informationen von CERTs. Die Richtlinie muss sicherstellen, dass alle diese Quellen in den Incident-Response-Prozess einfließen.
Meldeweg für Mitarbeitende: Jeder Mitarbeitende muss wissen, wie und an wen ein verdächtiges Ereignis gemeldet wird. Die Hemmschwelle muss niedrig sein: Lieber zehn Fehlalarme als ein übersehener Vorfall. Die Richtlinie definiert einen einfachen Meldeweg (E-Mail-Adresse, Telefonnummer, Ticketsystem) und stellt klar, dass Meldungen erwünscht sind und nicht zu negativen Konsequenzen führen.
Klassifizierung: Die Richtlinie definiert Schweregrade, die bestimmen, welche Eskalationsstufe und welche Reaktionszeit gilt.
| Schweregrad | Beschreibung | Beispiel | Reaktionszeit |
|---|---|---|---|
| Kritisch | Akute Bedrohung der Geschäftstätigkeit oder Datenverlust großen Ausmaßes | Ransomware-Befall, großflächiger Datenabfluss | Sofort, IRT-Aktivierung innerhalb 1 Stunde |
| Hoch | Erhebliche Beeinträchtigung oder Kompromittierung sensibler Daten | Kompromittiertes Admin-Konto, gezielter Angriff | IRT-Aktivierung innerhalb 4 Stunden |
| Mittel | Begrenzte Auswirkung, lokale Beeinträchtigung | Malware auf einzelnem Arbeitsplatz, Phishing-Erfolg ohne Datenabfluss | Bearbeitung am selben Arbeitstag |
| Niedrig | Geringfügig, keine unmittelbare Gefahr | Verdächtiger Login-Versuch, Spam mit Malware-Anhang (geblockt) | Bearbeitung innerhalb 72 Stunden |
Die Erstbewertung erfolgt durch die Person, die den Vorfall als Erste bearbeitet (First Responder). Die endgültige Klassifizierung nimmt das IRT vor und kann im Laufe der Analyse nach oben oder unten korrigiert werden.
Phase 3: Eindämmung, Beseitigung und Wiederherstellung
Sobald ein Vorfall bestätigt und klassifiziert ist, beginnt die aktive Reaktion. Die Richtlinie muss die grundsätzlichen Handlungsprinzipien festlegen, nicht die technischen Details jedes denkbaren Szenarios.
Eindämmung (Containment): Ziel ist, die Ausbreitung des Vorfalls zu stoppen, ohne dabei mehr Schaden zu verursachen. Die Richtlinie unterscheidet zwischen kurzfristiger Eindämmung (z.B. betroffenes System vom Netzwerk isolieren) und langfristiger Eindämmung (z.B. temporäre Firewall-Regeln, bis die Ursache beseitigt ist).
Wichtig: Die Richtlinie muss regeln, wer die Entscheidung trifft, ein System vom Netzwerk zu nehmen. Wenn ein Produktionssystem betroffen ist, hat diese Entscheidung unmittelbare geschäftliche Auswirkungen. Die Richtlinie legt fest, dass der IRT-Leiter in Abstimmung mit der Geschäftsführung diese Entscheidung trifft, und definiert einen beschleunigten Entscheidungsweg für den Fall, dass die Geschäftsführung nicht erreichbar ist.
Beweissicherung: Bevor du mit der Beseitigung anfängst, muss die Beweislage gesichert werden. Forensische Kopien betroffener Systeme, Logs sichern, Zeitstempel dokumentieren. Die Richtlinie muss betonen, dass die Beweissicherung vor der Bereinigung kommt, nicht umgekehrt. Wer ein kompromittiertes System sofort neu aufsetzt, vernichtet möglicherweise Beweise, die für die Ursachenanalyse, für Behörden oder für Versicherungsansprüche benötigt werden.
Beseitigung (Eradication): Die Ursache des Vorfalls wird identifiziert und entfernt. Malware wird bereinigt, kompromittierte Zugangsdaten werden zurückgesetzt, Schwachstellen werden gepatcht, unautorisierte Zugänge werden geschlossen.
Wiederherstellung (Recovery): Betroffene Systeme werden in den Normalbetrieb überführt. Die Richtlinie legt fest, dass die Wiederherstellung schrittweise erfolgt und dass die Systeme nach der Rückkehr in den Betrieb verstärkt überwacht werden, um sicherzustellen, dass der Angreifer keinen verborgenen Zugang hinterlassen hat.
Phase 4: Nachbereitung (Lessons Learned)
Die Nachbereitung ist die Phase, die am häufigsten übersprungen wird, obwohl sie für die langfristige Sicherheit am wertvollsten ist. Die Richtlinie muss sie als Pflicht definieren, nicht als optionalen Anhang.
Post-Incident-Review: Innerhalb von zwei Wochen nach Abschluss des Vorfalls führt das IRT einen strukturierten Review durch. Was ist passiert? Wann wurde der Vorfall erkannt? Wie schnell wurde reagiert? Was hat gut funktioniert? Was nicht? Welche Maßnahmen verhindern, dass der gleiche Vorfall erneut eintritt?
Dokumentation: Der gesamte Vorfall wird lückenlos dokumentiert: Zeitstrahl, beteiligte Personen, getroffene Entscheidungen, technische Analyse, Auswirkungen, eingeleitete Maßnahmen. Diese Dokumentation dient als Nachweis gegenüber Auditoren und Behörden.
Maßnahmenplan: Aus dem Review entstehen konkrete Verbesserungsmaßnahmen mit Verantwortlichen und Fristen. Die Umsetzung wird nachverfolgt.
Meldepflichten: NIS2 und DSGVO
Die Incident-Response-Richtlinie muss die gesetzlichen Meldepflichten konkret abbilden, denn die Fristen sind eng und lassen keinen Spielraum für Improvisation.
NIS2-Meldefristen
NIS2 Artikel 23 definiert ein dreistufiges Meldeverfahren an das BSI:
Erstmeldung innerhalb von 24 Stunden nach Kenntniserlangung eines erheblichen Sicherheitsvorfalls. Die Erstmeldung muss keine vollständige Analyse enthalten, aber mindestens eine erste Einschätzung des Vorfalls und seiner möglichen grenzüberschreitenden Auswirkungen.
Folgemeldung innerhalb von 72 Stunden mit einer ersten Bewertung des Vorfalls, seiner Schwere und Auswirkungen sowie gegebenenfalls der Kompromittierungsindikatoren (Indicators of Compromise).
Abschlussmeldung innerhalb eines Monats mit einer detaillierten Beschreibung des Vorfalls, der Ursachen, der getroffenen Maßnahmen und der grenzüberschreitenden Auswirkungen.
DSGVO-Meldepflicht
Wenn personenbezogene Daten betroffen sind, greift zusätzlich Artikel 33 DSGVO: Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden. Artikel 34 kann eine Benachrichtigung der betroffenen Personen erfordern, wenn ein hohes Risiko für deren Rechte und Freiheiten besteht.
Was die Richtlinie regeln muss
Die Richtlinie muss festlegen, wer die Entscheidung über eine Meldung trifft (typischerweise ISB plus Datenschutzbeauftragter plus Geschäftsführung), wer die Meldung technisch durchführt, welche Informationen zusammengetragen werden müssen und wo die Meldewege dokumentiert sind. Vorbereitete Meldeformulare und Textbausteine beschleunigen den Prozess erheblich.
Besonders wichtig: Die Richtlinie muss klarstellen, dass die 24-Stunden-Frist ab Kenntniserlangung gilt, nicht ab Abschluss der Analyse. Du meldest also auch dann, wenn du noch nicht genau weißt, was passiert ist.
Kommunikation im Vorfall
Ein Sicherheitsvorfall ist nicht nur ein technisches, sondern auch ein kommunikatives Ereignis. Die Richtlinie muss die Kommunikationswege vorab definieren.
Interne Kommunikation: Wer informiert die Geschäftsführung? Wie werden betroffene Abteilungen informiert? Über welchen Kanal, wenn die üblichen Kommunikationssysteme kompromittiert sind? Die Richtlinie sollte einen alternativen Kommunikationskanal definieren (z.B. Mobiltelefone, separater Messenger-Dienst), der auch bei einem Ausfall der internen IT funktioniert.
Kommunikation mit Kunden und Partnern: Wenn Kunden oder Geschäftspartner betroffen sind, müssen sie informiert werden. Die Richtlinie legt fest, wer diese Kommunikation verantwortet (typischerweise Geschäftsführung oder Kommunikationsabteilung, nicht die IT), welche Informationen geteilt werden dürfen und welchen Freigabeprozess eine solche Mitteilung durchläuft.
Presse und Öffentlichkeit: Bei schwerwiegenden Vorfällen kann das Medieninteresse groß sein. Die Richtlinie definiert, wer gegenüber der Presse auskunftsberechtigt ist (in der Regel nur die Geschäftsführung oder eine benannte Pressesprecherin) und dass technische Details nicht ohne Freigabe des IRT kommuniziert werden.
Behördenkommunikation: Neben den Meldepflichten kann es notwendig sein, mit Strafverfolgungsbehörden (Polizei, BKA, ZAC) zusammenzuarbeiten. Die Richtlinie legt fest, wer die Entscheidung über eine Strafanzeige trifft und wer die Kommunikation mit den Behörden führt.
Abgrenzung zu verwandten Dokumenten
Die Incident-Response-Richtlinie steht nicht allein. Sie ist eingebettet in ein Netz verwandter Dokumente, und die Richtlinie sollte die Abgrenzung klar definieren:
Incident-Response-Plan: Während die Richtlinie die Grundsätze und den Rahmen definiert, enthält der Plan die operativen Details: Schritt-für-Schritt-Anleitungen für bestimmte Szenarien (Ransomware, Datenleck, DDoS), technische Runbooks und Checklisten.
Business-Continuity-Plan (BCP): Der BCP regelt die Aufrechterhaltung des Geschäftsbetriebs bei größeren Störungen. Die Incident-Response-Richtlinie definiert, wann der Übergang vom Incident Response zum Business Continuity Management erfolgt.
Notfallhandbuch: Das Notfallhandbuch enthält operative Anweisungen für den IT-Notfall. Es ist detaillierter und praxisnäher als die Richtlinie und wird vom IRT im Ernstfall als Arbeitsdokument genutzt.
Kommunikationsplan: Regelt die Details der internen und externen Kommunikation bei Vorfällen. Die Richtlinie verweist darauf, der Kommunikationsplan enthält die Textvorlagen und Verteiler.
Beispielgliederung für eine Incident-Response-Richtlinie
- Zweck und Geltungsbereich
- Begriffe und Definitionen - Sicherheitsereignis vs. Sicherheitsvorfall, IRT, Schweregrade
- Normative Grundlagen - ISO 27001 A.5.24-A.5.27, NIS2 Art. 23, DSGVO Art. 33/34
- Incident-Response-Team - Zusammensetzung, Rollen, Stellvertreter, Erreichbarkeit
- Phase 1: Vorbereitung - Werkzeuge, Verträge, Übungen
- Phase 2: Erkennung und Analyse - Erkennungsquellen, Meldewege, Klassifizierung
- Phase 3: Eindämmung, Beseitigung, Wiederherstellung - Grundsätze, Entscheidungsbefugnisse, Beweissicherung
- Phase 4: Nachbereitung - Post-Incident-Review, Dokumentation, Maßnahmenplan
- Meldepflichten - NIS2-Fristen, DSGVO-Fristen, interne Eskalation
- Kommunikation - Intern, Kunden, Presse, Behörden
- Dokumentation und Aufbewahrung - Vorfallsdokumentation, Aufbewahrungsfristen
- Verantwortlichkeiten
- Schnittstellen zu verwandten Dokumenten - BCP, Notfallhandbuch, Kommunikationsplan
- Überprüfung und Aktualisierung
- Inkrafttreten und Freigabe
Häufige Fehler bei Incident-Response-Richtlinien
Zu vage Klassifizierung
Wenn die Schweregrade nicht klar definiert sind, beginnt im Ernstfall eine Diskussion darüber, ob der Vorfall „kritisch" oder nur „hoch" ist. Währenddessen verstreicht wertvolle Zeit. Definiere die Schweregrade mit konkreten Kriterien und Beispielen, nicht mit abstrakten Formulierungen.
Keine Stellvertreterregelung
Der IRT-Leiter ist im Urlaub, die Stellvertreterin krank. Wer entscheidet jetzt? Ohne dokumentierte Stellvertreterregelung für jede Rolle im IRT steht das Team handlungsunfähig da. Die Richtlinie muss für jede Rolle mindestens einen Stellvertreter benennen.
Veraltete Kontaktlisten
Kontaktlisten, die seit zwei Jahren nicht aktualisiert wurden, enthalten Telefonnummern von Mitarbeitenden, die längst das Unternehmen verlassen haben. Die Richtlinie muss festlegen, dass die Kontaktliste mindestens vierteljährlich aktualisiert wird. Noch besser: Jede Personalveränderung im IRT löst automatisch ein Update aus.
Fehlende Übung
Eine Richtlinie, die nie geübt wurde, ist im Ernstfall so nützlich wie eine Straßenkarte in einer Sprache, die du nicht liest. Tabletop-Übungen mindestens einmal jährlich sind Pflicht. Sie decken Lücken auf, bevor ein echter Vorfall das tut. Nach jeder Übung wird die Richtlinie bei Bedarf angepasst.
Keine Beweissicherung vor Bereinigung
Der häufigste Fehler im Ernstfall: Das kompromittierte System wird sofort neu installiert, bevor forensische Kopien erstellt wurden. Die Richtlinie muss die Reihenfolge unmissverständlich definieren: erst sichern, dann bereinigen. Dieser Grundsatz muss so verankert sein, dass er auch unter Zeitdruck nicht vergessen wird.
Von der Richtlinie zur gelebten Praxis
Eine Incident-Response-Richtlinie, die im Sharepoint verstaubt, schützt niemanden. Damit sie im Ernstfall funktioniert, braucht sie drei Dinge: Bekanntheit, Übung und regelmäßige Aktualisierung.
Alle Mitarbeitenden müssen wissen, wie sie einen verdächtigen Vorfall melden – der Artikel zum Sicherheitsvorfall erkennen und melden liefert dafür die Grundlage. Das IRT muss seine Rollen kennen und regelmäßig in Tabletop-Übungen durchspielen. Die Kontaktlisten müssen aktuell sein. Die Richtlinie muss nach jedem tatsächlichen Vorfall und mindestens jährlich überprüft werden.
ISMS Lite unterstützt dich beim gesamten Richtlinien-Lifecycle: Erstellung (auf Wunsch mit KI-Unterstützung), Versionierung bei jeder Änderung, digitale Kenntnisnahme durch alle Beteiligten und rechtssichere Freigabe durch die Geschäftsführung. So stellst du sicher, dass deine Incident-Response-Richtlinie nicht nur existiert, sondern aktuell, bekannt und wirksam ist.