Was ist SOC 2? Type 1 vs. Type 2 erklärt

Wenn Sie schon einmal gefragt wurden "Können Sie uns Ihren SOC 2 schicken?" und nicht sicher waren, was damit gemeint ist, liefert dieser Leitfaden die Antwort. Was ist SOC 2? Es ist ein unabhängiger Assurance-Bericht, erstellt von einer lizenzierten CPA-Gesellschaft, der die Kontrollen beschreibt, die eine Dienstleistungsorganisation zum Schutz von Kundendaten eingerichtet hat, und bestätigt, ob diese Kontrollen tatsächlich funktionieren. Es ist weder ein Gesetz noch ein Zertifikat für die Wand, und kein Softwareanbieter kann ihn für Sie ausstellen. Diese Seite richtet sich an Compliance-Manager, CISOs und Gründer, die Software oder Dienstleistungen an andere Unternehmen verkaufen und verstehen müssen, was ein SOC 2 bedeutet, bevor sie Budget und Kalenderzeit dafür einplanen.

Was SOC 2 tatsächlich ist

SOC 2 steht für System and Organization Controls 2. Es ist ein Berichtsrahmenwerk, definiert vom American Institute of Certified Public Accountants (AICPA). Ein SOC 2-Engagement ist eine Attestierung: Ein unabhängiger Prüfer untersucht Ihre Organisation anhand eines definierten Kriterienkatalogs, testet Ihre Nachweise und gibt ein formelles Urteil ab. Das Ergebnis ist ein detaillierter Bericht. Kunden und ihre Einkaufs- oder Sicherheitsteams lesen diesen Bericht, um zu entscheiden, ob sie Ihnen ihre Daten anvertrauen.

Die Kriterien, an denen der Prüfer Sie misst, sind die AICPA Trust Services Criteria. Es gibt fünf davon: Security, Availability, Processing Integrity, Confidentiality und Privacy. Security ist verpflichtend und wird oft als Common Criteria bezeichnet, weil sie das Rückgrat bilden, das jeder SOC 2-Bericht teilt. Die anderen vier sind optional, und Sie nehmen sie nur dort auf, wo sie für die Zusagen relevant sind, die Sie Ihren Kunden machen. Ein SaaS-Unternehmen, das Verfügbarkeit garantiert, ergänzt in der Regel Availability; ein Lohnabrechnungsdienstleister möglicherweise Processing Integrity und Confidentiality; eine Plattform für Gesundheits- oder Verbraucherdaten oft Privacy. Widerstehen Sie dem Drang, Kriterien hinzuzufügen, um gründlich zu wirken. Jedes zusätzliche Kriterium bedeutet einen weiteren Satz an Kontrollen, die Sie über das gesamte Zeitfenster betreiben und belegen müssen, und gerade Privacy ist eine ernsthafte Verpflichtung, die Aufbewahrung, Einwilligung und Löschung mit hineinzieht. Ergänzen Sie ein Kriterium, wenn ein Vertrag oder ein öffentliches Versprechen es verlangt, lassen Sie es andernfalls weg, und ergänzen Sie es bei der nächsten Erneuerung, falls ein Käufer tatsächlich danach fragt.

Ein Punkt ist es wert, früh betont zu werden, weil er das häufigste Missverständnis betrifft: SOC 2 ist ein Attestierungsbericht, unterzeichnet von einer CPA-Gesellschaft. Es gibt kein zentrales Register, keine Zertifikatsnummer und kein Akkreditierungslogo, das für sich genommen etwas bedeutet. Wenn jemand sagt, er sei "SOC 2-zertifiziert", besitzt er in Wirklichkeit einen SOC 2-Bericht mit dem Urteil eines Prüfers. Diese Unterscheidung zählt, wenn Sie die Aussagen eines Anbieters lesen oder Ihre eigenen formulieren.

Wer SOC 2 braucht und wer darauf verzichten kann

SOC 2 ist käufergetrieben. Keine Regierung verlangt den Bericht. Verlangt wird er von Ihren Kunden, meist als Bedingung für den Abschluss oder die Verlängerung eines Vertrags. Diese eine Tatsache sollte prägen, wie Sie über Umfang, Zeitplan und Kosten denken. Sie streben einen SOC 2 an, weil ein Deal davon abhängt oder weil absehbar ist, dass Deals bald davon abhängen werden. Die erste Frage lautet also, welcher Kunde fragt und was er stattdessen akzeptieren würde. Manche Käufer geben sich mit einem ISO 27001-Zertifikat zufrieden oder mit einem ausgefüllten Sicherheitsfragebogen und einem Gespräch mit Ihrem CTO. Das herauszufinden kostet eine E-Mail, und die Antwort ist manchmal deutlich günstiger als ein Audit.

Organisationen, die typischerweise einen brauchen

• SaaS- und B2B-Softwareanbieter mit US-Kundschaft, die Kundendaten speichern, verarbeiten oder übertragen.
• Cloud- und Infrastrukturanbieter, Datenplattformen und API-Unternehmen, deren Kunden im Einkaufsprozess nach der Sicherheitslage fragen.
• Managed Service Provider, Fintech- und Healthtech-Anbieter und jedes Unternehmen, das sensible Informationen im Auftrag eines Kunden verarbeitet.
• Startups auf dem Weg in höhere Marktsegmente, wo der erste Enterprise- oder regulierte Kunde einen SOC 2-Bericht zur harten Hürde im Security-Review macht.

Organisationen, die ihn meist entbehren können

• Unternehmen ohne B2B-Kunden, die danach fragen, wo die Kosten keinen Umsatz bringen und keine echte Frage beantworten.
• Unternehmen, deren Kunden ein anderes Framework genügt. Ein europäischer Käufer bevorzugt möglicherweise ISO 27001; einem Käufer im US-Gesundheitswesen ist HIPAA wichtiger; ein Zahlungsunternehmen konzentriert sich auf PCI DSS.
• Sehr frühe Teams ohne Produkt im Produktivbetrieb und noch ohne Kundendaten, die es zu schützen gilt.

SOC 2 existiert außerdem neben anderen Frameworks und ergänzt sie. Viele Organisationen pflegen SOC 2 und ISO 27001 gemeinsam, weil sich die zugrunde liegenden Kontrollen stark überschneiden und die beiden Berichte Fragen unterschiedlicher Zielgruppen beantworten. Wenn ein bestimmter Kunde oder eine Region Sie zu einem Framework führt, beginnen Sie dort und verwenden Sie dieselben Nachweise für die anderen wieder.

Was ein SOC 2 von Ihnen verlangt

Weil SOC 2 kriterienbasiert ist und Gestaltungsspielraum lässt, gibt es keine einheitliche Pflichtliste von Kontrollen, die auf jedes Unternehmen identisch zutrifft. Stattdessen beschreiben die Trust Services Criteria die Ergebnisse, die Ihre Kontrollen erreichen müssen, und Sie entwerfen Kontrollen, die zu Ihren eigenen Systemen, Ihrer Größe und Ihrem Risiko passen. Der Prüfer beurteilt dann, ob diese Kontrollen angemessen gestaltet sind und, bei einem Type 2, ob sie über den Zeitraum hinweg wirksam funktioniert haben.

In der Praxis decken die Security Common Criteria einen vertrauten Katalog an Governance- und Technikbereichen ab. Von Ihnen wird erwartet, dass Sie über die meisten der folgenden Punkte belastbare Kontrolle nachweisen:

• Governance und Risiko. Dokumentierte Richtlinien, definierte Rollen und Verantwortlichkeiten, ein Risikobewertungsprozess und Aufsicht durch das Management.
• Zugriffskontrolle. Eindeutige Benutzerkonten, Least-Privilege-Zugriff, Multi-Faktor-Authentifizierung und regelmäßige Zugriffsüberprüfungen mit Nachweisen, dass sie stattgefunden haben.
• Change Management. Ein kontrollierter Weg von der Codeänderung in die Produktion, mit Review, Tests und Freigabe, die Sie für reale Änderungen vorzeigen können.
• Betrieb und Überwachung. Logging, Alerting, Schwachstellenmanagement und die Fähigkeit, Anomalien zu erkennen und darauf zu reagieren.
• Incident Response. Ein dokumentierter Prozess für den Umgang mit Sicherheitsvorfällen, einschließlich Erkennung, Eskalation und Behebung.
• Lieferanten- und Drittparteienmanagement. Sorgfaltsprüfung der Unterauftragsverarbeiter und Lieferanten, die mit Ihren Systemen oder Daten in Berührung kommen.
• Personalsicherheit. Hintergrundprüfungen, wo angemessen, Onboarding und Offboarding sowie Security-Awareness-Schulungen.

Das prägende Merkmal von SOC 2, und der Teil, den Teams unterschätzen, sind die Nachweise. Eine Richtlinie, die besagt, dass Zugriffe vierteljährlich überprüft werden, reicht allein nicht aus. In einem Type 2-Audit müssen Sie die tatsächlichen Prüfprotokolle für jedes Quartal des Zeitraums vorlegen und zeigen, wer wann was überprüft hat. Ein SOC 2 ist im Kern ein Test, ob Ihre Kontrollen konsistent laufen und eine verlässliche Spur hinterlassen. Genau hier landen die echten Kosten. Die Richtlinien zu schreiben ist eine Sache von ein paar konzentrierten Wochen. Jeden Manager dazu zu bringen, jede Zugriffsüberprüfung pünktlich abzuschließen, jedes Quartal, mit einem Protokoll, das eine Stichprobe übersteht, bedeutet Monate des Hinterherlaufens, und es ist der Grund, warum interne SOC 2-Verantwortliche ausbrennen. Automatisieren Sie die Nachweiserfassung überall dort, wo die Kontrolle es zulässt, und machen Sie jede Kontrolle, die Sie nicht automatisieren können, zur namentlich zugewiesenen Aufgabe einer Person mit festem Termin.

Type 1 vs. Type 2: der Unterschied und welchen Sie brauchen

Die wichtigste Entscheidung in einem SOC 2-Engagement ist Type 1 gegenüber Type 2, und die Unterscheidung ist einfacher, als sie klingt. Ein Type 1-Bericht bewertet das Design Ihrer Kontrollen zu einem einzelnen Zeitpunkt. Der Prüfer fragt: Sind heute die richtigen Kontrollen vorhanden, und sind sie angemessen gestaltet, um die Kriterien zu erfüllen? Es ist eine Momentaufnahme.

Ein Type 2-Bericht bewertet die Wirksamkeit derselben Kontrollen im Betrieb über einen Zeitraum, üblicherweise drei bis zwölf Monate. Der Prüfer stellt eine härtere Frage: Haben diese Kontrollen tatsächlich funktioniert, konsistent, über das gesamte Prüffenster hinweg? Um sie zu beantworten, zieht der Prüfer Stichproben von Nachweisen aus dem gesamten Zeitraum. Ein Type 2 ist ein Film.

Type 2 ist das, was die meisten Kunden letztlich wollen, weil er zeigt, dass Ihre Sicherheit eine dauerhafte betriebliche Realität ist. Seien Sie ehrlich zu sich selbst, was ein Type 1 Ihnen bringt. Er löst einen Deal-Blocker und beweist, dass das Design trägt, und ein erfahrener Käufer liest ihn als Versprechen für die Zukunft. Wenn der fragende Kunde ein großes reguliertes Unternehmen ist, wird er den Type 2 ohnehin verlangen, sodass die Kosten für zwei Engagements auf dem Weg dorthin ein realer Posten sind, den Sie vor der Entscheidung abwägen sollten. Ein üblicher und vernünftiger Weg ist, mit einem Type 1 zu starten, um die Solidität des Designs zu belegen, dann das Beobachtungsfenster zu durchlaufen und einen Type 2 zu erstellen. Manche Organisationen überspringen den Type 1 ganz und gehen direkt zum Type 2, sobald ihre Kontrollen stabil sind. Die richtige Wahl hängt davon ab, wie schnell ein Kunde einen Beleg braucht: Ein Type 1 lässt sich früher erstellen, während ein Type 2 verlangt, dass Sie die Kontrollen zuerst über den vollen Zeitraum betreiben. Bedenken Sie, dass ein SOC 2-Bericht ein definiertes Abdeckungsfenster hat; die meisten Unternehmen erneuern daher jährlich, um für ihre Kunden eine lückenlose Abdeckung zu halten.

Wie Sie tatsächlich zu einem SOC 2 kommen: ein praktisches Programm

1. Entscheiden Sie, warum und wann. Klären Sie, welcher Kunde oder Deal die Anforderung treibt und ob er schnell einen Type 1 oder vollständig einen Type 2 braucht. Lassen Sie das Ihren Zeitplan bestimmen.
2. Legen Sie den Umfang fest. Wählen Sie, welche Trust Services Criteria gelten. Beginnen Sie mit dem verpflichtenden Security-Kriterium und ergänzen Sie Availability, Processing Integrity, Confidentiality oder Privacy nur dort, wo sie echte Kundenzusagen widerspiegeln. Definieren Sie, welche Systeme und Dienste im Umfang liegen.
3. Führen Sie ein Readiness-Assessment durch. Gleichen Sie Ihre aktuellen Kontrollen mit den Kriterien ab und finden Sie die Lücken. Hier erfahren Sie, wie weit Sie tatsächlich von der Audit-Reife entfernt sind.
4. Schließen Sie die Lücken. Schreiben Sie die fehlenden Richtlinien, aktivieren Sie die fehlenden technischen Kontrollen und reparieren Sie kaputte Prozesse. Gestalten Sie jede Kontrolle, wo immer möglich, so, dass sie automatisch Nachweise erzeugt.
5. Betreiben Sie die Kontrollen und sammeln Sie Nachweise. Für einen Type 2 lassen Sie die Kontrollen über das volle Beobachtungsfenster laufen und erfassen dabei die Aufzeichnungen: Zugriffsüberprüfungen, Change-Freigaben, Incident-Tickets, Schulungsprotokolle, Monitoring-Alerts.
6. Wählen Sie eine unabhängige CPA-Gesellschaft. Nur eine lizenzierte CPA-Gesellschaft kann die SOC 2-Prüfung durchführen und den Bericht ausstellen. Wählen Sie Ihren Prüfer früh, damit seine Erwartungen Ihre Nachweise prägen. Die Gesellschaften unterscheiden sich stärker, als man erwarten würde, darin, was sie für dasselbe Kriterium als Nachweis akzeptieren; wählen Sie Ihre also, bevor Sie die Nachweis-Pipeline aufbauen, und fragen Sie sie geradeheraus, wie eine bestehende Stichprobe aussieht. Ein Quartal an Aufzeichnungen für einen anderen Geschmack neu aufzubauen ist die am leichtesten vermeidbare Verzögerung im gesamten Prozess.
7. Schließen Sie das Audit ab. Der Prüfer testet Ihr Design und zieht bei einem Type 2 Stichproben von Nachweisen über den Zeitraum, dann stellt er den Bericht mit seinem Urteil aus.
8. Pflegen und erneuern Sie. Halten Sie die Kontrollen am Laufen, frischen Sie Nachweise kontinuierlich auf und planen Sie den nächsten Bericht, damit Ihre Abdeckung lückenlos bleibt.

Wenn Sie sehen möchten, wie Kontrollen, Nachweiserfassung und Audit-Vorbereitung an einem Ort zusammenkommen, lesen Sie, wie Venvera SOC 2 handhabt, und für einen breiteren Marktüberblick unseren Vergleich von SOC 2-Compliance-Software im Vergleich.

Häufig gestellte Fragen

Ist SOC 2 eine Zertifizierung?

Nein. SOC 2 ist ein Attestierungsbericht, ausgestellt von einer lizenzierten CPA-Gesellschaft. Es gibt keine Zertifikatsnummer und kein zentrales Register. Wenn ein Anbieter sagt, er sei "SOC 2-zertifiziert", besitzt er einen SOC 2-Bericht mit dem Urteil eines unabhängigen Prüfers.

Was ist der Unterschied zwischen Type 1 und Type 2?

Ein Type 1-Bericht bewertet, ob Ihre Kontrollen zu einem einzelnen Zeitpunkt angemessen gestaltet sind. Ein Type 2-Bericht bewertet, ob diese Kontrollen über einen Zeitraum, üblicherweise drei bis zwölf Monate, wirksam funktioniert haben, anhand von Nachweisen, die über das gesamte Fenster hinweg stichprobenartig geprüft werden. Type 2 ist der Bericht, den die meisten Kunden letztlich wollen.

Wie viele Trust Services Criteria gibt es und welche sind verpflichtend?

Es gibt fünf: Security, Availability, Processing Integrity, Confidentiality und Privacy. Security, die Common Criteria, ist in jedem SOC 2 verpflichtend. Die anderen vier sind optional, und Sie nehmen nur diejenigen auf, die zu den Zusagen passen, die Sie Ihren Kunden machen.

Müssen wir gesetzlich SOC 2-konform sein?

Kein Gesetz verlangt SOC 2. Der Bericht ist käufergetrieben: Kunden fordern ihn im Einkaufsprozess oder als Vertragsbedingung an. Sie streben ihn an, weil Umsatz davon abhängt; eine behördliche Pflicht besteht nicht. Wenn Ihren Kunden ISO 27001, HIPAA oder ein anderes Framework genügt, kann Ihnen das besser dienen.

Kann Venvera oder irgendeine Software unseren SOC 2-Bericht ausstellen?

Nein. Nur eine unabhängige, lizenzierte CPA-Gesellschaft kann die Prüfung durchführen und den Bericht ausstellen. Compliance-Software hilft Ihnen, Kontrollen aufzubauen, Nachweise zu sammeln und sich auf das Audit vorzubereiten, aber das Urteil selbst muss vom Prüfer kommen. Seien Sie vorsichtig bei jedem Tool, das etwas anderes suggeriert.

Wie lange dauert es, einen SOC 2 zu bekommen?

Ein Type 1 lässt sich relativ schnell erstellen, sobald Ihre Kontrollen entworfen und eingerichtet sind. Ein Type 2 dauert länger, weil Sie die Kontrollen über den vollen Beobachtungszeitraum betreiben müssen, üblicherweise drei bis zwölf Monate, bevor der Prüfer sie testen kann. Readiness und Gap-Behebung kosten zusätzlich Zeit, bevor einer der beiden Berichte beginnt.

Primärquellen

• AICPA Trust Services Criteria - die maßgeblichen Kriterien für Security, Availability, Processing Integrity, Confidentiality und Privacy, an denen ein SOC 2 gemessen wird. Trust Services Criteria.
• AICPA SOC 2-Überblick - die Erläuterung der AICPA selbst zu SOC 2-Berichten, ihrem Zweck und ihrer Verwendung. SOC 2 für Dienstleistungsorganisationen.

Hinweis zum Geltungsbereich. Dieser Leitfaden fasst allgemein zusammen, wie SOC 2 funktioniert. Die genauen Kriterien, den Umfang und die Kontrollerwartungen für Ihre Organisation sollten Sie anhand der aktuellen AICPA Trust Services Criteria und mit Ihrer gewählten CPA-Gesellschaft bestätigen.

Von Alexander Sverdlov, CEO und Gründer, Venvera. Veröffentlicht am 20. Juli 2026 - Zuletzt geprüft am 20. Juli 2026.