§17 KRITIS-Dachgesetz: Sicherheitsnachweis Step-by-Step für ICT-Lieferanten

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

"Was genau muss ich als ICT-Lieferant einreichen — und bis wann?" Diese Frage beschäftigt aktuell hunderte B2B-SaaS-Anbieter in Deutschland, die KRITIS-Betreiber beliefern. Ab dem 17. Juli 2026 tritt §17 KRITIS-Dachgesetz in Kraft und verlangt von ICT-Lieferanten einen formalen Sicherheitsnachweis.

Das Problem: Die meisten SaaS-Anbieter kennen die Anforderungen nicht konkret genug. "Wir haben SOC 2" reicht nicht. "Wir arbeiten daran" auch nicht. §17 verlangt spezifische Nachweise in einem definierten Format — und US-SaaS-Anbieter werden dabei auf strukturelle Hindernisse stoßen, die mit Compliance-Bemühen allein nicht zu lösen sind.

Dieser Guide führt Sie Schritt für Schritt durch den §17-Nachweis-Prozess, erklärt welche Dokumente akzeptiert werden, wo die kritischen Lücken für US-gehostete Dienste entstehen — und was EU-native SaaS-Anbieter als strategischen Vorteil haben.

Was §17 KRITIS-DG konkret fordert

§17 KRITIS-Dachgesetz (BGBl. I 2024) schafft eine direkte Rechtspflicht zwischen ICT-Lieferanten und KRITIS-Betreibern. Die Norm hat drei Kernanforderungen:

§17 Abs. 1 — Sicherheitsanforderungen für kritische Komponenten: Hersteller und Anbieter kritischer Komponenten müssen sicherstellen, dass ihre Produkte und Dienste den Sicherheitsanforderungen des KRITIS-Betreibers entsprechen. "Kritische Komponente" ist dabei weit gefasst: Software, Hardware und Dienste die bei Ausfall oder Kompromittierung den Betrieb kritischer Anlagen beeinträchtigen können.

§17 Abs. 2 — Nachweispflicht auf Anfrage: Auf Anfrage eines KRITIS-Betreibers müssen ICT-Lieferanten innerhalb einer angemessenen Frist (in der Praxis: 30-90 Tage) nachweisen, dass ihre Komponenten den vereinbarten Sicherheitsanforderungen genügen. Der Nachweis muss durch eine anerkannte Methode erbracht werden.

§17 Abs. 3 — BSI-Befugnisse: Das BSI kann bei begründetem Verdacht auf eigene Initiative Sicherheitsnachweise anfordern. Bei öffentlichen Sicherheitsbedenken kann das BSI den Einsatz einer kritischen Komponente untersagen.

Die Nachweismethoden: Was "anerkannt" bedeutet

Das KRITIS-DG nennt keine abschließende Liste, aber BSI-Praxis und die Begründung des Gesetzentwurfs zeigen klare Präferenzen:

Der entscheidende Unterschied: BSI C5 und ISO 27001 (deutsch-akkreditiert) werden von KRITIS-Betreibern direkt akzeptiert. SOC 2, AWS Compliance Reports und andere US-Standards werden in der Praxis als Zusatzmaterial betrachtet — nicht als primärer Nachweis.

Step-by-Step: Der §17-Nachweis-Prozess

Schritt 1: Bestimmen ob §17 für Sie gilt

Nicht jeder B2B-SaaS-Anbieter fällt automatisch unter §17. Die entscheidende Frage: Ist Ihr Dienst eine kritische Komponente für einen KRITIS-Betreiber?

Checkliste — §17 Anwendbarkeit:

• Kundenprofil prüfen: Beliefern Sie Unternehmen aus einem der 11 KRITIS-Sektoren? (Energie, Wasser, Ernährung, Gesundheit, Verkehr/Transport, Finanz/Versicherung, Informationstechnik/TK, Rüstung/Verteidigung, Weltraum, öffentliche Verwaltung, Medien/Kultur)
• Schwellenwert-Check: Betreibt Ihr Kunde eine Anlage oberhalb der BSI-Kritikalitätsschwellen? (z.B. Stromversorger >100.000 Anschlussnutzer)
• Funktionale Kritikalität: Würde ein Ausfall Ihres Dienstes den Betrieb der kritischen Anlage beeinträchtigen? Betriebstechnologie-Steuerung, Leitsysteme, kritische Kommunikation, Zugangskontrollen — automatisch relevant.
• Vertragliche Einstufung: Hat der KRITIS-Betreiber Ihren Dienst bereits als kritische Komponente in seinem KRITIS-DG-Konzept klassifiziert?

Wenn mindestens 2 dieser Kriterien zutreffen: §17 ist wahrscheinlich anwendbar. Im Zweifel rechtliche Beratung suchen — das BSI veröffentlicht dazu keine abschließende öffentliche Klassifikationsliste.

Schritt 2: Gap-Analyse gegen BSI C5

BSI C5 (Cloud Computing Compliance Criteria Catalogue) ist das primäre Referenzrahmenwerk für §17-Nachweise bei Cloud-Diensten. Der aktuelle BSI C5:2020 hat 17 Domänen mit 125 Anforderungen.

Die 5 kritischsten Domänen für ICT-Lieferanten:

Domäne OPS — Betriebssicherheit

• OPS-01 bis OPS-11: Change Management, Patch-Prozesse, Kapazitätsmanagement
• Häufige Lücke: Patch-SLAs nicht formalisiert, keine dokumentierten Change-Advisory-Prozesse
• KRITIS-Relevanz: Ungepatchte Systeme in kritischer Infrastruktur = direktes Risiko für Betreiber-Compliance

Domäne RMA — Resilienz und Verfügbarkeit

• RMA-01 bis RMA-08: Business Continuity, Disaster Recovery, SLA-Architektur
• Häufige Lücke: RPO/RTO-Garantien fehlen oder sind US-Rechtsraum unterliegend
• KRITIS-Relevanz: §17 erwartet belegbare Verfügbarkeitsarchitektur, nicht nur SLA-Versprechen

Domäne COS — Compliance und Datenschutz

• COS-01 bis COS-06: Rechtsrahmen, Subprozessoren, Datenlokalisierung
• Kritischste Lücke für US-SaaS: CLOUD Act-Exposition ist hier formal dokumentierbar — und verpflichtend offenzulegen
• KRITIS-Relevanz: BSI C5 verlangt Transparenz über alle Rechtsrahmen die auf Kundendaten zugreifen können

Domäne INM — Identitäts- und Zugriffsmanagement

• INM-01 bis INM-10: MFA, privilegierte Zugänge, Zugriffsprotokolle
• Häufige Lücke: Remote-Support-Zugänge nicht vollständig auditiert
• KRITIS-Relevanz: Unautorisierte Zugriffe auf KRITIS-Systeme = sofortiges §17-Problem

Domäne SIM — Sicherheitsvorfälle

• SIM-01 bis SIM-07: Incident-Detection, Response, KRITIS-Meldepflichten
• Häufige Lücke: Notification-Timelines nicht auf KRITIS-DG §28 ausgerichtet (4h Erstmeldung)
• KRITIS-Relevanz: §17 Abs. 2 erwartet Nachweis dass Vorfälle den Betreiber fristgerecht erreichen

Schritt 3: ISO 27001 — die Mindestanforderung

Falls BSI C5 Type II noch nicht erreichbar ist (das Attestierungsverfahren dauert 6-12 Monate), ist ISO 27001 Zertifizierung durch eine DAkkS-akkreditierte Stelle der Mindestnachweis.

Kritischer Unterschied US vs. EU bei ISO 27001:

Ein ISO 27001-Zertifikat durch einen US-Zertifizierer (z.B. Bureau Veritas US, SGS US) hat formal dieselbe ISO-Konformität wie ein europäisches Zertifikat. In der Praxis akzeptieren KRITIS-Betreiber zunehmend nur DAkkS-akkreditierte Stellen — weil ISO 27001 über UKAS/ANAB-akkreditierte Zertifizierer keine Rechtsgrundlage für BSI-Prüfungen bietet.

DAkkS-akkreditierte Zertifizierungsstellen (Auswahl):

• TÜV SÜD (München) — DAkkS D-ZM-14025-01-00
• TÜV Rheinland (Köln) — DAkkS D-ZM-12144-01-00
• DQS (Frankfurt) — DAkkS D-ZM-16080-01-00
• BSI (Bundesamt) — für behördliche Systeme
• DEKRA (Stuttgart) — DAkkS D-ZM-16085-01-00

Zeitplanung ISO 27001 bis Juli 2026: Der Weg von "kein ISMS" zu ISO 27001 Zertifikat dauert typisch 9-18 Monate. Wenn Sie heute (Mai 2026) noch keine Zertifizierung haben: Das July-2026-Fenster ist nicht mehr erreichbar. Fokus sollte dann auf strukturierter ISMS-Implementierung mit dokumentierbarem Fortschritt liegen — das zeigt KRITIS-Betreibern einen glaubwürdigen Weg zur Compliance.

Schritt 4: Das Nachweispaket zusammenstellen

KRITIS-Betreiber erwarten bei einer formalen §17-Anfrage ein strukturiertes Paket. Minimales akzeptiertes Paket:

Pflichtdokumente:

1. Zertifikat/Attestierung — BSI C5 Type II oder ISO 27001 (DAkkS-akkreditiert), inkl. Statement of Applicability
2. Scope-Dokument — Was genau ist im Scope der Zertifizierung? Deckt der Scope den KRITIS-relevanten Dienst ab?
3. Subprozessor-Liste — Vollständige Liste aller Unterauftragnehmer mit Standort und Rechtssitz
4. Datenlokalisierungs-Nachweis — Wo werden Daten des KRITIS-Betreibers gespeichert und verarbeitet?
5. Penetrationstest-Bericht — Aktuell (max. 12 Monate alt), durch akkreditierten Prüfer, OWASP/BSI-Methodik

Empfohlene Ergänzungsdokumente:

• Business Continuity und Disaster Recovery Konzept
• Incident-Response-Plan mit KRITIS-DG §28-konformen Notification-Pfaden
• Vulnerability-Management-Prozess-Beschreibung
• Zugriffskonzept für privilegierte Zugänge (Vendor-Remote-Access)

Schritt 5: CLOUD Act-Exposition dokumentieren

Das ist der Schritt den US-SaaS-Anbieter am liebsten überspringen würden — und der gleichzeitig entscheidend ist. BSI C5 Domäne COS verlangt explizite Dokumentation aller Rechtsrahmen die auf Kundendaten zugreifen können.

Das bedeutet: Ein US-SaaS-Anbieter muss im Nachweispaket dokumentieren, dass der CLOUD Act (18 U.S.C. §2703 et seq.) theoretisch einen gerichtlich angeordneten Datenzugriff durch US-Behörden ermöglicht — auch für in Europa gespeicherte Daten, solange das Unternehmen US-Jurisdiktion unterliegt.

Was bedeutet das in der Praxis für §17:

KRITIS-Betreiber müssen in ihrem eigenen KRITIS-DG-Konzept Risiken für kritische Komponenten bewerten. Ein dokumentierter CLOUD Act-Exposure bei einem ICT-Lieferanten ist ein formal zu bewertender Risikofaktor. KRITIS-Betreiber in sensiblen Sektoren (Energie, Verteidigung, öffentliche Verwaltung) werden diesen Faktor negativ gewichten — unabhängig davon wie gering die statistische Wahrscheinlichkeit eines CLOUD Act-Zugriffs ist.

Die EU-native Alternative: Ein ICT-Lieferant der ausschließlich EU-Recht (DSGVO, NIS2, KRITIS-DG) unterliegt, kann im COS-Kapitel seines BSI C5 Reports dokumentieren: "Kein US-Rechtszugriff möglich. Datenverarbeitung ausschließlich in DE/EU. Keine US-Muttergesellschaft." Das ist kein Marketing-Claim — das ist ein formaler Compliance-Vorteil der in der §17-Bewertung direkt messbar wird.

Die strukturellen Hürden für US-SaaS-Anbieter

Jenseits der CLOUD Act-Frage gibt es weitere strukturelle Herausforderungen für US-SaaS-Anbieter beim §17-Nachweis:

Problem 1: Scope-Gap bei Zertifizierungen

Viele US-SaaS-Anbieter haben SOC 2 Type II — aber SOC 2 deckt typischerweise die gesamte Plattform ab, nicht spezifische EU-Deployments. BSI C5 erwartet expliziten Scope-Einschluss der EU-Infrastruktur. Wenn Ihre EU-Datenverarbeitung auf geteilter globaler Infrastruktur läuft, ist der Scope-Nachweis komplex.

Problem 2: Subprozessor-Komplexität

US-SaaS-Anbieter nutzen typischerweise US-Hyperscaler (AWS/Azure/GCP) plus US-Subprozessoren für Support, Analytics und Operations. Jeder dieser Subprozessoren muss in der §17-Dokumentation mit Standort, Rechtssitz und eigenem Compliance-Status erfasst werden. Die Kette wird schnell unübersichtlich.

Problem 3: Incident Notification muss §28 KRITIS-DG-kompatibel sein

§28 KRITIS-DG verlangt vom Betreiber 4h-Erstmeldung bei signifikanten Sicherheitsvorfällen. Das bedeutet: ICT-Lieferanten müssen vertraglich garantieren, Vorfälle vor der 4h-Frist beim Betreiber zu melden. Viele US-SaaS-Anbieter haben Security Incident Notification Clauses die sich an GDPR Art. 33 (72h) orientieren — das ist zu langsam für KRITIS-DG §28.

Problem 4: BSI-Prüfbefugnisse gelten nur für in Deutschland regulierte Entitäten

§17 Abs. 3 gibt dem BSI das Recht, bei Sicherheitsbedenken Prüfungen anzuordnen. Für US-Unternehmen ohne deutsche Niederlassung ist die Durchsetzbarkeit dieser Befugnis rechtlich komplex. Das schützt US-SaaS-Anbieter aber nicht — es macht sie für KRITIS-Betreiber weniger attraktiv, weil der Betreiber die Compliance-Verantwortung für nicht-prüfbare Lieferanten selbst trägt.

Praktischer Zeitplan: Was bis Juli 2026 noch realistisch ist

Mit Stand Mai 2026 bleiben noch etwa 7-8 Wochen bis zum 17. Juli 2026. Hier eine realistische Einschätzung was noch erreichbar ist:

Kurzfristig erreichbar (bis Juli 2026):

ISO 27001-Readiness-Assessment (2-4 Wochen): Beauftragen Sie einen akkreditierten Zertifizierer für ein Gap-Assessment. Das Ergebnis ist kein Zertifikat — aber ein dokumentierter Nachweis dass Sie den Zertifizierungsprozess aktiv begonnen haben. KRITIS-Betreiber akzeptieren das für eine Übergangsphase.

Strukturiertes Sicherheitskonzept (3-6 Wochen): Ein formales Sicherheitskonzept nach BSI-Grundschutz-Methodik, das die relevanten BSI C5-Domänen adressiert, ist ein akzeptiertes Übergangsdokument. Kein Ersatz für Zertifizierung — aber zeigt KRITIS-Betreibern einen glaubwürdigen Fahrplan.

CLOUD Act-Risikoanalyse (1-2 Wochen): Dokumentieren Sie explizit Ihren Rechtsrahmen, die Jurisdiktion Ihrer Infrastruktur und Ihres Unternehmens — und die daraus resultierenden Risiken und Gegenmaßnahmen (z.B. EU-Datenresidenz-Garantien, technische Verschlüsselung). Das ist nicht die Lösung des CLOUD Act-Problems — aber es zeigt Transparenz.

Nicht mehr erreichbar (bis Juli 2026):

BSI C5 Type II Attestierung: Das Verfahren dauert 6-12 Monate ab erstem Kontakt mit dem Auditor. Selbst wenn Sie heute beginnen: Das Attestierungsdatum wird nach Juli 2026 liegen.

ISO 27001-Erstzertifizierung (falls kein bestehendes ISMS): Realistisch 9-18 Monate. Ausnahme: Sie haben bereits ein gut dokumentiertes ISMS und benötigen nur die formale Auditierung — dann sind 4-6 Monate möglich.

Die Positionierung: Warum §17 ein Marktchance ist

Hier ist der strategische Aspekt den viele als reinen Compliance-Aufwand sehen:

KRITIS-Betreiber müssen ihre Lieferanten bis Juli 2026 bewerten. Das bedeutet: Sie werden aktiv nach ICT-Lieferanten suchen, die §17-konforme Nachweise liefern können. Wer diese Nachweise bereits hat, hat einen messbaren Wettbewerbsvorteil beim Neukundengewinn in der KRITIS-Zielgruppe.

Für EU-native SaaS-Anbieter die bereits BSI C5 oder ISO 27001 (DAkkS) haben und kein CLOUD Act-Problem dokumentieren müssen, ist der Vorteil noch größer: Sie können proaktiv auf KRITIS-Betreiber zugehen und §17-Konformität als Verkaufsargument nutzen — während US-Konkurrenten noch mit der CLOUD Act-Dokumentationsfrage kämpfen.

Praktisches Vorgehen für EU-native SaaS-Anbieter:

1. BSI C5 Type II jetzt starten (Zeitplanung: fertig Q1 2027 für Folgeverträge)
2. ISO 27001 (DAkkS) als Brückennachweis bis C5 fertig
3. §17-Konformitätserklärung als Marketing-Asset auf Website und in Vertriebsunterlagen
4. Proaktive Kontaktaufnahme mit KRITIS-Sektoren (besonders Energie, Gesundheit, öffentliche Verwaltung)

Checkliste: §17 KRITIS-DG Bereitschaftscheck

Verwenden Sie diese Checkliste als Selbsteinschätzung:

Grundvoraussetzungen:

• ISMS nach ISO 27001 implementiert (dokumentiert, nicht zwingend zertifiziert)
• Risikobewertung deckt KRITIS-relevante Bedrohungsszenarien ab
• Patch-Management-Prozess formalisiert mit messbaren SLAs
• Incident Response Plan enthält KRITIS-DG §28-konforme Notification-Timelines (4h)
• Vollständige Subprozessor-Liste mit Standorten aktuell (<6 Monate alt)

Nachweis-Dokumente:

• BSI C5 Type II ODER ISO 27001 (DAkkS) vorhanden
• Scope deckt KRITIS-relevanten Dienst explizit ab
• Penetrationstest-Bericht aktuell (<12 Monate, OWASP/BSI-Methodik)
• CLOUD Act-Risikoanalyse dokumentiert (EU-native: Freistellung dokumentieren)
• Datenlokalisierungs-Nachweis für EU-Kundendaten

Vertragliche Vorbereitung:

• DPA nach DSGVO Art. 28 angepasst für KRITIS-Kontext
• Auftragsdatenverarbeitungsvereinbarung enthält §17-Compliance-Pflichten
• SLA enthält explizite Verfügbarkeitsgarantien und Penalty-Klauseln
• Security Incident Notification max. 2h (besser: 1h) für kritische Vorfälle

Fazit: §17 ist kein Bürokratie-Akt — es ist strukturelle Marktverschiebung

§17 KRITIS-Dachgesetz verändert die Auswahlkriterien für ICT-Lieferanten kritischer Infrastruktur fundamental. Was bisher informelle Best Practice war — Sicherheitsnachweise, Penetrationstests, Datenlokalisierung — wird ab Juli 2026 rechtliche Mindestvoraussetzung für Vertragsbeziehungen mit KRITIS-Betreibern.

Die gute Nachricht für EU-native SaaS-Anbieter: Sie haben strukturelle Vorteile die US-Konkurrenten durch Compliance-Aufwand allein nicht einholen können. Kein CLOUD Act-Problem. Keine Subprozessor-Kette durch US-Hyperscaler. BSI C5 und ISO 27001 (DAkkS) als natürliche Heimvorteil-Zertifizierungen.

Die schlechte Nachricht für alle die noch nichts getan haben: Die Zeit bis Juli 2026 reicht nicht mehr für vollständige Zertifizierung. Fokussieren Sie auf das was noch geht — strukturiertes Gap-Assessment, dokumentierten Fahrplan, transparente CLOUD Act-Risikoanalyse. Das zeigt KRITIS-Betreibern, dass Sie die Anforderungen ernst nehmen und einen glaubwürdigen Weg zur vollen Konformität gehen.

Die nächsten Posts dieser Serie behandeln KRITIS-DG Supply Chain Compliance (#1311) und den EU KRITIS Stack — welche EU-nativen Alternativen KRITIS-Betreiber nutzen können um die §17-Nachweislast ihrer Lieferanten zu minimieren.

§17 KRITIS-Dachgesetz tritt mit dem Stichtag 17. Juli 2026 in Kraft. Alle Angaben in diesem Artikel basieren auf dem Stand BGBl. I 2024 und BSI-Veröffentlichungen vom Mai 2026. Für rechtsverbindliche Auslegung empfehlen wir qualifizierte Rechtsberatung.