Was sind SOC 1, SOC 2 und SOC 3 – und worin unterscheiden sich Typ 1 und Typ 2?

SOC steht hier nicht für Security Operations Center, sondern für System and Organization Controls – eine Suite von Prüfungsberichten des US-amerikanischen Instituts AICPA (American Institute of Certified Public Accountants). Ein SOC-Bericht ist ein unabhängiges Attest: Ein Wirtschaftsprüfer bestätigt, dass bestimmte Kontrollen bei einem Dienstleister geeignet gestaltet sind – und bei Typ 2 auch, dass sie über einen Zeitraum wirksam liefen.

Für viele deutsche SaaS-Anbieter, Hosting-Partner und Outsourcing- Dienstleister wird das Thema konkret, sobald ein US-Kunde, ein Konzern oder eine Ausschreibung einen SOC-2-Typ-2-Bericht verlangt. In diesem Artikel erfährst du:

• Was SOC 1, SOC 2 und SOC 3 jeweils prüfen – und für wen
• Worin sich Typ 1 und Typ 2 unterscheiden
• Welche fünf Trust Services Criteria bei SOC 2 und SOC 3 gelten
• Warum „SOC-2-zertifiziert“ fachlich falsch ist
• Wie sich SOC 2 zu ISO 27001 verhält – und wie deveca GRC bei der Vorbereitung hilft

Was ein SOC-Bericht ist – und was er nicht ist

SOC-Berichte richten sich an Service Organizations: Unternehmen, die für Kunden Systeme betreiben oder Daten verarbeiten – Cloud, Payroll, Zahlungsabwicklung, Rechenzentrum, Managed Services. Der Auftraggeber (User Entity) kann die Kontrollen beim Dienstleister nicht selbst prüfen; der SOC-Bericht liefert ihm und seinem Auditor die nötige Sicherheit.

Wichtig für die Kommunikation nach außen: SOC ist keine Zertifizierung. Es gibt kein Siegel, das unbegrenzt gilt, und kein „SOC-2-zertifiziertes Unternehmen“ im Sinne von ISO 27001. Das Ergebnis ist ein zeitlich begrenzter Prüfungsbericht mit einer Meinung des Prüfers (unqualified / qualified). Wer auf der Website „SOC 2 certified“ schreibt, widerspricht dem AICPA-Rahmen – korrekt ist: „Wir verfügen über einen SOC-2-Typ-2-Bericht.“

Ausstellen darf den Bericht nur ein unabhängiger CPA nach den AICPA-Attestationsstandards (heute AT-C, historisch oft als SSAE 18 bezeichnet). Interne Audits, Pen-Tests oder ein ISMS ersetzen das nicht – sie sind aber die Grundlage, ohne die ein SOC-Audit scheitert.

SOC 1, SOC 2 und SOC 3 im Vergleich

Die AICPA unterscheidet drei Berichte für Service Organizations. Sie prüfen nicht denselben Gegenstand und sind nicht frei austauschbar:

Kurz: SOC 1 ist ein Finanzthema, SOC 2 ein Sicherheitsthema, SOC 3 die öffentliche Kurzfassung von SOC 2. Die meisten Technologieunternehmen brauchen SOC 2 – nicht SOC 1. Manche brauchen beides, etwa Payroll- oder Payment-Anbieter.

SOC 1: Kontrollen für die Finanzberichterstattung

Ein SOC-1-Bericht (SOC for Service Organizations: ICFR) prüft Kontrollen, die für den Jahresabschluss der Kunden relevant sind. Typische Adressaten: Lohnabrechnung, Fondsadministration, Zahlungsdienstleister, Buchhaltungs-Outsourcing. Der Bericht hilft dem Abschlussprüfer der User Entity bei der Risikoeinschätzung – nicht dem CISO bei der Cloud-Due-Diligence.

Wenn ein Kunde „SSAE-18-Bericht“ verlangt, meint er in der Praxis fast immer SOC 1. Für SaaS-Sicherheitsnachweise ist das die falsche Schiene.

SOC 2: Trust Services Criteria

Ein SOC-2-Bericht prüft, ob die Kontrollen des Dienstleisters die relevanten Trust Services Criteria (TSC) erfüllen – definiert in TSP Section 100 (Kriterien 2017, überarbeitete Points of Focus 2022). Nur Security ist Pflicht; die übrigen vier nimmst du in den Scope, wenn deine Kundenverträge, SLAs oder Datenflüsse das verlangen.

• Security (Common Criteria, CC1–CC9): Schutz vor unbefugtem Zugriff, Änderung und Zerstörung – Governance, Risiko, Change, Logging, Zugriffskontrolle. Immer im Scope.
• Availability: Systeme stehen wie zugesagt zur Verfügung – Kapazität, Monitoring, Backup, Disaster Recovery.
• Processing Integrity: Verarbeitung ist vollständig, korrekt, zeitgerecht und autorisiert – relevant für Transaktions- und Datenverarbeitungsplattformen.
• Confidentiality: Als vertraulich gekennzeichnete Informationen (Verträge, Geschäftsgeheimnisse, Kundendaten) sind geschützt – von der Erhebung bis zur Löschung.
• Privacy: Personenbezogene Daten werden gemäß festgelegten Zwecken erhoben, genutzt, aufbewahrt und gelöscht. Inhaltlich nah an der DSGVO, aber ein eigener AICPA-Katalog – kein GDPR-Zertifikat.

SOC-2-Berichte sind restricted use: Sie gehen an Management, Kunden, Geschäftspartner, deren Prüfer und Aufsichtsstellen – nicht ungefiltert auf die Marketingseite. Dafür existiert SOC 3.

SOC 3: die öffentliche Kurzfassung

SOC 3 prüft dieselben Trust Services Criteria wie SOC 2, enthält aber keine detaillierte Systembeschreibung und keine Testdetails. Deshalb darf der Bericht allgemein verteilt werden – etwa als Download oder Seal auf der Website.

Für Einkauf und Vendor-Risk reicht SOC 3 fast nie: Enterprise-Kunden wollen den SOC-2-Typ-2-Bericht mit Tests und Ergebnissen. SOC 3 ist ein Kommunikationstool, kein Ersatz für die Due Diligence. In der Praxis wird SOC 3 oft auf Basis derselben Typ-2-Prüfung erstellt wie der ausführliche SOC-2-Bericht.

Typ 1 vs. Typ 2: Stichtag oder Wirkungszeitraum

Typ 1 und Typ 2 gibt es bei SOC 1 und SOC 2. Sie beschreiben nicht den Inhalt (Finanzen vs. Sicherheit), sondern die Prüftiefe über die Zeit.

Ein Typ-1-Bericht sagt: „Am 31. März waren MFA, Change-Prozess und Backup-Konzept so gestaltet, dass sie die Kriterien erfüllen können.“ Ein Typ-2-Bericht sagt zusätzlich: „Zwischen Oktober und März wurden Zugriffe reviewed, Changes dokumentiert und Backups getestet – und die Stichproben belegen das.“

Deshalb ist Typ 2 der eigentliche Vertrauensnachweis. Typ 1 ist sinnvoll, wenn du schnell einen ersten Bericht brauchst, während der Beobachtungszeitraum für Typ 2 noch läuft. Viele Unternehmen starten mit Typ 1 und legen direkt den Typ-2-Zeitraum darauf – ohne die Kontrollen zwischendurch wieder abzubauen.

Welchen Bericht brauchst du?

• Kunden fragen nach Sicherheit, Cloud, Datenschutz: SOC 2 Typ 2. Security immer; Availability bei SLA-Zusagen; Confidentiality bei Kundendaten; Privacy, wenn personenbezogene Daten im Kern der Leistung liegen.
• Kunden bzw. deren WP brauchen Nachweise für den Jahresabschluss: SOC 1 Typ 2.
• Du willst öffentlich kommunizieren, ohne Testdetails preiszugeben: SOC 3 zusätzlich zum SOC-2-Typ-2-Bericht.
• Du sitzt in der EU und verkaufst primär an deutsche Mittelständler: Zuerst oft ISO 27001. SOC 2 kommt dazu, sobald US-Enterprise, Fonds oder globale Beschaffung den Bericht zur Bedingung machen.

SOC 2 ist in Deutschland keine gesetzliche Pflicht – im Gegensatz zu NIS2 oder der DSGVO. Es ist ein Marktnachweis. Wer ihn nicht hat, verliert Deals, nicht automatisch ein Bußgeld.

SOC 2 und ISO 27001: kein Entweder-oder

Im deutschsprachigen Raum ist ISO 27001 der etablierte ISMS-Standard. SOC 2 ist ein Attestationsbericht über ausgewählte Kriterien. Inhaltlich überlappen Security, Availability und Confidentiality stark mit Annex A und dem ISMS-Lebenszyklus – Scope, Risiken, Controls, Nachweise und Reviews sind dieselben Bausteine.

Der Unterschied liegt in Form und Adressat: ISO 27001 endet mit einem Zertifikat über das Managementsystem. SOC 2 endet mit einem Bericht über konkrete Kontrollen und – bei Typ 2 – deren Wirksamkeit im Zeitraum. Ein ISO-Zertifikat ersetzt den SOC-2-Bericht gegenüber US-Einkäufern selten; umgekehrt ersetzt SOC 2 in Ausschreibungen mit ISO-Pflicht oft nicht das Zertifikat.

Wer beides braucht, sollte nicht zwei Parallelwelten aufbauen. Dieselbe Control, dieselbe Evidenz, zwei Mappings: genau das ist der GRC-Ansatz.

So wirst du SOC-auditfähig – ohne Excel-Chaos

1. Scope festlegen: Welches System, welche Standorte, welche TSC, welcher Zeitraum? Zu breit macht das Audit teuer, zu eng fällt beim Kunden durch.
2. Kontrollen beschreiben und Verantwortliche benennen: Nicht „wir haben MFA“, sondern: für welche Systeme, welcher Standard, wer reviewed Ausnahmen, wo liegt der Nachweis.
3. Risiken und Maßnahmen verbinden: Die Common Criteria erwarten nachvollziehbares Risikomanagement – nicht nur eine Richtliniensammlung. Dafür ist ein Risikoregister die natürliche Quelle.
4. Evidenz kontinuierlich ablegen: Access Reviews, Change-Tickets, Backup-Tests, Awareness-Nachweise, Incident-Logs. Typ 2 prüft den Zeitraum, nicht den Ordner vom Vorabend.
5. Readiness vor dem CPA: Internes Audit oder Gap- Assessment, Findings schließen, dann den externen Prüfer kontrolliert einladen – mit begrenztem Scope statt Sharepoint-Zoo.

Wie deveca GRC bei SOC 1–3 unterstützt

Ein CPA stellt den Bericht aus – nicht die Software. Was Software leistet: den Zeitraum überstehen, ohne dass Nachweise, Controls und Verantwortlichkeiten in Mailanhängen verschwinden. deveca GRC ist dafür die gemeinsame Datenbasis.

• Kontroll-Framework: Ein Control-Set, mehrere Frameworks. ISO 27001, NIS2, TISAX und weitere Anforderungen teilen sich Nachweise – statt je Audit eine neue Excel-Liste. Ein natives Mapping auf die Trust Services Criteria (SOC 2 Type II) ist in der Roadmap.
• Evidenz und Auditor-Zugang: Im Audit-Programm planst du Prüfungen, hängst Nachweise an Findings und gibst externen Prüfern über das Auditor-Portal zeitlich und fachlich begrenzten Zugriff – passend zur restricted-use-Logik von SOC 2.
• Richtlinien, die gelebt werden: Richtlinienmanagement mit Versionierung, Freigabe und Bestätigung durch Mitarbeitende – ein Dauerbrenner in SOC-2-Stichproben (Awareness, Acceptable Use, Access).
• Risiko, Incidents, Dritte: Common Criteria verlangen Risikosteuerung, Vorfallbehandlung und Umgang mit Subdienstleistern. Genau dafür gibt es IT-Risikomanagement, Incident-Workflows und Drittparteienmanagement.
• Privacy-Scope: Nimmst du das TSC Privacy hinzu, greifen dieselben DSGVO-Artefakte, die du ohnehin brauchst: VVT, TOMs, Löschfristen – im Modul Datenschutz.

Der praktische Effekt: Du bereitest ISO 27001 und SOC 2 nicht als zwei Projekte vor. Du betreibst ein Managementsystem und ziehst für den CPA den Bericht, den der Markt gerade verlangt.

Häufige Fragen zu SOC 1, 2, 3 und Typ 1 / Typ 2

Ist SOC 2 eine Zertifizierung?

Nein. SOC 2 ist ein Attestationsbericht eines CPA. Gültig ist er für den geprüften Stichtag (Typ 1) bzw. den geprüften Zeitraum (Typ 2) – danach folgt in der Regel der nächste Bericht, oft jährlich.

Reicht Typ 1 für Enterprise-Kunden?

Selten dauerhaft. Typ 1 öffnet Türen und überbrückt die erste Beobachtungsphase. In Sicherheitsfragebögen und Rahmenverträgen steht fast immer SOC 2 Typ 2.

Brauche ich SOC 2, wenn ich ISO 27001 habe?

Nur wenn Kunden oder Partner den Bericht verlangen. Fachlich ist die Vorarbeit zu einem großen Teil dieselbe; formal sind Zertifikat und SOC-Bericht verschiedene Artefakte.

Wie lange dauert ein SOC-2-Typ-2-Audit?

Der Beobachtungszeitraum selbst liegt typischerweise bei drei bis zwölf Monaten. Die Feldarbeit des Prüfers danach ist kürzer – oft Wochen, nicht Jahre. Der Aufwand sitzt in der Vorbereitung: Controls, Nachweise, Lücken schließen.

Fazit

SOC 1 prüft finanzrelevante Kontrollen, SOC 2 prüft Sicherheits- und Vertrauenskriterien, SOC 3 macht daraus eine öffentliche Kurzfassung. Typ 1 ist ein Stichtagsfoto der Gestaltung, Typ 2 der Nachweis, dass die Kontrollen über Monate funktioniert haben. Wer US- oder Enterprise-Kunden bedient, landet in der Praxis bei SOC 2 Typ 2 – oft zusätzlich zu ISO 27001, nicht statt dessen.

Der teure Fehler ist, für jedes Framework eine neue Nachweiswelt zu bauen. Der günstige Weg: Governance, Risiken, Controls und Evidenz einmal sauber führen – und dem Prüfer genau das zeigen, was der jeweilige Bericht verlangt.

Wenn du Controls, Nachweise und Audits für ISO 27001 und kommende SOC-2-Anforderungen in einer Plattform halten willst, kannst du deveca GRC kostenlos testen.