SOC 2 verstehen: SOC 1/2/3 und der Attestierungsansatz

Problem in der Praxis

In vielen Organisationen taucht SOC 2 zuerst als Vertriebsanforderung auf. Ein US-Kunde verlangt im Vendor-Assessment einen SOC-2-Bericht, und plötzlich wird Informationssicherheit zum Dealbreaker. Die Reaktion ist oft hektisch: Man sucht einen Anbieter, der schnell ein Zertifikat ausstellt.

Genau hier beginnt das Missverständnis. SOC 2 wird nicht ausgestellt, sondern geprüft und berichtet. Statt eines Logos für die Webseite entsteht ein umfangreicher, in der Regel vertraulicher Bericht mit Beschreibung des Systems, der Kontrollen und der Prüfergebnisse. Wird das nicht verstanden, entstehen falsche Erwartungen an Dauer, Kosten, Wiederholung und an die Frage, wem man den Bericht zeigen darf. Diese Erwartungen muss der CISO frühzeitig geraderücken.

CISO-Einordnung

Hilfreich ist die Unterscheidung der SOC-Familie nach dem, was jeweils im Mittelpunkt steht:

• SOC 1 betrifft Kontrollen mit Bezug zur Finanzberichterstattung des Kunden, relevant vor allem für Dienstleister, deren Leistung in die Rechnungslegung ihrer Kunden einfließt.
• SOC 2 betrifft Kontrollen zu den Trust Services Criteria der AICPA, also Sicherheit und verwandte Aspekte. Der Bericht ist für einen eingeschränkten Empfängerkreis bestimmt (restricted use): Kunden, deren Prüfer und Interessenten unter Vertraulichkeit.
• SOC 3 adressiert dieselbe Welt, ist aber für die allgemeine Öffentlichkeit bestimmt (general use). Er enthält weniger Detail und keine ausführlichen Testergebnisse und eignet sich daher als frei verteilbares Vertrauenssignal.

Die Trust Services Criteria sind in Kategorien gegliedert. Sicherheit (Security) ist die einzige Pflichtkategorie und damit in jedem SOC-2-Bericht enthalten; ihre Kriterien werden als Common Criteria bezeichnet, weil sie kategorieübergreifend die gemeinsame Grundlage bilden. Weitere Kategorien wie Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Schutz personenbezogener Daten sind optional und kommen je nach Kundenanforderung in den Scope. Die Common Criteria der Security-Kategorie sind konzeptionell an das COSO-Rahmenwerk für interne Kontrolle angelehnt. Der verbindliche Wortlaut ist urheberrechtlich geschützt und gehört der AICPA; maßgeblich ist deren Originalpublikation, aktuell TSP Section 100 mit den "2017 Trust Services Criteria" und den revidierten "Points of Focus (2022)". Version und Stand sind vor verbindlicher Aussage gegen das Original zu prüfen.

Wichtig sind zudem die Berichtstypen. Type I beurteilt die Kontrollgestaltung zu einem Stichtag. Type II beurteilt zusätzlich die betriebliche Wirksamkeit über einen Zeitraum, oft sechs bis zwölf Monate, hat dadurch eine höhere Aussagekraft und wird von anspruchsvollen Kunden meist verlangt.

Umsetzungsperspektive

Aus CISO-Sicht lässt sich der Weg zu SOC 2 in wenige tragende Schritte gliedern:

• Scoping: Welches System beziehungsweise welcher Service, welche Kategorien, welcher Berichtstyp ist das Ziel?
• Readiness: Ein Gap-Assessment zeigt, wo Kontrollen fehlen oder unzureichend gestaltet sind. Hier entsteht die eigentliche Sicherheitsarbeit.
• Beobachtungszeitraum: Für Type II müssen die Kontrollen über den Zeitraum nachweisbar wirksam betrieben werden. Evidenz entsteht laufend, nicht punktuell.
• Prüfung: Die CPA-Firma erstellt den Bericht mit Prüfurteil. Abweichungen werden als Ausnahmen (exceptions) ausgewiesen; der Bericht ist deshalb nicht automatisch wertlos.

SOC 2 ist kein einmaliges Projekt: Kunden erwarten in der Regel jährlich einen aktuellen Type-II-Bericht ohne Lücke im Zeitraum. Es ist damit ein Dauerbetrieb, der sich gut auf ein bestehendes ISMS stützen lässt.

Typische Fehler

1. SOC 2 wird als Zertifikat kommuniziert und erzeugt damit intern wie extern falsche Erwartungen.
2. Der Bericht wird ohne Rücksicht auf den eingeschränkten Empfängerkreis breit verteilt.
3. Es wird ein Type-I-Bericht angestrebt, obwohl Kunden faktisch Type II erwarten.
4. Der Scope wird zu breit gewählt, sodass Aufwand und Kosten unnötig steigen.
5. Evidenz wird kurz vor der Prüfung manuell zusammengesucht statt im Regelbetrieb erzeugt.
6. SOC 2 und eine vorhandene ISO-27001-Welt werden getrennt betrieben, obwohl sich die Kontrollen stark überschneiden.

Risiken und Trade-offs

Der attestierungsbasierte Ansatz hat eine eigene Logik. SOC 2 sagt etwas über die geprüften Kontrollen im definierten Scope und Zeitraum aus, nicht mehr. Ein günstiger Bericht ist kein Generalfreibrief, und ein eng gewählter Scope kann nach außen mehr suggerieren, als geprüft wurde. Hinzu kommt ein Trade-off zwischen Aussagekraft und Aufwand: Mehr Kategorien und ein längerer Zeitraum erhöhen das Vertrauen, aber auch Kosten und Belastung.

Schließlich bleibt die Marktfrage: Im EU-Kontext ist häufig ISO 27001 als zertifizierbares Managementsystem etabliert, während SOC 2 vor allem im US- und SaaS-Geschäft erwartet wird. Wer beide Märkte bedient, sollte die hohe Überschneidung der Kontrollen für eine Doppelnutzung verwenden.

Entscheidungspunkte

• Wird ein SOC-2-Bericht von Kunden tatsächlich verlangt, oder reicht im Zielmarkt eine andere Vertrauensgrundlage?
• Type I oder Type II, und ab wann ist der Sprung zu Type II sinnvoll?
• Welcher Service und welcher Systemumfang gehören in den Scope, und welche optionalen Kategorien sind durch Kundenanforderungen begründet?
• Soll SOC 2 eigenständig aufgebaut oder auf ein vorhandenes ISMS aufgesetzt werden?
• Wer darf den Bericht erhalten, und wie wird der eingeschränkte Empfängerkreis durchgesetzt?

Praktische Empfehlungen

1. Kommunizieren Sie SOC 2 konsequent als Attestierungsbericht, nicht als Zertifikat, gerade gegenüber Vertrieb und Management.
2. Klären Sie frühzeitig mit anfragenden Kunden, ob Type I oder Type II und welche Kategorien erwartet werden, und wählen Sie den Scope so eng wie vertretbar und so breit wie nötig.
3. Bauen Sie Evidenz in den Regelbetrieb ein, sodass der Beobachtungszeitraum ohne Sonderaktion belegbar ist.
4. Nutzen Sie ein vorhandenes ISMS als Fundament und mappen Sie Kontrollen, statt parallele Strukturen aufzubauen.
5. Steuern Sie die Verteilung des Berichts aktiv über NDA und Freigabeprozess und ziehen Sie für verbindliche Detailfragen die AICPA-Originalpublikation und die CPA-Firma heran.

Relevante Normreferenzen

• AICPA, SOC für Service Organizations (System and Organization Controls): Referenzrahmen für SOC 1, SOC 2 und SOC 3 sowie für den Attestierungsansatz.
• AICPA, TSP Section 100 (Trust Services Criteria): maßgebliche Originalquelle für die Kriterien von SOC 2 und SOC 3; aktueller Stand sind die "2017 Trust Services Criteria" mit den revidierten "Points of Focus (2022)". Version, Ausgabe und Stand sind vor verbindlicher Aussage gegen die Originalpublikation zu prüfen.
• ISO/IEC 27001: zertifizierbares Managementsystem für Informationssicherheit, im EU-Markt verbreiteter Vergleichs- und Mapping-Bezug. Eigenständiger Standard, kein Bestandteil von SOC 2.