SOC 2 Compliance,
verständlich erklärt

SOC 2 ist ein Attestierungsbericht über die Controls, mit denen eine Dienstleistungsorganisation Kundendaten schützt. Er ist Teil des System and Organization Controls Frameworks der AICPA und wird nach dem Attestierungsstandard SSAE 18 durchgeführt. Die Arbeit übernimmt eine lizenzierte CPA-Firma, und das Ergebnis ist ein Bericht mit dem Prüfurteil, ob Ihre Controls die Kriterien erfüllen, gegen die Sie berichten.

Das mit Abstand Wichtigste ist: SOC 2 ist keine Zertifizierung. Es gibt kein "SOC 2 certificate" und keine Stelle, die Sie zertifiziert. Sie sind nicht "SOC 2 certified", sondern haben einen SOC 2 Bericht. Der Unterschied ist keine Wortklauberei: Er ändert, was Sie behaupten dürfen, was ein Kunde tatsächlich prüft und wie der gesamte Prozess aufgebaut ist. Ein Auditor stempelt kein Bestanden ab, sondern bildet sich ein fachliches Urteil über Ihr System und hält es schriftlich fest.

Weil es ein Bericht ist und kein Abzeichen, kommt es auf den Inhalt an. Ein SOC 2 Bericht enthält eine Beschreibung Ihres Systems, die vorhandenen Controls, die vom Auditor durchgeführten Tests, deren Ergebnisse und das daraus gebildete Urteil. Das Sicherheitsteam eines Interessenten liest den Bericht, es hakt nicht einfach ein Kästchen ab, das besagt, dass Sie einen haben.

Eine SOC 2 Prüfung gibt es in zwei Formen, und der Unterschied ist die Zeit. Ein Type-I-Bericht beurteilt, ob Ihre Controls zu einem einzelnen Zeitpunkt geeignet gestaltet sind, also eine Momentaufnahme. Der Auditor betrachtet Ihre Controls an einem bestimmten Datum und bildet sich ein Urteil, ob sie wie gestaltet die Kriterien erfüllen würden. Über den Alltag, ob die Controls Tag für Tag liefen, sagt er nichts.

Ein Type-II-Bericht beurteilt, ob Ihre Controls über einen Zeitraum wirksam funktioniert haben: ein Beobachtungsfenster, typischerweise irgendwo zwischen drei und zwölf Monaten. Statt einer Momentaufnahme zieht der Auditor Stichproben über das gesamte Fenster, um zu prüfen, dass jedes Control durchgehend tat, was es sollte. Das nachzuweisen ist deutlich schwerer, denn das Control muss gelaufen sein und die Nachweise müssen vorliegen, über Monate, bevor der Auditor überhaupt hinschaut.

In der Praxis wollen Kunden den Type II. Ein Type I sagt einem Käufer, dass Ihre Controls an einem Tag richtig aussahen, ein Type II sagt ihm, dass Ihre Controls über einen echten Zeitraum funktioniert haben. Viele Teams starten mit einem Type I, um schnell etwas in der Hand zu haben, und wechseln zum Type II, sobald die Controls eine Vorgeschichte haben. Das Ziel aber, nach dem fast alle fragen, ist der Type II.

SOC 2 wird gegen die Trust Services Criteria (TSC) bewertet, einen Satz von Kriterien, den die AICPA pflegt und der auf dem internen Kontrollrahmen COSO aufbaut. Es gibt fünf Kategorien, und ein verbreiteter Irrtum ist, dass Sie alle abdecken müssen. Müssen Sie nicht. Sie wählen, welche Kategorien im Geltungsbereich liegen, anhand der Zusagen, die Sie Kunden machen.

Security (auch Common Criteria genannt) ist immer erforderlich. Sie ist das Fundament jedes SOC 2 Berichts und deckt den Schutz des Systems vor unbefugtem Zugriff, Offenlegung und Schaden ab. Zusätzlich zu Security ergänzen Sie eine beliebige von vier optionalen Kategorien: Availability (das System ist wie zugesagt für Betrieb und Nutzung verfügbar), Processing Integrity (die Verarbeitung ist vollständig, gültig, korrekt, zeitgerecht und autorisiert), Confidentiality (als vertraulich eingestufte Informationen sind geschützt) und Privacy (personenbezogene Daten werden im Einklang mit Ihren Zusagen erhoben, genutzt, aufbewahrt und entsorgt).

Kategorien hinzuzufügen ist nicht kostenlos. Jede bringt eigene Kriterien, eigene Controls und eigene Nachweise mit, die aktuell zu halten sind. Der richtige Geltungsbereich ist der kleinste Satz, der ehrlich widerspiegelt, was Sie Kunden versprechen. Ein SaaS-Produkt mit einer Verfügbarkeitszusage in den Verträgen hat einen klaren Grund, Availability aufzunehmen. Ein Team, das keine personenbezogenen Daten im Auftrag von Kunden verarbeitet, hat meist keinen Grund, Privacy zu übernehmen. Kriterien zu wählen, die Sie nicht belegen können, macht die Prüfung nur schwerer.

SOC 2 wird selten um seiner selbst willen angestrebt. Die meisten Teams starten, weil ein Kunde gefragt hat. Es taucht in einem Security Review, einem Beschaffungsfragebogen oder einer Lieferantenrisikobewertung auf, meist von einem Käufer aus den USA. SOC 2 stammt aus den Vereinigten Staaten und ist zum De-facto-Vertrauensstandard für SaaS- und Cloud-Anbieter geworden, die dort verkaufen. Wenn Sie Software an amerikanische Unternehmen jeder Grösse verkaufen, kommt die Anfrage früher oder später, und oft blockiert sie einen Abschluss, bis Sie sie beantworten können.

Es funktioniert, weil ein Käufer damit die Frage auslagern kann, die er nicht selbst beantworten kann: "can I trust this vendor with our data?" Statt Sie direkt zu auditieren oder einen endlosen Fragebogen zu schicken, verlangt er einen SOC 2 Bericht einer unabhängigen CPA-Firma und liest das Urteil. Für den Anbieter wird aus "fill out our 200-question security review" ein "here is our SOC 2, under NDA". Genau deshalb behandeln Teams, die genug Enterprise-Abschlüsse gewinnen, es irgendwann als Eintrittskarte.

Der praktische Test, ob Sie es brauchen, ist einfach: Verlieren oder verzögern sich Abschlüsse, weil ein Kunde eine unabhängige Bestätigung Ihrer Sicherheit will und Sie sie nicht geben können? Im US-Markt ist SOC 2 meist die am breitesten anerkannte Antwort, und der grösste Teil des Wegs dorthin besteht darin, Sicherheit gut zu betreiben und die Nachweise zu führen.

Die ersten echten Entscheidungen in einem SOC 2 Projekt sind, gegen welche Trust Services Criteria Sie berichten und was "the system" eigentlich ist. Die Systembeschreibung (ein vorgeschriebener Teil des Berichts) legt die Grenze fest: welches Produkt, welche Infrastruktur, welche unterstützenden Prozesse und welche Menschen die Prüfung abdeckt. Ziehen Sie sie zu weit, haben Sie sich verpflichtet, alles auf einmal zu belegen. Ziehen Sie sie zu eng, deckt der Bericht nicht ab, wonach Ihr Kunde fragt.

Die meisten Teams legen den Geltungsbereich von SOC 2 rund um das Produkt, das ihre Kunden kaufen, und die Infrastruktur und Prozesse, die es betreiben, und wählen dann Kriterien passend zu den Versprechen, die sie über dieses Produkt machen. Die Systembeschreibung ist klar genug geschrieben, dass ein Leser des Berichts (der Sicherheitsprüfer eines Interessenten) genau erkennt, was geprüft wurde und was nicht.

Bei einem Type-II-Bericht liegt der Schwerpunkt auf dem Beobachtungszeitraum, dem Fenster, über das der Auditor prüft, dass Ihre Controls wirksam funktioniert haben. Üblich sind drei bis zwölf Monate. Ein erster Type II nutzt oft ein kürzeres Fenster, um schneller einen Bericht zu liefern, spätere Berichte decken dann ein volles Jahr ab. Wie lang auch immer, der Zeitraum hat eine harte Folge: Die Nachweise müssen für das gesamte Fenster vorliegen, laufend gesammelt, nicht in der Woche vor dem Eintreffen des Auditors zusammengetragen.

Hier entscheidet sich SOC 2 im Betrieb. Der Auditor zieht Stichproben über den Zeitraum (Zugriffsüberprüfungen, die quartalsweise hätten stattfinden sollen, Änderungsfreigaben bei Deployments, Vorfallsaufzeichnungen, Lieferantenbewertungen) und verlangt den Beleg, dass jedes Control an den vorgesehenen Daten lief. Ein Control, das in der Richtlinie existiert, aber über den Zeitraum keine Nachweisspur hat, ist für einen Type II ein Control, das nicht funktioniert hat. Teams, die Nachweise laufend fliessen lassen, kommen glatt durch. Teams, die zehn Monate Zugriffsüberprüfungen im Nachhinein rekonstruieren wollen, nicht.

Die andere Folge ist das Timing. Weil ein Type II rückblickend über einen echten Zeitraum schaut, können Sie die Prüfung nicht starten und in der Woche darauf einen sauberen Bericht haben. Der Zeitraum muss bereits stattgefunden haben, mit laufenden Controls. Das Beobachtungsfenster zu planen und sicherzustellen, dass die Controls ab dem Startdatum wirklich laufen, ist der grösste Teil dessen, was die Vorbereitung auf einen Type II ausmacht.

Eine SOC 2 Prüfung muss von einer unabhängigen, lizenzierten CPA-Firma durchgeführt werden. Diese Unabhängigkeit gibt dem Bericht sein Gewicht, und deshalb kann niemand SOC 2 selbst zertifizieren. Die Firma plant den Auftrag, prüft Ihre Systembeschreibung, testet Ihre Controls gegen die Kriterien im Geltungsbereich und stellt den Bericht mit ihrem Urteil aus. Bei einem Type II bedeutet dieses Testen, Nachweise über den Beobachtungszeitraum zu sampeln, statt einen einzelnen Tag zu prüfen.

Das Urteil zu Beginn des Berichts ist das, wonach ein Leser zuerst sucht. Ein uneingeschränktes Urteil bedeutet, der Auditor hat Ihre Controls als geeignet gestaltet und, bei einem Type II, über den Zeitraum wirksam betrieben befunden, ohne wesentliche Ausnahmen. Ein eingeschränktes Urteil bedeutet, er hat eine oder mehrere Ausnahmen gefunden, die bedeutend genug sind, um sie zu nennen: ein Control, das nicht wie beschrieben funktioniert hat, eine Lücke in den Nachweisen, ein nicht vollständig erfülltes Kriterium. Ein Bericht kann auch mit einem eingeschränkten Urteil nützlich sein, doch die Einschränkung sagt dem Leser genau, wo er hinschauen muss. Es lohnt sich also, jede Ausnahme zu verstehen, bevor der Bericht finalisiert wird.

Die Wahl der Firma zählt mehr, als ihr Preisschild vermuten lässt. Eine Firma, die Software und Cloud-Infrastruktur kennt, verlangt Nachweise in einer Form, die Ihr Team auch liefern kann. Eine, die das nicht tut, macht aus dem Auftrag eine Übersetzungsübung. So oder so liegt der grösste Teil des Aufwands bei Ihnen. Die Firma testet, was Sie ihr geben, also bestimmen Qualität und Verfügbarkeit Ihrer Nachweise den Ton der gesamten Prüfung.

Ein SOC 2 Bericht deckt einen bestimmten Zeitraum ab, und dann endet dieser Zeitraum. Weil Kunden eine aktuelle Bestätigung wollen, ist SOC 2 keine einmalige Übung: Die meisten Teams erstellen jedes Jahr einen neuen Type-II-Bericht für den nächsten Beobachtungszeitraum, damit es immer einen aktuellen Bericht zum Teilen gibt. Die Arbeit, die den ersten Bericht eingebracht hat (Zugriffsüberprüfungen im Rhythmus halten, Änderungsfreigaben festhalten, Vorfälle protokollieren, Lieferantenbewertungen durchführen), ist dieselbe Arbeit, die jeden weiteren Bericht erzeugt. Teams, die die erste Prüfung als Sprint behandeln, spüren die Kosten jedes Jahr erneut. Teams, die die Controls in ihren Alltag einbauen, nicht.

Zwischen dem Ende des Zeitraums eines Berichts und dem Beginn des nächsten klafft eine Lücke, und Kunden, die eine aktuelle Bestätigung verlangen, brauchen etwas, das sie überbrückt. Dafür gibt es den Bridge Letter (manchmal Gap Letter genannt): eine kurze Erklärung, meist von Ihrem Management, die bestätigt, dass die im jüngsten Bericht beschriebenen Controls ohne wesentliche Änderungen weiter funktioniert haben, über die Lücke hinweg. Er ersetzt den Bericht nicht und trägt nicht das Prüfurteil, aber er erlaubt Ihnen, ein Security Review in den Monaten zwischen den Prüfungen ehrlich zu beantworten.

Es gibt keinen einheitlichen Preis für SOC 2, weil der grösste Teil der Kosten Ihr eigener Aufwand ist und kein Posten auf einer Rechnung. Die CPA-Firma verrechnet eine Gebühr für die Prüfung, abgestuft nach den Kriterien im Geltungsbereich, der Grösse Ihres Systems und ob es ein Type I oder ein Type II ist. Diese Gebühr ist meist der kleinere Teil, und ein Type II kostet mehr als ein Type I, weil über einen Zeitraum mehr zu testen ist.

Der grössere Kostenblock ist es, die Controls aufzubauen und zu betreiben und die Nachweise über den gesamten Beobachtungszeitraum aktuell zu halten: das System festlegen, Kriterien wählen, Richtlinien schreiben, die Controls Monat für Monat betreiben und die Belege sammeln, die ein Auditor per Stichprobe prüft. Teams, die das aus Tabellen und geteilten Laufwerken zusammensetzen, zahlen bei jedem Jahresbericht erneut, in der Zeit, die es kostet, Nachweise zu rekonstruieren, die nie an einem Ort lagen.

Zwei Hebel bewegen die Gesamtkosten stärker als die Gebühr der Firma. Der erste ist der Geltungsbereich: Jede zusätzliche Trust Services Criteria bringt mehr Controls und mehr Nachweise, also hält das Berichten nur gegen die Kriterien, die Ihre Zusagen wirklich verlangen, den Aufwand verhältnismässig. Der zweite ist, die Controls laufend zu pflegen, statt die Nachweise vor der Prüfung jedes Jahres neu aufzubauen. Das ist der Unterschied zwischen einem Bericht, der grösstenteils Verwaltung ist, und einem, der zur Hetzjagd wird.