C5 als Kunde nutzen: einen Cloud-Provider bewerten

Problem in der Praxis

In Beschaffungs- und Auditgesprächen wird ein C5-Bericht häufig wie ein bestandenes Zeugnis behandelt: Der Anbieter legt ein Dokument vor, der Haken wird gesetzt, die Prüfung gilt als erledigt. Genau hier entstehen die teuren Fehler.

Typisch ist, dass der vorgelegte Bericht einen anderen Dienst oder eine andere Region abdeckt als die tatsächlich genutzte. Oder es handelt sich um einen Typ-1-Bericht, der nur die Gestaltung der Kontrollen zu einem Stichtag beurteilt, während der Kunde eine Aussage zur Wirksamkeit über den Betrieb braucht. Häufig wird auch übersehen, dass der Bericht Prüfungsausnahmen ("exceptions") enthält oder dass ganze Kriterienbereiche als nicht anwendbar erklärt wurden.

Der gravierendste blinde Fleck sind die komplementären kundenseitigen Kriterien. Eine Attestierung setzt regelmäßig voraus, dass der Kunde bestimmte Kontrollen selbst betreibt, etwa Identitäts- und Berechtigungsverwaltung, Konfiguration, Verschlüsselung im eigenen Verantwortungsbereich oder Protokollauswertung. Werden diese Pflichten nicht erkannt und nicht umgesetzt, trägt der Kunde das Risiko, obwohl formal ein C5-Bericht vorliegt.

CISO-Einordnung

Ein C5-Bericht beantwortet aus Kundensicht fünf Fragen, die ein CISO bewusst trennen sollte:

• Was ist geprüft? Welcher konkrete Dienst, welche Regionen, welche Sub-Dienstleister liegen im definierten System- und Service-Scope?
• Wie ist geprüft? Handelt es sich um Typ 1 (Angemessenheit der Kontrollgestaltung zu einem Stichtag) oder Typ 2 (zusätzlich betriebliche Wirksamkeit über einen Zeitraum)?
• Gegen welchen Maßstab? Deckt der Anbieter nur Basiskriterien für normalen Schutzbedarf ab oder auch Zusatzkriterien für hohen bzw. sehr hohen Schutzbedarf? Das ist die Kernfrage der Korbzuordnung.
• Mit welchem Ergebnis? Ist das Prüfurteil uneingeschränkt, oder enthält der Bericht Ausnahmen und Einschränkungen?
• Was bleibt bei mir? Welche komplementären kundenseitigen Kontrollen muss ich selbst betreiben, damit die attestierten Kontrollen überhaupt greifen?

Die Korbzuordnung verdient besondere Aufmerksamkeit. C5 unterscheidet Basiskriterien als Mindestmaß für normalen Schutzbedarf und Zusatzkriterien als Ausgangspunkt für erhöhte Anforderungen. Ein Anbieter, der nur Basiskriterien abbildet, kann formal korrekt attestiert sein und trotzdem nicht zum hohen Schutzbedarf einer regulierten Anwendung passen. Der CISO muss daher zuerst den eigenen Schutzbedarf bestimmen und dann prüfen, ob der Korb des Anbieters dazu passt.

Ebenso wichtig ist die Verantwortungsabgrenzung zwischen CSP, Kunde und Sub-Dienstleister. C5 prüft das vom Anbieter definierte System inklusive seiner Sub-Dienstleister; in der dritten Generation C5:2026 ist diese Abgrenzung ausdrücklich geschärft. Restrisiko entsteht genau an den Schnittstellen, an denen die Verantwortung vom Anbieter zum Kunden übergeht.

Umsetzungsperspektive

Ein belastbarer Lesevorgang folgt einer festen Reihenfolge statt einer Haken-Logik:

1. Scope-Abgleich. Den im Bericht beschriebenen Dienst, die Regionen und die Sub-Dienstleister mit dem tatsächlich genutzten Setup abgleichen. Nicht der Anbietername zählt, sondern der konkrete Dienst.
2. Berichtstyp prüfen. Für den laufenden Betrieb in der Regel Typ 2 verlangen. Typ 1 ist allenfalls für eine Erstbewertung oder einen neuen Dienst geeignet.
3. Korbzuordnung bewerten. Eigenen Schutzbedarf festlegen und prüfen, ob der Anbieter die passenden Basis- und ggf. Zusatzkriterien abdeckt und welche Kriterien als nicht anwendbar deklariert wurden.
4. Prüfurteil und Ausnahmen lesen. Den Abschnitt mit dem Urteil des Wirtschaftsprüfers und etwaigen Abweichungen auswerten, nicht nur das Deckblatt.
5. Komplementäre Pflichten extrahieren. Die im Bericht genannten kundenseitigen Kontrollen herausarbeiten und in das eigene ISMS sowie in Vertrag und Betriebskonzept überführen.
6. Restrisiko dokumentieren. Die Lücke zwischen attestiertem Umfang und eigenem Bedarf bewerten, einer Entscheidung zuführen und im Risikomanagement nachhalten.

Hinzu kommt die Versionslage. Bis zum Greifen der Umstellungstermine bleibt C5:2020 der maßgebliche Prüfmaßstab; verpflichtend wird C5:2026 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. C5:2026 erweitert den Kriterienumfang und adressiert zusätzliche Risikofelder wie Container-Management, Lieferketten, Kryptografie und Confidential Computing sowie höhere Transparenzanforderungen zu Datenstandorten und Souveränität. Der CISO sollte daher im Bericht immer prüfen, auf welche C5-Version er sich bezieht.

Typische Fehler

1. Der C5-Bericht wird als Siegel behandelt statt als Prüfdokument gelesen.
2. Scope, Region oder Sub-Dienstleister des Berichts weichen vom genutzten Dienst ab und werden nicht abgeglichen.
3. Ein Typ-1-Bericht wird akzeptiert, obwohl eine Wirksamkeitsaussage über den Zeitraum benötigt wird.
4. Die Korbzuordnung wird ignoriert, sodass nur Basiskriterien vorliegen, obwohl hoher Schutzbedarf besteht.
5. Komplementäre kundenseitige Pflichten werden nicht erkannt und nicht umgesetzt.
6. Prüfungsausnahmen im Bericht werden überlesen.

Risiken und Trade-offs

Wer C5 zu streng auslegt, schließt sonst geeignete Anbieter aus, nur weil ein Zusatzkriterium fehlt, das für den eigenen Anwendungsfall nicht relevant ist. Wer C5 zu locker auslegt, verlässt sich auf ein Dokument, das den genutzten Dienst gar nicht vollständig abdeckt.

Ein weiterer Trade-off liegt zwischen Marktbreite und Passgenauigkeit. Große Hyperscaler legen umfangreiche C5-Berichte vor, doch deren breiter Scope bedeutet nicht automatisch, dass der konkret genutzte Dienst im hohen Schutzbedarf abgedeckt ist. Umgekehrt kann ein kleinerer Anbieter mit eng zugeschnittenem Scope besser passen.

Schließlich ersetzt C5 keine eigene Risikoentscheidung. Die Attestierung ist eine fundierte externe Aussage zu einem Zeitpunkt oder Zeitraum, kein Dauerzustand und keine Garantie. Das verbleibende Restrisiko aus komplementären Pflichten, Schnittstellen und Versionsübergängen bleibt beim Kunden.

Entscheidungspunkte

• Welcher Schutzbedarf gilt für die Daten und Prozesse, die in den Cloud-Dienst ausgelagert werden?
• Verlangen wir Typ 1 oder Typ 2, und in welcher Aktualität muss der Bericht vorliegen?
• Welche Korbzuordnung (Basis bzw. Zusatzkriterien) ist Mindestanforderung für diese Auslagerung?
• Welche komplementären kundenseitigen Kontrollen übernehmen wir verbindlich, und wer ist intern dafür verantwortlich?
• Wie bewerten und genehmigen wir das verbleibende Restrisiko, und in welchem Turnus prüfen wir den Bericht erneut?

Praktische Empfehlungen

1. Bestimmen Sie zuerst den eigenen Schutzbedarf, dann lesen Sie den Bericht gegen diesen Maßstab.
2. Gleichen Sie Scope, Region und Sub-Dienstleister mit dem tatsächlich genutzten Dienst ab und fordern Sie bei Abweichung den passenden Bericht an.
3. Verlangen Sie für den laufenden Betrieb in der Regel einen aktuellen Typ-2-Bericht.
4. Extrahieren Sie die komplementären kundenseitigen Kriterien und überführen Sie sie in ISMS, Vertrag und Betrieb mit klarem Owner.
5. Dokumentieren Sie das Restrisiko als bewusste Managemententscheidung und legen Sie einen Re-Assessment-Turnus fest.
6. Achten Sie auf die C5-Version des Berichts und planen Sie den Übergang von C5:2020 zu C5:2026 in der Lieferantensteuerung ein.

Relevante Normreferenzen

• BSI C5 (Cloud Computing Compliance Criteria Catalogue): Referenz für Aufbau, Kriterien-Körbe und Attestierungslogik; verbindliche Details dem jeweils aktuellen C5-Katalog des BSI entnehmen.
• ISAE 3000 (Revised): Referenz für die Prüf- und Attestierungslogik (Typ 1 / Typ 2), auf der C5-Berichte beruhen.
• ISO/IEC 27001 / 27002 / 27017: von C5 referenzierte Kontrollstandards (reine Referenz, kein Wortlaut).
• SOC 2 (AICPA Trust Services Criteria): vergleichbare Attestierungslogik, nur als Querverweis.