Was hat sich im neuen C5 gegenüber C5:2020 geändert?

Im Projektordner liegt eine C5:2020-Kontrollmatrix. Sie wurde über Jahre gepflegt, hat Farbcodes, Besitzer und sogar eine Spalte mit dem beruhigenden Namen „erledigt“. Dann wird C5:2026 geöffnet. Die 17 Themenbereiche sind noch da – nur innerhalb der Schubladen wurde ziemlich gründlich umgebaut.

Wer jetzt lediglich die Jahreszahl austauscht, übersieht neue technische Anforderungen, feinere Datenbezüge und eine andere Struktur der Kriterien. C5:2026 ist keine vollständige Neuerfindung. Es ist aber auch kein kosmetisches Update.

Die kurze Antwort

C5:2026 baut auf C5:2020 auf und übernimmt bewährte Inhalte. Gleichzeitig wächst der Katalog von 121 auf 168 prüfbare Kriterien, zerlegt Anforderungen in klar abgegrenzte Subkriterien und ergänzt Themen wie Container, Lieferketten, Post-Quanten-Kryptografie und Confidential Computing.

Mandantentrennung, technische Souveränität und betroffene Datenarten werden genauer beschrieben. Zusatzkriterien sind nun ausdrücklich als Verschärfung oder Ergänzung klassifiziert. Außerdem wurden aktuelle Grundlagen wie ISO/IEC 27001:2022, CSA Cloud Controls Matrix Version 4, NIS2 und die Vorarbeiten zum europäischen EUCS berücksichtigt.

Für Cloudanbieter bedeutet das: vorhandene Kontrollen mappen, Änderungen bewerten, Lücken umsetzen und die Umstellung so terminieren, dass Prüfzeitraum und verwendete Katalogversion zusammenpassen.

C5:2020 und C5:2026 im direkten Vergleich

Die folgende Tabelle zeigt die wichtigsten Unterschiede auf Arbeitsebene. Die vollständige normative Grundlage ist der C5:2026-Katalog des BSI.

Die Zahl 168 allein sollte niemanden zu einer einfachen Aufwandshochrechnung verleiten. Manche Subkriterien machen bisher zusammengefasste Anforderungen nur prüfbarer. Andere bringen tatsächlich neue Kontrollaktivitäten. Entscheidend ist deshalb ein inhaltliches Delta-Mapping, kein Zeilenvergleich mit Taschenrechner.

Das vertraute Grundgerüst bleibt

Die 17 Themenbereiche bleiben erhalten. Dazu gehören Organisation der Informationssicherheit, Richtlinien, Personal, Asset Management, physische Sicherheit, Betrieb, Identitäten, Kryptografie, Kommunikation, Portabilität, Entwicklung, Lieferanten, Vorfälle, Kontinuität, Compliance, Kundenanfragen und staatliche Ermittlungsanfragen.

Das ist eine gute Nachricht für Anbieter, deren C5:2020-Kontrollsystem sauber aufgebaut ist. Rollen, Prozesse und Nachweise lassen sich weiterverwenden. Ein reifes ISO 27001-ISMS bleibt ebenfalls eine starke Grundlage, zumal C5:2026 die Ausgabe ISO/IEC 27001:2022 berücksichtigt. Warum die Systeme trotzdem nicht deckungsgleich sind, erklärt unser Artikel zu C5 und ISO 27001.

Die Umstellung beginnt daher nicht mit einem leeren Blatt. Sie beginnt mit der Frage: „Welche neuen oder geschärften Subkriterien deckt unsere bisherige Kontrolle tatsächlich ab?“

Subkriterien verändern die Kontrollmatrix

C5:2026 strukturiert Kriterien in inhaltlich klar abgegrenzte Subkriterien. Das verbessert die Zuordnung zu Kontrollen und soll die Prüfung eindeutiger machen. Für das Projektteam bedeutet es allerdings, dass eine alte Eins-zu-eins-Logik oft nicht mehr funktioniert.

Eine bisherige Sammelkontrolle kann mehrere Subkriterien abdecken. Umgekehrt kann ein neues Subkriterium eine eigene technische Kontrolle, einen zusätzlichen Nachweis oder eine präzisere Beschreibung verlangen. Wenn nur eines der zugehörigen Subkriterien nicht erfüllt ist, gilt nach den Prüfungsvorgaben das Kriterium nicht vollständig als erfüllt.

Gehen Sie daher je Subkriterium durch:

• Ist es auf unseren Dienst anwendbar?
• Welche Risiken adressiert es?
• Welche vorhandene Kontrolle deckt den Inhalt ab?
• Muss deren Scope, Frequenz oder Ausführung erweitert werden?
• Welcher Nachweis zeigt Gestaltung und Wirksamkeit?
• Wer besitzt Kontrolle und Abweichung?

Ein altes Mapping, das nur dieselbe Kontrolle an zwanzig neue Zeilen kopiert, sieht schnell fertig aus. Es erklärt aber noch nicht, ob alle Inhalte abgedeckt sind.

Zusatzkriterien sind jetzt sauberer sortiert

C5 unterscheidet weiterhin Basis- und Zusatzkriterien. Neu ist die ausdrückliche Klassifizierung der zusätzlichen Anforderungen:

• Additional Sharpening verschärft ein vorhandenes Basiskriterium mit strengeren Anforderungen.
• Additional Complementing ergänzt neue Anforderungen, die über das Basiskriterium hinausgehen.

Damit wird klarer, ob ein höheres Niveau dieselbe Kontrollidee strenger fasst oder eine zusätzliche Fähigkeit verlangt. Für Angebote, Verträge und Prüfaufträge ist das nützlich: Wer Zusatzkriterien zusagt, sollte nicht nur pauschal „erhöhte Sicherheit“ versprechen, sondern konkret festlegen, welche Anforderungen in den Scope gehören.

Container und cloudnative Technik rücken nach vorn

C5:2020 kannte moderne Cloud-Architekturen, doch C5:2026 bildet deren heutige Praxis deutlich detaillierter ab. Container und Images tauchen in Anforderungen an Inventar, Schwachstellen, Konfiguration, Protokollierung und privilegierte Aktivitäten auf.

Für Plattformteams entstehen konkrete Fragen:

• Sind Container-Images eindeutig inventarisiert und freigegeben?
• Werden Schwachstellen in Images vor und nach der Bereitstellung erkannt?
• Sind Registries, Orchestrierung und administrative Schnittstellen geschützt?
• Werden privilegierte Aktivitäten in Containerumgebungen protokolliert?
• Gibt es Regeln für verwaiste Ressourcen und nicht produktive Komponenten?
• Werden Basis-Images und Abhängigkeiten kontrolliert aktualisiert?

Ein allgemeiner Satz in der Hardening-Richtlinie reicht dafür selten. Die Umsetzung sitzt in Pipelines, Registries, Policies und Laufzeitüberwachung – und genau dort entstehen die Nachweise.

Lieferkette und Subdienstleister werden ernster genommen

Cloud-Dienste hängen von IaaS, PaaS, Rechenzentren, Entwicklungswerkzeugen, Identitätsdiensten und Bibliotheken ab. C5:2026 stärkt Supply-Chain-Management und die Betrachtung von Subdienstorganisationen.

In der Systembeschreibung sollen relevante Subdienstleister mit Leistung, Verarbeitungs- und Speicherland, Komplexität, Einzigartigkeit und resultierender Abhängigkeit dargestellt werden. Hinzu kommen erwartete Kontrollen beim Subdienstleister und eigene Kontrollen zur Überwachung ihrer Wirksamkeit.

Das verändert auch den C5-Scope: Nicht weil automatisch jeder Lieferant geprüft wird, sondern weil externe Kontrollbeiträge und Systemgrenzen nachvollziehbar sein müssen. Prüfen Sie bestehende Lieferantenakten daher auf Dienstbezug, nicht nur auf vorhandene Zertifikate.

Kryptografie bekommt eine Zukunftsperspektive

C5:2026 verlangt nicht, über Nacht sämtliche Verschlüsselung auf Post-Quanten-Verfahren umzustellen. Der Katalog ergänzt aber Anforderungen an Kryptoagilität und eine Strategie für Post-Quanten-Kryptografie.

Kryptoagilität bedeutet, verwendete Verfahren oder Implementierungen wechseln zu können, wenn Schlüsselgrößen, Algorithmen oder Bedrohungen sich ändern. Dafür braucht der Anbieter zuerst Transparenz: Wo werden welche Verfahren, Schlüssel, Zertifikate und Bibliotheken eingesetzt? Welche Daten müssen langfristig geschützt werden? Welche Komponenten lassen sich schwer migrieren?

Ein praktischer Start besteht aus Kryptoinventar, Risikobewertung, Verantwortlichkeiten, Auslösern für Änderungen und einem Migrationsplan. Damit wird aus „Quantum machen wir später“ eine steuerbare Aufgabe.

Multi-Tenancy und Souveränität werden konkreter

Mandantentrennung ist der Kern vieler Cloud-Dienste. C5:2026 betrachtet die technische Isolation detaillierter. Anbieter müssen ihre Architektur, Zugriffspfade, Ressourcen und Kontrollen so beschreiben und nachweisen, dass die Trennung nicht nur logisch behauptet wird.

Auch Souveränität erhält mehr technisches Gewicht. Dabei geht es nicht um ein Werbeetikett, sondern um belastbare Informationen und Fähigkeiten: Abhängigkeiten, Steuerungsmöglichkeiten, Datenorte, Zugriffsmöglichkeiten und technische Optionen müssen Kunden eine fundierte Entscheidung erlauben.

Die allgemeinen Rahmenbedingungen des Cloud-Dienstes bleiben deshalb wichtig. Ein Testat sagt nicht pauschal, dass jeder Dienst für jeden Einsatz souverän genug ist. Kunden müssen den Bericht und ihre Anforderungen zusammenbringen. Die korrespondierenden Kundenkontrollen bleiben Teil dieser geteilten Verantwortung.

Datenarten werden genauer zugeordnet

Aus Rückmeldungen zu C5:2020 hat das BSI die Frage geschärft, für welche Datenarten einzelne Kriterien gelten. C5:2026 unterscheidet unter anderem Daten von Cloudkunden, Kontodaten, Konfigurationsdaten und abgeleitete Daten genauer.

Das wirkt unscheinbar, hat aber praktische Folgen. Ein Anbieter kann nicht mehr jede Kontrolle mit dem pauschalen Verweis auf „Daten“ beschreiben. Er muss wissen, welche Daten im Dienst entstehen, wo sie fließen, wer sie kontrolliert und welche Schutz- oder Löschanforderung greift.

Aktualisieren Sie deshalb Dateninventar, Datenflussbilder, Löschkonzept und Kontrollbeschreibungen gemeinsam. Sonst verwendet jedes Dokument denselben Begriff und meint etwas anderes.

Neue Bezugsrahmen, neue Crosswalks

C5:2026 berücksichtigt neben den Arbeiten am EUCS unter anderem ISO/IEC 27001:2022, die CSA Cloud Controls Matrix Version 4 und NIS2. Das erleichtert langfristig eine konsistente europäische und internationale Einordnung.

Für bestehende Projekte heißt es dennoch: alte Mappings prüfen. Eine Referenz auf einen früheren Normabschnitt beweist nicht automatisch inhaltliche Deckung. Übernehmen Sie Crosswalks nur, wenn Kontrollziel, Datenbezug, Scope und Nachweis weiterhin passen.

Das gilt besonders für Unternehmen, die C5 neben mehreren Standards betreiben. Eine gemeinsame Kontrollbibliothek ist sinnvoll. Sie darf aber nicht zur Übersetzungsmaschine werden, die unterschiedliche Anforderungen glattbügelt.

Die Umstellungsfristen

C5:2026 ist für Typ-1-Stichtage am oder nach dem 1. Juni 2027 und für Typ-2-Zeiträume anzuwenden, die am oder nach diesem Datum beginnen. Eine frühere Anwendung ist erlaubt.

Beginnt ein Typ-2-Zeitraum vor dem 1. Juni 2027 und endet danach, soll der Auftrag vollständig C5:2020 verwenden. Eine Mischung aus beiden Katalogversionen in derselben Prüfung soll vermieden werden.

Zusätzlich verlangt C5:2026 Transparenz schon vor dem vollständigen Wechsel: Endet ein Prüfzeitraum am oder nach dem 28. Februar 2027, soll der Anbieter geplante Kontrolländerungen für die neue Version in der Systembeschreibung darstellen. Dazu gehören betroffenes Kriterium, Art der Änderung, Umsetzungsstatus und Termin. Der Prüfer beurteilt in dieser Übergangsphase die angemessene Darstellung, noch nicht automatisch Gestaltung oder Wirksamkeit der geplanten Änderung.

Das macht die Terminplanung spannend: Kontrolländerungen, Beobachtungszeitraum und Prüfversion müssen zueinander passen. Unser Beitrag zu C5 Typ 1 und Typ 2 hilft bei der Wahl des Prüfpfads.

Ein Umstellungsplan in sieben Schritten

1. Prüfkalender festlegen: Stichtag oder Zeitraum bestimmt, welche Version gilt.
2. Altes Mapping sichern: Bestehende Kontrollen und Nachweise bleiben Ausgangsbasis.
3. Delta-Mapping durchführen: Jedes neue oder geänderte Subkriterium inhaltlich bewerten.
4. Lücken priorisieren: Lange technische, vertragliche und organisatorische Vorläufe zuerst angehen.
5. Kontrollen anpassen: Scope, Frequenz, Besitzer und Nachweise aktualisieren.
6. Systembeschreibung erneuern: Technik, Daten, Subdienstleister und wesentliche Änderungen transparent darstellen.
7. Wirksamkeit vorprüfen: Interne Tests durchführen, bevor der relevante Zeitraum läuft.

Stimmen Sie den Plan früh mit der Prüfgesellschaft ab. Der Weg zum C5-Testat bleibt grundsätzlich derselbe, aber Kriterienstruktur und Erwartung an die Darstellung haben sich verändert.

Was Sie jetzt nicht tun sollten

Warten Sie nicht bis Frühjahr 2027, wenn Ihr nächster Typ-2-Zeitraum im Juni beginnen soll. Technische Umbauten und Vertragsänderungen brauchen Vorlauf. Kopieren Sie außerdem keine vollständigen Kontrolltexte blind aus C5:2020. Bewährte Kontrollen bleiben nützlich, müssen aber gegen die neuen Inhalte geprüft werden.

Und starten Sie nicht mit der Zahl 168 als Projektplan. Die wirkliche Arbeit steckt in den Deltas, die Ihren Dienst betreffen. Ein Anbieter ohne Container hat andere Schwerpunkte als eine hochgradig cloudnative Plattform. Ein Unternehmen mit vielen Subdienstleistern muss andere Baustellen zuerst öffnen als ein Anbieter mit eigenem Rechenzentrum.