Zum Inhalt springen
einfachISO
C5

ISO 27001 vorhanden – wie groß ist die Lücke zu C5 wirklich?

Joachim Reinke
Von Joachim Reinke
Gründer & Geschäftsführer
Cloudanbieter-Team überquert mit zusätzlichen Nachweisen die kurze Brücke vom vorhandenen ISMS zum C5-Kontrollsystem

Das ISO 27001-Zertifikat ist da. Das ISMS läuft, Interne Audits finden statt und die Managementbewertung hat ihren festen Termin. Dann fragt ein großer Kunde nach einem C5-Testat. Im Raum fällt der beruhigende Satz: „Dann ist C5 ja fast erledigt.“

Vielleicht. Vielleicht steht aber auch erst das Fundament.

Wie groß die Lücke wirklich ist, hängt weniger am Zertifikat an der Wand als an drei praktischen Fragen: Deckt Ihr ISMS den konkreten Cloud-Dienst ab? Sind die cloudtypischen Kontrollen technisch und organisatorisch ausreichend konkret? Und können Sie ihre Durchführung über den relevanten Zeitraum belastbar nachweisen?

Die kurze Antwort

Ein funktionierendes ISO 27001-ISMS ist die beste Ausgangslage für C5:2026. Sie bringen Governance, Risikomanagement, Richtliniensteuerung, Rollen, Schulung, Lieferantenmanagement, Incident Management, Business Continuity, Internes Audit und kontinuierliche Verbesserung bereits mit.

C5 ist trotzdem kein kleines Zusatzmodul. Der Kriterienkatalog zieht das Managementsystem auf einen konkreten Cloud-Dienst herunter und verlangt in vielen Bereichen deutlich detailliertere Kontrollen, Transparenzangaben und Betriebsnachweise. Hinzu kommen Themen wie Shared Responsibility, Subdienstleister, Portabilität, Produktsicherheit und der Umgang mit Behördenanfragen.

Die Lücke ist deshalb selten „Wir müssen Informationssicherheit komplett neu erfinden.“ Sie lautet eher: Wir müssen vorhandene ISMS-Strukturen dienstbezogen schärfen, Cloud-Lücken schließen und aus gelebter Arbeit prüfbare Evidenz machen.

Den grundsätzlichen Unterschied zwischen Zertifizierung und Testat erklären wir im Artikel C5 und ISO 27001: Warum Zertifikat und Testat nicht dasselbe sind. Hier geht es um die nächste Frage: Wie weit sind Sie mit Ihrem bestehenden System tatsächlich?

Warum ISO 27001 so viel Vorarbeit leistet

Der C5:2026-Kriterienkatalog des BSI verlangt ausdrücklich ein ISO 27001-konformes ISMS. Dessen Scope soll die Organisationseinheiten, Standorte, Regionen und Verfahren abdecken, die für Entwicklung und Betrieb des Cloud-Dienstes relevant sind. C5 baut also nicht zufällig auf bekannten ISMS-Strukturen auf, sondern ganz bewusst.

Ein gutes bestehendes System liefert typischerweise bereits:

  • eine Informationssicherheitsleitlinie und messbare Sicherheitsziele;
  • definierte Rollen und Verantwortlichkeiten;
  • eine Methode zur Risikobewertung und Risikobehandlung;
  • gelenkte Richtlinien und Prozesse;
  • Asset-, Lieferanten- und Berechtigungsmanagement;
  • Schulungen und Awareness;
  • Prozesse für Vorfälle, Schwachstellen und Notfälle;
  • Interne Audits, Managementbewertung und Verbesserungsmaßnahmen.

Das ist nicht wenig. Ein Unternehmen ohne ISMS muss diese Mechanik zusätzlich zu den cloudbezogenen Kontrollen aufbauen. Ein zertifiziertes Unternehmen sollte sie bereits betreiben und dafür Nachweise besitzen.

Der Haken steckt im Wort „sollte“. Ein Zertifizierungsscope kann sehr breit, sehr schmal oder anders geschnitten sein als der geplante C5-Scope. Eine Richtlinie kann für das Gesamtunternehmen vernünftig sein und trotzdem zu wenig über Container, Schlüsselverwaltung oder Mandantentrennung sagen. Und ein Prozess kann im Audit grundsätzlich funktioniert haben, ohne die von C5 verlangten Details nachzuweisen.

Die Readiness-Landkarte: Was trägt, was kommt dazu?

Die folgende Tabelle ist keine pauschale Prozentrechnung. Sie zeigt, wo ein reifes ISMS normalerweise stark hilft und wo C5 häufig zusätzliche Arbeit auslöst.

Bereich

Was aus ISO 27001 typischerweise trägt

Was C5 zusätzlich konkret macht

Governance und Risiken

ISMS, Leitlinie, Ziele, Rollen, Risikoprozess, Managementbewertung

Verbindung zum konkreten Cloud-Dienst, Shared Responsibility, Cloud-Bedrohungen und dienstbezogene Systemgrenzen

Richtlinien und Personal

Dokumentenlenkung, Schulung, Vertraulichkeit, Rollenwechsel

genauere Vorgaben für Ausnahmen, Qualifikation, Remote-Arbeit und dienstrelevante Verantwortlichkeiten

Assets und physische Sicherheit

Inventare, Klassifizierung, Zutritt, Umweltschutz

vollständige Hardware- und Softwarebestände für den Dienst sowie Einbindung externer Rechenzentren

Technischer Betrieb

Backup, Logging, Malware-Schutz, Schwachstellen- und Patchmanagement

granularere Anforderungen an Kapazität, Wiederherstellung, Monitoring, Mandantentrennung, Container und Confidential Computing

Identitäten, Netze und Kryptografie

Berechtigungsmodell, starke Authentisierung, Netzschutz und Verschlüsselung

detaillierter Lebenszyklus privilegierter Rechte, Kundendatenzugriffe, Schlüsselmanagement und kryptografischer Wandel

Entwicklung und Produktsicherheit

Secure Development, Change Management, Tests und Freigaben

konkrete Verbindung zu CI/CD, Komponenten, Produktfunktionen, sicheren Voreinstellungen und Kundenhinweisen

Lieferanten und Portabilität

Lieferantenbewertung, Verträge und Leistungsüberwachung

Subdienstleistermethodik, Datenflüsse, Kontrollabhängigkeiten, Exit, Datenbereitstellung und sichere Löschung

Vorfälle, Notfälle und Compliance

Incident-Prozess, BCM, Interne Audits und Anforderungsverzeichnis

dienstbezogene Reaktionspläne, belastbare Wiederanlaufparameter, Transparenz und kontrollierter Umgang mit Behördenanfragen

Die größte Überraschung: Meist fehlt nicht überall etwas. Einige Bereiche sind fast übernahmefähig, andere brauchen eine fachliche Vertiefung und wenige Themen müssen neu aufgebaut werden. Genau deshalb ist eine echte Zuordnung hilfreicher als die Aussage „ISO deckt ungefähr soundsoviel Prozent von C5 ab.“ Solche Zahlen wirken präzise und verschweigen, ob der vorhandene Prozess zum Cloud-Dienst passt und tatsächlich gelebt wird.

Lücke 1: Der ISMS-Scope passt nicht automatisch zum C5-Scope

ISO 27001 zertifiziert den festgelegten Anwendungsbereich eines Managementsystems. C5 betrachtet einen oder mehrere konkret beschriebene Cloud-Dienste einschließlich relevanter Systeme, Prozesse, Regionen und Abhängigkeiten. Beide Grenzen können übereinstimmen, müssen es aber nicht.

Ein Beispiel: Ihr ISMS umfasst das deutsche Unternehmen und dessen zentrale IT. Der Cloud-Dienst läuft zusätzlich in mehreren Regionen eines Hyperscalers, wird teilweise von einer ausländischen Entwicklungseinheit betreut und nutzt einen externen Supportdienst. Dann hilft das ISMS organisatorisch, aber die C5-Systembeschreibung muss diese Lieferkette und Verantwortungsgrenzen sauber erfassen.

Prüfen Sie deshalb früh:

  1. Welche Dienstvarianten und Regionen sollen in das Testat?
  2. Welche Teams und Standorte entwickeln oder betreiben sie?
  3. Welche Plattformen, Tools und zentralen Prozesse sind sicherheitsrelevant?
  4. Welche Subdienstleister tragen wesentliche Kontrollen?
  5. Wo enden Anbieterpflichten und beginnen Kundenpflichten?

Unser Beitrag zum C5-Scope behandelt diese Abgrenzung ausführlich. Für die Readiness reicht zunächst die Erkenntnis: Ein unpassender Scope kann ein gutes ISMS in die falsche Richtung arbeiten lassen.

Lücke 2: C5 will Cloud-Details statt allgemeiner Kontrollüberschriften

Anhang A der ISO 27001 enthält eine breite Auswahl von Controls. Die konkrete Ausgestaltung ergibt sich aus Risiken, Anforderungen und dem Unternehmen. C5 übersetzt zahlreiche dieser Themen viel genauer auf Cloud-Dienste.

Beim Betrieb geht es beispielsweise nicht nur darum, dass Protokollierung, Backup und Schwachstellenmanagement existieren. Der Cloudanbieter muss festlegen, welche Daten und Systeme erfasst werden, wie Überwachung, Aufbewahrung, Zugriff und Löschung funktionieren, wie Befunde behandelt werden und welche Nachweise entstehen. C5:2026 behandelt außerdem Container-Management und Confidential Computing ausdrücklich.

Ähnlich sieht es bei Kryptografie, Identitäten und Entwicklung aus. Eine Verschlüsselungsrichtlinie ist eine gute Basis. Für C5 müssen unter anderem Schlüsselerzeugung, Speicherung, Rotation, Archivierung, Kompromittierung und externe Schlüsselmanagementsysteme beherrscht werden. Ein Change-Prozess hilft. Er muss aber mit dem echten Entwicklungs- und Deploymentweg zusammenpassen.

Das ist kein Ruf nach mehr Papier. Oft ist die Technik bereits besser als ihre Beschreibung. Dann besteht die Arbeit darin, vorhandene Architekturentscheidungen, automatisierte Kontrollen und Betriebsabläufe in eine klare Kontrolllogik zu bringen. Fehlt die technische Umsetzung, hilft allerdings auch die schönste Kontrollmatrix nicht.

Lücke 3: Aus ISMS-Nachweisen werden Kontrollnachweise

Im ISO-Audit zeigen Sie, dass das Managementsystem geeignet ist, umgesetzt wird und sich verbessert. Dafür werden natürlich ebenfalls Nachweise geprüft. C5 strukturiert die Nachweisführung jedoch konsequent entlang dienstbezogener Kontrollen.

Für jede relevante Anforderung brauchen Sie eine nachvollziehbare Antwort auf fünf Fragen:

  • Welche Kontrolle erfüllt sie?
  • Wer führt die Kontrolle aus oder überwacht sie?
  • Für welche Systeme, Regionen und Dienstbestandteile gilt sie?
  • Wann oder wie oft wird sie ausgeführt?
  • Welcher Nachweis belegt die Durchführung und das Ergebnis?

Ein jährlicher Berechtigungsreview ist beispielsweise nicht nur eine Prozessbeschreibung. Sie brauchen den definierten Bestand, den Reviewumfang, einen Verantwortlichen, die dokumentierte Durchführung, erkannte Abweichungen und deren Bearbeitung. Bei automatisierten Kontrollen kommen Konfiguration, Überwachung und der Umgang mit Fehlern hinzu.

Diese Nachweislogik wird besonders wichtig, wenn die Wirksamkeit über einen Zeitraum betrachtet wird. Den Unterschied zwischen Stichtag und Zeitraum erläutert unser Beitrag C5 Typ 1 oder Typ 2. Für die Readiness bedeutet das: Beginnen Sie nicht erst kurz vor der Prüfung mit dem Sammeln von Belegen. Kontrollen müssen früh genug stabil laufen und verwertbare Spuren hinterlassen.

Lücke 4: Subdienstleister und Kundenpflichten werden sichtbar

Viele ISO-zertifizierte Cloudanbieter haben ein Lieferantenmanagement. C5 fragt genauer, wie Rechenzentren, Hyperscaler, Supportanbieter und andere relevante Dienstleister in die Erbringung des konkreten Cloud-Dienstes eingreifen.

Sie müssen Datenflüsse, Abhängigkeiten und erwartete Kontrollen verstehen. Verträge und Testate der Dienstleister sind wichtig, aber nicht das Ende der Prüfung. Der Anbieter bleibt dafür verantwortlich, seine Kontrolllandschaft und die Überwachung relevanter Subdienstleister schlüssig zu beschreiben.

Auf der anderen Seite stehen die Kunden. Bestimmte Sicherheitsziele werden nur erreicht, wenn Kunden ihren Anteil erfüllen, etwa Benutzer verwalten oder sichere Konfigurationen wählen. C5 macht diese Schnittstellen über korrespondierende Kundenkriterien sichtbar. Wie diese funktionieren, erklären wir im Artikel C5 endet nicht beim Cloudanbieter.

Die typische Überraschung lautet hier: Shared Responsibility ist technisch allen bekannt, aber vertraglich, dokumentarisch und in den Kundenhinweisen nicht sauber genug beschrieben.

Lücke 5: Transparenz ist selbst ein Arbeitspaket

C5 verlangt nicht nur Kontrollen. Der Bericht soll Kunden auch verständliche Informationen über die Rahmenbedingungen des Cloud-Dienstes liefern. Dazu gehören unter anderem Rechtsraum, Verarbeitungsorte, Verfügbarkeit, Wiederanlaufparameter, vorhandene Testate und der Umgang mit Ermittlungsanfragen staatlicher Stellen.

Diese Informationen liegen in Unternehmen häufig verteilt: etwas im Vertrag, etwas in der Datenschutzerklärung, etwas im Architektur-Wiki und etwas im Kopf eines Kollegen, der gerade im Urlaub ist. Für C5 müssen sie konsistent, aktuell und prüfbar zusammengeführt werden.

Auch Produktsicherheit und Portabilität bringen Transparenzpflichten mit. Kunden brauchen Hinweise zur sicheren Konfiguration, zu bekannten Schwachstellen und zu ihren Verantwortlichkeiten. Für den Vertragsausstieg müssen Datenbereitstellung und Löschung geregelt sein. Ein gutes ISMS hilft bei der Steuerung solcher Anforderungen, erzeugt die konkreten Kundeninformationen aber nicht automatisch.

So führen Sie einen belastbaren C5-Readiness-Check durch

Beginnen Sie nicht mit einem neuen Richtlinienpaket. Nehmen Sie den C5:2026-Katalog, den geplanten Scope und Ihre vorhandenen Kontrollen zusammen. Bewerten Sie jedes anwendbare Kriterium in einer Kontrollmatrix.

Eine brauchbare Bewertung unterscheidet vier Zustände:

  1. Abgedeckt: Kontrolle passt zum Cloud-Dienst, läuft stabil und erzeugt geeignete Nachweise.
  2. Nachschärfen: Grundprozess existiert, C5-Details oder Dienstbezug fehlen jedoch.
  3. Nachweis fehlt: Kontrolle läuft vermutlich, ihre Durchführung ist aber nicht belastbar belegt.
  4. Lücke: Kontrolle oder erforderliche Transparenzinformation fehlt tatsächlich.

Ergänzen Sie pro Lücke Verantwortlichen, Maßnahme, Abhängigkeiten und Zieltermin. Technische Themen sollten beim jeweiligen Engineering- oder Operations-Team landen, nicht pauschal beim ISB. Lieferantenfragen gehören mit Einkauf und Legal geklärt, Kundeninformationen mit Produktmanagement und Vertrieb.

Danach wird priorisiert. Beginnen Sie mit Scope-Entscheidungen, Architekturabhängigkeiten und Kontrollen, die über längere Zeit Nachweise erzeugen müssen. Eine hübsch formatierte Richtlinie lässt sich später vergleichsweise schnell fertigstellen. Einen fehlenden Wiederherstellungstest für sechs Monate rückwirkend durchzuführen, ist schwieriger. Erstaunlicherweise verweigert sich die Zeitmaschine auch in C5-Projekten weiterhin der Zusammenarbeit.

Den gesamten Weg von der Kontrollmatrix bis zur unabhängigen Prüfung beschreibt C5: Wie bekommt man ein C5-Testat?.

Woran Sie eine gute Ausgangslage erkennen

Ihre C5-Lücke ist wahrscheinlich überschaubarer, wenn der Cloud-Dienst vollständig im ISMS-Scope liegt, technische Prozesse wirklich dem dokumentierten Modell folgen und Kontrollen automatisiert oder regelmäßig Nachweise erzeugen. Hilfreich sind außerdem ein reifes Lieferantenmanagement, klare Datenflüsse, ein aktuelles Architekturmodell und eindeutige Produktverantwortung.

Größer wird die Lücke, wenn das Zertifikat nur einen Randbereich abdeckt, zentrale Cloud-Komponenten außerhalb des ISMS liegen, Prozesse überwiegend informell laufen oder technische Nachweise erst auf Zuruf zusammengesucht werden. Auch starkes Wachstum, viele Dienstvarianten und eine unübersichtliche Subdienstleisterkette erhöhen den Aufwand.

Eine seriöse Readiness-Aussage lautet deshalb nicht pauschal „Mit ISO sind Sie zu 80 Prozent fertig.“ Sie lautet: Diese C5-Kriterien sind durch passende Kontrollen und Nachweise abgedeckt, diese müssen geschärft werden und diese fehlen. Alles andere ist eher Verkaufsprosa mit Prozentzeichen.

Interesse geweckt?

Sie haben ISO 27001 bereits im Griff und möchten wissen, was für C5 konkret noch fehlt? Sprechen Sie mit uns. Wir prüfen Ihren geplanten Scope, ordnen bestehende Kontrollen zu und machen aus der vermuteten Lücke einen belastbaren Maßnahmenplan.

Häufig gestellte Fragen

Ersetzt eine ISO 27001-Zertifizierung das C5-Testat?
Nein. Die Zertifizierung bestätigt ein ISMS in seinem festgelegten Anwendungsbereich. Das C5-Testat bezieht sich auf konkret beschriebene Cloud-Dienste, deren Kontrollen, Rahmenbedingungen und Nachweise. Beide Prüfungen überschneiden sich, haben aber einen anderen Gegenstand.
Wie viel C5 ist durch ISO 27001 bereits abgedeckt?
Das lässt sich nicht seriös als pauschaler Prozentsatz angeben. Entscheidend sind Scope, Reife der Kontrollen, Cloud-Architektur und vorhandene Nachweise. Ein dienstnahes, gelebtes ISMS kann sehr viel tragen; ein schmaler oder überwiegend formaler Zertifizierungsscope deutlich weniger.
Welche C5-Themen fehlen bei ISO 27001 besonders häufig?
Häufige Lücken sind die dienstbezogene Systembeschreibung, detaillierte Cloud-Betriebskontrollen, Subdienstleisterabhängigkeiten, korrespondierende Kundenkriterien, Portabilität, Produktsicherheit und konsistente Transparenzangaben zu Regionen, Wiederanlauf und Behördenanfragen.
Muss das ISMS für C5 nach ISO 27001 zertifiziert sein?
C5:2026 verlangt ein ISO 27001-konformes ISMS. Eine gültige Zertifizierung ist eine starke Grundlage und kann als zusätzliches Kriterium relevant sein. Das Basiskriterium kann nach den Erläuterungen des BSI jedoch auch durch geeignete Dokumentation und Prüfung der Konformität erfüllt werden.
Wann sollte der Readiness-Check beginnen?
Vor der Festlegung des Prüfungszeitraums. Scope, technische Lücken und Kontrollen mit wiederkehrenden Nachweisen brauchen Vorlauf. Je früher klar ist, welche Belege über einen Zeitraum entstehen müssen, desto geringer ist das Risiko einer unnötigen Warteschleife vor der Prüfung.
Was ist der erste praktische Schritt von ISO 27001 zu C5?
Legen Sie den geplanten C5-Scope fest und erstellen Sie eine Kontrollmatrix. Ordnen Sie jedem anwendbaren C5-Kriterium vorhandene Kontrollen, Verantwortliche und Nachweise zu. Danach trennen Sie Nachschärfungen, Nachweislücken und echte Umsetzungslücken.