SOC 2
SOC 2 ist ein Attestierungsbericht über die Kontrollen einer Dienstleistungsorganisation anhand der AICPA Trust Services Criteria. Erfahren Sie, wie SOC 2 funktioniert, Typ I vs. Typ II und welche Relevanz es für AI hat.
Was SOC 2 tatsächlich ist
SOC 2 ist keine Zertifizierung und kein Bestanden/Nicht-bestanden-Abzeichen. Es ist eine Attestierungsleistung, die nach den Attestierungsstandards des American Institute of Certified Public Accountants (AICPA) durchgeführt wird. Eine lizenzierte CPA-Gesellschaft — die einzige Partei, die einen SOC-2-Bericht ausstellen darf — prüft die Kontrollen einer Dienstleistungsorganisation und gibt ein unabhängiges Urteil darüber ab, ob diese Kontrollen die anwendbaren Trust Services Criteria erfüllen.
Das Ergebnis ist ein Bericht, kein Logo. Ein SOC-2-Bericht enthält das Urteil des Prüfers, die Erklärung des Managements, eine Beschreibung des geprüften Systems und — bei einem der Berichtstypen — die detaillierten Tests, die der Prüfer durchgeführt hat, samt deren Ergebnissen. Da es sich um eine Attestierung handelt, liegt der Wert im evidenzbasierten Urteil des Prüfers, nicht in einer Marketingaussage.
SOC-2-Berichte werden typischerweise unter einer Nutzungsbeschränkung ausgestellt, das heißt, sie werden unter NDA mit Kunden, Interessenten und deren Prüfern geteilt, statt offen veröffentlicht zu werden. Dies unterscheidet SOC 2 von SOC 3, einem zur allgemeinen Nutzung bestimmten Zusammenfassungsbericht über dieselbe Prüfung, den eine Organisation öffentlich verbreiten darf.
Die Trust Services Criteria
SOC 2 baut auf fünf Trust Services Criteria (TSC) auf. Security — als Common Criteria bezeichnet — ist stets erforderlich; die übrigen vier werden nur einbezogen, wenn sie für die von der Organisation erbrachten Dienstleistungen und die ihren Kunden gegenüber gemachten Zusagen relevant sind. Ein Anbieter beschränkt den Geltungsbereich seines Berichts auf die Kriterien, die seinen Pflichten entsprechen.
| Trust Services Criterion | Erforderlich? | Was es bewertet |
|---|---|---|
| Security (Common Criteria) | Immer | Schutz von Systemen und Daten vor unbefugtem Zugriff, Offenlegung und Beschädigung — Zugriffskontrolle, Change-Management, Risikobewertung, Überwachung |
| Availability | Optional | Ob Systeme wie zugesagt für Betrieb und Nutzung verfügbar sind, einschließlich Resilienz, Wiederherstellung und Kapazität |
| Processing Integrity | Optional | Ob die Systemverarbeitung vollständig, valide, korrekt, zeitgerecht und autorisiert ist |
| Confidentiality | Optional | Schutz von als vertraulich eingestuften Informationen über ihren gesamten Lebenszyklus, einschließlich Handhabung und Entsorgung |
| Privacy | Optional | Erhebung, Nutzung, Aufbewahrung, Offenlegung und Entsorgung personenbezogener Informationen im Einklang mit der Datenschutzerklärung der Organisation |
Da die Kriterien namentlich statt durch feste Kontrollnummern bezeichnet werden, können zwei Organisationen SOC-2-Berichte sehr unterschiedlicher Tiefe vorweisen. Ein Bericht, der nur Security abdeckt, ist bedeutend enger als einer, der Security, Confidentiality und Privacy abdeckt. Zu lesen, welche Kriterien im Geltungsbereich liegen, ist der erste Schritt bei der Bewertung jedes SOC-2-Berichts.
Typ I im Vergleich zu Typ II
SOC-2-Berichte gibt es in zwei Typen, und die Unterscheidung ist zentral dafür, wie viel Sicherheit ein Bericht bietet. Ein Typ-I-Bericht beschreibt die Kontrollen einer Dienstleistungsorganisation und beurteilt, ob sie zu einem einzelnen Zeitpunkt angemessen gestaltet sind. Ein Typ-II-Bericht geht weiter: Er testet, ob diese Kontrollen über einen festgelegten Prüfzeitraum hinweg — typischerweise drei bis zwölf Monate — wirksam funktioniert haben.
| SOC 2 Typ I | SOC 2 Typ II | |
|---|---|---|
| Was geprüft wird | Gestaltung der Kontrollen | Gestaltung und Wirksamkeit im Betrieb |
| Zeitrahmen | Ein einzelner Zeitpunkt | Ein Zeitraum (üblicherweise 3–12 Monate) |
| Nachweis | Kontrollen existieren und sind gut gestaltet | Kontrollen wurden getestet und funktionierten durchgängig |
| Sicherheitsniveau | Niedriger — eine Momentaufnahme | Höher — nachgewiesene Leistung über die Zeit |
| Typische Nutzung | Erster Bericht; neue Kontrollprogramme | Laufende Sicherheit; was die meisten Käufer verlangen |
In der Praxis bevorzugen Enterprise-Käufer Typ II deutlich, da ein zeitpunktbezogenes Gestaltungsurteil nichts darüber aussagt, ob die Kontrollen im Alltag tatsächlich befolgt wurden. Viele Organisationen stellen einen Typ I als ersten Meilenstein aus und gehen dann zu einem jährlichen Typ-II-Zyklus über. Ein SOC-2-Bericht trägt zudem ein „as of"- oder Abdeckungsdatum; ein Bericht, dessen Zeitraum lange zurückliegt, bietet schwächere aktuelle Sicherheit, weshalb Käufer aktuelle Berichte verlangen und zwischen den Zyklen ein Bridge Letter des Anbieters.
Wie SOC 2 in der Lieferantenprüfung genutzt wird
Für die meisten B2B-Software-Käufer ist SOC 2 die Eintrittskarte zu einer Sicherheitsprüfung. Wenn eine Organisation einen Anbieter bewertet, der ihre Daten verarbeiten wird, fordert das Sicherheits- oder Beschaffungsteam den SOC-2-Bericht des Anbieters an und liest ihn, statt einer Behauptung von „SOC-2-konform" zu vertrauen.
Eine gründliche Prüfung betrachtet mehrere Dinge: welche Trust Services Criteria im Geltungsbereich liegen, ob der Bericht Typ I oder Typ II ist, die Länge und Aktualität des Prüfzeitraums, das Urteil des Prüfers (ein uneingeschränktes Urteil ist sauber; ein eingeschränktes Urteil weist auf Ausnahmen hin), etwaige festgestellte Ausnahmen und die Reaktion des Managements sowie die komplementären Kontrollen der Nutzerorganisation (Complementary User-Entity Controls), die der Bericht beim Kunden voraussetzt. Subdienstleister — die eigenen kritischen Anbieter des Anbieters — werden ebenfalls offengelegt, sodass ein Käufer erkennen kann, was aus dem Geltungsbereich ausgeklammert ist.
SOC 2 ersetzt nicht die eigene Sorgfaltsprüfung eines Käufers, aber es konsolidiert eine große Menge unabhängiger Nachweise in einem Dokument, weshalb es zu einer nahezu universellen Anforderung in der Enterprise-Beschaffung geworden ist.
Warum SOC 2 für AI von Bedeutung ist
Während Organisationen AI-Tools und AI-gestützte Anbieter einführen, ist SOC 2 in zwei Richtungen zu einem Brennpunkt für AI-Risiko geworden.
Erstens sind AI-Anbieter selbst Dienstleistungsorganisationen. Ein Unternehmen, das einen AI-Assistenten, eine Modell-API oder ein agentisches Produkt anbietet, verarbeitet Kundendaten, und Käufer verlangen zunehmend einen SOC-2-Bericht, bevor sie es freigeben — genau wie bei jedem SaaS-Anbieter. AI-Funktionen, die in bestehende Produkte eingebettet sind, fallen in den Geltungsbereich der SOC-2-Prüfung dieses Produkts, was bedeutet, dass die Kontrollen rund um Modellzugriff, Datenhandhabung und Protokollierung nun Teil dessen sind, was Prüfer und Kunden unter die Lupe nehmen.
Zweitens schafft die eigene Einführung von AI in einer Organisation neue Kontrollziele, die auf die Trust Services Criteria abbilden. Sensible Daten, die in Prompts und Tool-Calls fließen, berühren Confidentiality und Privacy. Der Zugriff auf AI-Modelle und Agenten berührt Security. Die Fähigkeit nachzuweisen, wer welches AI-Tool genutzt hat, welche Daten übermittelt wurden und was autonome Agenten getan haben, berührt die Überwachungs- und Protokollierungserwartungen innerhalb der Common Criteria. Prüfer und Kunden fragen nun, wie die AI-Nutzung gesteuert wird, nicht nur, ob es der Rest der Umgebung ist.
Die praktische Folge ist, dass AI-Governance Teil der SOC-2-Bereitschaft wird. Organisationen, die keine Kontrolle über AI-Zugriff, Datenexposition durch Prompts und Agenten-Aktionen nachweisen können, sehen sich in ihren eigenen Audits und in der Sorgfaltsprüfung, die ihre Kunden über sie durchführen, mit Fragen konfrontiert.
