ISO 27001 vs SOC 2: Was übertragbar ist und was nicht

Nach Paul Gillet · Aktualisiert 2026-10-17

ISO/IEC 27001 und SOC 2 beantworten dieselbe Kundenfrage, „Können wir Ihnen unsere Daten anvertrauen?“, auf unterschiedliche Weise. ISO 27001 zertifiziert ein Managementsystem: Eine akkreditierte Zertifizierungsstelle bestätigt, dass Sie ein Informationssicherheits-Managementsystem (ISMS) betreiben, das die Klauseln 4 bis 10 erfüllt, und dass Sie in einer Statement of Applicability festgelegt haben, welche der 93 Maßnahmen aus Anhang A zutreffen. SOC 2 ist eine Attestierung: Eine CPA-Firma berichtet darüber, ob Ihre Kontrollen die Trust Services Criteria der AICPA erfüllen. Ein Type-II-Bericht zeigt, wie diese Kontrollen über einen Zeitraum gewirkt haben, typischerweise 3 bis 12 Monate.

Die technische Überschneidung ist groß. Zugriffskontrolle, Protokollierung und Überwachung, Änderungsmanagement, Schwachstellenmanagement, Incident Response, Lieferantenmanagement und Backup kommen in beiden vor, und die meisten Sicherheitsmaßnahmen, die Sie für das eine umsetzen, zählen auch für das andere. Die Unterschiede liegen eher in Struktur und Schwerpunkt als in den Kontrollen selbst.

Beim Wechsel von SOC 2 zu ISO 27001 ist der eigentliche Mehraufwand das Managementsystem. ISO verlangt einen definierten ISMS-Geltungsbereich, Informationssicherheitsziele, dokumentierte Informationen unter Lenkung, einen Prozess zur Risikobeurteilung und -behandlung mit einer Statement of Applicability, interne Audits und Managementbewertungen. Dies sind die ISO-Klauseln, die unten als nicht zugeordnet erscheinen, dazu einige Anhang-A-Maßnahmen, insbesondere zur physischen Sicherheit, die SOC-2-Prüfer bei reinen Cloud-Unternehmen oft nur oberflächlich behandeln.

Beim Wechsel von ISO 27001 zu SOC 2 hat nahezu jedes Sicherheitskriterium, einschließlich der Kriterien zum Kontrollumfeld (Aufsicht durch die Geschäftsführung, Integrität und ethische Werte, Verantwortlichkeit), ein ISO-Gegenstück. Der neue Aufwand liegt in den optionalen Kategorien, die Sie einbeziehen. Processing Integrity und die meisten Datenschutzkriterien haben kein Pendant im ISMS und erscheinen hier als „Keine Zuordnung in unseren Daten“; Ausnahmen sind Aufbewahrung, Löschung und Meldung von Datenschutzverletzungen, die durch die Protokoll-, Lösch- und Vorfallmaßnahmen von ISO teilweise abgedeckt werden. Availability und Confidentiality liegen meist nahe an dem, was ISO bereits verlangt.

Auf einen Blick

Welches brauchen Sie?

Ausgangspunkt ist, wer fragt. Wenn US-Unternehmenskunden Sicherheitsfragebögen schicken, die nach „Ihrem SOC 2“ fragen, ist ein SOC-2-Type-II-Bericht das, was den Abschluss sichert; ein ISO-Zertifikat wird oft akzeptiert, aber nicht immer. Wenn Kunden in Europa, Asien oder im öffentlichen Sektor sitzen oder Ausschreibungen ISO/IEC 27001 nennen, ist das Zertifikat die erwartete Antwort. Viele Softwareunternehmen, die international verkaufen, benötigen schließlich beides.

Wenn noch niemand danach fragt, baut ISO 27001 das nachhaltigere Programm auf, weil das Managementsystem Risikobeurteilung, Ziele, interne Audits und Managementbewertungen erzwingt. SOC 2 führt schneller zu einem ersten Ergebnis, wenn ein bestimmter Abschluss davon abhängt.

Beides umsetzen, ohne alles doppelt zu machen

1. Einen Kontrollsatz aufbauen. Ordnen Sie jede Kontrolle ihrer Anhang-A-Maßnahme und ihrem Trust-Services-Kriterium zu; der Vergleich unten zeigt, wo sie übereinstimmen.
2. Das ISMS nur einmal schreiben. Geltungsbereich, Risikobeurteilung, Statement of Applicability, interne Audits und Managementbewertungen sind ISO-Anforderungen, liefern SOC-2-Prüfern aber auch die Governance-Nachweise, die CC1–CC5 verlangen.
3. Nachweise laufend erfassen. SOC 2 Type II prüft Nachweise über den gesamten Zeitraum, daher dienen Nachweise, die dafür erfasst wurden, auch den ISO-Überwachungsaudits.
4. Den Auditkalender abstimmen. Manche Firmen bieten kombinierte oder unmittelbar aufeinanderfolgende Audits an; wenn der SOC-2-Zeitraum mit dem ISO-Überwachungszyklus abgestimmt wird, sinkt die Belastung.
5. Die Lücken in beide Richtungen im Blick behalten. SOC 2 ergänzt Privacy und Processing Integrity, sofern im Umfang; ISO ergänzt die Managementsystem-Klauseln und die physische Sicherheit, die reine Cloud-SOC-2-Umfänge oberflächlich behandeln.

Kosten und Aufwand

Keines von beiden hat einen festen Preis. Die externe Gebühr (Zertifizierungsstelle oder CPA-Firma) hängt von Umfang, Personalstärke und Standorten ab und ist meist kleiner als der interne Aufwand und die Tools. Für ein kleines Unternehmen, das zum ersten Mal zertifiziert wird, sollten Sie mehrere Monate Teilzeitarbeit einer Person einplanen, die das Programm verantwortet, dazu die Auditgebühr. Beides umzusetzen kostet weniger als das Doppelte von einem der beiden, weil die meisten Kontrollen und Nachweise gemeinsam genutzt werden.

Ein realistischer Zeitplan für beides

Ein typischer Weg für ein Softwareunternehmen, das mit SOC 2 beginnt:

1. Monate 1–3: Vorbereitung. System abgrenzen, Richtlinien schreiben, die Lücken schließen, die die Lückenanalyse aufdeckt, CPA-Firma auswählen.
2. Monat 3: Type I (optional), sobald die Kontrollen konzipiert und eingeführt sind.
3. Monate 3–9: der erste Type-II-Beobachtungszeitraum, typischerweise drei bis sechs Monate, mit dem Bericht einige Wochen nach dessen Ende.
4. Monate 6–12: das ISMS ergänzen. ISO-Geltungsbereich definieren, Risikobeurteilung durchführen, Statement of Applicability schreiben sowie ein internes Audit und eine Managementbewertung durchführen. Die meisten Anhang-A-Maßnahmen laufen für SOC 2 bereits.
5. Monate 10–14: ISO Stage 1 und Stage 2 Audits.

Mit ISO 27001 zu beginnen kehrt die Reihenfolge um: sechs bis zwölf Monate bis zur Zertifizierung, danach eine SOC-2-Bereitschaftsprüfung und ein drei- bis sechsmonatiger Beobachtungszeitraum. In beiden Fällen braucht das zweite Framework nur einen Bruchteil der Zeit des ersten.

Praxisbeispiel: ein SaaS-Unternehmen mit 50 Beschäftigten

Angenommen, ein B2B-Softwareunternehmen mit 50 Beschäftigten hat einen SOC-2-Type-II-Bericht zu Security, Availability und Confidentiality. Ein großer europäischer Kunde verlangt nun eine ISO-27001-Zertifizierung.

Was übertragbar ist: Zugriffskontrolle, Änderungsmanagement, Protokollierung und Überwachung, Schwachstellenmanagement, Incident Response, Lieferantenmanagement, Backups und Business Continuity. Das Unternehmen betreibt diese Kontrollen bereits und erfasst Nachweise dafür, daher gehen sie weitgehend unverändert in die Statement of Applicability ein.

Was neu ist: das ISMS selbst. Das Unternehmen braucht einen dokumentierten Geltungsbereich (wahrscheinlich das Produkt, dessen Infrastruktur und die Teams, die es betreiben), Informationssicherheitsziele mit Messgrößen, eine formale Methode und ein Register für die Risikobeurteilung, eine Statement of Applicability mit begründeten Ausschlüssen, ein internes Audit durch eine von der Arbeit unabhängige Person und eine Managementbewertung mit Protokoll. Einige Maßnahmen aus Anhang A erfordern ebenfalls Aufmerksamkeit, typischerweise die physische Sicherheit des Büros und Threat Intelligence.

Was es kostet: vor allem die Zeit der Person, die das ISMS verantwortet, dazu die Gebühren der Zertifizierungsstelle und ein externer interner Auditor, falls niemand Unabhängiges verfügbar ist. Da Kontrollen und Nachweise bereits existieren, kostet das zweite Framework deutlich weniger als das erste.

Kernaussagen

• Einen Kontrollsatz betreiben und zweimal nachweisen. Ordnen Sie jede Kontrolle sowohl einer Anhang-A-Maßnahme als auch einem Trust-Services-Kriterium zu.
• SOC 2 → ISO: Budget für das ISMS selbst einplanen (Geltungsbereich, Ziele, Risikobehandlung, SoA, internes Audit, Managementbewertung), nicht für neue technische Kontrollen.
• ISO → SOC 2: früh entscheiden, in welchen optionalen Kategorien Sie im Umfang sind. Privacy und Processing Integrity sind die Bereiche, in denen neue Arbeit entsteht.

Diesen Vergleich herunterladen (CSV) In der Lückenanalyse öffnen →