8 Min. Lesezeit

BSI-KRITIS, NIS2 und C5 stehen 2026 nicht mehr nebeneinander, sondern übereinander. Wer Cloud-Dienste in einer kritischen Infrastruktur einbindet, muss alle drei Rahmenwerke gleichzeitig bedienen, ohne dass die Architektur zur Compliance-Routine ohne Wirkung wird. Dieser Praxischeck zeigt, an welchen Stellen die Frameworks tatsächlich kollidieren und wie ein Multi-Cloud-Setup unter Prüfung besteht.

Kurzfassung: Compliance entscheidet sich beim Zusammenspiel aus Service-Auswahl, Tenant-Konfiguration, Evidenz und Meldeorganisation. Der Provider liefert nur einen Baustein.

Das Wichtigste in Kürze

• Kreis regulierter Einrichtungen wächst: Mit der NIS2-Umsetzung im NIS2UmsuCG und dem KRITIS-Dachgesetz fallen deutlich mehr Unternehmen unter Cybersecurity- und Resilienz-Pflichten. Nicht jede Organisation wird KRITIS-Betreiber im engeren Sinn, aber NIS2/BSIG-Pflichten und KRITIS-nahe Nachweisketten greifen breiter als bisher.
• C5 ist Nachweisrahmen, nicht Endpunkt: Der Testat-Ordner deckt den Provider ab. Tenant-Konfiguration, Schlüsselverwaltung, Zugriffskontrolle und Protokollierung müssen vom Betreiber separat belegbar sein.
• Multi-Cloud erzeugt mehrere Audit-Pfade pro Workload: Provider-Testat, Tenant-Evidenz, Lieferketten- und Subprozessoren-Nachweis liegen ohne zentrales Evidenz-Layer in getrennten Welten. Der Prüfaufwand steigt deutlich.

VerwandtBYOD im deutschen Enterprise 2026  /  SAP Sovereign Cloud France

Was 2026 wirklich neu ist

Was ist BSI-KRITIS-Compliance bei Cloud-Nutzung? Es ist die Pflicht für Betreiber kritischer Infrastrukturen, jeden produktiv genutzten Cloud-Service einzeln nachzuweisen: Datenklasse, Standort, Provider-Testat (typischerweise BSI C5 Typ 2), eigene Konfigurations-Evidenz im Tenant, dokumentierte Vorfall-Meldekette inklusive 24-Stunden-Frühwarnung nach NIS2. Pauschale Provider-Testate reichen seit 2026 nicht mehr aus.

Die Diskussion um KRITIS und Cloud läuft seit Jahren, aber 2026 verschiebt sich der Anker. Mit der zweiten Verordnung zur Änderung der BSI-Kritisverordnung sind Schwellenwerte in mehreren Sektoren niedriger angesetzt. Parallel koppelt der Entwurf zum KRITIS-Dachgesetz physische und digitale Resilienz erstmals zusammen. Daneben läuft die NIS2-Umsetzung im NIS2UmsuCG, das den Kreis pflichtiger Stellen deutlich erweitert. Wer bisher knapp unter der KRITIS-Grenze lag, ist jetzt drin oder sehr nah dran.

Wichtig zur sauberen Einordnung: Für Cloud-Setups ist NIS2/BSIG der unmittelbarere Cybersecurity-Hebel. Das KRITIS-Dachgesetz erhöht zusätzlich den Resilienz- und Nachweisdruck auf Betreiber kritischer Anlagen, muss aber teilweise noch durch Rechtsverordnungen konkretisiert werden. Wer die Regime trennt, plant präziser.

Der Effekt auf Cloud-Strategien ist nicht subtil. Jeder produktiv genutzte Cloud-Service muss einzeln nachgewiesen werden: Kategorie, Datenklasse, Standort, Provider-Testat, eigene Konfigurations-Evidenz. Was vor drei Jahren als pauschaler „wir haben C5″ durchging, wird in einer KRITIS-Prüfung 2026 zerlegt. Die Prüfer erwarten Service-Level-Granularität, nicht Hyperscaler-Gesamtbild.

C5 bleibt ein wichtiger Nachweisrahmen für Cloud-Provider. Für Betreiber ist er aber nur ein Baustein: Die eigene Tenant-Konfiguration, Zugriffskontrolle, Schlüsselverwaltung und Protokollierung müssen separat belegbar sein. Die Trennung wurde lange weichgespült und fällt jetzt im Audit zurück auf den Betreiber.

Die drei Rahmenwerke und wo sie sich beißen

Wer KRITIS, NIS2 und C5 als getrennte Spuren behandelt, baut sich drei parallele Audit-Universen. Das ist teuer und unnötig. In der Praxis überlappen die Anforderungen zu rund zwei Dritteln. Genau die übrigen dreißig Prozent müssen verstanden werden, sonst gibt es Findings.

Der praktisch wichtigste Konflikt: NIS2 verlangt eine 24-Stunden-Frühwarnung bei meldepflichtigen Vorfällen. KRITIS-Sektorvorgaben sind teilweise enger, teilweise weiter. C5 wiederum verpflichtet den Provider zur Information seiner Kunden. Die Eskalation nach BSI muss der Kunde selbst leisten. Wer die Schnittstelle nicht eingerichtet hat, bekommt eine Vorfallmeldung vom Hyperscaler und kann sie organisatorisch nicht weiterverarbeiten.

Wichtige Präzisierung zur Frist: Die 24-Stunden-Uhr startet, sobald die pflichtige Stelle Kenntnis von einem erheblichen Sicherheitsvorfall erhält und den Meldepfad auslösen muss. Provider-Alarme sind nur ein möglicher Auslöser, nicht der einzige. Wer den internen Bewertungs- und Eskalationspfad nicht eingerichtet hat, verbrennt einen Großteil der 24 Stunden mit organisatorischer Klärung.

Zweiter Konflikt: Lieferanten-Sicherheit. NIS2 zieht den Schutz der Lieferkette ins Zentrum. Die Multi-Cloud-Realität bedeutet, dass jeder Hyperscaler und jeder SaaS-Tier-2-Anbieter Teil dieser Kette ist. C5 deckt nur den ersten Cloud-Anbieter ab, nicht dessen Subprozessoren. Wer SaaS auf Hyperscaler X betreibt, hat zwei Lieferantenebenen mit unterschiedlichen Nachweispflichten.

Vom Framework zum Setup: Vier Wochen, ein Pfad

Das folgende Vorgehen ist verdichtet aus Compliance-Projekten in Versorgern, KRITIS-naher Industrie und Versicherern. Der Zeitrahmen passt für ein bestehendes Multi-Cloud-Setup mit zwei bis drei Hyperscalern und einer Hand voll SaaS-Tools mit Kundendatenzugriff.

Der gefühlte Drang, alles parallel zu bearbeiten, ist verständlich, aber ineffizient. Ohne saubere Inventur ist jedes Posture-Tool überflüssig. Ohne Schutzbedarfsfeststellung weiß niemand, welche Konfigurations-Evidenz wirklich kritisch ist. Diese Reihenfolge trägt in der Praxis am verlässlichsten.

Wer schon eine zentrale Cloud-Plattform für Inventur und Drift-Erkennung betreibt, kann Woche 3 verkürzen. Wer noch in Excel-Listen pro Fachbereich denkt, sollte Woche 1 verlängern und nicht abkürzen. Eine unvollständige Inventur fällt im KRITIS-Audit auf Seite eins auf. Dann beginnt der Korrekturlauf unter Zeitdruck.

Was trägt, was bricht: Multi-Cloud unter Prüfung

Im Konflikt zwischen Architektur-Idealismus und Audit-Realität entscheidet sich, ob ein Setup Prüfungen überlebt. Die folgenden Muster haben in den letzten zwei Jahren häufig zu Findings geführt – oder eben gerade nicht.

Auffällig oft scheitert es nicht an der Technik, sondern an der Organisation. Cloud-Architekturen sind in den meisten KRITIS-Betreibern technisch sauber. Was fehlt, sind dokumentierte Schnittstellen zwischen IT-Sicherheit, Compliance und Fachbereich. Wer seinen Meldepfad nicht einmal pro Quartal durchspielt, kennt ihn faktisch nicht.

Der zweite häufige Stolperstein ist die SaaS-Schattenebene. Marketing-Tools, HR-Systeme, Legal-Plattformen – sie alle landen über kurz oder lang in der KRITIS-Nähe, weil sie Daten von kritischen Anlagen verarbeiten oder Identitäten von Betriebspersonal halten. Wer hier ein Inventar-Loch hat, hat ein Audit-Loch.

Architektur-Entscheidungen mit Compliance-Hebel

Drei Architektur-Bausteine wirken überproportional. Sie sind nicht neu, aber 2026 sind sie keine Kür mehr.

Erstens: Identity Federation mit zentralem Audit-Backbone. Wer Hyperscaler X, Y und drei SaaS-Anbieter mit getrennten Identity-Stacks betreibt, hat fünf Audit-Logs. Wer einen zentralen Identity-Provider mit konsistenter Federation einsetzt, hat einen. Der Prüfaufwand sinkt nicht linear, sondern überproportional, weil Vorfall-Forensik einen einzigen Pfad nimmt.

Zweitens: Customer-Managed Keys, mindestens für Datenklasse „hoch“ und „sehr hoch“. Provider-managed Keys sind bequem und reichen für „normal“. Bei KRITIS-relevanten Datenklassen ist die Diskussion um Schlüsselhoheit eine, die das Audit liest und bewertet. Eine eigene Key-Infrastruktur, sei es External Key Manager oder dedizierte HSM-Anbindung, bringt im Prüfbericht Punkte und im Vorfall Handlungsspielraum.

Drittens: Konfigurations-Evidenz als First-Class-Citizen. Provider-Testate sind Punkt-in-Time-Aussagen. Eine produktive Cloud ändert sich täglich. Wer keinen Drift-Detector hat, der Konfigurationsabweichungen gegen einen Soll-Stand alarmiert, kann zwischen den Prüfzeitpunkten nicht belegen, dass die Kontrollen wirksam sind. Die Prüfer-Frage „wann wussten Sie davon“ ist nur mit einem Logsenken-Eintrag zu beantworten, nicht mit einer Annahme.

Ein C5-Testat im Ordner ersetzt nicht den Audit-Trail im Tenant. Das ist die Lehre aus jedem ernsten KRITIS-Prüfbericht der letzten zwei Jahre.

Lieferketten und der Subprozessoren-Knoten

NIS2 hat die Lieferkettensicherheit aus dem Anhang nach vorne geholt. Für Cloud-Multi-Setups bedeutet das: Jeder Subprozessor wird sichtbar. Hyperscaler X nutzt Sub-Prozessor A für Logging, Sub-Prozessor B für Threat Intelligence, Sub-Prozessor C für Hardware-Wartung. Diese Liste muss vorliegen, sie muss aktualisiert werden. Ihre Änderung muss vertraglich angezeigt werden.

Im Multi-Cloud-Setup multipliziert sich das. Drei Hyperscaler mit jeweils zwölf bis zwanzig Subprozessoren ergeben rund fünfzig Lieferketten-Einträge. Ohne ein zentrales Auslagerungs-Register, das diese Liste pflegt und Änderungen mit Datum protokolliert, ist die NIS2-Frage nach Lieferketten-Risikomanagement nicht beantwortbar.

Praktischer Schritt: Auslagerungs-Register als CSV oder Datenbank-Tabelle, monatlich abgeglichen mit den Provider-Subprozessor-Listen. Änderungs-Notice in den Vertrag schreiben, Verantwortlichkeit für Review benennen. Klingt nach Bürokratie, ist aber die Voraussetzung für eine NIS2-Prüfung ohne offensichtliche Findings.

Was Prüfer 2026 wirklich sehen wollen

Aus Gesprächen mit Prüfern, ohne dass das Detail jedes einzelnen Prüfberichts öffentlich wäre, kristallisiert sich ein Muster heraus. Drei Bereiche bekommen 2026 überproportional Aufmerksamkeit.

Der erste Bereich ist die Vollständigkeit der Inventur. Wer Cloud-Services nicht pro Service inventarisiert, sondern pro Provider, fällt sofort auf. Prüfer fragen nach einer Anlage, schauen sich die Service-Liste an und vergleichen mit Netzwerk-Telemetrie. Wenn dort SaaS-Tools auftauchen, die nicht in der Liste sind, ist das ein direktes Finding.

Der zweite Bereich ist die Wirksamkeit der Vorfall-Meldekette. NIS2 fordert 24-Stunden-Frühwarnung. Prüfer fragen nicht nach dem Prozess, sondern nach der letzten Übung. Eine quartalsweise Übung mit Vertretungsregelung und Fallback-Kommunikation reicht in der Regel.

Der dritte Bereich ist die Konsistenz der Schlüssel- und Identitäts-Hoheit über alle Cloud-Tenants. Hier kommt die Multi-Cloud-Komplexität voll durch. Eine einzige Sicht auf rotierte Schlüssel und kritische Identity-Events der letzten 90 Tage ist die Mindestanforderung. Fehlt sie, entsteht ein Audit-Problem.

Häufige Fragen

Bildquelle: KI-generiert (Mai 2026)