Sofortantwort
SOC 2 einfach erklärt
Compliance-Standard für Sicherheit und Datenschutz bei Cloud-Services.
- Kurz gesagt
- 5 Trust Principles: Security, Availability, Processing Integrity, Confidentiality, Privacy
- Typischer Einsatz
- SaaS-Anbieter, Cloud-Services, Vendor-Auswahl
- Wichtig zu wissen
- Oft Voraussetzung für Enterprise-Deals
SOC 2 im Überblick
SOC 2 ist ein Audit-Standard, der bestätigt, dass ein Unternehmen Sicherheitskontrollen implementiert hat.
Die 5 Trust Principles:
| Prinzip | Frage |
|---|---|
| Security | Sind Systeme vor unbefugtem Zugriff geschützt? |
| Availability | Sind Systeme verfügbar wie versprochen? |
| Processing Integrity | Werden Daten korrekt verarbeitet? |
| Confidentiality | Sind vertrauliche Daten geschützt? |
| Privacy | Werden personenbezogene Daten korrekt behandelt? |
Technisch betrachtet
Typische Kontrollen
| Bereich | Kontrolle |
|---|---|
| Access Control | MFA, RBAC, Least Privilege |
| Encryption | At Rest, In Transit |
| Monitoring | Audit Logs, Alerting |
| Incident Response | Dokumentierter Prozess |
| Change Management | Code Review, Approvals |
Ablauf eines SOC-2-Audits
1. Scoping
└── Welche Trust Principles? Welche Systeme?
2. Gap-Analyse & Readiness Assessment
└── Wo fehlen Kontrollen oder Nachweise?
3. Kontrollen implementieren
└── Policies, technische Maßnahmen, Evidenz-Sammlung
4. Beobachtungszeitraum (nur Type II)
└── Kontrollen müssen über Monate nachweisbar funktionieren
5. Audit durch CPA-Firma
└── Prüfung und Erstellung des Reports
6. Report an Kunden weitergeben
└── Meist unter NDA, da vertrauliche Details enthalten
Wichtig: SOC 2 ist keine Zertifizierung mit Siegel, sondern ein Attestierungsbericht einer Wirtschaftsprüfungsgesellschaft. Der Report beschreibt die geprüften Kontrollen und dokumentiert Ausnahmen (“Exceptions”) – Enterprise-Kunden lesen ihn im Rahmen ihres Vendor-Risk-Managements.
SOC 2 für KI-Anbieter und KI-Nutzer
Für Unternehmen, die KI-Produkte anbieten oder LLM-Dienste einkaufen, spielt SOC 2 eine wachsende Rolle:
- Vendor-Prüfung von LLM-Providern: Wer Kundendaten an einen KI-Dienst schickt, sollte dessen SOC-2-Report anfordern und prüfen – insbesondere die Confidentiality-Kontrollen und den Umgang mit Daten für Trainingszwecke.
- KI-Features im eigenen Scope: Baut ein SaaS-Anbieter LLM-Funktionen ein, gehören die entsprechenden Datenflüsse, API-Keys und Subprozessoren in den Audit-Scope. Neue KI-Subprozessoren müssen Kunden meist vertraglich angezeigt werden.
- Nachvollziehbarkeit von KI-Agenten: Wenn autonome Agenten auf Produktionsdaten zugreifen, erwarten Auditoren dieselben Kontrollen wie bei menschlichen Nutzern – eigene Identitäten, Least Privilege und Audit Logging.
- Evidenz automatisieren: Compliance-Automatisierungsplattformen sammeln Nachweise (Zugriffsreviews, Monitoring-Daten) kontinuierlich – das reduziert den manuellen Aufwand im Beobachtungszeitraum erheblich.
Typische Stolperfallen
| Fehler | Folge |
|---|---|
| Alle 5 Trust Principles wählen | Unnötig großer Scope – Security ist Pflicht, der Rest optional nach Kundenbedarf |
| Kontrollen erst kurz vor Audit einführen | Type II verlangt Nachweise über den gesamten Zeitraum |
| Evidenz manuell sammeln | Hoher Aufwand, lückenhafte Nachweise |
| Report als Marketing-Siegel missverstehen | SOC 2 ist ein vertraulicher Bericht, kein Logo-Programm |
| Subprozessoren vergessen | Auch Dienstleister (inkl. LLM-Provider) gehören ins Vendor-Management |
Abgrenzung zu verwandten Begriffen
- SOC 1 prüft Kontrollen mit Relevanz für die Finanzberichterstattung der Kunden – nicht Informationssicherheit allgemein.
- SOC 3 ist die öffentliche Kurzfassung eines SOC-2-Reports ohne vertrauliche Details.
- ISO 27001 zertifiziert ein Managementsystem nach internationalem Standard; SOC 2 attestiert konkrete Kontrollen. In Europa wird oft ISO 27001 erwartet, in Nordamerika SOC 2 – viele Anbieter brauchen beides.