KRITIS in die Cloud: Was die Migration absichert

Seit dem 17. März 2026 gilt das KRITIS-Dachgesetz. Wer jetzt sensible Systeme in die Cloud verlagert, muss Verfügbarkeit, Datenhoheit und Nachweispflicht von Anfang an zusammendenken. Die Migration entscheidet darüber, ob das spätere Audit zur Formsache wird oder zur Baustelle.

Das Wichtigste in Kürze

• Der Kreis wird größer: Mehr als 30.000 Unternehmen fallen seit dem NIS2-Umsetzungsgesetz neu unter erweiterte Sicherheitspflichten, viele davon stufen sich erstmals als wichtige oder besonders wichtige Einrichtung ein.
• C5 wird strenger: Der neue Kriterienkatalog C5:2026 zählt 168 Kriterien statt bisher 121 und regelt Container, Supply Chain und Confidential Computing erstmals explizit. Verbindlich wird er ab 1. Juni 2027.
• Reihenfolge schlägt Tempo: Wer den Schutzbedarf vor der Anbieterwahl klärt, spart sich teure Rückbauten. Architektur und Exit-Plan entscheiden, ob die Migration eine Compliance-Last bleibt oder ein Resilienz-Gewinn wird.

Verwandt:Der billige Cloud-Chip mit dem teuren Rückweg  /  Ingress-NGINX ist abgekündigt: Der Weg zur Gateway API

Erst der Schutzbedarf, dann der Anbieter

Was ist KRITIS? Als Kritische Infrastruktur gelten Einrichtungen, deren Ausfall die Versorgung der Bevölkerung gefährdet, etwa in Energie, Wasser, Gesundheit, Finanzen oder Transport. Ihre Betreiber unterliegen besonderen Sicherheits- und Meldepflichten. Seit dem NIS2-Umsetzungsgesetz und dem KRITIS-Dachgesetz betrifft das deutlich mehr Unternehmen als zuvor.

Die häufigste Reihenfolge ist auch die teuerste: zuerst den Hyperscaler wählen, dann fragen, was er eigentlich schützen muss. Für KRITIS-Betreiber dreht sich das um. Am Anfang steht die Klassifizierung jedes Workloads nach Schutzbedarf, Kritikalität für den Versorgungsauftrag und Wiederanlaufzeit. Ein Abrechnungssystem mit Personendaten hat einen anderen Schutzbedarf als ein internes Wiki. Genau diese Trennung entscheidet später über das Deployment-Modell.

Praktisch heißt das: Daten und Dienste in drei Klassen einteilen. Was darf in eine öffentliche Region, was nur in eine souveräne Umgebung, was bleibt vorerst im eigenen Rechenzentrum? Wer diese Karte vor dem ersten Migrationsticket zeichnet, verhandelt mit dem Anbieter über konkrete Anforderungen statt über Marketing-Folien.

Datenresidenz: Wo die Workloads wirklich liegen

Eine EU-Region im Auswahlmenü ist kein Beweis für Datenhoheit. Entscheidend ist, wer technisch und rechtlich Zugriff auf die Daten hat, in welchem Land der Betreiber sitzt und ob Support oder Wartung aus Drittstaaten erfolgen. Für sensible KRITIS-Workloads sind die relevanten Fragen: Liegt der Schlüssel beim Provider oder beim Kunden? Lässt sich der Zugriff des Anbieters technisch ausschließen, etwa über Confidential Computing oder kundengehaltene Keys?

Das C5:2026 nimmt genau diese Punkte ernster als sein Vorgänger. Mit 168 statt 121 Kriterien adressiert der Katalog erstmals Container-Management, Lieferketten und Confidential Computing als eigene Anforderungsblöcke. Für die Migration heißt das: Datenresidenz ist ein Architektur-Thema, das Verschlüsselung, Key-Management und Betriebsmodell verbindet. Eine Checkbox im Beschaffungsformular bildet das nicht ab.

Ein C5-Testat öffnet die Tür, mehr nicht

Ein C5-Testat des Providers ist für KRITIS-nahe Beschaffung oft die Eintrittskarte. Es belegt, dass der Anbieter den Katalog erfüllt, sagt aber nichts darüber aus, ob die eigene Konfiguration diese Sicherheit auch nutzt. Cloud-Sicherheit ist geteilte Verantwortung: Der Provider liefert die testierte Plattform, der Betreiber konfiguriert Identitäten, Netzsegmentierung und Logging. Ein perfektes Testat schützt nicht vor einem offenen Storage-Bucket.

Bei der Anbieterauswahl lohnt der nüchterne Vergleich der Betriebsmodelle. Jedes hat seinen Platz, abhängig von der Schutzbedarfsklasse aus Schritt eins.

Der Exit-Plan entscheidet über die Verfügbarkeit

Verfügbarkeit trägt bei KRITIS den Versorgungsauftrag. Fällt der Dienst aus, fällt die Versorgung. Eine Cloud-Migration verbessert die Resilienz nur, wenn der Plan für den Ausfall vor dem Plan für den Normalbetrieb steht. Das beginnt beim Lock-in: Wie schnell lässt sich ein Dienst zu einem zweiten Anbieter oder zurück ins eigene Rechenzentrum verlagern, wenn der Provider ausfällt, die Preise springen oder eine Behörde es verlangt?

Wer kritische Dienste auf portable Bausteine setzt, etwa auf Container und standardisierte Schnittstellen statt auf proprietäre Managed Services, hält den Rückweg offen. Multi-Cloud zahlt sich genau dort aus, wo der Ausfall eines Anbieters den Versorgungsauftrag trifft. Für unkritische Dienste bleibt es teurer Aufwand.

Das Audit beginnt vor der Migration

Die Nachweispflicht ist die Stelle, an der gute Architektur sichtbar wird oder eben fehlt. Betroffene Einrichtungen müssen sich beim BSI registrieren. Durch das KRITIS-Dachgesetz kommt für die physische Resilienz eine zweite Registrierung beim BBK hinzu, Frist hier ist der 17. Juli 2026. Wer Logging, Asset-Inventar und Incident-Prozesse erst nach der Migration nachzieht, dokumentiert Lücken statt Kontrolle.

Deshalb gehört die Beweisführung in die Migrationsplanung: zentrale Protokollierung, ein gepflegtes Verzeichnis der ausgelagerten Dienste und klare Meldewege ab Tag eins. Dann zieht das Audit am Ende nur einen Bericht aus dem laufenden Betrieb.

Häufige Fragen

Bildquelle: KI-generiert (Juni 2026)