Compliance · 2026-07-03

SOC 2 vs. ISO 27001: Was brauchen Sie wirklich?

SOC 2 und ISO 27001 sind die beiden Security-Frameworks, nach denen ein B2B-Unternehmen am wahrscheinlichsten gefragt wird. Die Frage, welches zuerst, verbrennt mehr Führungszeit als fast jede andere Compliance-Entscheidung. Die Kurzfassung: Die Frameworks überlappen inhaltlich stark und unterscheiden sich vor allem in Audit-Modell und Publikum. Entscheiden Sie danach, wer fragt, und bauen Sie ein Kontrollset, das beiden dient.

Was die beiden Frameworks eigentlich sind

SOC 2 ist eine Attestierung, keine Zertifizierung. Eine CPA-Gesellschaft prüft Ihre Kontrollen gegen die AICPA Trust Services Criteria - Security ist Pflicht; Availability, Confidentiality, Processing Integrity und Privacy sind optional - und stellt einen Bericht aus. Ein Type-I-Bericht bewertet das Kontrolldesign zu einem Stichtag; ein Type-II-Bericht die Wirksamkeit über einen Beobachtungszeitraum, typisch 3-12 Monate. Käufer lesen den Bericht selbst, inklusive Abweichungen.

ISO/IEC 27001 ist ein Zertifizierungsstandard für ein Informationssicherheits-Managementsystem (ISMS). Eine akkreditierte Zertifizierungsstelle auditiert Ihr ISMS - einschließlich der anwendbaren Annex-A-Kontrollen der ISO 27001:2022 - und stellt ein Zertifikat im Drei-Jahres-Zyklus mit jährlichen Überwachungsaudits aus. Käufer sehen meist Zertifikat und Anwendbarkeitserklärung, nicht das Audit-Detail.

Wo sie sich in der Praxis unterscheiden

Die Substanz - Zugriffskontrolle, Change Management, Monitoring, Incident Response, Lieferantenmanagement, Business Continuity - ist weitgehend dasselbe Kontrollset unter anderen Etiketten. Die Unterschiede, die zählen, sind kommerziell und strukturell.

  • Publikum: SOC 2 dominiert US-Enterprise-Einkauf; ISO 27001 wiegt in Europa, bei regulierten Käufern und in öffentlichen Ausschreibungen schwerer.
  • Ergebnis: SOC 2 liefert einen detaillierten Bericht, den Ihr Kunde unter NDA liest; ISO 27001 ein Zertifikat, das Sie jedem zeigen können.
  • Modell: SOC 2 prüft Kontrollen jede Periode neu; ISO 27001 zertifiziert das Managementsystem, das die Kontrollen betreibt.
  • Flexibilität: Bei SOC 2 wählen Sie Trust-Kriterien pro Bericht; bei ISO 27001 passiert das Scoping über ISMS-Grenze und Anwendbarkeitserklärung.

Wie Sie in einem Meeting entscheiden

Listen Sie Ihre laufenden Deals und Ihren Zielmarkt. Blockieren US-Enterprise-Fragebögen, entsperrt ein SOC 2 Type II am schnellsten Umsatz. Viele US-Käufer akzeptieren ISO 27001 nicht als Ersatz. Sind Ihre Käufer europäische Banken, Versicherer oder öffentliche Auftraggeber, ist ISO 27001 meist die erwartete Basis, und DORA oder Auslagerungsregulierung lässt Ihre Kunden explizit danach fragen.

Wenn beide Märkte zählen: Starten Sie mit dem, von dem die nächsten zwölf Monate Umsatz abhängen, aber entwerfen Sie das Kontrollset von Tag eins für beide. Die Grenzkosten des zweiten Frameworks auf einem geteilten Kontrollset sind weit niedriger als zwei getrennte Programme.

Kosten und Zeitplan: was beides wirklich treibt

Keines der Frameworks hat einen Festpreis, aber die Treiber sind vorhersehbar. Audit-Honorare skalieren mit dem Scope (Anzahl Systeme, Standorte, Trust-Kriterien bzw. Annex-A-Kontrollen), der organisatorischen Komplexität und damit, wie viel Nacharbeit die Readiness-Phase aufdeckt. Der größere Kostenblock ist fast immer intern: Engineering-Zeit, um Lücken zu schließen, Richtlinien zu schreiben, die tatsächlich gelebt werden, und Nachweise zu erzeugen. Budgetieren Sie die Readiness-Phase als das eigentliche Projekt und das Audit als seinen Checkpoint.

Zum Zeitplan: Ein SOC 2 Type I ist nach einigen Monaten ernsthafter Readiness-Arbeit typischerweise erreichbar; der Type II braucht danach zusätzlich sein Beobachtungsfenster. ISO 27001 dauert Ende-zu-Ende meist länger, weil das ISMS - Risikoanalyse, Anwendbarkeitserklärung, internes Audit, Management-Review - vor dem Zertifizierungsaudit existiert und gearbeitet haben muss. Beides sind wiederkehrende Verpflichtungen: SOC 2 wird jede Periode neu geprüft, ISO 27001 hat jährliche Überwachungsaudits. Was Sie bauen, muss das Team tragen können, das Sie tatsächlich haben.

Was Auditoren von einem Cloud-Team konkret verlangen

Über beide Frameworks hinweg sind die Anfragen, die bei einem Cloud- oder Plattform-Team landen, bemerkenswert konsistent. Wenn das Folgende existiert und direkt von der Infrastruktur erzeugt wird, werden beide Audits drastisch billiger:

  • Access Reviews: wer Admin in welchem Cloud-Account ist, wann zuletzt geprüft wurde, und Nachweis, dass Leaver fristgerecht Zugriff verlieren.
  • Change Management: Pull-Request-Historie mit Review und Freigabe vor Produktionsänderungen - mit IaC nahezu gratis.
  • Logging und Monitoring: zentrale Audit-Logs, Alarme auf sicherheitsrelevante Ereignisse und ein dokumentierter Reaktionspfad.
  • Backup und Recovery: Restore-Tests mit datiertem Nachweis.
  • Lieferantenmanagement: eine aktuelle Liste der Auftragsverarbeiter und Cloud-Dienste mit Verantwortlichem, Zweck und Datenklassifizierung.
  • Incident-Aufzeichnungen: Post-Incident-Notizen für alles Wesentliche - Erkennung, Reaktion, Follow-up.

Der Shared-Control-Set-Ansatz

Womit auch immer Sie starten: Kontrollen einmal bauen und auf beide Frameworks mappen - ein Access-Review-Prozess, eine Change-Management-Pipeline, ein Incident-Runbook, ein Lieferantenregister, jeweils den Trust Services Criteria und Annex A zugeordnet. In der Cloud lässt sich der Großteil der Nachweise aus der Infrastruktur selbst erzeugen: IaC-Review-Gates, IAM-Access-Reviews, zentrale Logs, automatisierte Backup-Restore-Tests.

Genau hier zahlt sich Readiness-Arbeit aus. Die Cloud-Umgebung in einen Zustand zu bringen, in dem Nachweise kontinuierlich entstehen, ist der eigentliche Kostenblock, und er ist über SOC 2, ISO 27001 und DORA wiederverwendbar.

Cloud Security & Compliance Readiness

FAQ

Können wir SOC 2 und ISO 27001 gleichzeitig machen?

Ja. Auf einem geteilten Kontrollset ist das oft effizient. Aber rechnen Sie mit zwei Audit-Prozessen mit unterschiedlichem Rhythmus. Die meisten Teams versetzen sie um ein bis zwei Quartale, damit dieselben Leute nicht zwei Audits im selben Monat bedienen.

Brauchen wir sofort einen Type-II-Bericht?

Meist ist Type I zuerst der pragmatische Weg: Er belegt das Design schnell, und das Type-II-Beobachtungsfenster läuft danach an. Manche Käufer akzeptieren Type I plus verbindliches Type-II-Datum.