Sicherheitsvorfall erkennen, bewerten und melden - der komplette Ablauf

Wenn der Ernstfall eintritt

Montagmorgen, 7:42 Uhr. Der Systemadministrator öffnet sein Dashboard und sieht 143 fehlgeschlagene Anmeldeversuche auf dem Exchange-Server innerhalb der letzten Nacht. Drei davon waren erfolgreich. Von einer IP-Adresse in Südostasien. Gleichzeitig meldet eine Mitarbeiterin aus der Buchhaltung, dass sie eine seltsame E-Mail von ihrem eigenen Postfach an alle Kollegen verschickt hat, ohne es getan zu haben.

Ist das ein Sicherheitsvorfall? Ja. Ist es ein kritischer Vorfall? Das hängt davon ab, was in den nächsten 30 Minuten passiert. Und genau hier trennt sich die Spreu vom Weizen: Unternehmen mit einem klaren Incident-Response-Plan handeln jetzt strukturiert und schnell. Unternehmen ohne einen solchen Prozess improvisieren, verlieren Zeit und machen Fehler, die den Schaden vergrößern.

Dieser Artikel beschreibt den kompletten Ablauf, von der Erkennung über die Bewertung und Eindämmung bis zur Nachbereitung. Er ist so geschrieben, dass du ihn als Grundlage für deinen eigenen Incident-Response-Prozess nutzen kannst.

Phase 1: Erkennung - die drei Kanäle

Sicherheitsvorfälle werden über drei grundlegend verschiedene Wege erkannt. Jeder dieser Kanäle hat eigene Stärken und Schwächen, und ein robuster Prozess braucht alle drei.

Kanal 1: Technisches Monitoring

Das ist der Kanal, an den die meisten zuerst denken. SIEM-Systeme, Intrusion-Detection-Systeme, Endpoint-Detection-and-Response-Lösungen, Firewall-Logs, Antivirus-Alerts. Diese Systeme generieren automatisch Alarme, wenn vordefinierte Schwellenwerte überschritten oder bekannte Angriffsmuster erkannt werden.

Die Stärke technischen Monitorings liegt in der Geschwindigkeit und Objektivität. Wenn eine Ransomware beginnt, Dateien zu verschlüsseln, erkennt ein EDR-System das innerhalb von Sekunden. Die Schwäche: Es erkennt nur, wofür es konfiguriert wurde. Neue Angriffstechniken, Social-Engineering-Angriffe oder langsame, unauffällige Datenexfiltration bleiben oft unter dem Radar.

Typische technische Indikatoren für einen Vorfall:

Für ein mittelständisches Unternehmen mit 50 bis 200 Mitarbeitern muss das Monitoring nicht auf dem Niveau eines SOC bei einem Konzern sein. Aber ein paar Grundlagen sind unverzichtbar: zentrale Log-Sammlung, Alerting bei offensichtlichen Anomalien und jemand, der die Alerts auch tatsächlich liest und bewertet. Wenn Alarme generiert werden, aber niemand hinschaut, kannst du das Monitoring auch abschalten.

Kanal 2: Mitarbeiter-Meldungen

Dieser Kanal wird chronisch unterschätzt. Dabei sind es häufig Mitarbeiter, die als Erste merken, dass etwas nicht stimmt. Die Kollegin, die eine verdächtige E-Mail erhalten hat. Der Vertriebsmitarbeiter, dem auffällt, dass sein CRM-Zugang nicht mehr funktioniert. Die Auszubildende, die beobachtet, dass ein USB-Stick im Serverraum steckt, den niemand kennt.

Damit dieser Kanal funktioniert, brauchst du drei Dinge:

Erstens einen klaren Meldeweg. Jeder Mitarbeiter muss wissen, an wen er sich wendet, wenn ihm etwas auffällt. Das kann eine zentrale E-Mail-Adresse sein (security@firma.de), eine Telefonnummer oder ein einfaches Formular im Intranet. Der Weg muss niedrigschwellig sein und darf keine Angst vor Konsequenzen erzeugen.

Zweitens eine Kultur, in der Meldungen erwünscht sind. Wenn jemand einen Phishing-Link angeklickt hat und sich nicht traut, das zu melden, weil er Ärger befürchtet, hast du ein Problem. Der Vorfall wird nicht weniger schlimm, weil er verschwiegen wird, sondern schlimmer. Eine Blame-free-Kultur bei Sicherheitsvorfällen ist kein Luxus, sondern eine operative Notwendigkeit.

Drittens regelmäßige Awareness-Schulungen. Mitarbeiter können nur melden, was sie als ungewöhnlich erkennen. Wer nie gelernt hat, wie eine Phishing-Mail aussieht, wird sie nicht als solche identifizieren. Kurze, regelmäßige Schulungen im Rahmen eines Security-Awareness-Programms, idealerweise vierteljährlich, halten die Aufmerksamkeit hoch.

Kanal 3: Externe Hinweise

Manchmal erfährst du von einem Sicherheitsvorfall in deinem Unternehmen durch Dritte: Ein Geschäftspartner meldet, dass er verdächtige E-Mails von deiner Domain erhält. Das BSI informiert dich über eine Schwachstelle, die bei dir ausgenutzt worden sein könnte. Ein Sicherheitsforscher kontaktiert dich, weil er deine Daten in einem Darknet-Forum gefunden hat. Oder dein Managed-Security-Provider schlägt Alarm.

Für diesen Kanal brauchst du eine veröffentlichte Kontaktadresse für Sicherheitsmeldungen (eine security.txt auf der Website nach RFC 9116 ist ein guter Anfang) und einen internen Prozess, der solche Meldungen ernst nimmt und an die richtige Stelle weiterleitet.

Phase 2: Erstbewertung - Schweregrad bestimmen

Wenn ein potenzieller Vorfall erkannt wurde, beginnt die kritischste Phase: die Erstbewertung. Innerhalb von maximal 30 Minuten muss eine erste Einschätzung vorliegen, die über das weitere Vorgehen entscheidet.

Die Schweregrad-Skala von 1 bis 10

Eine Schweregrad-Skala hilft, Vorfälle konsistent zu bewerten und die richtige Reaktion auszulösen. Hier ist ein praxiserprobtes Modell mit vier Stufen:

Kriterien für die Erstbewertung

Um den Schweregrad zu bestimmen, beantworte in der Erstbewertung folgende Fragen:

Welche Systeme sind betroffen? Ein einzelner Arbeitsplatz-PC ist anders zu bewerten als der Domain-Controller oder das ERP-System. Je geschäftskritischer das System, desto höher der Schweregrad.

Sind personenbezogene Daten betroffen? Wenn ja, löst das zusätzliche Meldepflichten nach DSGVO aus. Kundendaten, Mitarbeiterdaten, Gesundheitsdaten und Finanzdaten haben unterschiedliche Sensibilitätsstufen.

Ist der Angriff noch aktiv? Ein laufender Angriff erfordert sofortige Eindämmung. Ein bereits abgeschlossener Vorfall, der nachträglich entdeckt wird, erlaubt eine sorgfältigere Analyse.

Welcher Angriffstyp liegt vor? Ransomware erfordert andere Sofortmaßnahmen als ein Datenabfluss. Ein DDoS-Angriff hat andere Prioritäten als ein kompromittiertes E-Mail-Konto.

Wie breit ist der Angriff gestreut? Betrifft er ein einzelnes System, ein Netzwerksegment oder das gesamte Unternehmen? Die Antwort auf diese Frage bestimmt den Ressourceneinsatz für die Eindämmung.

Eskalationskriterien

Auf Basis des Schweregrades wird eskaliert. Definiere vorher klar, wer bei welchem Schweregrad informiert wird:

Ein wichtiger Punkt: Die Erstbewertung ist genau das, eine erste Einschätzung. Sie kann und wird sich im Verlauf der Untersuchung ändern. Ein Vorfall, der anfangs als Schweregrad 3 eingestuft wurde, kann sich als Schweregrad 8 herausstellen, wenn bei der Analyse weitere kompromittierte Systeme entdeckt werden. Deshalb ist die Neubewertung ein fester Bestandteil des Prozesses.

Phase 3: Eindämmung - den Schaden begrenzen

Sobald die Erstbewertung abgeschlossen ist, beginnt die Eindämmung. Das Ziel: Verhindern, dass sich der Vorfall weiter ausbreitet. Gleichzeitig darfst du dabei nicht voreilig Beweise vernichten, die für die spätere Analyse und mögliche strafrechtliche Verfolgung wichtig sind.

Sofortige Eindämmung (Short-Term Containment)

Die ersten Maßnahmen zielen darauf ab, die unmittelbare Ausbreitung zu stoppen:

Betroffene Systeme isolieren. Netzwerkkabel ziehen, WLAN deaktivieren, VLAN umkonfigurieren. Wichtig: Systeme nicht herunterfahren, solange forensische Sicherung noch aussteht. Im Arbeitsspeicher befinden sich oft wertvolle Hinweise, die beim Ausschalten verloren gehen.

Kompromittierte Konten sperren. Passwörter zurücksetzen, Sessions beenden, Token invalidieren. Wenn ein Admin-Konto betroffen ist, müssen alle Systeme geprüft werden, auf die dieses Konto Zugriff hatte.

Netzwerksegmente trennen. Wenn die Ausbreitung unklar ist, kann es sinnvoll sein, ganze Netzwerksegmente temporär zu isolieren. Das ist ein drastischer Schritt mit Auswirkungen auf den Geschäftsbetrieb, aber bei Schweregrad 8 oder höher oft unvermeidlich.

Externe Kommunikation blockieren. Wenn ein Command-and-Control-Kanal identifiziert wurde: die entsprechenden Domains und IP-Adressen auf der Firewall blockieren. Das schneidet dem Angreifer die Kontrolle über die kompromittierten Systeme ab.

Erweiterte Eindämmung (Long-Term Containment)

Nach den Sofortmaßnahmen folgen Maßnahmen, die eine kontrollierte Weiterarbeit ermöglichen, während die Untersuchung läuft:

Temporäre Workarounds einrichten. Wenn das ERP-System isoliert wurde, brauchen die Mitarbeiter eine Möglichkeit, ihre Arbeit fortzusetzen. Manuelle Prozesse, Offline-Systeme oder alternative Zugangswege können überbrücken.

Forensische Sicherung durchführen. Bevor Systeme bereinigt werden: Images ziehen, Logs sichern, RAM-Dumps erstellen. Diese Daten sind die Grundlage für die Ursachenanalyse und eventuell für rechtliche Schritte.

Monitoring verstärken. Während der Eindämmungsphase ist erhöhte Wachsamkeit nötig. Angreifer versuchen häufig, über alternative Wege zurück ins Netzwerk zu gelangen, wenn ihre primären Zugänge gesperrt werden.

Phase 4: Beseitigung - die Ursache eliminieren

Die Eindämmung stoppt die Ausbreitung, beseitigt aber nicht die Ursache. In dieser Phase wird der Angriff vollständig aus der Umgebung entfernt.

Malware entfernen. Auf allen betroffenen Systemen müssen Schadsoftware, Backdoors und persistente Mechanismen identifiziert und entfernt werden. Das klingt einfach, ist es aber oft nicht. Professionelle Angreifer installieren mehrere Backdoors und Persistenzmechanismen, um nach einer Bereinigung zurückkehren zu können.

Schwachstellen schließen. Die Eintrittspforte des Angreifers muss identifiziert und geschlossen werden. War es eine ungepatchte Schwachstelle? Ein schwaches Passwort? Eine Fehlkonfiguration? Wenn du die Ursache nicht behebst, wird der nächste Angriff über denselben Weg kommen.

Credentials rotieren. Alle Passwörter und Zugangsdaten, die potenziell kompromittiert wurden, müssen geändert werden. Bei einem schwerwiegenden Vorfall, insbesondere bei Kompromittierung des Active Directory, kann das bedeuten, dass sämtliche Passwörter im Unternehmen zurückgesetzt werden müssen. Ein enormer Aufwand, aber bei einer Domain-Controller-Kompromittierung unvermeidlich.

Systeme neu aufsetzen. Bei schweren Kompromittierungen ist es oft sicherer und schneller, betroffene Systeme aus sauberen Backups wiederherzustellen oder komplett neu aufzusetzen, statt zu versuchen, sie zu bereinigen. Du kannst nie mit absoluter Sicherheit ausschließen, dass nach einer Bereinigung nicht doch noch ein versteckter Mechanismus übrig ist.

Phase 5: Wiederherstellung - zurück zum Normalbetrieb

Die Wiederherstellung ist der Übergang vom Krisenmodus zurück in den Normalbetrieb. Dieser Übergang muss kontrolliert und überwacht erfolgen, nicht überstürzt.

Systeme schrittweise wieder in Betrieb nehmen. Nicht alles gleichzeitig hochfahren. Beginne mit den kritischsten Systemen und erweitere schrittweise. Überwache jedes System nach dem Hochfahren intensiv auf Anzeichen einer erneuten Kompromittierung.

Funktionalität verifizieren. Bevor ein System wieder produktiv genutzt wird, muss überprüft werden, ob es korrekt funktioniert. Sind alle Daten vorhanden? Stimmen die Konfigurationen? Funktionieren die Schnittstellen zu anderen Systemen?

Erhöhtes Monitoring beibehalten. Für mindestens zwei bis vier Wochen nach der Wiederherstellung sollte das Monitoring auf erhöhtem Niveau bleiben. Angreifer, die aus einem Netzwerk verdrängt wurden, versuchen häufig, über alternative Wege zurückzukehren.

Backlog abarbeiten. Während des Vorfalls haben sich vermutlich Aufgaben angestaut: E-Mails, die nicht bearbeitet wurden, Bestellungen, die manuell erfasst werden mussten, Berichte, die nicht erstellt werden konnten. Plane Zeit und Ressourcen für die Aufarbeitung ein.

Zeitliche Einordnung der Wiederherstellung

Die Dauer der Wiederherstellung hängt stark vom Schweregrad ab:

Bei einem Ransomware-Angriff, der das gesamte Netzwerk verschlüsselt hat, ist eine vollständige Wiederherstellung in unter zwei Wochen ambitioniert. Viele mittelständische Unternehmen brauchen vier bis sechs Wochen, bis alle Systeme wieder vollständig funktionsfähig sind.

Phase 6: Lessons Learned - aus dem Vorfall lernen

Diese Phase ist die wertvollste und wird trotzdem am häufigsten übersprungen. Nach dem Stress der Krisenbewältigung wollen alle zurück zum Tagesgeschäft. Genau das ist der Fehler.

Der Lessons-Learned-Workshop

Innerhalb von zwei Wochen nach Abschluss der Wiederherstellung sollte ein strukturierter Workshop stattfinden. Teilnehmer: alle, die am Vorfall beteiligt waren, von der IT über das Management bis zur Kommunikation.

Die zentrale Frage ist nicht, wer schuld war. Schuldzuweisungen verhindern ehrliche Analyse. Die Fragen lauten stattdessen:

Was ist passiert? Erstelle eine lückenlose Timeline des Vorfalls. Wann wurde er erkannt? Wann wurde eskaliert? Welche Maßnahmen wurden in welcher Reihenfolge ergriffen?

Was hat gut funktioniert? Welche Prozesse haben wie geplant funktioniert? Wo war die Reaktion schnell und effektiv? Diese Erkenntnisse sind genauso wichtig wie die Schwachstellen, denn sie zeigen dir, was du beibehalten und stärken solltest.

Was hat nicht funktioniert? Wo gab es Verzögerungen? Wo fehlten Informationen? Welche Prozesse haben versagt oder existierten gar nicht? Wo war der Vorfall schlimmer als nötig, weil die Reaktion zu langsam oder falsch war?

Was ändern wir? Für jede identifizierte Schwachstelle: konkrete Maßnahmen mit Verantwortlichem und Termin. Keine vagen Absichtserklärungen, sondern messbare Verbesserungen. Wenn das Monitoring zu langsam war, kommt ein neues Alerting-System mit Deadline und Budget. Wenn die Kommunikation chaotisch war, wird der Kommunikationsplan überarbeitet und beim nächsten Planspiel getestet.

Die Vorfallsdokumentation

Jeder Vorfall wird dokumentiert. Diese Dokumentation erfüllt mehrere Zwecke: Sie ist Nachweis gegenüber Aufsichtsbehörden, Grundlage für Versicherungsansprüche, Lernmaterial für die Organisation und Eingabe für die Verbesserung des Incident-Response-Prozesses. Tools wie ISMS Lite generieren die BSI-Erstmeldung direkt aus den erfassten Vorfallsdaten, sodass du in der 24-Stunden-Frist nicht bei null anfangen musst.

Eine vollständige Vorfallsdokumentation enthält:

• Zeitstempel der Erkennung, Meldung und aller wesentlichen Maßnahmen
• Art und Schweregrad des Vorfalls (inklusive eventueller Neubewertungen)
• Betroffene Systeme, Daten und Geschäftsprozesse
• Ergriffene Eindämmungs- und Beseitigungsmaßnahmen
• Ursachenanalyse (Root Cause Analysis)
• Auswirkungen auf den Geschäftsbetrieb (Ausfallzeit, finanzieller Schaden)
• Ergebnisse des Lessons-Learned-Workshops
• Definierte Verbesserungsmaßnahmen mit Verantwortlichen und Terminen

Der NIS2/DSGVO-Meldepflicht-Check

Parallel zu den operativen Phasen läuft eine kritische Prüfung: Muss dieser Vorfall gemeldet werden? Und wenn ja, an wen und bis wann?

Meldepflicht nach NIS2

Wenn dein Unternehmen unter NIS2 fällt, gelten folgende Fristen für erhebliche Sicherheitsvorfälle:

Ein erheblicher Sicherheitsvorfall im Sinne von NIS2 liegt vor, wenn er:

• schwerwiegende Betriebsstörungen verursacht oder verursachen kann,
• finanzielle Verluste für die Einrichtung nach sich zieht oder
• andere Personen oder Einrichtungen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt.

In der Praxis: Ein Ransomware-Angriff, der den Geschäftsbetrieb unterbricht, ist praktisch immer meldepflichtig. Ein isolierter Malware-Fund auf einem einzelnen Arbeitsplatz-PC ohne Ausbreitung typischerweise nicht. Im Zweifelsfall lieber melden als nicht melden, das BSI bewertet keine Unterlassung wohlwollend.

Meldepflicht nach DSGVO

Wenn personenbezogene Daten betroffen sind, kommt zusätzlich die DSGVO-Meldepflicht ins Spiel:

Die DSGVO-Meldung an die Aufsichtsbehörde entfällt nur, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Bei verschlüsselten Daten, die exfiltriert wurden, bei Kundendatenbanken, die kopiert wurden, oder bei Gesundheitsdaten, die offengelegt wurden, ist ein Risiko praktisch immer gegeben.

Doppelte Meldepflicht

Beachte: NIS2 und DSGVO schließen sich nicht gegenseitig aus. Ein Ransomware-Angriff, der gleichzeitig den Geschäftsbetrieb stört (NIS2-relevant) und Kundendaten betrifft (DSGVO-relevant), löst beide Meldepflichten aus. Du meldest dann sowohl ans BSI als auch an die Datenschutz-Aufsichtsbehörde, mit unterschiedlichen Fristen und Inhalten.

Der Meldepflicht-Entscheidungsbaum

Für die schnelle Entscheidung unter Zeitdruck hilft ein einfacher Entscheidungsbaum:

Frage 1: Fällt dein Unternehmen unter NIS2? Wenn ja: Ist der Vorfall erheblich (Betriebsstörung, finanzieller Schaden, Schaden für Dritte)? Dann Meldung ans BSI innerhalb von 24 Stunden.

Frage 2: Sind personenbezogene Daten betroffen? Wenn ja: Besteht ein Risiko für die Rechte und Freiheiten der Betroffenen? Dann Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden. Bei hohem Risiko zusätzlich Benachrichtigung der Betroffenen.

Frage 3: Beides trifft nicht zu? Dann keine externe Meldepflicht, aber interne Dokumentation ist dennoch Pflicht.

Das Zusammenspiel der Phasen in der Praxis

Die sechs Phasen klingen auf dem Papier sequenziell, in der Realität überlappen sie sich. Während du noch mit der Eindämmung beschäftigt bist, läuft bereits die Erstmeldung ans BSI. Während die Beseitigung läuft, beginnt auf unkritischen Systemen schon die Wiederherstellung. Das ist normal und auch richtig so.

Entscheidend ist, dass trotz dieser Parallelität keine Phase übersprungen wird. Besonders die Erstbewertung und die Lessons Learned werden unter Zeitdruck gerne abgekürzt oder weggelassen. Bei der Erstbewertung führt das zu falscher Priorisierung und Ressourcenverschwendung. Beim Lessons Learned dazu, dass derselbe Fehler drei Monate später erneut passiert.

Ein Durchlauf am Beispiel

Montag, 7:42 Uhr: Die geschilderte Situation mit den fehlgeschlagenen Anmeldeversuchen und der kompromittierten Mailbox.

7:42 - Erkennung. Der Administrator erkennt die Anomalie im Dashboard und erhält gleichzeitig die Meldung der Mitarbeiterin. Zwei Kanäle gleichzeitig, das erhöht die Dringlichkeit.

7:55 - Erstbewertung. Analyse der Logs zeigt: Drei erfolgreiche Anmeldungen mit gültigen Credentials aus dem Ausland. Die Mailbox wurde genutzt, um Phishing-Mails an interne und externe Kontakte zu versenden. Schweregrad: 5, mit Tendenz nach oben, da noch unklar ist, ob weitere Konten betroffen sind. IT-Leitung und ISB werden informiert.

8:10 - Eindämmung. Das kompromittierte Konto wird gesperrt, die Sitzungen werden beendet, das Passwort wird zurückgesetzt. Die IP-Adresse wird auf der Firewall blockiert. Alle Mitarbeiter erhalten eine Warnung, keine Anhänge aus der verdächtigen E-Mail zu öffnen.

8:30 - Erweiterte Analyse. Prüfung aller Konten auf ungewöhnliche Anmeldemuster. Zwei weitere Konten zeigen erfolgreiche Anmeldungen von derselben IP-Adresse. Neubewertung auf Schweregrad 7. Geschäftsführung wird informiert. Prüfung der Meldepflicht beginnt.

9:00 - Beseitigung. Alle drei kompromittierten Konten sind gesichert. MFA wird für alle Konten erzwungen (war vorher optional). Die Eintrittspforte war ein Password-Spray-Angriff auf Konten ohne MFA.

9:30 - Meldepflicht-Check. DSGVO: In den kompromittierten Mailboxen befanden sich Kundendaten (E-Mail-Adressen, Namen, Bestellinformationen). Meldung an die Aufsichtsbehörde wird vorbereitet. NIS2: Falls das Unternehmen unter NIS2 fällt, wird die Erstmeldung ans BSI vorbereitet.

Dienstag bis Freitag - Wiederherstellung und Monitoring. Erhöhtes Monitoring auf allen Systemen. Analyse, ob über die kompromittierten Konten weitere Aktionen stattgefunden haben (Datenzugriffe, Weiterleitungsregeln, delegierte Berechtigungen).

Zwei Wochen später - Lessons Learned. Workshop mit IT-Team, ISB und Geschäftsleitung. Ergebnis: MFA wird für alle Konten verpflichtend (nicht mehr optional). Die Passwort-Richtlinie wird verschärft. Ein automatisches Alerting bei Anmeldungen aus ungewöhnlichen Geo-Locations wird eingerichtet. Die Awareness-Schulung zum Thema Passwort-Sicherheit wird vorgezogen.

Die drei häufigsten Fehler bei der Vorfallsbehandlung

Fehler 1: Zu schnell bereinigen. Der Reflex, sofort alles zu löschen und Systeme neu aufzusetzen, ist verständlich, aber gefährlich. Wenn du die Beweise vernichtest, bevor du die Ursache verstanden hast, weißt du nicht, ob der Angreifer noch andere Zugangswege hat. Und gegenüber der Aufsichtsbehörde kannst du keine fundierte Ursachenanalyse vorlegen.

Fehler 2: Kommunikation vernachlässigen. Während die IT im Krisenmodus arbeitet, wissen die Mitarbeiter nicht, was los ist, die Geschäftsführung hat keine Informationen für Kunden und Partner, und die Presseanfragen landen im Leeren. Ein Kommunikationsplan ist genauso wichtig wie der technische Response-Plan.

Fehler 3: Nach der Wiederherstellung aufhören. Der Vorfall ist behoben, alle Systeme laufen wieder, der Normalbetrieb kehrt zurück und alle sind erleichtert. Genau jetzt beginnt die Phase, die den größten langfristigen Wert hat: die Nachbereitung. Unternehmen, die ihre Lessons Learned konsequent umsetzen, werden bei jedem Vorfall besser. Unternehmen, die diese Phase überspringen, machen dieselben Fehler immer wieder.

Was du jetzt tun kannst

Wenn du diesen Artikel liest und noch keinen Incident-Response-Prozess hast, musst du nicht alles auf einmal umsetzen. Fang mit drei Dingen an:

Definiere Meldewege. Wohin wendet sich ein Mitarbeiter, der etwas Verdächtiges bemerkt? Wer entscheidet über die Eskalation? Wer meldet an das BSI und die Aufsichtsbehörde? Schreib das auf einer Seite auf und kommuniziere es.

Erstelle die Schweregrad-Skala. Nimm die Tabelle aus diesem Artikel, passe sie an dein Unternehmen an und stelle sicher, dass dein IT-Team sie kennt und anwenden kann.

Teste den Prozess einmal durch. Spiel ein Szenario durch, am besten als Tabletop-Übung mit dem IT-Team. Freitagabend, Ransomware, Exchange ist verschlüsselt. Was tun wir? Wer ruft wen an? Wo steht die Nummer des externen Dienstleisters? Diese einfache Übung deckt mehr Lücken auf als jedes Dokument.

Weiterführende Artikel

• DSGVO-Datenpanne melden: Wann, wie und an wen
• Incident Response Plan erstellen: Vorlage und Praxisbeispiel
• NIS2-Meldefristen im Überblick: 24h, 72h, 1 Monat – was wann fällig ist
• Tabletop-Übung planen und durchführen: So testest du deinen Notfallplan
• NIS2-Erstmeldung ans BSI: Inhalt, Fristen und Vorlage

Ein strukturierter Incident-Response-Prozess schützt nicht vor Vorfällen. Aber er entscheidet darüber, ob aus einem Sicherheitsvorfall eine kontrollierbare Störung wird oder eine existenzbedrohende Krise.