SOC 2 — Prüfbericht statt Zertifikat

SOC 2 ist ein Prüfungsformat für Dienstleister, die Daten ihrer Kunden verarbeiten. Der Anbieter beschreibt sein System und die Kontrollen, mit denen er es steuert. Eine Wirtschaftsprüfungsgesellschaft prüft diese Beschreibung und die Kontrollen und gibt ein Urteil ab. Das Ergebnis ist ein Bericht, der an Kunden weitergegeben wird — meist unter einer Vertraulichkeitsvereinbarung, denn er enthält interne Details.

Der Standard stammt vom amerikanischen Berufsverband der Wirtschaftsprüfer und beruht auf dessen Prüfungsstandards. Das erklärt die wichtigste Eigenheit: SOC 2 ist keine Norm mit Anforderungskatalog, sondern ein Prüfungsrahmen. Die Kriterien geben Themen und Zielsetzungen vor, die konkreten Kontrollen formuliert der Anbieter selbst. Zwei SOC-2-Berichte können deshalb sehr unterschiedliche Sicherheitsniveaus abbilden — und beide sind formal in Ordnung.

In Deutschland spielt SOC 2 vor allem im Vertrieb eine Rolle. Wer Software als Dienst an amerikanische Unternehmen verkauft, wird im Beschaffungsprozess danach gefragt, und ein ISO-27001-Zertifikat wird dort häufig nicht als gleichwertig anerkannt — auch wenn es inhaltlich mehr aussagt.

Was geprüft wird

Grundlage sind die Trust Services Criteria. Verpflichtend ist immer die Kategorie Sicherheit, die sogenannten Common Criteria. Die übrigen vier Kategorien wählt der Anbieter nach seinem Geschäftsmodell.

Die Common Criteria sind in neun Gruppen gegliedert, die den Aufbau des Berichts bestimmen.

Drei Punkte entscheiden über die Aussagekraft des späteren Berichts.

Die Systembeschreibung. Sie ist der Teil, den der Anbieter selbst verantwortet, und der Teil, den Kunden zuerst lesen. Sie muss den Dienst, die Infrastruktur, die Beteiligten und die Grenzen des Systems zutreffend darstellen. Eine Beschreibung, die nicht zur Wirklichkeit passt, führt zu einem eingeschränkten Urteil — unabhängig davon, wie gut die Kontrollen sind.

Die Formulierung der Kontrollen. Der Anbieter legt selbst fest, was er zusagt. Wer eine Kontrolle zu eng formuliert, produziert Ausnahmen im Bericht: Eine Zusage, jeden Zugriffsantrag innerhalb von 24 Stunden zu genehmigen, wird bei 40 Stichproben irgendwann verletzt. Eine Zusage, Anträge dokumentiert zu genehmigen, hält. Beides ist zulässig — die zweite Variante beschreibt jedoch die tatsächliche Praxis.

Der Umgang mit Unterauftragnehmern. Fast jeder Anbieter nutzt Cloud-Infrastruktur und weitere Dienste. Der Bericht muss klären, ob deren Kontrollen ausgeklammert oder einbezogen werden. Bei der üblichen Ausklammerung müssen die Berichte der Unterauftragnehmer eingeholt und bewertet werden — und die Punkte, die der Kunde selbst erfüllen muss, gehören ausdrücklich in den Bericht.

Für wen sich SOC 2 lohnt und wann nicht

Der entscheidende Anlass ist der Vertrieb in die Vereinigten Staaten. Dort ist der Bericht in Beschaffungsprozessen etabliert, und Einkaufsabteilungen fragen ihn standardmäßig ab. Ohne Bericht verlängert sich die Prüfung des Anbieters um Monate voller Einzelfragebögen — oder das Geschäft kommt nicht zustande.

Der zweite Anlass sind Kunden, deren eigene Prüfer den Nachweis verlangen. Wer für Finanzdienstleister oder börsennotierte Unternehmen arbeitet, wird Teil deren Kontrollumfelds. Deren Abschlussprüfer akzeptieren einen Bericht über den Dienstleister als Nachweis — und zwar in dem Format, das sie kennen.

Gegen ein Projekt sprechen zwei Konstellationen. Für Anbieter mit rein europäischem Kundenkreis ist SOC 2 nachrangig: Hier wird ISO 27001 erwartet, im öffentlichen Sektor zusätzlich der BSI-C5-Kriterienkatalog. Und wer beides parallel startet, ohne die Kontrollen einmal gemeinsam zu entwerfen, zahlt zweimal für dieselbe Arbeit.

Nüchtern betrachtet sagt der Bericht weniger über das Sicherheitsniveau aus, als sein Ruf vermuten lässt. Da der Anbieter die Kontrollen selbst formuliert, ist ein Bericht ohne Ausnahmen auch bei bescheidenem Anspruchsniveau erreichbar. Wer einen fremden Bericht bewertet, sollte deshalb nicht auf das Urteil schauen, sondern auf die Liste der Kontrollen, den Prüfzeitraum, die einbezogenen Kategorien und die Behandlung der Unterauftragnehmer.

Der Weg zum Bericht

Der Ablauf unterscheidet sich grundlegend von einer Zertifizierung nach ISO-Norm. Es gibt kein Stufe-1- und Stufe-2-Audit, keine akkreditierte Zertifizierungsstelle und keinen Dreijahreszyklus.

Geltungsbereich und Kriterien festlegen. Welcher Dienst, welche Umgebungen, welche Kategorien. Jede zusätzliche Kategorie erhöht Aufwand und Prüfumfang, ohne den Vertrieb zwangsläufig zu erleichtern.

Kontrollen entwerfen und einführen. Aus den Kriterien werden eigene Kontrollen abgeleitet und im Betrieb verankert. In dieser Phase entsteht der eigentliche Wert des Projekts — vorausgesetzt, die Kontrollen beschreiben, wie tatsächlich gearbeitet wird.

Bereitschaft prüfen. Üblich ist eine Vorbewertung durch eine unabhängige Partei. Sie deckt Lücken auf, solange sie noch korrigierbar sind. Wer hier eine ehrliche Rückmeldung will, sollte sie nicht bei dem einholen, der später prüft.

Beobachtungszeitraum durchlaufen. Für einen Typ-II-Bericht muss ein Zeitraum vergehen, in dem die Kontrollen nachweislich gelaufen sind. Sechs bis zwölf Monate sind üblich; der erste Bericht deckt häufig einen kürzeren Zeitraum ab, spätere dann ein volles Jahr.

Prüfung und Bericht. Der Prüfer erhebt Nachweise, führt Stichproben durch und erstellt den Bericht. Feststellungen erscheinen als Ausnahmen im Berichtsteil und werden nicht entfernt — der Anbieter kann eine Stellungnahme beifügen.

Jährlich wiederholen. Damit keine Lücke zwischen den Berichten entsteht, schließt der nächste Zeitraum nahtlos an. Wer eine Lücke lässt, muss sie gegenüber Kunden erklären.

Woran Projekte scheitern

Der Typ wird falsch gewählt. Ein Typ-I-Bericht wird beauftragt, weil er schneller fertig ist. Der Kunde verlangt Typ II — und der Beobachtungszeitraum beginnt erst jetzt. Der Vertriebstermin verschiebt sich um Monate.

Die Systembeschreibung stammt aus einem Werkzeug. Werkzeuge zur Automatisierung von Nachweisen liefern Vorlagen, die schnell befüllt sind. Wenn die Beschreibung dann Komponenten enthält, die es nicht gibt, oder Grenzen zieht, die nicht stimmen, wird das im Prüfungsgespräch auffallen. Ein hoher Erfüllungsgrad in einem solchen Werkzeug ist kein Prüfungsurteil.

Zugänge Ausgeschiedener bleiben aktiv. Das ist die mit Abstand häufigste Ausnahme in SOC-2-Berichten. Ein Konto in einem Nebensystem — Monitoring, Ticketsystem, Wiki — wird beim Austritt vergessen, weil die Deaktivierung an mehreren Stellen manuell erfolgt.

Die Rechteüberprüfung findet einmal statt. Zugesagt ist eine vierteljährliche Überprüfung, dokumentiert ist eine. Bei einem Zeitraum von zwölf Monaten prüft der Prüfer alle vier — drei fehlen.

Notfalländerungen laufen am Prozess vorbei. Das Änderungsmanagement funktioniert im Regelbetrieb. Für dringende Korrekturen gibt es kein nachgelagertes Verfahren, sodass Änderungen ohne Ticket und ohne Freigabe im Protokoll auftauchen.

Unterauftragnehmer werden nicht bewertet. Die Berichte des Infrastrukturanbieters werden nie gelesen, und die dort genannten Punkte, die der Kunde selbst umsetzen muss, sind nie geprüft worden. Das ist eine strukturelle Lücke, weil ein wesentlicher Teil der Kontrollen dort liegt.

Kontrollen versprechen zu viel. Fristen und Zahlen in der Kontrollbeschreibung werden im Alltag nicht durchgehalten. Jede Abweichung wird zur Ausnahme im Bericht — und Ausnahmen bleiben dort stehen. Wie sich Nachweise so führen lassen, dass sie tragen, beschreibt der Beitrag zum Nachweis der Wirksamkeit von Maßnahmen.

Zwischen zwei Berichten klafft eine Lücke. Der Bericht endet zum Jahreswechsel, der nächste Zeitraum beginnt erst im Frühjahr. Für die Zwischenzeit gibt es kein Prüfungsurteil, und der Bridge Letter des Anbieters trägt nur begrenzt.

Abgrenzung zu Normen und anderen Prüfungen

Für Anbieter mit Geschäft auf beiden Seiten des Atlantiks stellt sich die Frage nach der Reihenfolge. Der wirtschaftliche Weg beginnt in aller Regel mit ISO 27001: Das Managementsystem liefert die Struktur — Risikoverfahren, Statement of Applicability, Dokumentenlenkung, internes Audit, Managementbewertung —, und aus den dort festgelegten Maßnahmen lassen sich die SOC-2-Kontrollen ableiten. Der umgekehrte Weg ist mühsamer, weil SOC 2 die Managementsystemebene gar nicht verlangt und sie dann nachgebaut werden muss. Wer ohnehin beide Nachweise braucht, sollte die Kontrollen von Anfang an gegen beide Rahmen abbilden und Nachweise nur einmal erheben. Der Beitrag zur Zusammenführung mehrerer Normen in einem System beschreibt das Vorgehen, das sich auch auf Prüfungsformate anwenden lässt.