C5 vs. SOC 2: gleiche Logik, anderer Markt

Problem in der Praxis

In vielen Organisationen werden C5 und SOC 2 als zwei voneinander getrennte Projekte behandelt. Der Vertrieb fordert SOC 2, weil US-Kunden danach fragen. Das deutsche Geschäft oder eine regulierte Branche fordert C5. In der Folge laufen zwei Readiness-Projekte, zwei Beobachtungszeiträume, teils zwei Prüfungsteams, und die gleichen Kontrollen werden doppelt beschrieben, doppelt getestet und doppelt belegt.

Das ist teuer und erzeugt Reibung, obwohl die inhaltliche Überschneidung der Kontrollthemen hoch ist. Beide Rahmenwerke adressieren Zugriffssteuerung, Change Management, Betrieb, Incident-Behandlung, Lieferanten und Continuity. Der Unterschied liegt in der Verpackung: C5 gibt einen konkreten Kriterienkatalog vor, SOC 2 verlangt, dass das Unternehmen selbst geeignete Kontrollen zu den Trust Services Criteria definiert und nachweist.

Das zweite Praxisproblem ist begriffliche Unschärfe. Kunden und interne Stakeholder sprechen von "C5-Zertifikat" oder "SOC-2-zertifiziert". Beide Formulierungen sind falsch und führen zu falschen Erwartungen an Geltung, Aussagekraft und Vergleichbarkeit der Berichte.

CISO-Einordnung

Es lohnt sich, beide Rahmenwerke an denselben Leitfragen zu messen, statt sie als unvergleichbar zu behandeln:

• Welcher Markt und welche Kunden fordern den Nachweis tatsächlich?
• Welche Prüf-Logik liegt zugrunde, und ist Typ 2 gefordert?
• Wie ist der Kriterienrahmen aufgebaut: fest vorgegeben oder prinzipienbasiert?
• Wie weit überlappen die Kontrollthemen, und wo gibt es echte Zusatzanforderungen?
• Lässt sich eine Evidenzbasis für mehrere Berichte nutzen?

C5 ist ein Werk des BSI. Der Nachweis erfolgt über einen Attestierungsbericht nach ISAE 3000 (Revised), und nur Wirtschaftsprüfer beziehungsweise Wirtschaftsprüfungsgesellschaften dürfen C5-Prüfungen durchführen und attestieren. C5 hat in Deutschland faktische Verbindlichkeit erlangt, unter anderem über den BSI-Mindeststandard zur Nutzung externer Cloud-Dienste und über vertragliche sowie regulatorische Anforderungen. Die großen Hyperscaler führen C5-Attestierungen.

SOC 2 stammt von der AICPA und wird durch eine unabhängige Wirtschaftsprüfungsgesellschaft (CPA firm) attestiert. Maßgeblich sind die Trust Services Criteria mit der verpflichtenden Kategorie Security und optionalen Kategorien für Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz. SOC 2 ist vor allem im US- und SaaS-Kontext der eingebürgerte Vertrauensnachweis gegenüber Geschäftskunden. Die inhaltliche Ausgestaltung von SOC 2 ist urheberrechtlich geschützt; Detailkriterien werden hier nicht wiedergegeben.

Der zentrale inhaltliche Unterschied: C5 arbeitet mit einem festen Kriterienkatalog, der weniger Interpretationsspielraum lässt und Kontrollen präzise vorgibt. SOC 2 ist prinzipienbasiert und überlässt dem Unternehmen, welche konkreten Kontrollen es zur Erfüllung der Kriterien einsetzt. Beides hat Vor- und Nachteile: C5 erleichtert Vergleichbarkeit, SOC 2 erlaubt mehr Anpassung an das eigene Kontrollsystem.

Umsetzungsperspektive

Wer beide Nachweise braucht, sollte sie als ein Programm mit gemeinsamer Kontroll- und Evidenzbasis aufsetzen, nicht als zwei getrennte Projekte.

• Ein gemeinsames internes Kontrollsystem als Quelle, auf das beide Berichte abbilden.
• Eine konsolidierte Kontroll-Landkarte, die C5-Themenbereiche und SOC-2-Kategorien auf dieselben internen Kontrollen mappt.
• Ein gemeinsamer Beobachtungszeitraum für beide Typ-2-Berichte, soweit die Prüfer das mittragen.
• Eine zentrale Evidenzsammlung, aus der beide Prüfungen ihre Nachweise ziehen.
• Idealerweise eine Wirtschaftsprüfungsgesellschaft, die beide Berichte abdeckt.

Die Prüf-Logik ist kompatibel: Beide Rahmenwerke nutzen die Attestierungssystematik der Wirtschaftsprüfung mit Typ 1 und Typ 2. Eine konsolidierte Evidenzbasis senkt daher Aufwand und Inkonsistenzrisiko erheblich, ohne die Aussagekraft eines Berichts zu schwächen.

C5 entwickelt sich weiter. Neben C5:2020 mit 121 Kriterien in 17 Themenbereichen existiert seit dem Frühjahr 2026 die dritte Generation C5:2026, die strukturell an das europäische Schema EUCS angelehnt ist und Kriterien in Unterkriterien gliedert. C5:2026 erweitert die Risikofelder unter anderem um Container-Management, Lieferketten-/Supply-Chain-Themen, Kryptografie und Confidential Computing und berücksichtigt die NIS2-Richtlinie sowie ISO/IEC 27001:2022. Für die Programmplanung relevant: C5:2026 ist verpflichtend für Typ-1-Prüfungen mit Stichtagen ab dem 1. Juni 2027 und für Typ-2-Prüfungen mit Zeiträumen, die ab dem 1. Juni 2027 beginnen; eine frühere freiwillige Anwendung ist möglich. Bis dahin bleibt C5:2020 maßgeblicher Prüfmaßstab. Verbindliche Kriteriendetails sind dem jeweils aktuellen C5-Katalog des BSI zu entnehmen.

Typische Fehler

1. C5 und SOC 2 als zwei isolierte Projekte führen statt als ein Programm mit gemeinsamer Evidenzbasis.
2. Von "C5-Zertifikat" oder "SOC-2-Zertifizierung" sprechen, obwohl es sich um Attestierungsberichte handelt.
3. Den prinzipienbasierten Charakter von SOC 2 und den festen Katalog von C5 verwechseln und Erwartungen falsch setzen.
4. Typ 1 als gleichwertig zu Typ 2 darstellen, obwohl Kunden meist die Wirksamkeitsaussage von Typ 2 erwarten.
5. Den Versionssprung bei C5 ignorieren und Stichtagspflichten für C5:2026 zu spät einplanen.

Risiken und Trade-offs

Zwei parallele Nachweise erhöhen Kosten und Komplexität. Wer sie nicht konsolidiert, zahlt doppelt und riskiert widersprüchliche Aussagen in den Berichten. Wer dagegen zu stark vereinheitlicht, kann marktspezifische Erwartungen verfehlen: US-Kunden erwarten typischerweise SOC 2, regulierte deutsche Abnehmer und die öffentliche Hand erwarten C5.

Ein weiterer Trade-off betrifft die inhaltliche Steuerung. Der feste C5-Katalog gibt Sicherheit und Vergleichbarkeit, lässt aber wenig Spielraum, Kontrollen am eigenen Betriebsmodell auszurichten. SOC 2 ist flexibler, verlagert aber die Beweislast stärker auf die Organisation, die die Eignung ihrer selbst gewählten Kontrollen plausibel machen muss.

Schließlich ist Marktwahrnehmung ein Risiko: Ein Bericht ohne den vom Zielmarkt erwarteten Rahmen wird trotz hoher inhaltlicher Substanz oft nicht als ausreichend akzeptiert.

Entscheidungspunkte

• Für welche Märkte und Kundensegmente ist welcher Nachweis tatsächlich kaufentscheidend?
• Reicht jeweils Typ 1, oder ist Typ 2 die realistische Mindesterwartung?
• Welche Kontrollthemen lassen sich konsolidiert für C5 und SOC 2 belegen?
• Soll eine gemeinsame Wirtschaftsprüfungsgesellschaft beide Berichte erstellen?
• Wird C5:2020 angepeilt, oder steigt die Organisation direkt auf C5:2026 ein, auch mit Blick auf die Stichtagspflichten ab Juni 2027?

Praktische Empfehlungen

1. Behandeln Sie C5 und SOC 2 als ein Programm mit gemeinsamer Kontroll- und Evidenzbasis, nicht als getrennte Projekte.
2. Steuern Sie die Reihenfolge nach Marktbedarf: Beginnen Sie mit dem Nachweis, den Ihre zahlungskräftigsten Kunden zuerst verlangen.
3. Bilden Sie C5-Themenbereiche und SOC-2-Kategorien einmalig auf dieselben internen Kontrollen ab und pflegen Sie dieses Mapping aktiv.
4. Planen Sie einen gemeinsamen Typ-2-Beobachtungszeitraum, soweit die Prüfer das mittragen.
5. Kommunizieren Sie intern und extern sauber von "Attestierungsbericht", nicht von "Zertifikat".
6. Verankern Sie den C5-Versionssprung in der Roadmap und entnehmen Sie verbindliche Kriteriendetails stets dem aktuellen BSI-Katalog.

Relevante Normreferenzen

• BSI C5 (Cloud Computing Compliance Criteria Catalogue): Werk des BSI, frei nutzbar mit Quellenangabe; Prüfstandard mit WP-Attestierung nach ISAE 3000 (Revised). C5:2020 und C5:2026 unterscheiden.
• SOC 2 / Trust Services Criteria (AICPA): reine Referenz, urheberrechtlich geschützt; kein Wortlaut und keine Kriterienlisten.
• ISO/IEC 27001:2022: Referenz für das zertifizierbare Informationssicherheits-Managementsystem; von C5:2026 referenziert.
• NIST-Cybersecurity-Publikationen: nur konzeptionelle Referenz, keine direkte normative Bindung zu C5 oder SOC 2.