C5-Roadmap für den CISO: Rolle klären, Nachweise bündeln, Pflege sichern

Problem in der Praxis

C5 wird häufig isoliert gestartet, ausgelöst durch eine Kundenanforderung oder eine Ausschreibung. Es entsteht ein eigenes Projekt, getrennt vom bestehenden ISMS und von vorhandenen Attestierungen. Die Folge sind doppelte Kontrolldokumentation, mehrfach erhobene Evidenz und konkurrierende Prüfkalender.

Verschärft wird das durch eine unklare Rolle. Viele Organisationen sind gleichzeitig Cloud-Kunde und, für Teile ihres Angebots, selbst Cloud-Diensteanbieter. Wird das nicht getrennt, vermischen sich zwei völlig unterschiedliche Aufgaben: das Lesen und Bewerten fremder C5-Berichte einerseits und das Erbringen einer eigenen Attestierung andererseits.

Schließlich wird C5 oft als Einmalereignis behandelt. Ist der erste Bericht erteilt, lassen Kontrollbetrieb und Evidenz nach, der Versionsübergang wird nicht eingeplant, und der nächste Beobachtungszeitraum beginnt unvorbereitet. Eine Attestierung bezieht sich aber stets auf einen Stichtag oder Zeitraum und ist kein Dauerzustand.

CISO-Einordnung

C5 ist ein Kriterienkatalog des BSI für die Sicherheit von Cloud-Diensten. Der Nachweis erfolgt nicht über ein Zertifikat, sondern über eine Attestierung durch einen Wirtschaftsprüfer (WP) nach ISAE 3000. Damit teilt C5 die Prüflogik mit SOC 2 und unterscheidet sich grundlegend von ISO/IEC 27001, das ein zertifizierbares Managementsystem über eine akkreditierte Zertifizierungsstelle ist.

Für die Roadmap sollte der CISO drei Steuerungsebenen trennen:

• Rolle. Als Kunde ist C5 ein Werkzeug der Auslagerungssteuerung: fremde Berichte gegen den eigenen Schutzbedarf lesen, Scope und Berichtstyp prüfen, komplementäre kundenseitige Pflichten extrahieren. Als Anbieter ist C5 ein Aufbauprojekt mit Dauerbetrieb: Scope schneiden, Kontrollen im internen Kontrollsystem (IKS) betreiben, durchgängige Evidenz erzeugen, WP beauftragen.
• Nachweisbündel. C5, ISO/IEC 27001 und SOC 2 adressieren einen weitgehend gemeinsamen Kontrollkern in unterschiedlichen Vehikeln. C5 referenziert die ISO-Controls; für C5:2020 in der Ausgabe ISO/IEC 27002:2013, während sich C5:2026 auf ISO/IEC 27001:2022 bezieht. Diese Nähe erlaubt es, ein ISMS als gemeinsamen Unterbau zu führen und Evidenz mehrfach zu verwerten, statt drei getrennte Welten zu pflegen.
• Pflege. Attestierung und Zertifizierung sind wiederkehrende Aussagen. Sie verlangen laufenden Kontrollbetrieb, wiederkehrende Prüfungen und einen geplanten Versionsübergang.

Ein weiterer Steuerungspunkt ist die Verantwortungsabgrenzung. C5 prüft das vom Anbieter definierte System inklusive Sub-Dienstleister; in der Generation C5:2026 ist die Abgrenzung zwischen Anbieter, Kunde und Sub-Dienstleister ausdrücklich geschärft. Restrisiko entsteht an den Schnittstellen, an denen Verantwortung übergeht.

Umsetzungsperspektive

Eine C5-Roadmap lässt sich high-level in drei Etappen führen.

1. Rolle klären. Zuerst feststellen, ob die Organisation Cloud-Dienste konsumiert, selbst anbietet oder beides. Daraus folgen zwei unterschiedliche Arbeitspakete, die nicht vermischt werden sollten. Auf der Kundenseite gehören die Bewertung fremder Berichte und die Lieferantensteuerung in das Verfahren; auf der Anbieterseite die eigene Attestierung mit Scope, Korbzuordnung und Berichtstyp.
2. Nachweise bündeln. Den vorhandenen Nachweisbestand inventarisieren: Welche Geltungsbereiche, welche Kontrollen, welche Prüfkalender existieren für ISO/IEC 27001 und gegebenenfalls SOC 2? Anschließend das ISMS als gemeinsamen Kern festlegen, Kontrollen einmal beschreiben und über ein Mapping mehreren Rahmenwerken zuordnen. Wo C5 und SOC 2 dieselbe ISAE-3000-Logik nutzen, kann eine kombinierte WP-Prüfung Doppelaufwand vermeiden. Eine vollständige Kriterienliste ist dafür nicht erforderlich und sollte nicht reproduziert werden; es genügt die Zuordnung auf Kontroll- und Themenebene.
3. Pflege verankern. Kontrollbetrieb und Evidenz als Nebenprodukt laufender Prozesse anlegen, einen Beobachtungszeitraum dauerhaft offen halten und Berichtskadenz, interne Prüfungen und Managementbewertung in einen festen Turnus bringen. Auf der Kundenseite gehört ein Re-Assessment-Turnus für fremde Berichte dazu.

Der Versionsübergang ist Teil der Pflege. 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, wobei eine frühere freiwillige Anwendung möglich ist. 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; strukturell ist die Generation an das europäische Schema EUCS angelehnt. Die genauen Kriterienzahlen der Generation C5:2026 stammen bislang überwiegend aus Sekundärquellen und sind vor verbindlicher Verwendung am aktuellen BSI-Katalog zu verifizieren.

Typische Fehler

1. C5 wird als isoliertes Projekt gestartet, getrennt vom bestehenden ISMS und von vorhandenen Attestierungen.
2. Die Rolle (Kunde, Anbieter oder beides) wird nicht geklärt, sodass Bewertungs- und Nachweisaufgaben vermischt werden.
3. Kontrollen und Evidenz werden je Rahmenwerk doppelt gepflegt, statt einen gemeinsamen Kern zu nutzen.
4. Die Nähe von C5 und SOC 2 in der ISAE-3000-Logik wird nicht genutzt, kombinierte Prüfungen werden nicht erwogen.
5. C5 wird als Einmalereignis behandelt; Kontrollbetrieb, Evidenz und der nächste Beobachtungszeitraum verfallen nach dem ersten Bericht.
6. Der Übergang von C5:2020 zu C5:2026 wird nicht eingeplant.

Risiken und Trade-offs

Ein gebündelter Ansatz senkt Aufwand und Reibung, erhöht aber die Abhängigkeit von einem konsistenten ISMS-Kern: Ist dieser schwach, schlagen Mängel auf mehrere Nachweise zugleich durch. Wer hingegen jedes Rahmenwerk getrennt führt, erkauft sich Unabhängigkeit mit dauerhaftem Doppelaufwand und konkurrierenden Prüfkalendern.

Bei der Rolle besteht der Trade-off zwischen Fokus und Vollständigkeit. Wer sich nur auf die Anbieterperspektive konzentriert, übersieht leicht die kundenseitigen Pflichten aus konsumierten Diensten; wer nur als Kunde denkt, unterschätzt den Aufwand einer eigenen Attestierung.

Schließlich bleibt jeder externe Nachweis eine Aussage zu einem Zeitpunkt oder Zeitraum, keine Garantie. Restrisiko aus komplementären Pflichten, Schnittstellen zu Sub-Dienstleistern und Versionsübergängen bleibt eine bewusste Managemententscheidung des CISOs.

Entscheidungspunkte

• In welcher Rolle stehen wir zu C5: als Kunde, als Anbieter oder in beiden Rollen, und mit welcher Priorität?
• Welche Nachweise (ISO/IEC 27001, SOC 2, C5) sind vorhanden oder gefordert, und wo überschneiden sich Geltungsbereiche und Kontrollen?
• Führen wir ein gemeinsames ISMS als Kern mit Mapping, oder rechtfertigt ein Sonderfall getrennte Strukturen?
• Lohnt eine kombinierte WP-Prüfung von C5 und SOC 2, um Doppelaufwand zu vermeiden?
• Welcher Pflegeturnus (Kontrollbetrieb, Evidenz, interne Prüfung, Managementbewertung, Re-Assessment fremder Berichte) ist angemessen?
• Wann und wie vollziehen wir den Übergang von C5:2020 zu C5:2026?

Praktische Empfehlungen

1. Klären Sie zuerst die Rolle und trennen Sie die Arbeitspakete Kundenbewertung und eigene Attestierung sauber.
2. Inventarisieren Sie vorhandene Nachweise und bestimmen Sie Überschneidungen, bevor Sie ein neues C5-Projekt aufsetzen.
3. Führen Sie ein ISMS als gemeinsamen Kern und ordnen Sie Kontrollen über ein Mapping mehreren Rahmenwerken zu, ohne Kriterienlisten zu reproduzieren.
4. Prüfen Sie eine kombinierte WP-Prüfung von C5 und SOC 2 entlang der gemeinsamen ISAE-3000-Logik.
5. Machen Sie Evidenz zum Nebenprodukt laufender Prozesse und halten Sie einen Beobachtungszeitraum dauerhaft offen.
6. Etablieren Sie einen festen Pflege- und Re-Assessment-Turnus und planen Sie den Übergang von C5:2020 zu C5:2026 früh ein; verbindliche Zahlen und Termine am aktuellen BSI-Katalog verifizieren.

Relevante Normreferenzen

• BSI C5 (Cloud Computing Compliance Criteria Catalogue): Kriterienkatalog des BSI für die Sicherheit von Cloud-Diensten; Nachweis über WP-Attestierung. BSI-Werk, frei nutzbar mit Quellenangabe. Für verbindliche Kriterien, Themenbereiche, Versionsstände und Termine den aktuellen C5-Katalog des BSI heranziehen.
• ISAE 3000 (Revised): internationaler Prüfstandard, der die methodische Grundlage der C5- und SOC-2-Attestierung bildet (Referenz).
• ISO/IEC 27001 / 27002: zertifizierbares ISMS bzw. von C5 referenzierte Kontrollstandards (reine Referenz, kein Wortlaut); für C5:2020 in der Ausgabe 27002:2013, C5:2026 bezieht sich auf ISO/IEC 27001:2022.
• SOC 2 (AICPA Trust Services Criteria): vergleichbare Attestierungslogik nach ISAE 3000, nur als Querverweis.