SOC 2 Incident Response: Anforderungen und Playbook
SOC 2 erfordert eine getestete Incident-Response-Fähigkeit. Dieser Leitfaden behandelt die Anforderungen, wie Sie ein Playbook aufbauen, welche Nachweise Prüfer benötigen und häufige Fehler bei der Vorfallreaktion.
GRCTrail Team
Sicherheitsvorfälle sind für SaaS-Unternehmen keine Hypothese. Sie sind eine betriebliche Realität. Ein falsch konfigurierter S3-Bucket exponiert Kundendaten. Eine kompromittierte Abhängigkeit schleust Schadcode in Ihre Build-Pipeline ein. Ein Credential-Stuffing-Angriff überlastet Ihren Authentifizierungsdienst. Wenn diese Ereignisse eintreten, verlangt SOC 2, dass Sie sie erkennen, systematisch reagieren und daraus lernen — und dass Sie nachweisen können, dass Sie alle drei Schritte durchgeführt haben.
Mehrere Common Criteria adressieren das Incident Management über den gesamten Lebenszyklus: Überwachung auf Anomalien, Bewertung, ob Ereignisse Vorfälle darstellen, Ausführung von Reaktionsverfahren und Kommunikation mit betroffenen Parteien. Prüfer werden nicht einfach prüfen, ob Sie einen Incident-Response-Plan abgelegt haben. Sie werden testen, ob Ihr Team seine Rollen kennt, ob Ihre Erkennungssysteme funktionieren, ob Sie den Plan tatsächlich ausgeführt (oder getestet) haben und ob Post-Incident-Reviews zu Verbesserungen geführt haben.
SOC 2 Anforderungen an Incident Response
CC7.2: Überwacht Systemkomponenten — Ihre Organisation muss Infrastruktur- und Anwendungskomponenten überwachen, um Anomalien zu erkennen.
CC7.3: Bewertet Sicherheitsereignisse — Wenn die Überwachung etwas Abnormales erkennt, benötigen Sie einen definierten Triageprozess.
CC7.4: Reagiert auf Sicherheitsvorfälle — Wenn ein Ereignis als Vorfall klassifiziert wird, müssen Sie dokumentierte Reaktionsverfahren ausführen.
CC7.5: Kommuniziert Sicherheitsvorfälle — Sie müssen betroffene Parteien — Kunden, Regulatoren, Partner — benachrichtigen.
CC2.3: Externe Kommunikation — Adressiert externe Kommunikationsprozesse.
Für ein vollständiges Mapping aller Common Criteria siehe unseren SOC 2 Common Criteria Leitfaden.
Überschneidung mit DSGVO-Meldepflichten: Wenn Ihr SaaS personenbezogene Daten von EU-Einwohnern verarbeitet, löst ein Sicherheitsvorfall mit personenbezogenen Daten DSGVO-Meldepflichten aus — 72 Stunden an die Aufsichtsbehörde. Ihr Incident-Response-Plan muss diese parallelen Fristen berücksichtigen. Siehe unseren DSGVO-Leitfaden zur Meldung von Datenschutzverletzungen.
Aufbau Ihres Incident-Response-Plans
Phase 1: Vorbereitung
Schweregrade definieren:
| Schweregrad | Kriterien | Reaktionszeit | Beispiele |
|---|---|---|---|
| P1 — Kritisch | Aktive Datenschutzverletzung, vollständiger Serviceausfall oder aktive Ausnutzung von Produktionssystemen | Sofort (innerhalb von 15 Minuten) | Kundendatenexfiltration, Ransomware verschlüsselt Produktion, gesamte Plattform nicht verfügbar |
| P2 — Hoch | Teilweise Serviceverschlechterung, bestätigte Schwachstelle wird aktiv angegriffen oder unbefugter Zugriff erkannt | Innerhalb 1 Stunde | Authentifizierungsdienst beeinträchtigt, Brute-Force-Angriff erfolgreich gegen Konten, unbefugter Admin-Zugriff |
| P3 — Moderat | Sicherheitsereignis erfordert Untersuchung, geringe Serviceauswirkung oder Richtlinienverstoß | Innerhalb 4 Stunden | Verdächtige Anmeldemuster, nicht-kritischer Serviceausfall, Mitarbeiter greift auf unbefugte Ressourcen zu |
| P4 — Niedrig | Informelle Sicherheitsereignisse, Beinahe-Vorfälle oder geringe Richtlinienausnahmen | Innerhalb 24 Stunden | Fehlgeschlagener Phishing-Versuch (keine Credentials kompromittiert), Schwachstellenscan-Ergebnis, Sicherheitstool-Fehlkonfiguration |
Das Incident-Response-Team aufstellen:
- Incident Commander — Verantwortet die Reaktion. Trifft Entscheidungen zu Eindämmungsstrategie, Ressourceneinsatz und Kommunikationstiming.
- Technical Lead — Leitet die technische Untersuchung und Behebung.
- Communications Lead — Verwaltet interne und externe Kommunikation. Erstellt Kundenbenachrichtigungen, koordiniert mit der Rechtsabteilung.
- Scribe — Dokumentiert alles in Echtzeit. Diese Rolle ist kritisch für das Post-Incident-Review und für Audit-Nachweise.
Kommunikationskanäle einrichten. Dedizierter Incident-Slack-Channel, PagerDuty-Eskalationsrichtlinien, War-Room-Verfahren, Out-of-Band-Kommunikation.
Benachrichtigungsvorlagen vorbereiten. Vorlagen für initiale Kundenbenachrichtigung, Status-Updates, Lösungsbenachrichtigung und regulatorische Meldung (siehe DSGVO-Meldung von Datenschutzverletzungen).
Eskalationswege dokumentieren. Verknüpfen Sie Ihre Incident-Response-Verfahren mit Ihrem breiteren Richtlinien- und Verfahren-Framework.
Phase 2: Erkennung und Analyse
Monitoring- und Alerting-Systeme: SIEM oder Log-Aggregation, APM, Infrastruktur-Monitoring, EDR, Cloud-Security-Monitoring (AWS CloudTrail, GCP Audit Logs, Azure Activity Logs).
Triageprozess: Alert verifizieren, Ereignis klassifizieren, Schweregrad zuweisen, Reaktion aktivieren.
Beweissicherung. Ab dem Moment, in dem ein Vorfall vermutet wird, forensische Beweise sichern.
Phase 3: Eindämmung
Kurzfristige Eindämmung: Betroffene Systeme isolieren, kompromittierte Credentials widerrufen, bösartige IPs blockieren, kompromittierte Benutzerkonten deaktivieren.
Langfristige Eindämmung: Patches deployen, zusätzliches Monitoring implementieren, temporäre Zugriffskontrollen einrichten.
Kundenkommunikation während der Eindämmung. Für P1- und P2-Vorfälle früh und ehrlich kommunizieren. Statusseite aktualisieren, proaktive Benachrichtigungen senden.
Phase 4: Beseitigung und Wiederherstellung
Ursachenidentifikation. Genau bestimmen, wie der Vorfall aufgetreten ist.
Bedrohung beseitigen. Schwachstelle patchen, Malware entfernen, kompromittierte Systeme aus bekannt sicheren Images neu aufbauen, alle möglicherweise exponierten Credentials rotieren.
Systemwiederherstellung und -validierung. Vor der Servicewiederherstellung: Patch verifizieren, unbefugte Zugriffsmechanismen bestätigt entfernt, Datenintegrität validieren, Sicherheitsscans durchführen.
Auf Wiederauftreten überwachen. Nach der Wiederherstellung mindestens 30 Tage erhöhtes Monitoring aufrechterhalten.
Phase 5: Post-Incident-Review
Schuldzuweisungsfreier Post-Mortem-Prozess. Innerhalb von 5 Werktagen nach Vorfallslösung durchführen.
Folgendes dokumentieren: Zeitablauf, Ursache, Auswirkung, Was gut lief, Was verbessert werden könnte, Maßnahmen.
Risikoregister aktualisieren. Jeder Vorfall sollte in Ihre Risikobewertung einfließen.
Erkenntnisse organisationsübergreifend teilen.
Incident-Response-Tests
Tabletop-Übungen — Hypothetische Szenarien mit dem Reaktionsteam durchgehen. Verschiedene Szenarien abdecken: Datenschutzverletzung, Ransomware, DDoS, Insider-Bedrohung, Lieferantenkompromittierung.
Simulierte Vorfälle — Realistische Sicherheitsereignisse in Ihre Monitoring-Systeme einspeisen.
Red-Team-Übungen — Externes Team beauftragt, echte Angriffe zu simulieren.
Häufigkeit: Mindestens eine Tabletop-Übung jährlich. Testergebnisse und Verbesserungen dokumentieren — dies ist ein wichtiger Audit-Nachweis.
Was Prüfer testen
Incident-Response-Richtlinie und -Verfahren existieren und sind aktuell.
Teammitglieder kennen ihre Rollen. Prüfer können Teammitglieder interviewen.
Monitoring- und Erkennungsfähigkeiten sind vorhanden und funktionieren.
Nachweise der tatsächlichen Vorfallbehandlung. Wenn Sicherheitsvorfälle während des Beobachtungszeitraums auftraten.
Nachweise von Tests.
Post-Incident-Reviews und Folgemaßnahmen. Prüfer wollen sehen, dass Erkenntnisse in tatsächliche Verbesserungen umgesetzt wurden.
Häufige Fehler
Keine definierten Schweregrade.
Incident-Response-Plan, der nie getestet wurde.
Kein Post-Incident-Review-Prozess.
Verzögerungen bei der Kundenbenachrichtigung. Kunden und Regulatoren erwarten zeitnahe Benachrichtigung, auch wenn die initialen Informationen unvollständig sind.
Forensische Beweise nicht sichern.
Incident-Response-Team, das nicht-technische Stakeholder ausschließt. Rechtsbeistand, Customer Success und Führungskräfte einbeziehen.
Wie GRCTrail hilft
- Incident-Response-Playbook-Vorlagen für gängige SaaS-Vorfalltypen — Datenschutzverletzung, Ransomware, DDoS, Insider-Bedrohung, Lieferantenkompromittierung
- Incident-Tracking und Zeitablauf-Dokumentation in einem mit Zeitstempeln versehenen, prüfbaren Format
- Benachrichtigungs-Workflow-Management, das Kunden- und regulatorische Meldepflichten, Fristen und Abschlussstatus verfolgt
- Post-Incident-Review-Vorlagen mit strukturierten Feldern
- Automatische Audit-Nachweiserstellung
Verwandte Leitfäden
Verwandte Artikel
Der SOC 2 Audit-Prozess: Zeitplan, Schritte und was Sie erwartet
Eine schrittweise Anleitung zum SOC 2 Audit-Prozess, von der Auswahl eines Prüfers bis zum Erhalt Ihres Berichts. Behandelt Zeitpläne, Vorbereitung und was Prüfer bewerten.
SOC 2 Common Criteria (CC) Kontrollen erklärt
Eine detaillierte Aufschlüsselung aller neun SOC 2 Common-Criteria-Kategorien (CC1-CC9), was jede erfordert und wie SaaS-Unternehmen Kontrollen für jede implementieren sollten.
SOC 2 Compliance-Checkliste für SaaS-Unternehmen
Eine umfassende SOC 2 Compliance-Checkliste, die jeden Schritt von der Scoping-Phase bis zum Audit-Abschluss abdeckt. Erstellt für SaaS-Teams, die sich auf ihren ersten oder nächsten SOC 2 Bericht vorbereiten.