Publiziert: Zuletzt aktualisiert:

SOC 2

SOC 2 ist ein Attestierungsbericht der AICPA, in dem ein unabhängiger Wirtschaftsprüfer die Kontrollen einer Dienstleistungsorganisation an den Trust Services Criteria misst. Es ist kein Zertifikat, sondern ein Prüfbericht: ein US-geprägter Vertrauensnachweis, der den prozessorientierten Anspruch von ISO 27001 ergänzt, statt ihn zu ersetzen.

Wer eine Cloud-Plattform, eine SaaS-Anwendung oder einen Hosting-Dienst einkauft, will wissen, ob der Anbieter seine Kunden- und Betriebsdaten im Griff hat. In den USA hat sich dafür SOC 2 als gängiger Nachweis etabliert. Das American Institute of Certified Public Accountants (AICPA) hat den Rahmen geschaffen, und Anbieter legen den Bericht regelmässig vor, sobald ein Kunde nach der Sicherheit ihrer Dienste fragt. Diese Seite beschreibt, was SOC 2 attestiert, warum es ein Bericht und kein Zertifikat ist, und wie es sich zu ISO 27001 verhält.

Bericht statt Zertifikat

Der wichtigste Punkt zuerst, weil er am häufigsten verwechselt wird: SOC 2 ist eine Attestierung, kein Zertifikat. Bei ISO 27001 prüft eine akkreditierte Zertifizierungsstelle das Managementsystem und stellt bei Erfolg ein Zertifikat aus, das die Konformität bestätigt. Bei SOC 2 führt ein unabhängiger Wirtschaftsprüfer (in den USA ein Certified Public Accountant, CPA) eine Prüfung der Kontrollen durch und gibt darüber ein schriftliches Prüfurteil ab. Das Ergebnis ist ein ausführlicher Bericht, kein Siegel.

Daraus folgt ein praktischer Unterschied. Ein ISO-27001-Zertifikat ist ein kurzes Dokument, das man vorzeigen kann. Ein SOC-2-Bericht ist ein vertrauliches Dokument von oft mehreren Dutzend Seiten, das die Systembeschreibung des Anbieters, die getesteten Kontrollen, die Prüfmethodik und das Urteil des Prüfers enthält. Anbieter geben ihn typischerweise nur unter einer Vertraulichkeitsvereinbarung an Kunden und Interessenten weiter. Die Aussage steckt nicht in einem Stempel, sondern im Inhalt des Berichts.

Die fünf Trust Services Criteria

Die inhaltliche Grundlage von SOC 2 sind die Trust Services Criteria (TSC) der AICPA, gegliedert in fünf Kategorien. Nur die erste ist verpflichtend; die übrigen vier wählt die Organisation nach Relevanz für ihren Dienst:

  • Sicherheit (Security). Schutz von Systemen und Daten vor unbefugtem Zugriff. Diese Kategorie, auch als gemeinsame Kriterien (Common Criteria) bezeichnet, ist die einzige verpflichtende Grundlage jedes SOC-2-Berichts.
  • Verfügbarkeit (Availability). Ist das System wie zugesagt verfügbar und betriebsbereit?
  • Verarbeitungsintegrität (Processing Integrity). Erfolgt die Verarbeitung vollständig, gültig, genau und zeitgerecht?
  • Vertraulichkeit (Confidentiality). Werden als vertraulich eingestufte Informationen entsprechend geschützt?
  • Datenschutz (Privacy). Werden Personendaten im Einklang mit den zugesagten Datenschutzpraktiken erhoben, genutzt und gelöscht?

Weil die Auswahl der Kategorien beim Anbieter liegt, sagt allein die Existenz eines SOC-2-Berichts noch nichts über dessen Umfang. Erst der Blick auf den Geltungsbereich (Scope) zeigt, welche Kriterien tatsächlich geprüft wurden. Ein Bericht, der nur die Sicherheit abdeckt, trifft keine Aussage über Verfügbarkeit oder Datenschutz. Genau hier lohnt das genaue Lesen, das auch die technische Sicht auf Compliance einfordert.

Type I gegen Type II

SOC 2 kennt zwei Berichtsarten, die sich nicht im Umfang, sondern im Prüfzeitpunkt unterscheiden:

  • Type I beurteilt, ob die Kontrollen zu einem bestimmten Stichtag angemessen gestaltet sind. Er beantwortet die Frage: Sind die richtigen Kontrollen vorhanden und sinnvoll entworfen?
  • Type II beurteilt zusätzlich, ob diese Kontrollen über einen Zeitraum hinweg auch wirksam funktioniert haben. Der Prüfer testet die Kontrollen über eine Beobachtungsperiode, die typischerweise mehrere Monate bis zu einem Jahr umfasst. Er beantwortet die schwierigere Frage: Haben die Kontrollen im Alltag tatsächlich gewirkt?

Für den Einkauf ist der Unterschied wesentlich. Ein Type-I-Bericht ist eine Momentaufnahme des Designs, oft der erste Schritt eines Anbieters. Ein Type-II-Bericht belegt die gelebte Wirksamkeit über Zeit und hat deshalb den höheren Aussagewert. Wer einen SOC-2-Nachweis verlangt, sollte präzisieren, welcher Typ gemeint ist.

flowchart TD
    A["SOC-2-Prüfung<br/>durch unabhängigen CPA"] --> B["Geltungsbereich festlegen<br/>welche der fünf Kriterien"]
    B --> C{"Prüfzeitpunkt?"}
    C -- "Stichtag" --> D["Type I<br/>Design der Kontrollen"]
    C -- "Zeitraum" --> E["Type II<br/>Wirksamkeit über Monate"]
    D --> F["Prüfbericht<br/>kein Zertifikat"]
    E --> F

Der Ablauf zeigt die zwei Weichen jeder SOC-2-Prüfung: zuerst legt die Organisation den Geltungsbereich fest, also welche der fünf Kriterien geprüft werden, dann entscheidet der Prüfzeitpunkt über Type I (Design zum Stichtag) oder Type II (Wirksamkeit über einen Zeitraum). Beide Wege münden in einen ausführlichen Prüfbericht, nicht in ein Siegel.

SOC 2 und ISO 27001 im Vergleich

SOC 2 und ISO 27001 verfolgen dasselbe Ziel, nämlich nachweisbare Informationssicherheit, auf unterschiedlichen Wegen. Sie schliessen sich nicht aus, sondern decken sich in weiten Teilen:

  • Herkunft und Verbreitung. ISO 27001 ist eine internationale Norm und im europäischen Raum die übliche Erwartung. SOC 2 ist US-geprägt und im nordamerikanischen Markt sowie bei Cloud- und SaaS-Anbietern der gängige Nachweis.
  • Ergebnisform. ISO 27001 führt zu einem Zertifikat einer akkreditierten Stelle. SOC 2 führt zu einem Attestierungsbericht eines Wirtschaftsprüfers.
  • Prüfgegenstand. ISO 27001 prüft ein vollständiges Informationssicherheits-Managementsystem (ISMS) samt Risikoprozess und kontinuierlicher Verbesserung. SOC 2 prüft konkrete Kontrollen gegen die ausgewählten Trust Services Criteria.
  • Gültigkeit. Ein ISO-Zertifikat gilt mit Überwachungsaudits drei Jahre. Ein SOC-2-Type-II-Bericht deckt eine vergangene Periode ab und wird daher meist jährlich erneuert.

Für Schweizer Organisationen, die mit US-Partnern oder internationalen Kunden arbeiten, kann beides verlangt werden. Wer bereits ein ISMS nach ISO 27001 betreibt, hat einen grossen Teil der für SOC 2 nötigen Kontrollen schon umgesetzt; die Wege ergänzen sich. Welcher Nachweis zu welchem Markt passt, ist eine Frage der Anbietersteuerung.

Was ein Prüfbericht belegt und was nicht

SOC 2 ist kein Datenschutzrecht und ersetzt keine gesetzliche Pflicht. Eine SOC-2-Datenschutzkategorie (Privacy) prüft, ob ein Anbieter seine eigenen zugesagten Datenschutzpraktiken einhält, nicht ob er das revidierte Datenschutzgesetz (revDSG) oder die DSGVO erfüllt. Ein SOC-2-Bericht ist deshalb ein nützliches Indiz für die Reife eines Anbieters, aber kein Beleg für die Rechtskonformität einer konkreten Datenverarbeitung.

Hinzu kommt die Souveränitätsfrage. Ein US-Anbieter mit makellosem SOC-2-Type-II-Bericht kann technisch hervorragend kontrolliert sein und trotzdem dem US Cloud Act unterliegen, der einen rechtlichen Zugriff auf die Daten ermöglicht. Die beiden Ebenen, technische Kontrollreife und rechtlicher Zugriff, sind getrennt zu bewerten. Ein Vertrauensnachweis über Kontrollen löst die Frage der Datenhoheit nicht auf. Diese Trennung sauber zu führen, gehört zur Nachweis- und Lieferkettenarbeit.

Worauf beim Lesen zu achten ist

  • Type prüfen. Type I ist eine Momentaufnahme, Type II belegt Wirksamkeit über Zeit. Nur Type II hat den vollen Aussagewert.
  • Geltungsbereich prüfen. Welche der fünf Kriterien deckt der Bericht ab und welche Systeme? Sicherheit allein ist nicht Verfügbarkeit plus Datenschutz.
  • Beobachtungsperiode prüfen. Ein Type-II-Bericht über einen sehr kurzen Zeitraum sagt weniger als einer über zwölf Monate.
  • Ausnahmen prüfen. Der Prüfer dokumentiert festgestellte Abweichungen (Exceptions). Ein Bericht ohne jede Ausnahme ist nicht automatisch der bessere; entscheidend ist, wie der Anbieter mit den dokumentierten Abweichungen umgeht.
  • Datum und Prüfer prüfen. Der Bericht deckt eine vergangene Periode ab. Ein zwei Jahre alter Bericht sagt wenig über den heutigen Betrieb.

Referenzen

Verwandte Themen

  • ISO 27001, der internationale ISMS-Standard, den SOC 2 ergänzt.
  • Compliance, die technische Sicht auf Nachweis und Kontrolle.
  • US Cloud Act, die rechtliche Zugriffsebene, die ein SOC-2-Bericht nicht auflöst.
  • nFADP / DSG, der Schweizer Datenschutz, den SOC 2 nicht ersetzt.

KI fragen

Diese Links öffnen externe KI-Dienste, die Unterhaltung und deren Inhalt werden dabei an den jeweiligen Anbieter übertragen.