Incident Response: Was es ist, wie man einen Plan erstellt und was B2B-Unternehmen wissen müssen

Incident Response ist der strukturierte Prozess, den eine Organisation nutzt, um Sicherheitsvorfälle zu erkennen, einzudämmen, zu untersuchen und sich davon zu erholen. Jede Organisation, die Daten verarbeitet, wird früher oder später mit einem Vorfall konfrontiert — ob Phishing-Kompromittierung, fehlkonfigurierter Cloud-Dienst, Ransomware-Angriff oder Insider-Bedrohung.

Für B2B-SaaS-Unternehmen ist Incident-Response-Fähigkeit sowohl eine betriebliche Notwendigkeit als auch eine Compliance-Anforderung. Enterprise-Käufer erwarten dokumentierte Incident-Response-Verfahren in Lieferantenbewertungen. Regulatorische Rahmenwerke — DSGVO, NIS2, DORA, ISO 27001 — schreiben spezifische Prozesse für die Vorfallbehandlung und Meldung vor. Der Unterschied zwischen einem bewältigten Vorfall und einer Krise hängt oft von der Vorbereitung ab.

Dieser Leitfaden behandelt den Aufbau eines Incident-Response-Programms, die Phasen der Vorfallbehandlung, regulatorische Meldepflichten und die Kommunikation von Vorfällen gegenüber Kunden.

Grundlagen des Incident Response

Was einen Sicherheitsvorfall darstellt

Ein Sicherheitsvorfall ist jedes Ereignis, das die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationssystemen oder Daten gefährdet oder bedroht. Beispiele umfassen:

Kategorie	Beispiele
Datenschutzverletzungen	Unbefugter Zugriff auf personenbezogene Daten, Exfiltration von Kundendaten
Malware und Ransomware	Verschlüsselung von Systemen, Cryptomining, Backdoor-Installation
Kontokompromittierung	Gestohlene Anmeldedaten, Session-Hijacking, Rechteeskalation
Denial-of-Service	Volumetrische DDoS, Angriffe auf Anwendungsebene, Ressourcenerschöpfung
Insider-Bedrohungen	Böswilliger Datendiebstahl, versehentliche Datenexposition, Richtlinienverstöße
Supply-Chain-Kompromittierung	Kompromittierte Drittanbieter-Software, verwundbare Abhängigkeiten
Cloud-Fehlkonfiguration	Exponierte Speicher-Buckets, übermäßig permissive IAM, unverschlüsselte Daten

Vorfall vs. Ereignis vs. Schwachstelle

Begriff	Definition	Beispiel
Sicherheitsereignis	Ein beobachtbares Vorkommnis in einem System oder Netzwerk	Fehlgeschlagener Anmeldeversuch
Sicherheitsvorfall	Ein Ereignis, das die Sicherheit gefährdet oder Richtlinien verletzt	Erfolgreicher Brute-Force-Angriff mit Datenzugriff
Schwachstelle	Eine Schwäche, die ausgenutzt werden könnte	Ungepatchte Software, schwache Passwortrichtlinie

Nicht jedes Ereignis ist ein Vorfall, und nicht jede Schwachstelle führt zu einem. Effektive Triage unterscheidet zwischen Rauschen und echten Vorfällen, die eine Reaktion erfordern.

Der Incident-Response-Lebenszyklus

NIST-Framework (SP 800-61)

Der NIST Computer Security Incident Handling Guide definiert vier Phasen:

Phase 1: Vorbereitung

Die Vorbereitung erfolgt vor dem Eintreten von Vorfällen:

Incident-Response-Team (IRT) mit definierten Rollen etablieren
Incident-Response-Verfahren für gängige Szenariotypen dokumentieren
Erkennungs- und Überwachungswerkzeuge einsetzen (SIEM, EDR, Netzwerküberwachung)
Kommunikationsvorlagen für interne und externe Benachrichtigungen erstellen
Beziehungen zu externen Parteien aufbauen (Rechtsberatung, Forensik-Anbieter, Strafverfolgung, CERTs)
Tabletop-Übungen und Simulationen durchführen
Umfassende und manipulationssichere Protokollierung sicherstellen

Phase 2: Erkennung und Analyse

Identifizierung, dass ein Vorfall eingetreten ist und Verständnis des Umfangs:

Sicherheitswarnungen von SIEM, IDS/IPS, EDR und Cloud-Sicherheitswerkzeugen überwachen
Anomalien in Logs, Netzwerkverkehr und Benutzerverhalten analysieren
Ereignisse über mehrere Datenquellen hinweg korrelieren
Schweregrad des Vorfalls bestimmen und gemäß Taxonomie klassifizieren
Erste Erkenntnisse und Zeitverlauf dokumentieren
Relevante Stakeholder gemäß Eskalationsverfahren benachrichtigen

Phase 3: Eindämmung, Beseitigung und Wiederherstellung

Den Vorfall stoppen, die Bedrohung beseitigen und den Betrieb wiederherstellen:

Kurzfristige Eindämmung: Betroffene Systeme isolieren, um Ausbreitung zu verhindern (Netzwerksegmentierung, Kontosperrung, Firewall-Regeln)
Beweissicherung: Forensische Images erstellen, Logs sichern, Beweiskette aufrechterhalten
Langfristige Eindämmung: Temporäre Fixes anwenden, um den Weiterbetrieb zu ermöglichen, während die vollständige Behebung vorbereitet wird
Beseitigung: Malware entfernen, Angriffsvektoren schließen, Schwachstellen patchen, kompromittierte Anmeldedaten zurücksetzen
Wiederherstellung: Systeme aus sauberen Backups wiederherstellen, Integrität überprüfen, auf erneute Infektion überwachen
Validierung: Bestätigen, dass die Bedrohung beseitigt ist und Systeme normal funktionieren

Phase 4: Post-Incident-Aktivitäten

Aus dem Vorfall lernen, um zukünftige Reaktionen zu verbessern:

Post-Incident-Review durchführen (schuldfreie Nachbesprechung)
Vollständigen Vorfallzeitverlauf dokumentieren
Grundursachen und beitragende Faktoren identifizieren
Bestimmen, was gut funktioniert hat und was verbessert werden muss
Incident-Response-Verfahren basierend auf Erkenntnissen aktualisieren
Abhilfemaßnahmen bis zum Abschluss nachverfolgen
Relevante Erkenntnisse (bei Bedarf anonymisiert) mit Branchenkollegen teilen

Einen Incident-Response-Plan erstellen

Vorfallklassifizierung

Klare Schweregrade mit objektiven Kriterien definieren:

Schweregrad	Kriterien	Reaktionszeit	Beispiele
Kritisch (P1)	Aktive Datenschutzverletzung, systemweiter Ausfall, Ransomware	Sofort (< 1 Stunde)	Kundendaten exfiltriert, Produktion verschlüsselt
Hoch (P2)	Signifikante Kompromittierung, teilweise Servicebeeinträchtigung	< 4 Stunden	Kontoübernahme, Malware auf Server, erfolgreicher gezielter Phishing-Angriff
Mittel (P3)	Eingedämmte Kompromittierung, begrenzte Auswirkung	< 24 Stunden	Malware auf einzelnem Arbeitsplatz, Richtlinienverstoß, verdächtige Aktivität
Niedrig (P4)	Geringfügiges Ereignis, keine bestätigte Kompromittierung	< 72 Stunden	Phishing-E-Mail gemeldet (kein Klick), Port-Scan erkannt

Rollen im Incident-Response-Team

Rolle	Verantwortlichkeit
Incident Commander	Gesamtkoordination, Entscheidungsfindung, Eskalation
Technischer Lead	Technische Untersuchung, Eindämmung und Behebung
Kommunikations-Lead	Interne und externe Kommunikation, Medienbetreuung
Rechtsberatung	Regulatorische Meldepflichten, Beweissicherung, Haftung
Executive Sponsor	Geschäftsentscheidungen, Ressourcenallokation, Stakeholder-Management
Forensik-Analyst	Beweissammlung, Malware-Analyse, Ursachenbestimmung
Operations	Systemwiederherstellung, Backup-Management, Servicekontinuität

Kommunikationsplan

Interne Kommunikation:

Eskalationsmatrix mit Kontaktdaten (Telefon, nicht nur E-Mail)
Einrichtungsverfahren für War-Room oder Incident-Channel
Status-Update-Kadenz (alle 2-4 Stunden bei aktiven Vorfällen)
Need-to-Know-Klassifizierung für sensible Vorfalldetails

Externe Kommunikation:

Regulatorische Meldevorlagen (DSGVO 72 Stunden, NIS2 24 Stunden, DORA 4 Stunden)
Kundenbenachrichtigungsvorlagen (betroffen vs. potenziell betroffen)
Medien-Halteaussage und Sprecher-Benennung
Kriterien und Verfahren für die Einschaltung der Strafverfolgung

Regulatorische Meldepflichten für Vorfälle

DSGVO (Artikel 33-34)

Anforderung	Detail
Wer meldet	Verantwortlicher an Aufsichtsbehörde
Frist	Innerhalb von 72 Stunden nach Bekanntwerden
Schwelle	Verletzungen, die voraussichtlich ein Risiko für die Rechte der Betroffenen darstellen
Benachrichtigung Betroffener	Erforderlich bei hohem Risiko (Artikel 34)
Pflicht des Auftragsverarbeiters	Verantwortlichen unverzüglich benachrichtigen

NIS2 (Artikel 23)

Anforderung	Detail
Frühwarnung	Innerhalb von 24 Stunden nach Bekanntwerden eines erheblichen Vorfalls
Vorfallmeldung	Innerhalb von 72 Stunden mit erster Bewertung
Zwischenberichte	Auf Anfrage des CSIRT oder der zuständigen Behörde
Abschlussbericht	Innerhalb eines Monats nach der Vorfallmeldung
Schwelle	Erhebliche betriebliche Störung oder finanzieller Verlust

DORA (Artikel 17-19)

Anforderung	Detail
Erstmeldung	Innerhalb von 4 Stunden nach Klassifizierung (oder 24 Stunden nach Erkennung)
Zwischenbericht	Innerhalb von 72 Stunden nach Klassifizierung
Abschlussbericht	Innerhalb eines Monats nach dem letzten Zwischenbericht
Klassifizierungskriterien	Betroffene Kunden, Dauer, geografische Ausbreitung, Datenverluste
Freiwillige Meldung	Bedeutende Cyber-Bedrohungen können freiwillig gemeldet werden

ISO 27001

Kontrolle	Anforderung
A.5.24	Planung und Vorbereitung des Vorfallmanagements etablieren
A.5.25	Sicherheitsereignisse bewerten und entscheiden
A.5.26	Gemäß dokumentierter Verfahren reagieren
A.5.27	Aus Vorfällen lernen, um Sicherheit zu verbessern
A.5.28	Beweise ordnungsgemäß sammeln und sichern
A.6.8	Mechanismus zur Meldung von Sicherheitsereignissen bereitstellen

Incident Response für B2B-SaaS-Unternehmen

SaaS-spezifische Überlegungen

Multi-Tenant-Auswirkung: Ein Vorfall in einer Multi-Tenant-Plattform kann alle Kunden gleichzeitig betreffen. Ihr Plan muss Mandantenisolierung, mandantenübergreifende Auswirkungsbewertung und kundenindividuelle Benachrichtigung berücksichtigen.

Geteilte Verantwortung: Cloud-Infrastruktur-Vorfälle können Ihren Cloud-Anbieter (AWS, Azure, GCP) betreffen. Klären Sie Verantwortlichkeiten und Eskalationswege mit Anbietern im Voraus.

Auftragsverarbeiter-Pflichten: Als Auftragsverarbeiter unter der DSGVO müssen Sie Ihre Kunden (Verantwortliche) unverzüglich benachrichtigen, damit diese ihre eigene 72-Stunden-Meldefrist gegenüber den Aufsichtsbehörden einhalten können.

API- und Integrationssicherheit: Vorfälle, die APIs oder Integrationen betreffen, können nachgelagerte Systeme beeinflussen. Identifizieren Sie Abhängigkeiten und Meldepflichten für verbundene Dienste.

Continuous Deployment: Schnelle Release-Zyklen können Schwachstellen einführen. Ihr Incident-Response-Plan sollte Vorfälle abdecken, die aus Deployments entstehen (Rollback-Verfahren, Feature-Flag-Kill-Switches).

Kundenkommunikation während Vorfällen

Best Practices für B2B-Vorfallkommunikation:

Zeitnah benachrichtigen — Direkte Kommunikation an betroffene Kunden, nicht nur ein Statusseiten-Update
Sachlich bleiben — Darlegen, was bekannt ist, was nicht bekannt ist und was untersucht wird
Spekulationen vermeiden — Keine Vermutungen über Zuordnung, Umfang oder Auswirkungen vor Abschluss der Untersuchung
Handlungsempfehlungen geben — Kunden mitteilen, was sie tun müssen (Anmeldedaten rotieren, Zugriffsprotokolle prüfen, eigene Nutzer benachrichtigen)
Regelmäßige Updates — Erwartungen für Update-Frequenz setzen und einhalten
Post-Incident-Bericht veröffentlichen — Zeitverlauf, Grundursache, Abhilfemaßnahmen und geplante Verbesserungen

Incident Response testen

Tabletop-Übungen

Szenariobasierte Diskussionen, bei denen das IRT hypothetische Vorfälle durchspielt:

Keine tatsächlichen Systeme werden beeinträchtigt
Fokus auf Entscheidungsfindung, Kommunikation und Verfahrensvalidierung
Typische Dauer: 2-4 Stunden
Empfohlene Häufigkeit: vierteljährlich
Szenarien einbeziehen, die für Ihre Technologie und Bedrohungslandschaft relevant sind

Funktionale Übungen

Praktische Übungen, die spezifische technische Fähigkeiten testen:

Wiederherstellung aus Backup innerhalb der Recovery-Time-Objectives
Isolierung eines kompromittierten Systems aus dem Netzwerk
Forensische Analyse einer simulierten Kompromittierung durchführen
Kommunikationsverfahren ausführen (intern und extern)
Empfohlene Häufigkeit: halbjährlich

Vollständige Simulationen

End-to-End-Übungen, die den gesamten Incident-Response-Prozess testen:

Simulierter Angriff mit realer (aber kontrollierter) technischer Aktivität
Testet Erkennungsfähigkeiten — kann Ihr Team den Vorfall identifizieren?
Umfasst Geschäftsführungskommunikation und externe Meldeverfahren
Empfohlene Häufigkeit: jährlich
Erwägen Sie die Beauftragung eines Red Teams für mehr Realismus

Häufige Fehler beim Incident Response

Kein Plan bis zum ersten Vorfall

Incident-Response-Verfahren während eines aktiven Vorfalls zu erstellen führt zu Chaos. Die Zeit für Planung ist vor dem Vorfall — nicht währenddessen. Selbst ein grundlegender dokumentierter Plan verbessert die Reaktionseffektivität erheblich.

Unzureichende Protokollierung

Was nicht protokolliert wurde, kann nicht untersucht werden. Stellen Sie umfassende Protokollierung über Anwendungen, Infrastruktur, Authentifizierungssysteme und Netzwerkgrenzen sicher. Bewahren Sie Logs mindestens 12 Monate auf (viele Vorschriften erfordern längere Zeiträume).

Beweisvernichtung

Gut meinende IT-Mitarbeiter, die kompromittierte Systeme sofort neu aufsetzen, vernichten forensische Beweise, die für die Untersuchung und behördliche Meldung benötigt werden. Schulen Sie Personal in Beweissicherung vor der Behebung.

Kommunikationsfehler

Interne Kommunikationszusammenbrüche während Vorfällen verursachen doppelte Arbeit, widersprüchliche Maßnahmen und versäumte Meldungen. Externe Kommunikationsfehler — verspätete, inkonsistente oder irreführende Kundenbenachrichtigungen — zerstören Vertrauen schneller als der Vorfall selbst.

Verzicht auf Post-Incident-Reviews

Jeder Vorfall, auch geringfügige, bietet Lernmöglichkeiten. Organisationen, die Post-Incident-Reviews auslassen, wiederholen dieselben Fehler. Machen Sie Post-Incident-Reviews obligatorisch und schuldfrei.

Wie Orbiq Incident Response unterstützt

Trust Center: Veröffentlichen Sie Ihren Incident-Response-Status, Post-Incident-Berichte und Behebungsstatus für Kundentransparenz
Kontinuierliches Monitoring: Verfolgen Sie Incident-Response-Kontrollen über ISO 27001-, NIS2- und DORA-Anforderungen hinweg
Evidence Management: Zentralisieren Sie Vorfallaufzeichnungen, Post-Mortem-Dokumentation und Übungsberichte, zugeordnet zu Compliance-Frameworks
KI-gestützte Fragebögen: Beantworten Sie Incident-Response-Fragen in Sicherheitsfragebögen automatisch aus Ihren dokumentierten Verfahren

Weiterführende Lektüre

DSGVO-Compliance — Anforderungen an die Meldung von Datenschutzverletzungen unter der DSGVO
Informationssicherheitsleitlinie — Der Richtlinienrahmen für Incident-Response-Verfahren
Compliance-Automatisierung — Automatisierung von Incident-Response-Nachweisen und -Berichten
Penetrationstest — Proaktive Tests, die Vorfälle verhindern

Dieser Leitfaden wird vom Orbiq-Team gepflegt. Letzte Aktualisierung: März 2026.