KRITIS-Dachgesetz Supply Chain Compliance 2026: Was ICT-Lieferanten jetzt tun müssen

Post #4 in der sota.io EU KRITIS-Dachgesetz Compliance-Serie

Die meisten Diskussionen über KRITIS-Dachgesetz-Compliance fokussieren auf KRITIS-Betreiber selbst: Energieversorger, Wasserwerke, Krankenhäuser. Dabei übersieht man das eigentliche Novum des Gesetzes — §17 zieht die gesamte ICT-Lieferkette direkt in die Compliance-Pflicht.

Wenn Ihr Unternehmen Software, Cloud-Dienste oder digitale Infrastruktur an KRITIS-Betreiber verkauft, sind Sie bereits heute von KRITIS-DG betroffen. Nicht als Kunde — als Lieferant. Die Deadline: 17. Juli 2026.

Dieser Guide erklärt konkret, welche Supply-Chain-Anforderungen KRITIS-DG §17 für ICT-Lieferanten schafft, wo US-Cloud-Dienste strukturell scheitern werden — und warum EU-native Alternativen hier einen regulatorischen Vorteil haben, der über Marketing hinausgeht.

Die Supply-Chain-Revolution des KRITIS-DG

Das KRITIS-Dachgesetz (BGBl. I 2024) geht in einem zentralen Punkt deutlich über NIS2 hinaus: Während NIS2 Artikel 21 Supply-Chain-Risiken als Managementpflicht der Betreiber adressiert, schafft KRITIS-DG §17 eine direkte Nachweispflicht auf Lieferantenseite.

Drei Regelungsebenen, die zusammenwirken

Ebene 1 — §13 KRITIS-DG: Registrierungspflicht der Betreiber (2026-07-17) KRITIS-Betreiber müssen sich bis zum 17. Juli 2026 beim BSI registrieren. Als Teil dieser Registrierung müssen sie ihre kritischen ICT-Komponenten und -Dienste erfassen. Das erzeugt unmittelbaren Druck auf Lieferanten: Betreiber brauchen Compliance-Belege von ihren SaaS-Anbietern für die eigene Registrierung.

Ebene 2 — §17 KRITIS-DG: Direkte Lieferantenpflichten §17 Abs. 2 verpflichtet ICT-Lieferanten, auf Anfrage des KRITIS-Betreibers den Nachweis zu erbringen, dass ihre Komponenten die vereinbarten Sicherheitsanforderungen erfüllen. Akzeptierte Nachweisformen:

• BSI C5 Typ-2-Testat (gilt als "Gold Standard" bei deutschen Behörden)
• ISO/IEC 27001-Zertifizierung mit KRITIS-relevantem Anwendungsbereich
• Branchenspezifische Zertifizierungen (TISAX für Automotive, HDS für Gesundheitswesen)
• BSI-anerkannte Prüfung nach IT-Grundschutz-Kompendium

Ebene 3 — §19 KRITIS-DG: BSI-Einschränkungsrecht Das BSI kann den Einsatz kritischer Komponenten von Herstellern verbieten oder einschränken, wenn diese aus Ländern mit erhöhtem Risiko stammen — oder wenn "keine hinreichende Vertrauenswürdigkeit" nachgewiesen werden kann. Das ist die regulatorische Absicherung von §17: Lieferanten die keine Nachweise liefern, können aus KRITIS-Lieferketten ausgeschlossen werden.

Was "kritische ICT-Komponente" im Lieferkettenkontext bedeutet

Die Definition ist bewusst weit gehalten. Laut §2 Abs. 13 KRITIS-DG sind kritische Komponenten:

"Hardware, Software und IT-Dienste, die für das Funktionieren kritischer Anlagen wesentlich sind oder bei denen ein Ausfall oder eine Kompromittierung zu erheblichen Störungen des Betriebs kritischer Anlagen führen könnte."

Für B2B-SaaS-Anbieter bedeutet das: Nicht die Intention des Produkts entscheidet, sondern die Nutzung durch den KRITIS-Betreiber.

Typische SaaS-Kategorien die unter §17 fallen können

Entscheidend: Viele SaaS-Anbieter werden erst durch KRITIS-Betreiber-Anfragen erfahren, dass ihr Produkt als "kritische Komponente" klassifiziert wurde.

Der CLOUD Act als Supply-Chain-Ausschluss-Grund

Hier liegt die fundamentale Herausforderung für US-Cloud-Dienste im KRITIS-Umfeld. Das Problem ist nicht Datenschutz per se — es ist die strukturelle Unvereinbarkeit von US-Bundesrecht mit §19-KRITIS-DG-Anforderungen.

CLOUD Act §2713 als permanentes BSI-Risikoflag

Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. §2713) verpflichtet US-Unternehmen und deren Tochtergesellschaften weltweit, auf Gerichtsbeschluss gespeicherte Daten herauszugeben — unabhängig vom physischen Serverstandort.

Für KRITIS-Betreiber und das BSI bedeutet das:

Szenario 1 — Direkter Datenzugriff: US-Behörden können via CLOUD Act Betriebsdaten eines KRITIS-Betreibers anfordern, die bei einem US-SaaS-Anbieter liegen. Konfigurationsdaten, Schwachstellen-Scans, Incident-Logs — alles was für einen Angreifer nützlich wäre, liegt theoretisch offen.

Szenario 2 — Dienstverfügbarkeit als Sanktionshebel: Bei politischen Konflikten kann eine US-Sanktions-Executive-Order einen US-SaaS-Anbieter zwingen, Dienste für bestimmte Kunden oder Regionen zu sperren. Eine KRITIS-Betriebsunterbrechung durch Sanktionsentscheidung — das ist genau das Szenario das §19 KRITIS-DG verhindern soll.

Szenario 3 — Hersteller-Vertrauenswürdigkeit §19: Das BSI prüft bei §19-Einschränkungsentscheidungen explizit: Ist der Hersteller rechtlich in der Lage, die Confidentiality und Availability der Daten gegenüber dem deutschen Staat zu garantieren? Für US-Unternehmen unter CLOUD Act lautet die ehrliche Antwort: Nein, nicht vollständig.

CLOUD Act Scores relevanter Dienste

Score-Methodik: 25 = vollständige CLOUD Act Unterwerfung, 0 = keine US-Jurisdiction

§17-Compliance-Roadmap für ICT-Lieferanten

Wenn Sie KRITIS-Betreiber beliefern oder beliefern wollen, empfehlen wir folgende Schritte:

Schritt 1: KRITIS-Berührtheitsprüfung (sofort, 1-2 Tage)

Klären Sie intern:

• Welche Ihrer Kunden könnten KRITIS-Betreiber sein? (Sektoren: Energie, Wasser, Transport, Gesundheit, Ernährung, IKT, Finanzen, Staat)
• Welche Ihrer Produkte/Dienste werden für betriebskritische Prozesse dieser Kunden genutzt?
• Wurden Sie bereits von Kunden nach Compliance-Belegen gefragt?

Ergebnis: Eine Liste der KRITIS-exponierten Kundenbeziehungen und Produkte.

Schritt 2: Gap-Analyse gegen BSI C5 (2-4 Wochen)

BSI C5 (Cloud Computing Compliance Criteria Catalogue) ist der de-facto Standard für §17-Nachweise. Das BSI veröffentlicht den Kriterienkatalog kostenlos. Wichtige Kontrollbereiche:

OIS — Richtlinien zur Informationssicherheit: Existiert eine dokumentierte IS-Richtlinie? Wer ist verantwortlich?

ORP — Organisation und Personal: Sicherheitsklauseln in Arbeitsverträgen, Rollenkonzept, Schulungsnachweise.

OPS — Betrieb: Patch-Management-Prozesse, Change-Control, Incident-Response-Plan mit definierten RTO/RPO.

DLL — Datenlöschung und -vernichtung: GDPR-konforme Löschkonzepte, nachweisbare Datenlöschung bei Vertragsende.

RB — Risikobasierter Ansatz: Formales Risikomanagement-Framework, dokumentierte Risikobehandlung.

IDM — Identitäts- und Zugriffsmanagement: MFA-Pflicht, Least-Privilege-Konzept, privilegierte Zugangsverwaltung.

KRY — Kryptographie: Verschlüsselungsstandards (AES-256, TLS 1.3), Key-Management, Zertifikatsverwaltung.

LOG — Protokollierung: Vollständige Audit-Logs, Log-Integrität, SIEM-Anbindung.

SIM — Sicherheitsvorfallsmanagement: Definierter Incident-Response-Prozess, Meldepflichten, Forensik-Readiness.

Schritt 3: Auditierung und Zertifizierung (3-9 Monate)

Wählen Sie je nach Situation:

Option A — ISO 27001 (bereits vorhanden oder machbar): Schnellster Weg wenn Grundlagen vorhanden. Scope muss KRITIS-relevante Dienste einschließen. Ca. 3-6 Monate wenn Vorarbeit geleistet. Kosten: €15.000-€50.000 je nach Größe.

Option B — BSI C5 Typ-2-Testat (empfohlen für DE-KRITIS-Markt): Aufwendiger als ISO 27001, aber stärkste Akzeptanz beim BSI. Prüfzeitraum: mindestens 6 Monate. Kosten: €50.000-€150.000. Empfehlenswert für Anbieter mit strategischem KRITIS-Fokus.

Option C — Kombinierter Ansatz: ISO 27001 als Basis + BSI C5 als Aufbau. Effizienteste Nutzung der Compliance-Investition. Gut für Anbieter mit mittelfristigem KRITIS-Wachstumsplan.

Schritt 4: Vertragsgestaltung mit KRITIS-Betreibern (parallel)

Überprüfen Sie bestehende Verträge mit KRITIS-Betreibern auf:

• Unterauftragnehmerpflichten: Haften Sie für Ihre eigenen Subunternehmer/Cloud-Provider?
• Datenzugangsklauseln: Erlauben Ihre AGB staatlichen Datenzugriff? Das könnte §19-Probleme schaffen.
• Meldepflichten: KRITIS-DG verpflichtet Betreiber zur BSI-Meldung — Ihre SLAs müssen Incident-Informationen zeitgerecht liefern.
• Gerichtsstand und anwendbares Recht: US-Recht als Gerichtsstand? Problematisch für KRITIS-Kontrakte.

Schritt 5: Supply-Chain-Transparenz dokumentieren (laufend)

§17 fordert implizit auch Transparenz über Ihre eigene Supply Chain. Dokumentieren Sie:

• Welche Cloud-Infrastruktur nutzen Sie? (IaaS-Provider, Rechenzentren, Jurisdiktionen)
• Welche kritischen Dienste beziehen Sie von Dritten? (Monitoring, Auth, Backup)
• Für jeden kritischen Sublieferanten: Zertifizierungsstatus, Jurisdiction, Vertragsbedingungen

CLOUD Act-Falle: Wenn Sie selbst auf AWS/Azure/GCP laufen und KRITIS-Betreiber bedienen, ist Ihre eigene §17-Compliance schwer zu erfüllen — denn Sie können keine Jurisdiktionsfreiheit für Kundendaten garantieren.

EU-native Infrastruktur als strukturelle Compliance-Lösung

Für ICT-Lieferanten die KRITIS-Betreiber langfristig bedienen wollen, ist der Wechsel auf EU-native Infrastruktur keine Compliance-Option unter vielen — es ist die strukturell robusteste Lösung.

Was EU-native Infrastruktur bietet

Jurisdiktionssicherheit: Keine US-Bundesbehörde kann via CLOUD Act auf Kundendaten zugreifen. Kein §19-BSI-Risikoflag.

Nachweisbarkeit: BSI C5-Typ-2-Testate sind für EU-native Provider einfacher zu erlangen — kein "Foreign Government Access" Kontrollbereich mit strukturellen Risiken.

Vertragskonformität: KRITIS-Verträge mit Jurisdiktionsanforderungen erfüllbar ohne rechtliche Konstrukte.

Geo-Redundanz in der EU: DR/BCP-Konzepte mit EU-Rechenzentren vermeiden Cross-Border-Transfers für Wiederherstellungsdaten.

Praktische Entscheidungsmatrix für KRITIS-Lieferanten

Nutzt aktuell US-Cloud (AWS/Azure/GCP)?
├─ Ja → KRITIS-Verträge aktuell strukturell problematisch
│   ├─ Kurzfristig: BSI C5 Gap-Analyse, Jurisdiktionsrisiken dokumentieren
│   ├─ Mittelfristig: EU-native Migration planen (6-18 Monate)
│   └─ Langfristig: Nur EU-Infrastruktur für KRITIS-Kunden
└─ Nein → Gute Ausgangslage
    ├─ ISO 27001 / BSI C5 Zertifizierung vorantreiben
    └─ §17-Nachweis-Readiness dokumentieren

EU-native PaaS-Alternativen für KRITIS-Lieferanten

Als Lieferant der selbst auf EU-nativer Infrastruktur deployt, vereinfachen Sie sowohl Ihre eigene §17-Compliance als auch die Ihrer KRITIS-Kunden. Relevante Optionen:

sota.io — EU-native managed PaaS: Hetzner Germany (BSI-IT-Grundschutz-kompatibles RZ), keine US-Muttergesellschaft, keine CLOUD-Act-Unterwerfung. Git-Deploy für jede Sprache ab €9/mo. Für KRITIS-Lieferanten die eine saubere §17-Infrastruktur-Basis brauchen.

Hetzner Cloud — EU-native IaaS: Hetzner Online GmbH, Gunzenhausen DE. ISO 27001 + BSI IT-Grundschutz-kompatibel. CLOUD Act Exposure: 0/25. Standard für viele EU-Compliance-Szenarien.

Nextcloud (selbstgehostet auf EU-Infrastruktur): Für Collaboration/File-Sharing im KRITIS-Umfeld. Keine SaaS-Abhängigkeit, vollständige Datenkontrolle. Nextcloud GmbH: Stuttgart, DE.

Die Meldepflicht-Kaskade: Was passiert wenn etwas schiefläuft

KRITIS-DG §21 verpflichtet KRITIS-Betreiber zur BSI-Meldung bei erheblichen Sicherheitsvorfällen. Als ICT-Lieferant sitzen Sie in dieser Kaskade — Ihre SLAs und Incident-Response-Prozesse müssen angepasst werden.

Meldepflichten im Überblick

Wichtig für SaaS-Anbieter: Sie sind nicht direkt gegenüber dem BSI meldepflichtig — aber gegenüber dem KRITIS-Betreiber. Wenn Ihre SLAs keine 24-Stunden-Incident-Notification vorsehen, ist das eine §17-Compliance-Lücke.

Vertragliche Anpassungen für KRITIS-Kontrakte

Überprüfen Sie und ergänzen Sie ggf.:

□ Incident-Notification: Erhebliche Vorfälle innerhalb 2h an KRITIS-Betreiber
□ Root-Cause-Analysis: Vorabversion innerhalb 72h, Final innerhalb 30 Tagen
□ Forensik-Kooperation: BSI-Unterstützung bei §21-Ermittlungen
□ Log-Aufbewahrung: Mindestens 12 Monate (empfohlen 24 Monate für KRITIS)
□ Datenlöschbestätigung: Nachweisbare Löschung bei Vertragsende (BSI C5 DLL)
□ Sub-Lieferanten-Transparenz: Liste kritischer Subprozessoren auf Anfrage
□ Jurisdiktionsklarheit: Anwendbares Recht, Serverstandorte, Datentransfer-Protokoll

Zeitplan und kritische Fristen

Empfehlung: Starten Sie die BSI C5 Gap-Analyse jetzt — selbst wenn Ihre KRITIS-Kunden noch keine formale Anfrage gestellt haben. Die Lücke zwischen heutigem Compliance-Stand und §17-ready beträgt in der Regel 3-12 Monate.

Zusammenfassung

KRITIS-Dachgesetz §17 ist kein abstraktes Betreiberproblem — es ist eine direkte Compliance-Herausforderung für jeden B2B-SaaS-Anbieter der KRITIS-Betreiber bedient. Die Kernbotschaften:

1. Die Lieferkette ist compliance-pflichtig: §17 zieht ICT-Lieferanten direkt in die Pflicht, nicht nur als vertragliche Weitergabe vom Betreiber.

2. CLOUD Act ist ein strukturelles Hindernis: US-SaaS-Dienste können die Jurisdiktionsanforderungen von §19 nicht erfüllen — unabhängig von Datenschutz-Bemühungen.

3. BSI C5 ist der Nachweis-Standard: SOC 2, FedRAMP etc. werden als §17-Nachweis nicht ausreichen. BSI C5 Typ 2 oder ISO 27001 mit KRITIS-relevantem Scope ist erforderlich.

4. EU-native Infrastruktur vereinfacht alles: Wer auf Hetzner, Scaleway oder sota.io deployt statt auf AWS/Azure/GCP, hat keine strukturellen Jurisdiktions-Probleme — das vereinfacht §17, BSI C5 und Kundenverträge.

5. Start jetzt, nicht nach der Deadline: §17-Nachweise brauchen 3-12 Monate Vorlaufzeit. Wer jetzt anfängt, ist bis Q3/Q4 2026 ready. Wer wartet, gerät unter Zeitdruck.

Post #4 von 5 in der EU KRITIS-Dachgesetz Compliance-Serie. Den nächsten Post — EU KRITIS Stack Finale: EU-native Alternativen im direkten Vergleich — finden Sie in Kürze auf sota.io.

Weiterführende Ressourcen: KRITIS-Dachgesetz §17 Sicherheitsnachweis Step-by-Step | KRITIS-DG vs. NIS2 für B2B-SaaS | KRITIS-Dachgesetz CLOUD Act Risiken