C5-Aufwand und Projektdauer: Womit muss ein Cloudanbieter rechnen?
Der Vertrieb hat einen Großkunden in Aussicht. Der Kunde verlangt C5, Vertragsabschluss möglichst im nächsten Quartal. In der Geschäftsleitung entsteht daraus eine scheinbar einfache Frage: „Wie viele Wochen brauchen wir für das Testat?“ Die ehrliche Antwort passt leider nicht in eine Kalenderzelle.
Ein Cloudanbieter kann die Prüfung beauftragen. Er kann aber nicht rückwirkend Rollen klären, Kontrollen über Monate wirksam betreiben oder fehlende Nachweise herbeizaubern. Deshalb besteht ein C5-Projekt aus mehr als Dokumentation und ein paar Prüfungstagen.
Die kurze Antwort
Der Aufwand wird vor allem durch fünf Dinge bestimmt: den C5-Scope, die Reife des bestehenden Kontrollsystems, die Zahl technischer und organisatorischer Lücken, die Abhängigkeit von Subdienstleistern und die gewünschte Prüfungsart.
Für einen reifen Cloudanbieter mit belastbarem ISMS kann die Vorbereitung einige Monate dauern. Wer Prozesse, technische Kontrollen und Nachweisführung erst aufbauen muss, plant eher in Quartalen als in Wochen. Bei Typ 2 kommt der Prüfzeitraum hinzu: C5:2026 sieht mindestens drei und grundsätzlich höchstens zwölf Monate vor. Feldarbeit, Rückfragen und Berichtserstellung folgen danach beziehungsweise teilweise überlappend.
Das ist keine Verzögerungstaktik, sondern die Natur einer Prüfung, die nicht nur Papier, sondern ein funktionierendes Kontrollsystem beurteilt.
Die sechs Phasen eines realistischen C5-Projekts
Die folgenden Zeitspannen sind praktische Planungswerte, keine Vorgaben des BSI und keine Termingarantie. Phasen können sich überlappen. Bei großer Produktbreite, vielen Ländern oder tiefen Lieferketten können sie deutlich länger dauern.
|
Phase |
Praktischer Richtwert |
Wesentliche Ergebnisse |
|---|---|---|
|
1. Ziel und Scope |
2–4 Wochen |
Dienst, Regionen, Systemgrenzen, Prüfungsart, Projektauftrag |
|
2. Readiness und Lückenanalyse |
4–8 Wochen |
Kriterienmapping, Reifegrad, Lücken, Maßnahmenplan |
|
3. Umsetzung und Stabilisierung |
3–9 Monate |
Kontrollen, Technik, Rollen, Richtlinien und erste belastbare Nachweise |
|
4. Prüfungsbereitschaft |
4–8 Wochen |
Systembeschreibung, Kontrollmatrix, Evidence-Index, interne Tests |
|
5. Typ-2-Zeitraum |
mindestens 3, meist mehrere Monate |
fortlaufende Ausführung und Nachweise über den festgelegten Zeitraum |
|
6. Prüfung und Bericht |
etwa 6–12 Wochen |
Prüfungshandlungen, Rückfragen, Feststellungen, Qualitätssicherung, Bericht |
Bei einem Typ-1-Erstauftrag entfällt der längere Wirksamkeitszeitraum, weil ein Stichtag betrachtet wird. Trotzdem müssen die Kontrollen an diesem Stichtag geeignet gestaltet und implementiert sein. Typ 1 ist keine Generalprobe mit leeren Kulissen. Die Unterschiede erklärt unser Beitrag zu C5 Typ 1 und Typ 2.
Phase 1: Ziel und Scope festnageln
Der schnellste Weg in ein teures Projekt ist ein unscharfer Scope. „Unsere Cloud-Plattform“ kann drei Produktlinien, fünf Regionen, optionale Module und zahlreiche Betriebsvarianten bedeuten. Jede Variante zieht Architektur, Kontrollen, Nachweise und Subdienstleister nach sich.
Klären Sie am Anfang:
- Welcher konkrete Cloud-Dienst soll im Bericht stehen?
- Welche Produktionsumgebungen, Regionen und Varianten gehören dazu?
- Welche Entwicklungsteile und zentralen Unternehmensfunktionen unterstützen ihn?
- Welche Subdienstleister tragen relevante Kontrollen?
- Wer sind die vorgesehenen Nutzer des Prüfberichts?
- Soll der Erstauftrag Typ 1 oder direkt Typ 2 sein?
- Welche Kundentermine sind echte Anforderungen und welche nur Wunschdaten?
Nach C5:2026 ist Typ 1 auf Erstaufträge begrenzt; spätere Aufträge sollen Typ 2 sein. Ein vorheriger Typ-1-Bericht ist für Typ 2 nicht zwingend. Der richtige Weg hängt daher von Marktdruck, Reife und Risikobereitschaft ab – nicht von einer automatischen Pflichtfolge.
Phase 2: Readiness ohne Schönfärberei
In der Readiness-Prüfung wird jedes anwendbare C5-Kriterium mit vorhandenen Kontrollen und Nachweisen abgeglichen. Dabei entstehen drei Kategorien:
- Kontrolle vorhanden und nachweisbar.
- Kontrolle vorhanden, aber unklar, inkonsistent oder ohne belastbaren Nachweis.
- Kontrolle fehlt oder passt nicht zum betrachteten Dienst.
Die zweite Kategorie ist häufig die größte. Prozesse laufen, aber niemand kann belegen, dass Reviews regelmäßig stattfanden. Technische Einstellungen sind korrekt, aber Änderungen daran werden nicht kontrolliert. Verantwortliche kennen ihre Aufgaben, doch bei Urlaub existiert keine Vertretung.
Ein zertifiziertes ISO 27001-ISMS verkürzt diese Arbeit erheblich. Risikomanagement, interne Audits, Richtlinien, Korrekturmaßnahmen und viele Sicherheitsprozesse sind dann bereits angelegt. C5 wird dadurch jedoch nicht automatisch erfüllt, weil Dienstbezug, Systembeschreibung, detaillierte technische Kriterien und prüfbare Kontrollausführung hinzukommen. Die grundsätzliche Abgrenzung finden Sie in C5 versus ISO 27001.
Phase 3: Der eigentliche Aufwand steckt in der Umsetzung
Dokumente lassen sich relativ schnell schreiben. Ein belastbares Kontrollsystem braucht länger. Besonders zeitintensiv sind Maßnahmen, die mehrere Teams, Werkzeuge oder Lieferanten betreffen.
Typische Aufwandstreiber sind:
- zentrale Protokollierung und belastbare Auswertung sicherheitsrelevanter Ereignisse,
- privilegierte Zugriffe, technische Identitäten und regelmäßige Rezertifizierung,
- Schwachstellenmanagement, Penetrationstests und nachvollziehbare Behebung,
- sichere Entwicklung, Codeprüfungen, Abhängigkeiten und Freigaben,
- Notfallplanung, Wiederherstellungstests und dokumentierte Ergebnisse,
- Mandantentrennung und sichere Cloud-Konfiguration,
- Kryptografie, Schlüsselmanagement und technische Inventare,
- Lieferantenkontrollen, Vertragsanpassungen und fehlende Prüfberichte,
- Portabilität, Löschung und geordnete Vertragsbeendigung.
Viele Maßnahmen können parallel laufen. Sie konkurrieren aber um dieselben Mitarbeiter aus Plattformbetrieb, Entwicklung und Informationssicherheit. Ein Projektplan, der jede Aufgabe gleichzeitig startet, ist kein Parallelplan. Er ist eine Warteschlange mit bunten Balken.
Wer im Projekt wirklich gebraucht wird
C5 lässt sich nicht dauerhaft an den Informationssicherheitsbeauftragten delegieren. Die Kontrollen leben in den Fachbereichen.
|
Rolle |
Typischer Beitrag |
|---|---|
|
Geschäftsleitung |
Auftrag, Priorität, Ressourcen und Managementerklärung |
|
C5-Projektleitung |
Scope, Kriterienmapping, Maßnahmen, Termine und Prüferkoordination |
|
Informationssicherheit |
ISMS, Risiken, Richtlinien, Monitoring und interne Prüfung |
|
Cloud- und Plattformbetrieb |
Konfiguration, Logging, Backup, Netzwerk, Zugriffe und Betriebsnachweise |
|
Entwicklung und DevSecOps |
Entwicklungslebenszyklus, Code, Änderungen, Abhängigkeiten und Releases |
|
Personal und Organisation |
Eintritt, Wechsel, Austritt, Schulung und Rollen |
|
Einkauf und Lieferantenmanagement |
Subdienstleister, Sicherheitsanforderungen, Reviews und Exit |
|
Recht und Datenschutz |
Verträge, Datenorte, Behördenanfragen und regulatorische Anforderungen |
|
Service und Incident Management |
Vorfälle, Kundenkommunikation, Probleme und Verfügbarkeit |
|
Interne Revision oder unabhängige Prüfer |
objektive Tests vor der externen Prüfung |
Nicht jede Rolle arbeitet Vollzeit im Projekt. Entscheidend sind feste Besitzer und reservierte Zeit. Wenn technische Teams Nachweise nur nebenbei liefern sollen, kommt die Rechnung spätestens in der Feldprüfung.
Für die Kapazitätsplanung hilft eine einfache Unterscheidung: Die Projektleitung koordiniert Kriterien, Termine und Prüfer; die Kontrollbesitzer führen die eigentliche Kontrolle aus; technische Ansprechpartner erklären Systeme und liefern Populationen. Werden diese drei Aufgaben einer einzigen Person zugeschoben, entsteht ein Flaschenhals. Planen Sie deshalb für intensive Readiness- und Prüfungswochen ausdrücklich Vertretungen und geschützte Arbeitszeit ein.
Phase 4: Aus Arbeit wird prüfbarer Nachweis
Vor dem Prüfzeitraum beziehungsweise Stichtag müssen Kontrolle, Besitzer, Frequenz, System und Nachweis zusammenpassen. Eine Kontrollmatrix verbindet diese Informationen mit den C5-Kriterien.
Zusätzlich benötigt der Anbieter bei einem Bestätigungsauftrag eine Systembeschreibung. Sie erklärt den Dienst, seine Komponenten, Kontrollumgebung, relevante Ereignisse, Kundenkontrollen und Subdienstleister. Das ist keine Marketingbeschreibung. Sie muss so konkret sein, dass ein sachkundiger Leser das Kontrollsystem versteht.
Ein sauberer Evidence-Index spart in der Prüfung enorm Zeit. Er enthält pro Kontrolle:
- eindeutigen Namen und Besitzer,
- Zweck und Ausführungsfrequenz,
- Population, aus der Stichproben gezogen werden,
- Speicherort und Format des Nachweises,
- Zeitraum und Bezug zum Scope,
- Qualitätscheck vor Übergabe.
Führen Sie interne Walkthroughs durch. Lassen Sie einen unbeteiligten Kollegen eine Kontrolle anhand der Beschreibung und Nachweise nachvollziehen. Wenn er dafür fünf Chats, drei Ticketsysteme und den einzigen Mitarbeiter mit historischem Wissen braucht, ist die Kontrolle noch nicht prüfungsfest.
Phase 5: Der Typ-2-Zeitraum lässt sich nicht komprimieren
Der C5:2026-Katalog des BSI sieht für Typ 2 einen Zeitraum von mindestens drei Monaten vor. Unterhalb davon kann der Prüfer keine ausreichenden Nachweise zur Wirksamkeit gewinnen. Der Zeitraum soll grundsätzlich höchstens zwölf Monate umfassen; begründete Ausnahmen sind möglich.
Die Mindestdauer ist nicht automatisch die beste Dauer. Bei monatlichen Kontrollen entstehen in drei Monaten nur wenige Ausführungen, bei quartalsweisen möglicherweise nur eine. Kunden können außerdem einen längeren Zeitraum erwarten. Legen Sie den Zeitraum gemeinsam mit Prüfer und Marktanforderung fest.
Wichtig ist der Startpunkt: Der Zeitraum sollte erst beginnen, wenn die wesentlichen Kontrollen implementiert sind und stabil laufen. Andernfalls sammeln Sie nicht Belege für Wirksamkeit, sondern sauber datierte Abweichungen.
Phase 6: Feldarbeit, Rückfragen und Bericht
Der Ablauf der C5-Prüfung umfasst mehr als Interviews. Prüfer untersuchen Gestaltung und Implementierung sowie bei Typ 2 die Wirksamkeit. Dazu nutzen sie unter anderem Befragungen, Einsichtnahmen, Beobachtungen und Wiederholungen. Stichproben müssen aus vollständigen Populationen stammen.
Planen Sie Kapazität für:
- Kick-off und Walkthroughs,
- Bereitstellung von Populationen und Stichproben,
- technische Nachweise und Live-Demonstrationen,
- Nachfragen und ergänzende Unterlagen,
- Einordnung möglicher Abweichungen,
- Prüfung von Berichtsentwürfen auf sachliche Richtigkeit,
- Qualitätssicherung bei der Prüfgesellschaft.
Die Berichtserstellung ist kein sofortiger Export nach dem letzten Interview. Feststellungen müssen bewertet, Texte abgestimmt und intern qualitätsgesichert werden. Versprechen Sie dem Vertrieb deshalb nicht das Datum des letzten Prüftags als Datum des fertigen Berichts.
Was die Projektdauer nach oben treibt
Ein einzelner SaaS-Dienst in einer Region ist anders als eine Plattformfamilie mit mehreren Betriebsmodellen. Besonders starke Zeitverlängerer sind:
- unklarer oder ständig wachsender Scope,
- fehlende Verantwortliche,
- viele manuelle Kontrollen ohne verlässliche Termine,
- technische Schulden in Identitäten, Logging oder Netzsegmentierung,
- fehlende Daten- und Assetinventare,
- zahlreiche kritische Subdienstleister,
- Verträge ohne Sicherheits- und Prüfanforderungen,
- Kontrollen mit niedriger Frequenz, die noch nie ausgeführt wurden,
- parallele Großprojekte oder Plattformmigrationen,
- späte Prüferbeauftragung.
Auch ein Wechsel auf C5:2026 gehört in die Planung. Der neue Katalog ergänzt und schärft unter anderem Container, Lieferketten, Kryptografie, Mandantentrennung und Souveränität. Alte C5:2020-Mappings sollten nicht einfach umetikettiert werden.
Wie Sie Zeit sparen, ohne Ecken abzuschneiden
Beginnen Sie mit Scope und Readiness, bevor Sie jede Richtlinie überarbeiten. Priorisieren Sie Kontrollen mit langer Vorlaufzeit: Verträge, technische Umbauten, Wiederherstellungstests, Penetrationstests und Kontrollen mit geringer Frequenz.
Automatisieren Sie Nachweise dort, wo Systeme ohnehin zuverlässige Daten liefern. Ein automatisch erzeugter Zugriffsreport ist meist belastbarer als eine vierteljährlich zusammengesuchte Tabelle. Standardisieren Sie Kontrollbeschreibungen und benennen Sie pro Nachweis einen Besitzer.
Beauftragen Sie die Prüfgesellschaft früh genug für Termin, Methode und Erwartungsabgleich. Die Verantwortung für die Umsetzung bleibt bei Ihnen, doch frühe Klarheit verhindert Überraschungen. Und halten Sie den Scope stabil: Jede spät ergänzte Region zieht eine kleine Parade aus Architektur, Datenflüssen, Lieferanten und Nachweisen hinter sich her.