AICPA-Prüfbericht zu Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) — typisch für SaaS-Vendoren.
Learning and orientation only — not legal advice.
Wer Cloud-Warehouses, BI-SaaS oder Reverse-ETL-Dienste einkauft, bekommt als Nachweis meist einen SOC-2-Bericht. Er ist die häufigste Währung im Vendor-Assessment.
Der Wert liegt nicht im Logo, sondern im Kleingedruckten: Systembeschreibung, Prüfzeitraum, getestete Controls, gefundene Abweichungen und die Controls, die der Prüfer euch zuschreibt. Genau diese Teile werden am seltensten gelesen.
Dienstleister, die Kundendaten verarbeiten und ihren Kunden Sicherheitsnachweise liefern müssen — vor allem US-geprägte SaaS-Anbieter, zunehmend auch europäische.
Als Kunde seid ihr indirekt betroffen: Ihr müsst Berichte lesen, Lücken bewerten und die euch zugewiesenen Controls tatsächlich umsetzen.
SOC 2 ist eine Attestierung durch einen Prüfer, keine Zertifizierung mit Gütesiegel.
Der Bericht gilt nur für das beschriebene System und den genannten Zeitraum.
Die Kategorie Privacy in SOC 2 ist nicht deckungsgleich mit DSGVO-Pflichten.
Berichte sind meist vertraulich — plant Fristen für NDA und Beschaffung ein.
Security ist immer dabei; Availability, Confidentiality, Processing Integrity und Privacy sind optional. Fehlt eine Kategorie, wurde sie nicht geprüft.
Type I beurteilt nur die Ausgestaltung zu einem Stichtag, Type II die Wirksamkeit über einen Zeitraum. Für Vendor-Entscheidungen zählt praktisch nur Type II.
Sie legt Dienste, Regionen, Komponenten und Grenzen fest. Wenn euer genutztes Produkt oder eure Region dort fehlt, hilft der Bericht wenig.
Der eigentliche Informationsgehalt steckt in den Testergebnissen und Ausnahmen — nicht im Prüfungsurteil auf Seite eins.
Der Bericht listet Controls, die ihr selbst umsetzen müsst (MFA, Rechtevergabe, Konfiguration). Ohne diese Hausaufgaben gilt die Zusicherung des Anbieters nicht.
Unterauftragnehmer werden per Carve-out ausgeschlossen oder inklusiv geprüft. Bei Carve-out braucht ihr die Nachweise dieser Anbieter separat.
Deckt der Zeitraum eure Nutzung ab? Für die Zeit nach Berichtsende gibt es üblicherweise ein Bridge Letter.
Jährliche Erneuerung nachhalten und Änderungen an Architektur oder Subprozessoren neu bewerten.
CUEC-Liste in konkrete Aufgaben übersetzen: SSO/MFA erzwingen, Rollen begrenzen, Netzwerkregeln setzen, Logs aktivieren.
Anbieter, Produkt, Berichtstyp, Zeitraum, Kategorien und offene Findings an einem Ort — sonst beginnt jede Prüfung von vorn.
Das Warehouse mit PII verdient eine tiefere Prüfung als ein Diagramm-Tool ohne Kundendaten.
Nutzt die Kriterien als Spiegel für eigene Access-, Logging- und Change-Prozesse, statt sie nur beim Anbieter zu prüfen.
Ein BI-SaaS läuft meist auf einem Hyperscaler; prüft, ob dessen Controls inklusiv oder per Carve-out behandelt sind.
Für jeden kritischen Datenanbieter, nicht nur für den größten.
Inklusive Bridge Letter für die Lücke bis heute.
Systembeschreibung wirklich gelesen und mit dem eigenen Setup verglichen.
Findings dokumentiert, Risiko akzeptiert oder kompensiert — mit Owner.
Jede Kundenpflicht hat ein Team und einen Umsetzungsnachweis.
Carve-out-Anbieter separat bewertet oder bewusst akzeptiert.
Security-Attestierung ersetzt keine Rechtsgrundlage, keine Transferprüfung und keine Löschfähigkeit.
Ein Design-Nachweis zum Stichtag sagt nichts über den Betrieb über zwölf Monate.
Zwei Jahre alte Berichte ohne Bridge Letter sind im Audit wertlos.
Der Bericht endet an der Anbietergrenze; die Infrastruktur darunter bleibt ungeprüft.
Wenn der Anbieter MFA und Rechteverwaltung euch zuweist und niemand es tut, entsteht genau dort die Lücke.
