BSI C5 verstehen: Cloud-Sicherheit als Attestierung

Problem in der Praxis

Viele Organisationen behandeln C5 wie ein ISO-Zertifikat: Man erwartet ein einseitiges Logo-Dokument mit Gültigkeitsdatum, hakt es im Lieferantenfragebogen ab und legt es zur Seite. Das verfehlt den Kern des Instruments.

Der eigentliche Wert von C5 steckt im Attestierungsbericht selbst. Dort beschreibt der Anbieter sein System und seine Kontrollen, der Prüfer dokumentiert sein Vorgehen, sein Urteil und gegebenenfalls festgestellte Ausnahmen. Wer nur prüft, ob ein Anbieter "C5 hat", übersieht die maßgeblichen Fragen: Welcher Dienst und welcher Zeitraum waren überhaupt im Prüfumfang? War es eine Typ-1- oder eine Typ-2-Prüfung? Welche Verantwortung bleibt beim Kunden? Welche Abweichungen hat der Prüfer berichtet?

Spiegelbildlich unterschätzen Anbieter, die C5 erbringen wollen, den Aufwand. Eine Attestierung ist kein Marketingdokument, sondern setzt ein funktionierendes internes Kontrollsystem voraus, das ein unabhängiger Prüfer über einen Zeitraum hinweg belegen kann.

CISO-Einordnung

Für den CISO ist C5 zunächst eine Frage der Logik des Nachweises, nicht der einzelnen Kriterien. Drei Einordnungen sind tragend.

Erstens: Attestierung statt Zertifizierung. Eine ISO/IEC-27001-Zertifizierung bescheinigt über eine akkreditierte Zertifizierungsstelle ein funktionierendes Managementsystem. C5 funktioniert anders. Ein Wirtschaftsprüfer beurteilt nach ISAE 3000 die Kontrollen eines konkreten Dienstes und legt ein Prüfurteil vor. Das ist dieselbe Prüf-Logik wie bei SOC 2 (Referenz). Das Ergebnis ist ein Bericht, kein Zertifikat.

Zweitens: Typ 1 gegen Typ 2. Eine Typ-1-Attestierung beurteilt die Angemessenheit der Kontrollgestaltung zu einem Stichtag. Eine Typ-2-Attestierung beurteilt zusätzlich die betriebliche Wirksamkeit der Kontrollen über einen Zeitraum. Für eine belastbare Lieferantenbewertung hat Typ 2 deutlich höhere Aussagekraft, weil er nicht nur das Design, sondern den gelebten Betrieb belegt. Kunden fordern in der Praxis überwiegend Typ 2.

Drittens: geteilte Verantwortung. C5 prüft den vom Anbieter definierten Dienst samt eingebundener Sub-Dienstleister. Was der Anbieter abdeckt und was in der Verantwortung des Kunden bleibt, ergibt sich aus der Verantwortungsabgrenzung. Der CISO muss diese Grenze kennen, denn die Attestierung des Anbieters ersetzt nicht die eigene Absicherung der Cloud-Nutzung.

Inhaltlich ist C5 ein strukturierter Kriterienkatalog, der sich an etablierte Standards anlehnt und auf sie abbildbar ist. Konkrete Pflichten lassen sich auf den jeweils aktuellen C5-Katalog des BSI zurückführen; eine vollständige Kriterienliste gehört nicht in die Managementbetrachtung.

Umsetzungsperspektive

Die Sicht hängt von der Rolle ab.

Als Cloud-Kunde behandelt der CISO C5 als Baustein der Auslagerungssteuerung. Sinnvoll ist, vor der Anbieterauswahl festzulegen, welcher Berichtstyp erwartet wird, welcher Dienst im Prüfumfang liegen muss und welche eigenen Schutzbedarfe abzudecken sind. Der Bericht wird gelesen, nicht abgelegt: Prüfumfang, Zeitraum, Prüfurteil, Ausnahmen und die kundenseitig erwarteten Kontrollen sind die relevanten Stellen.

Als Cloud-Anbieter erbringt der CISO C5 als Projekt mit klarer Abfolge: Scoping des Dienstes und der Sub-Dienstleister samt Berichtstyp, ein Readiness- beziehungsweise Gap-Assessment, die Gestaltung und Umsetzung der Kontrollen im internen Kontrollsystem, bei Typ 2 ein Beobachtungszeitraum mit Evidenzsammlung und schließlich die Prüfung durch den Wirtschaftsprüfer. Nur Wirtschaftsprüfer beziehungsweise Prüfungsgesellschaften dürfen die Attestierung erteilen.

Beim Versionsstand ist Sorgfalt gefragt. Mit der dritten Generation C5:2026 hat das BSI den Katalog grundlegend überarbeitet, an die europäische Struktur EUCS angelehnt und um Risikofelder wie Container-Management, Lieferketten-Sicherheit, Kryptografie und Confidential Computing erweitert; auch die NIS2-Richtlinie wird berücksichtigt und die Transparenz zu Datenstandorten geschärft. Verpflichtend wird C5:2026 für Typ-1-Prüfungen mit Stichtagen ab dem 1. Juni 2027 sowie für Typ-2-Prüfungen mit Prüfungszeiträumen, die ab dem 1. Juni 2027 beginnen; eine frühere freiwillige Anwendung ist möglich. Bis dahin bleibt C5:2020 der maßgebliche Prüfmaßstab. In jeder internen Kommunikation gehört dazu, auf welche Version Bezug genommen wird.

Typische Fehler

1. C5 wird als Zertifikat verstanden und nur das Vorhandensein, nicht der Bericht geprüft.
2. Typ 1 und Typ 2 werden gleichgesetzt, obwohl nur Typ 2 die Wirksamkeit über einen Zeitraum belegt.
3. Der Prüfumfang wird nicht geprüft: Der attestierte Dienst deckt nicht den tatsächlich genutzten Dienst ab.
4. Die geteilte Verantwortung wird ignoriert; kundenseitige Kontrollen bleiben unbearbeitet.
5. Versionen werden vermischt und C5:2020 sowie C5:2026 ohne klaren Bezug behandelt.
6. Anbieter unterschätzen, dass eine Attestierung ein gelebtes internes Kontrollsystem voraussetzt.

Risiken und Trade-offs

Ein C5-Bericht schafft Vertrauen, aber er ist stichtags- oder zeitraumbezogen und auf einen definierten Dienst begrenzt. Er ist eine Momentaufnahme der Kontrollwirksamkeit, keine Dauergarantie. Wer ihn als statischen Freibrief behandelt, trägt das Risiko, Veränderungen beim Anbieter zu übersehen.

Für Anbieter besteht der Trade-off zwischen Aussagekraft und Aufwand. Typ 2 ist marktseitig erwartet, bindet aber über den Beobachtungszeitraum erhebliche Ressourcen. Eine zu enge Scope-Definition senkt den Aufwand, mindert aber den Nutzen für Kunden und kann zu Nachfragen führen.

Hinzu kommt der Abgrenzungsaufwand gegenüber benachbarten Nachweisen. C5, ISO/IEC 27001 und SOC 2 (Referenzen) überschneiden sich inhaltlich, folgen aber unterschiedlicher Logik. Mehrfachnachweise können sinnvoll sein, erzeugen aber Kosten; ihr paralleler Betrieb will gesteuert sein.

Entscheidungspunkte

• Treten wir als Cloud-Kunde, als Cloud-Anbieter oder in beiden Rollen auf, und welche Sicht auf C5 folgt daraus?
• Fordern wir von Anbietern Typ 1 oder Typ 2, und warum?
• Welcher Dienst und welcher Zeitraum müssen zwingend im Prüfumfang liegen?
• Wer liest und bewertet bei uns die Attestierungsberichte, und nach welchen Kriterien?
• Erbringen wir selbst eine Attestierung, und wenn ja, gegen welche C5-Version und mit welchem Zeitplan im Hinblick auf den 1. Juni 2027?
• Wie verhält sich C5 zu vorhandenen oder geplanten Nachweisen wie ISO/IEC 27001 oder SOC 2?

Praktische Empfehlungen

1. Behandeln Sie C5 als Attestierung, nicht als Zertifikat, und lesen Sie den Bericht statt nur seine Existenz zu prüfen.
2. Fordern Sie als Kunde standardmäßig Typ 2 und begründen Sie Ausnahmen bewusst.
3. Prüfen Sie immer den Prüfumfang gegen den tatsächlich genutzten Dienst.
4. Arbeiten Sie die kundenseitig erwarteten Kontrollen aus der geteilten Verantwortung aktiv ab.
5. Legen Sie in jeder Aussage fest, ob Sie C5:2020 oder C5:2026 meinen, und planen Sie den Übergang zum 1. Juni 2027 ein.
6. Verweisen Sie bei verbindlichen Detailfragen stets auf den jeweils aktuellen C5-Katalog des BSI.

Relevante Normreferenzen

• BSI C5 (Cloud Computing Compliance Criteria Catalogue): Kriterienkatalog des BSI für die Sicherheit von Cloud-Diensten; maßgeblich ist der jeweils aktuelle Katalog (derzeit C5:2020 sowie die dritte Generation C5:2026).
• ISAE 3000 (Revised): internationaler Prüfstandard für Attestierungen, Grundlage des C5-Prüfurteils (Typ 1 und Typ 2).
• ISO/IEC 27001 / 27002: referenzierte Normen, auf die C5 abbildbar ist; eigene Zertifizierungslogik (Referenz).
• SOC 2 (AICPA): vergleichbare Attestierungslogik nach ISAE 3000 mit prinzipienbasierten Kriterien (Referenz).