SOC 1 vs SOC 2: Unterschiede der Compliance-Frameworks erklärt

SOC 1 bewertet Kontrollen zur Finanzberichterstattung; SOC 2 bewertet Sicherheits- und Datenschutzmaßnahmen. Erfahren Sie, wann welcher Berichtstyp angefordert werden sollte und wie Sie die Compliance von Anbietern bewerten.

Was sind SOC 1 und SOC 2?

Laut dem Verizon Data Breach Investigations Report 2024 verursachen Drittanbieter mittlerweile 62 % der Datenschutzverletzungen, wobei laut IBMs Cost of a Data Breach Report 2024 eine durchschnittliche Drittanbieter-Verletzung 4,76 Millionen US-Dollar kostet. Wenn ein Anbieter fragt, welchen SOC-Bericht Sie benötigen, bestimmt Ihre Antwort den gesamten Prozess der Lieferantenrisikobewertung.

SOC 1 und SOC 2 sind unabhängige Prüfberichte, die von lizenzierten Wirtschaftsprüfern gemäß den SSAE No. 18-Attestierungsstandards ausgestellt werden. Beide bewerten die internen Kontrollen eines Serviceunternehmens, dienen jedoch unterschiedlichen Zwecken. Laut der  AICPA untersucht SOC 1 „Kontrollen bei einem Serviceunternehmen, die wahrscheinlich für die interne Kontrolle der Nutzerunternehmen über die Finanzberichterstattung relevant sind.“ Diese Berichte konzentrieren sich ausschließlich darauf, ob die Kontrollen des Anbieters die Genauigkeit Ihrer Finanzberichte nach GAAP wesentlich beeinflussen könnten.

SOC 2 befasst sich mit Sicherheits- und Betriebskontrollen. Die AICPA definiert SOC 2 als „einen Bericht über Kontrollen bei einem Serviceunternehmen, die für Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit oder Datenschutz relevant sind.“ Sie benötigen SOC 2-Berichte, wenn Sie Anbieter bewerten, die sensible Kundendaten speichern, verarbeiten oder übertragen.

Verständnis von SOC 1 und SOC 2: Unterschiede zwischen Typ I und Typ II

Über die Wahl zwischen SOC 1 und SOC 2 hinaus müssen Sie auch angeben, welchen Berichtstyp Sie benötigen. Sowohl SOC 1 als auch SOC 2 gibt es in zwei Varianten. Typ I-Berichte bewerten das Kontrolldesign zu einem bestimmten Zeitpunkt. Typ II-Berichte bewerten sowohl die Angemessenheit des Designs als auch die Wirksamkeit der Kontrollen über einen Zeitraum von 6 bis 12 Monaten.

Bei der Risikobewertung von kritischen Lieferanten bieten Typ II-Berichte deutlich mehr Sicherheit, da sie den nachhaltigen Betrieb der Kontrollen und nicht nur deren theoretische Angemessenheit nachweisen. Unternehmenskunden verlangen zunehmend von Anbietern, dass sie angemessene Datenschutz- und Sicherheitsmaßnahmen vor der Beschaffungsfreigabe nachweisen, wodurch die Typ II-Attestierung für SaaS- und Technologieanbieter im Enterprise-Bereich faktisch verpflichtend wird.

Wann Sie SOC 1-Berichte benötigen

Nachdem Sie die Berichtstypen verstanden haben, stellt sich die nächste Frage, welches Rahmenwerk auf Ihre Lieferantenbeziehung zutrifft. Fordern Sie SOC 1 Typ II-Berichte an, wenn Anbieter Transaktionen verarbeiten, die Ihre Finanzberichte beeinflussen. Laut AICPA bewerten SOC 1-Prüfungen Kontrollen, „die wahrscheinlich für die interne Kontrolle der Nutzerunternehmen über die Finanzberichterstattung relevant sind.“

Typische Szenarien, die eine SOC 1 Typ II-Attestierung erfordern, sind:

• Lohnabrechnungsdienstleister, die Buchungssätze im Hauptbuch erstellen
• Umsatzerkennungsplattformen, die ASC 606-Compliance-Berechnungen durchführen
• Abrechnungssysteme, die Umsatzpositionen beeinflussen
• Kreditdienstleister, die Zinsberechnungen verwalten
• Leistungsadministratoren, die aufgeschobene Vergütungen verarbeiten

Ihre externen Prüfer benötigen diese Berichte, um zu validieren, dass ausgelagerte Finanzprozesse während des gesamten Prüfungszeitraums angemessene Kontrollen für die Sarbanes-Oxley-Compliance aufrechterhalten.

Wann Sie SOC 2-Berichte benötigen

Während SOC 1 Finanzberichterstattungskontrollen adressiert, konzentrieren sich die meisten Risikobewertungen von Anbietern auf Datensicherheit. Sie benötigen SOC 2, wenn Sie Serviceunternehmen bewerten, die Kundendaten verarbeiten. Cloud-Anbieter, SaaS-Anwendungen, Zahlungsdienstleister, Sicherheitsdienste und Anbieter, die sensible Kundendaten verarbeiten, erfordern alle eine SOC 2-Bewertung.

Unternehmen sollten SOC 2 Typ II-Berichte anfordern, wenn Anbieter vertrauliche Informationen verarbeiten, wenn Sicherheitsvorfälle Reputations- oder regulatorische Risiken verursachen könnten oder wenn die Einhaltung von Datenschutzvorschriften (DSGVO, CCPA, HIPAA) von den Kontrollen des Anbieters abhängt. SOC 2-Compliance ist zur Basiserwartung für Technologieanbieter im Enterprise-Umfeld geworden.

SOC 1 vs SOC 2: Wichtige Unterschiede für Sicherheitsteams

Mit dem Verständnis, was jedes Rahmenwerk bewertet, können Sicherheitsteams fundierte Entscheidungen darüber treffen, welche Berichte anzufordern sind und wie sie zu interpretieren sind.

Geltungsbereich und Zweck

SOC 1 dient Ihren externen Prüfern und unterstützt Ihren Finanzberichtsprüfungsprozess. Externe Prüfer benötigen die Sicherheit, dass ausgelagerte Finanzprozesse angemessene Kontrollen im Hinblick auf die Finanzberichterstattung aufrechterhalten. SOC 1-Berichte adressieren dieses spezifische Bedürfnis mit Kontrollzielen, die sich auf finanzielle Datenintegrität, Transaktionsgenauigkeit und Auswirkungen auf das Hauptbuch konzentrieren.

SOC 2 dient Ihnen direkt bei der Bewertung, ob Anbieter Kundendaten schützen können. Der Bericht behandelt Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz und liefert detaillierte Informationen zu den Kontrollen eines Serviceunternehmens, die für diese fünf Trust Services Criteria relevant sind.

Verteilung und Zielgruppen

Die  AICPA gibt an, dass SOC 1-Berichte den Bedürfnissen von „Unternehmen, die Serviceorganisationen nutzen, und den Wirtschaftsprüfern, die die Abschlüsse der Nutzerunternehmen prüfen“ entsprechen. Die Verteilung ist auf bestehende Kunden, potenzielle Kunden und deren Prüfer beschränkt.

SOC 2-Berichte richten sich an breitere Interessengruppen: Sicherheitsteams, Risikomanagement-Funktionen, Beschaffungsabteilungen, Compliance-Beauftragte und Kunden, die detaillierte Informationen zu Datenschutzkontrollen benötigen. Obwohl es sich weiterhin um Berichte mit eingeschränkter Nutzung handelt, die NDAs erfordern, umfasst die SOC 2-Verteilung alle mit legitimen Sicherheitsbewertungsbedürfnissen.

Unterschiede im Kontrollrahmen

SOC 1 bewertet Kontrollen, die für Ziele der Finanzberichterstattung relevant sind, unter Verwendung eines Kontrollrahmens für die Finanzberichterstattung. Dazu gehören Transaktionsautorisierung, Vollständigkeit und Genauigkeit von Finanzdaten, Funktionstrennung, Abstimmungsverfahren und allgemeine IT-Kontrollen zur Unterstützung von Finanzanwendungen.

SOC 2 verwendet ausschließlich die Trust Services Criteria mit standardisierten Kontrollzielen in den Bereichen Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz. Diese Standardisierung ermöglicht einen direkten Vergleich zwischen Anbietern und die Ausrichtung an Ihren bestehenden  Sicherheitskontrollrahmen.

Integration in Ihr Sicherheitsprogramm

Laut  LinfordCos Rahmenwerkanalyse lässt sich das NIST Cybersecurity Framework direkt auf die SOC 2-Kriterien abbilden: NIST Identify entspricht CC3 Risikobewertung, NIST Protect entspricht CC6 Zugriffskontrollen und Vertraulichkeits-/Datenschutzkriterien, NIST Detect entspricht CC4 Überwachung und CC7 Systembetrieb, NIST Respond integriert sich mit CC9 Incident-Response-Fähigkeiten und NIST Recover ist mit dem Verfügbarkeitskriterium verbunden. Diese Ausrichtung bedeutet, dass SOC 2-Berichte von Anbietern standardisierte Nachweise für dieselben Kontrollkategorien liefern, die Sie intern umsetzen.

SOC 1 vs SOC 2: Vergleich

Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen SOC 1- und SOC 2-Berichten zusammen, um Sicherheitsteams bei der Entscheidung zu unterstützen, welche Attestierung für bestimmte Lieferantenbeziehungen gilt.

Kriterium	SOC 1	SOC 2
Hauptzweck	Bewertet Kontrollen, die die interne Kontrolle der Nutzerunternehmen über die Finanzberichterstattung (ICFR) beeinflussen	Bewertet Kontrollen, die für Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz relevant sind
Geltender Standard	SSAE No. 18, AT-C Abschnitt 320 (Berichterstattung über eine Prüfung von Kontrollen)	SSAE No. 18, AT-C Abschnitt 205 (unter Verwendung der von der AICPA entwickelten Trust Services Criteria)
Kontrollrahmen	Individuelle Kontrollziele, die vom Serviceunternehmen basierend auf den Auswirkungen auf die Finanzberichterstattung definiert werden	Standardisierte Trust Services Criteria (TSC) mit fünf Kategorien; Sicherheit ist verpflichtend, vier weitere optional
Hauptzielgruppe	Externe Prüfer, die Abschlussprüfungen durchführen, und Finanzteams, die für SOX-Compliance verantwortlich sind	Sicherheitsteams, Lieferantenrisikomanagement, Beschaffung, Compliance-Beauftragte und Unternehmenskunden
Typischer Anforderer	CFO, Controller oder externes Prüfungsteam während des jährlichen Abschlussprüfungszyklus	CISO, Third-Party-Risk-Management-Team oder Beschaffung während Lieferanten-Onboarding und jährlicher Überprüfungen
Regulatorischer Treiber	Sarbanes-Oxley (SOX) Abschnitt 404-Compliance für börsennotierte Unternehmen; unterstützt GAAP-Finanzberichterstattung	SOC 2-Compliance unterstützt DSGVO, CCPA, HIPAA und andere Datenschutzvorschriften; zunehmend in Enterprise-Verträgen gefordert
Typische Anbietertypen	Lohnabrechnungsdienstleister, Leistungsadministratoren, Kreditdienstleister, Umsatzerkennungsplattformen, Abrechnungssysteme	Cloud-Anbieter, SaaS-Anwendungen, Rechenzentren, Managed Security Services, Zahlungsdienstleister
Fokus der Kontrollprüfung	Transaktionsautorisierung, Genauigkeit von Finanzdaten, Funktionstrennung, Abstimmungsverfahren, allgemeine IT-Kontrollen	Zugriffskontrollen, Verschlüsselung, Incident Response, Change Management, Verfügbarkeit, Datenaufbewahrung, Datenschutzpraktiken
Definition des Berichtsumfangs	Umfang definiert durch Kontrollen, die für spezifische Finanzprozesse und Transaktionen des Anbieters relevant sind	Umfang definiert durch Systemgrenzen, Infrastrukturbestandteile und die anwendbaren Trust Services Criteria
Standardisierungsgrad	Kontrollziele variieren erheblich zwischen Anbietern je nach ihren spezifischen Finanzdienstleistungen	Standardisierte Kriterien ermöglichen direkten Vergleich zwischen Anbietern und Ausrichtung an Frameworks wie NIST CSF
Verfügbarkeit von Bridge Letters	Bridge Letters verlängern die Sicherheit zwischen Prüfungszeiträumen für Kontinuität der Finanzberichterstattung	Bridge Letters weniger verbreitet; kontinuierliches Monitoring und aktualisierte Berichte werden für Sicherheit bevorzugt
Typische Audit-Kosten	20.000 bis 60.000+ US-Dollar, abhängig von der Komplexität der Finanzprozesse und dem Transaktionsvolumen	12.000 bis 100.000+ US-Dollar, abhängig von Umfang, Anzahl der Trust Services Criteria und Unternehmensgröße

Das Verständnis dieser Unterschiede stellt sicher, dass Sie den passenden Berichtstyp anfordern und Ihre Überprüfung auf die für Ihre spezifischen Risiken relevanten Kontrollen fokussieren.

Stärkung der Lieferantenrisikobewertung mit SentinelOne

SOC 2-Berichte dokumentieren, ob Anbieter Multi-Faktor-Authentifizierung, rollenbasierte Zugriffskontrollen und Privileged Access Management wie in CC6 spezifiziert implementieren. Die  Singularity Platform erweitert diese Transparenz durch Echtzeit-Verhaltensanalysen in Ihrer gesamten Umgebung, einschließlich Aktivitäten von Anbieter-Konten und Drittanbieter-Integrationen.

Purple AI ermöglicht laut frühen Anwendern bis zu 80 % schnellere Bedrohungsuntersuchungen. Die verhaltensbasierte KI der Plattform erkennt anomales Verhalten, das von erwarteten Mustern abweicht, und markiert potenzielle Sicherheitsprobleme zur Untersuchung. Mit 88 % weniger Warnmeldungen in  MITRE ATT&CK-Evaluierungen können SOC-Analysten ihre Untersuchungszeit auf echte Bedrohungen konzentrieren, anstatt Fehlalarme zu bearbeiten.

Kontinuierlicher Compliance-Nachweis

SentinelOne AI-SIEM ist für das autonome SOC konzipiert. Es schützt Ihr Unternehmen mit der branchenweit schnellsten KI-gestützten offenen Plattform für all Ihre Daten und Workflows.

Basierend auf dem SentinelOne Singularity™ Data Lake beschleunigt es Ihre Workflows mit Hyperautomation. Es bietet Ihnen unbegrenzte Skalierbarkeit und endlose Datenaufbewahrung. Sie können die Daten in Ihrem Legacy-SIEM filtern, anreichern und optimieren. Es kann alle überschüssigen Daten aufnehmen und Ihre aktuellen Workflows beibehalten.

Sie können Daten für die Echtzeit-Erkennung streamen und mit autonomer KI datengesteuerten Schutz in Maschinen-Geschwindigkeit ermöglichen. Sie erhalten zudem mehr Transparenz für Untersuchungen und Erkennungen mit der branchenweit einzigen einheitlichen Konsolen-Erfahrung.

Es ist schemafrei und ohne Indexierung, und ist Exabyte-fähig, was bedeutet, dass es jede Datenmenge verarbeiten kann. Sie können Ihren gesamten Security-Stack einfach integrieren. Es kann sowohl strukturierte als auch unstrukturierte Daten aufnehmen und unterstützt OCSF nativ. Sie können zudem konsistente und effektive Bedrohungsreaktionen mit automatisierten Incident-Response-Playbooks sicherstellen. Reduzieren Sie Fehlalarme, Alarmrauschen, optimieren Sie Ressourceneinsatz und verbessern Sie Ihre gesamte Sicherheitslage noch heute.

Fordern Sie eine SentinelOne-Demo an, um zu sehen, wie die Singularity Platform autonome Bedrohungsabwehr und kontinuierliches Monitoring bietet, das Ihr Lieferantenrisikobewertungsprogramm ergänzt.

Wichtige Erkenntnisse

SOC 1 bewertet Kontrollen der Finanzberichterstattung für externe Prüfer, während SOC 2 Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz für das Lieferantenrisikomanagement prüft. Typ II-Berichte, die eine 6- bis 12-monatige operative Wirksamkeit nachweisen, bieten deutlich mehr Sicherheit als Typ I-Stichtagsbewertungen und sind daher die bevorzugte Wahl für Enterprise-Lieferantenbewertungen.

SOC 2-Compliance erfordert für die erstmalige Attestierung 12+ Monate mit sorgfältiger Planung der Beobachtungszeiträume, Abhängigkeiten von Anbietern und Nachweiserhebung. Kontinuierliches Monitoring ergänzt jährliche SOC-Attestierungen durch Echtzeit-Kontrollverfolgung, und ergänzende User Entity Controls (CUECs) bleiben Ihre Verantwortung, auch wenn Anbieter einwandfreie SOC-Meinungen vorweisen.

FAQs

Was ist SOC 1 und SOC 2?

SOC 1 und SOC 2 sind unabhängige Prüfungsberichte, die von lizenzierten Wirtschaftsprüfern gemäß den SSAE Nr. 18 Attestierungsstandards ausgestellt werden. SOC 1 prüft Kontrollen, die für die interne Kontrolle der Nutzerunternehmen über die Finanzberichterstattung relevant sind, mit Fokus auf Anbieter, deren Dienstleistungen die Genauigkeit von Finanzabschlüssen beeinflussen. 

SOC 2 bewertet Kontrollen in Bezug auf Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz für Dienstleistungsunternehmen, die mit sensiblen Daten umgehen. Beide Berichtstypen sind als Typ I (Zeitpunktbetrachtung) und Typ II (Wirksamkeit der Kontrollen über 6-12 Monate) verfügbar.

Was ist der Hauptunterschied zwischen SOC 1 und SOC 2?

SOC 1 konzentriert sich auf Kontrollen, die die Finanzberichterstattung betreffen, und dient externen Prüfern, die eine Absicherung über ausgelagerte Finanzprozesse benötigen. SOC 2 konzentriert sich auf Sicherheits- und Datenschutzkontrollen und richtet sich an Sicherheitsteams und Risikomanager, die die Datenverarbeitungspraktiken von Anbietern bewerten. 

Fordern Sie SOC 1 an, wenn Anbieter Transaktionen verarbeiten, die Ihre Finanzberichte beeinflussen. Fordern Sie SOC 2-Nachweise an, wenn Anbieter sensible Kundendaten speichern, verarbeiten oder übertragen.

Welche typischen Warnsignale gibt es in einem SOC-Bericht?

Wichtige Warnsignale sind qualifizierte Prüfermeinungen, die auf Kontrollmängel hinweisen, enge Geltungsbereichsdefinitionen, die kritische von Ihnen genutzte Services ausschließen, zahlreiche Kontrollausnahmen ohne dokumentierte Behebung, Beobachtungszeiträume von weniger als sechs Monaten sowie wesentliche Änderungen der Kontrolldarstellungen zwischen Berichtszeiträumen. 

Prüfen Sie außerdem, ob Subservice-Organisationen ausgeschlossen wurden, sodass Sie diese Abhängigkeiten separat bewerten müssen.

Wie adressieren SOC-Berichte Cybersecurity-Risiken?

SOC-Berichte bieten wertvolle Sicherheit, haben jedoch Einschränkungen, die Sicherheitsteams verstehen müssen. Das SOC-Framework adressiert direkt Ihre Herausforderungen im Third-Party Risk Management, doch jüngste Sicherheitsvorfälle zeigen Lücken auf, wenn man sich ausschließlich auf jährliche Bestätigungen verlässt. Der SolarWinds-Vorfall 2020 zeigte, wie Anbieter-Risikoanalysen, die sich nur auf jährliche SOC 2-Bestätigungen stützten, eine fortlaufende Kompromittierung übersahen, von der über 18.000 Organisationen betroffen waren. Angreifer schleusten schädlichen Code in Software-Updates ein, umgingen Sicherheitskontrollen und blieben monatelang unentdeckt. 

Die MOVEit-Sicherheitslücke beim Datei-Transfer im Jahr 2023 setzte über 2.500 Organisationen und 66 Millionen Personen einem Risiko aus, als Angreifer die Software eines vertrauenswürdigen Anbieters ausnutzten. Diese Vorfälle verdeutlichen, warum es für ein effektives Lieferantenrisikomanagement entscheidend ist, genau zu verstehen, was SOC 2 bewertet – und was nicht.

Kann ein Anbieter sowohl SOC 1- als auch SOC 2-Berichte haben?

Ja. Organisationen, die sowohl Finanz- als auch Datensicherheitsdienstleistungen anbieten, streben häufig eine doppelte Zertifizierung an. Eine Plattform zur Leistungsverwaltung benötigt möglicherweise SOC 1 für Kontrollen der Finanzberichterstattung über Gehaltsabzüge und SOC 2 für Datenschutzkontrollen zum Schutz von Mitarbeitergesundheitsdaten. 

Der Prüfer führt separate Prüfungen mit unterschiedlichen Kontrollrahmen durch, wobei sich die Beweiserhebung für IT-Generalkontrollen überschneiden kann.

Was bedeutet eine qualifizierte SOC-Meinung für das Anbieterrisiko?

Ein eingeschränktes Testat weist darauf hin, dass der Prüfer Kontrollmängel festgestellt hat, die die Ausstellung eines uneingeschränkten (sauberen) Testats verhinderten. In Typ-II-Berichten dokumentiert Abschnitt 4 die Testergebnisse und Ausnahmen und bietet Transparenz über spezifische Kontrollabweichungen während des Prüfungszeitraums. 

Sie müssen bewerten, ob die dokumentierten Mängel Daten betreffen, die Sie dem Anbieter anvertrauen, und ob kompensierende Kontrollen in Ihrer Umgebung die Lücken abdecken. Eingeschränkte Testate erfordern eine vertiefte Risikobewertung, bevor der Anbieter freigegeben wird.

Wie beeinflussen ausgeschlossene Subservice-Organisationen die Risikobewertung?

SOC-Berichte können Unterdienstleister entweder mit einer Carve-Out-Methode (Kontrollen des Unterdienstleisters sind vom Geltungsbereich ausgeschlossen) oder einer Inclusive-Methode (Kontrollen des Unterdienstleisters sind eingeschlossen) darstellen. 

Wenn ein Anbieter den Carve-Out-Ansatz verwendet, schließt sein SOC-Bericht Kontrollen bei kritischen Unterdienstleistern wie AWS-Infrastruktur oder Zahlungsabwicklungsnetzwerken aus. Unternehmen müssen ausgeschlossene Ebenen identifizieren und separate SOC 2-Berichte von kritischen Unterdienstleistern anfordern, die mit sensiblen Daten umgehen.

Was sind ergänzende Kontrollen der Nutzerorganisation und warum sind sie wichtig?

Ergänzende Kontrollen der Nutzerorganisation (CUECs) sind Kontrollen, deren Umsetzung die Serviceorganisation beim Kunden voraussetzt, um die Kontrollziele zu erreichen. Häufige CUECs sind Benutzerzugriffsüberprüfungen, Funktionstrennung, Überprüfung von Serviceorganisationsberichten, kundenseitige Konfiguration und Überwachung der Verarbeitungsergebnisse. 

Ein einwandfreies SOC-Urteil eines Anbieters entbindet den Kunden nicht von eigenen Kontrollpflichten. Abschnitt 1 des Berichts listet alle CUECs auf, die von Ihnen umgesetzt werden müssen.

Wie oft sollten wir aktualisierte SOC-Berichte von Anbietern anfordern?

Jährliche SOC 2-Berichte sind ab Ausstellungsdatum 12 Monate gültig. Organisationen sollten das Ablaufdatum der SOC-Berichte von Anbietern verfolgen, um eine kontinuierliche Compliance-Transparenz zu gewährleisten. 

Bei Hochrisiko-Anbietern, die sensible Daten verarbeiten, sollte eine kontinuierliche Überwachung während des Jahres implementiert werden, um Sicherheitsvorfälle, SLA-Compliance und Eigentümerwechsel zwischen den formalen Auditzyklen zu verfolgen.