Incident Response: Der Plan für den Ernstfall

Irgendwann trifft es fast jeden Betrieb. Etwa ein verschlüsselter Server, eine gemeldete Datenpanne oder ein seltsamer Login um drei Uhr nachts. In genau diesem Moment entscheidet die Incident Response über den weiteren Verlauf. Denn sie ist der geordnete Umgang mit einem Sicherheitsvorfall. Wer hier einen Plan hat, verliert nur Stunden. Hingegen verliert Tage und viel Geld, wer keinen hat.

Dieser Beitrag erklärt die Incident Response von Grund auf. Zunächst geht es um den Begriff und den Business-Impact. Danach folgen die sechs Phasen nach NIST und SANS. Zum Schluss geht es um den konkreten Aufbau eines Plans und eines Teams. Dabei liegt der Fokus auf österreichischen KMU. Also auf Betrieben, die keine eigene Sicherheitsabteilung haben und trotzdem reagieren müssen.

Was Incident Response bedeutet

Incident Response ist die strukturierte Reaktion auf einen Sicherheitsvorfall. Dabei umfasst der Begriff alle Schritte von der Erkennung bis zur Nachbereitung. Zudem verfolgt er ein klares Ziel. Nämlich den Schaden zu begrenzen und den Betrieb rasch wiederherzustellen. Ein Vorfall ist dabei jedes Ereignis, das die Vertraulichkeit, Integrität oder Verfügbarkeit Ihrer Daten gefährdet. Also ein Ransomware-Angriff, ein gestohlenes Passwort oder ein Datenleck.

Ein Alltagsbild macht das greifbar. Denken Sie deshalb an die Feuerwehr. Denn niemand wartet auf den Brand, um dann erst über Schläuche und Fluchtwege nachzudenken. Genau so funktioniert der geordnete Umgang mit einem Vorfall. Somit liegt der Plan fertig in der Schublade, bevor es brennt. Dabei geht es nicht um Technik allein. Vielmehr geht es um Rollen, Abläufe und klare Entscheidungen unter Druck.

Vorfall ist nicht gleich Vorfall

Zunächst ist nicht jede Auffälligkeit ein echter Vorfall. Ein blockiertes Konto nach dreimaliger Fehleingabe ist nur ein Ereignis. Hingegen ist ein Angreifer, der sich über dieses Konto Zugang verschafft, ein Vorfall. Deshalb steht am Anfang jeder Reaktion die Einordnung. Denn erst die Analyse trennt den Fehlalarm vom echten Notfall. Die NIST-Empfehlung SP 800-61 liefert dafür den international anerkannten Rahmen.

Reaktion statt Prävention

Der Prozess setzt dort an, wo Vorbeugung nicht mehr reicht. Zwar senken Firewalls und Schulungen das Risiko. Doch kein Schutz ist lückenlos. Deshalb braucht jeder Betrieb einen zweiten Verteidigungsring. Genau dieser Ring greift, wenn ein Angreifer die erste Linie überwunden hat. Wie die erste Stunde eines akuten Angriffs abläuft, zeigt unser Beitrag zu Cyberangriff: Was Sie in den ersten Stunden tun müssen.

Oft wird der Begriff mit Prävention verwechselt. Das führt zu einer gefährlichen Lücke. Denn viele Betriebe investieren nur in Abwehr und vergessen die Reaktion. Kommt der Vorfall dann doch, fehlt der Plan. Deshalb betrachten wir beide Seiten immer gemeinsam. Zunächst senkt Vorbeugung die Wahrscheinlichkeit. Danach senkt eine gute Incident Response den Schaden, wenn es trotzdem passiert. Somit ergibt erst beides zusammen einen belastbaren Schutz.

Warum ein Plan über den Schaden entscheidet

Ein guter Incident-Response-Plan senkt den Schaden messbar. Denn der teuerste Faktor bei einem Vorfall ist Zeit. Je länger ein Angreifer unbemerkt im Netz bleibt, desto größer wird der Schaden. Genau hier trennt sich Vorbereitung von Improvisation. Somit verkürzt die kritische Phase deutlich, wer strukturiert reagiert.

Die Zahlen belegen das. So kostet ein Datenleck in Deutschland laut dem IBM Cost of a Data Breach Report 2025 im Schnitt rund 3,87 Millionen Euro. Betriebe, die auf schnelle Erkennung und Reaktion setzen, sparen dabei sechsstellige Beträge pro Vorfall. Zudem sinkt die Verweildauer eines Angreifers mit gutem Monitoring oft von mehreren Tagen auf wenige. Folglich ist jeder eingesparte Tag bares Geld. Das BSI zur Reaktion auf Cybervorfälle bestätigt diesen Zusammenhang zwischen Reaktionszeit und Schadenshöhe.

Der Business-Impact eines Vorfalls

Ein Sicherheitsvorfall trifft mehr als die IT. So steht die Produktion still. Zudem warten Kunden und Mitarbeiter sind blockiert. Außerdem drohen rechtliche Folgen. Denn eine Datenpanne müssen Sie oft binnen 72 Stunden melden. Wie das geht, lesen Sie unter Datenpanne melden: Was in 72 Stunden zu tun ist. Fällt der Betrieb unter NIS2, gelten sogar noch strengere Fristen.

Meldefristen als Zeitdruck

NIS2 verlangt eine erste Warnung binnen 24 Stunden. Danach folgt ein Bericht nach 72 Stunden und ein Abschlussbericht nach einem Monat. Diese Fristen halten Sie nur ein, wenn der Prozess vorher steht. Wer erst im Vorfall zu planen beginnt, meldet zu spät. Die Details erklären wir unter NIS2 Meldepflicht: 24, 72 Stunden und Abschlussbericht. Somit ist eine gute Reaktion auch eine Frage der Compliance.

Die sechs Phasen der Incident Response

Die Incident Response folgt einem festen Ablauf. Dabei stammen die beiden bekanntesten Modelle von NIST und vom SANS Institute. Beide beschreiben denselben Kreislauf, nur mit leicht anderer Gliederung. Für die Praxis in einem KMU eignet sich das SANS-Modell mit sechs Phasen besonders gut. Denn es ist konkret und leicht zu merken.

Von der Vorbereitung bis zu den Lessons Learned

• Vorbereitung: Rollen, Kontakte, Tools und Backups stehen bereit. Diese Phase entscheidet über alle folgenden.
• Erkennung und Analyse: Auffälligkeiten werden bewertet. Aus einem Alarm wird ein bestätigter Vorfall.
• Eindämmung: Betroffene Systeme werden isoliert. Der Angreifer verliert den weiteren Zugriff.
• Beseitigung: Schadsoftware und Zugänge des Angreifers werden entfernt. Die Ursache wird geschlossen.
• Wiederherstellung: Systeme gehen kontrolliert wieder in den Betrieb. Backups werden eingespielt und geprüft.
• Lessons Learned: Der Vorfall wird nachbesprochen. Aus den Fehlern entstehen Verbesserungen für die nächste Vorbereitung.

Der Ablauf ist ein Kreis, kein gerader Weg. Denn die Lessons Learned fließen zurück in die Vorbereitung. Somit wird jede Runde besser als die letzte. Genau das ist der Sinn eines gelebten Prozesses. Deshalb betont die EU-Agentur ENISA diesen Lernkreislauf als Kern jeder wirksamen Reaktion.

NIST und SANS im Vergleich

Beide Modelle führen zum selben Ziel. Dabei liegt der Unterschied nur in der Zusammenfassung einzelner Schritte. Deshalb stellt sie die folgende Tabelle gegenüber.

NIST fasst also drei Schritte zu einem zusammen. Hingegen trennt SANS sie sauber auf. Für die Praxis empfehlen wir die feinere Gliederung. Denn Eindämmung und Beseitigung sind zwei verschiedene Aufgaben. Somit arbeitet klarer, wer sie trennt. Ein bewährter Ablauf steht auch im Beitrag Zwischenfallreaktion: Struktur für den einzelnen Vorfall.

Incident-Response-Plan und CSIRT aufbauen

Ein Incident-Response-Plan macht aus der Theorie einen konkreten Ablauf. Dabei beschreibt er, wer im Ernstfall was tut. Zudem legt er Rollen, Meldewege und Eskalationsstufen fest. Denn ohne diesen Plan reagiert jeder anders. Somit gehen in der Hektik wichtige Schritte unter. Deshalb ist der Plan das Herzstück jeder Reaktion.

Was im Plan stehen muss

Ein brauchbarer Plan bleibt kurz und klar. Dabei nennt er die zentralen Punkte auf wenigen Seiten. Dazu gehören diese Elemente:

• Rollen und Kontakte: Wer entscheidet, wer meldet, wer kommuniziert. Mit Telefonnummern, auch privaten.
• Klassifizierung: Wie schwer ist ein Vorfall? Ab wann wird eskaliert?
• Sofortmaßnahmen: Erste Schritte je Vorfallart, etwa bei Ransomware oder Datenabfluss.
• Meldewege: An Behörde, Datenschutzbehörde, Versicherung und Kunden. Mit Fristen.
• Wiederanlauf: Reihenfolge, in der Systeme zurückkommen.

Die konkrete Vorlage und das Vorgehen dazu finden Sie im Beitrag IT-Notfallplan erstellen: Vorlage und Vorgehen für KMU. Für den häufigsten Ernstfall lohnt zusätzlich der Blick auf Ransomware: Schutz und Reaktion im Unternehmen.

Das CSIRT: das Team hinter dem Plan

Ein Plan ohne Team bleibt Papier. Deshalb braucht die Reaktion ein festes Team. Fachleute nennen es CSIRT, also Computer Security Incident Response Team. In großen Konzernen ist das eine eigene Abteilung. Hingegen sind es in einem KMU meist drei bis fünf Personen mit klaren Rollen. Dabei zählt nicht die Größe, sondern die Klarheit. Somit weiß jeder, was er tut.

Ein typisches CSIRT im Mittelstand hat eine Leitung, einen technischen Kopf und eine Person für Kommunikation. Dazu kommt oft externe Verstärkung. Denn nicht jeder Betrieb hat forensisches Wissen im Haus. Genau hier setzt Notfallmanagement und BCM an. Dabei verbindet es das Team mit klaren Abläufen. Zudem unterstützt in Österreich das nationale CERT.at mit Warnungen und Koordination.

Üben, nicht nur schreiben

Ein Plan wird erst durch Übung wirksam. Deshalb gehört ein Trockenlauf zur Vorbereitung. So spielen Sie einen Ransomware-Fall einmal im Jahr durch. Wer ruft wen an? Wo liegen die Backups? Und funktioniert die Kommunikation ohne die eigene IT? Solche Übungen decken Lücken auf, bevor der Ernstfall es tut. Zudem geben sie dem Team Sicherheit. Der Faktor Mensch spielt dabei eine große Rolle, denn im Stress zählt Routine.

Bewahren Sie den Plan zudem auch offline auf. Denn bei einem Ransomware-Angriff ist oft das gesamte Netz verschlüsselt. Somit kommen Sie im Ernstfall nicht heran, wenn der Plan nur auf dem Server liegt. Ein Ausdruck im Ordner und eine Kopie auf einem getrennten Stick lösen das Problem. Ebenso wichtig sind aktuelle Kontaktdaten. Deshalb prüfen Sie diese bei jeder Übung. Denn eine falsche Nummer kostet im Vorfall wertvolle Minuten.

Incident Response im Zusammenspiel mit ISMS und BCM

Die Incident Response steht nicht für sich allein. Vielmehr ist sie ein Baustein im größeren Bild der Informationssicherheit. So wirken rundherum das ISMS, das Notfallmanagement und die Awareness der Mitarbeiter. Somit ergeben sie erst zusammen einen wirksamen Schutz. Denn wer nur einen Teil hat, hat Lücken.

Das ISMS als Rahmen

Zunächst liefert ein ISMS nach ISO 27001 die Struktur für die gesamte Sicherheit. Zudem fordert es einen Prozess für Sicherheitsvorfälle. Damit ist die Reaktion fest im Managementsystem verankert. Somit steht sie nicht als Insel daneben, sondern greift in die Risikoanalyse und in die Maßnahmen. Wie ein solches System entsteht, zeigt ISMS nach ISO 27001. Der Prozess wird so nachvollziehbar und auditierbar.

BCM sorgt für den Weiterbetrieb

Der Vorfallprozess stoppt den Angriff. Hingegen hält das Business Continuity Management das Geschäft am Laufen. Somit greifen beide ineinander. Während das CSIRT einen Server bereinigt, sorgt das BCM für einen Ersatzweg. So läuft der Betrieb weiter, wenn auch eingeschränkt. Diese Verzahnung ist besonders für KMU wichtig, deren Cybersicherheit als KMU mit knappen Mitteln auskommen muss. Denn ein Ausfall ohne Plan B kostet schnell die Existenz.

Awareness senkt die Zahl der Vorfälle

Die beste Reaktion ist der Vorfall, der nie eskaliert. Deshalb zahlt sich Sensibilisierung doppelt aus. Denn ein geschultes Team erkennt Phishing früher und meldet schneller. Genau diese Meldung startet den gesamten Prozess. Andernfalls bleibt ein Angriff oft tagelang unbemerkt. Wie Sie diese Kultur aufbauen, lesen Sie unter Security Awareness. So wird jeder Mitarbeiter zum Sensor im eigenen Frühwarnsystem.

Wie SecTec Sie bei der Incident Response begleitet

SecTec unterstützt österreichische KMU beim gesamten Thema Incident Response. Dabei setzen wir auf machbare Schritte statt auf Angst. Denn ein guter Plan muss zum Betrieb passen. So braucht ein Zehn-Personen-Betrieb etwas anderes als ein Industriezulieferer mit 200 Beschäftigten. Genau diese Passung schaffen wir gemeinsam.

Vom Plan bis zur Übung

Zunächst beginnen wir mit einer klaren Bestandsaufnahme. Wo liegen Ihre kritischen Daten? Und welche Vorfälle sind am wahrscheinlichsten? Ein IT-Security-Audit liefert dafür die Grundlage. Darauf bauen wir Ihren Incident-Response-Plan auf. Danach helfen wir beim Aufbau des Teams und führen den ersten Trockenlauf durch. Somit bleibt der Plan kein Dokument, sondern wird zur gelebten Routine.

Externe Verstärkung im Ernstfall

Nicht jeder Betrieb hält ein volles Sicherheitsteam vor. Das muss er auch nicht. So übernimmt ein externer CISO die Steuerung im Vorfall und dazwischen. Somit haben Sie im Ernstfall einen ruhigen Kopf an der Seite. Zudem bündeln wir die Fäden zur Behörde, zur Versicherung und zu Ihren Kunden. Damit gewinnen Sie genau das, was im Vorfall am knappsten ist: Zeit und Übersicht.

Der erste Schritt ist ein Gespräch

Der Einstieg ist unkompliziert. In einem kurzen Gespräch klären wir Ihre Ausgangslage. Danach schlagen wir konkrete Schritte vor, die zu Ihrem Betrieb passen. Ob Sie unter NIS2 fallen oder nicht, spielt für den Start keine Rolle. Denn eine geordnete Reaktion nützt jedem Betrieb. Nehmen Sie deshalb einfach über die Kontaktseite mit uns Verbindung auf. Der Rest ergibt sich im Dialog.

Erstgespräch vereinbaren

Häufig gestellte Fragen

Was ist Incident Response einfach erklärt?

Incident Response ist die strukturierte Reaktion auf einen Sicherheitsvorfall. Dabei umfasst sie alle Schritte von der Erkennung über die Eindämmung bis zur Nachbereitung. Das Ziel bleibt dabei immer gleich. Nämlich den Schaden begrenzen und den Betrieb rasch wiederherstellen.

Welche Phasen hat die Incident Response?

Das SANS-Modell nennt sechs Phasen. Zunächst Vorbereitung und Erkennung. Danach folgen Eindämmung, Beseitigung und Wiederherstellung. Zum Schluss kommen die Lessons Learned. Hingegen fasst NIST die mittleren Schritte zu einem Block zusammen. Somit beschreiben beide Modelle denselben Kreislauf.

Was ist ein CSIRT?

Ein CSIRT ist das Team, das im Vorfall reagiert. Dabei steht die Abkürzung für Computer Security Incident Response Team. In einem KMU sind das meist drei bis fünf Personen mit klaren Rollen. Somit zählt nicht die Größe, sondern dass jeder seine Aufgabe kennt.

Braucht ein kleines Unternehmen wirklich einen Incident-Response-Plan?

Ja. Denn gerade KMU trifft ein Vorfall oft härter. Zudem haben sie weniger Reserven für einen langen Ausfall. Dabei reicht ein kurzer, klarer Plan von wenigen Seiten meist aus. Wichtig ist nur, dass er vor dem Ernstfall bereitliegt und geübt wurde.

Wie hängt Incident Response mit NIS2 zusammen?

Zunächst verlangt NIS2 Meldungen binnen 24 und 72 Stunden. Diese Fristen halten Sie nur ein, wenn der Reaktionsprozess vorher steht. Somit ist eine gute Reaktion auch eine Compliance-Pflicht. Denn wer erst im Vorfall plant, meldet in der Regel zu spät.

Was ist der Unterschied zwischen Incident Response und BCM?

Incident Response stoppt den Angriff und beseitigt die Ursache. Hingegen hält das Business Continuity Management den Betrieb währenddessen am Laufen. Somit greifen beide ineinander. Dabei bekämpft das eine den Vorfall, während das andere den Weiterbetrieb sichert.

Wie oft sollte man den Incident-Response-Plan üben?

Mindestens einmal im Jahr. Dabei reicht ein kurzer Trockenlauf schon aus. So spielen Sie einen realistischen Fall durch, etwa Ransomware. Somit decken Sie Lücken auf, bevor es der echte Vorfall tut. Zudem gewinnt das Team dabei Sicherheit.

Fazit: Vorbereitung schlägt Hektik im Ernstfall

Die Incident Response entscheidet über den Verlauf eines Vorfalls. Denn der teuerste Faktor ist Zeit. Wer einen Plan, ein Team und geübte Abläufe hat, verliert Stunden statt Tage. Hingegen zahlt drauf, wer improvisiert. Dabei geben die sechs Phasen von der Vorbereitung bis zu den Lessons Learned die klare Struktur vor.

Für ein KMU muss die Reaktion nicht kompliziert sein. Ein kurzer Plan, klare Rollen und ein jährlicher Trockenlauf schaffen bereits viel Sicherheit. Der beste Zeitpunkt für den Aufbau ist jetzt, nicht im Vorfall. Wir unterstützen Sie gern vom ersten Plan bis zur laufenden Betreuung.

Denken Sie an das Bild der Feuerwehr vom Anfang. Niemand plant den Löschangriff erst, wenn es brennt. Genau so gehört die Incident Response vorbereitet, bevor der Vorfall kommt. Der Aufwand dafür bleibt überschaubar. Der Nutzen im Ernstfall ist dagegen enorm. Machen Sie den ersten Schritt, solange Sie Zeit dafür haben.

SecTec begleitet Sie dabei. Herstellerunabhängig und mit Blick auf das Ganze. Jetzt Erstgespräch vereinbaren