KRITIS-Dachgesetz vs. NIS2: Was der Unterschied für B2B-SaaS-Anbieter bedeutet

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

"Wir haben NIS2 abgehakt — das reicht doch auch für KRITIS-DG, oder?" Diese Frage höre ich häufig von B2B-SaaS-Anbietern, die kritische Infrastruktur in Deutschland beliefern. Die Antwort ist: Nein, und der Unterschied ist fundamental.

NIS2 adressiert Betreiber wesentlicher Dienste — die Energieversorger, Kliniken und Verkehrsunternehmen selbst. Das KRITIS-Dachgesetz geht einen entscheidenden Schritt weiter: Mit §17 entsteht eine direkte Compliance-Pflicht auf Lieferantenseite. Als B2B-SaaS-Anbieter der kritische Infrastruktur beliefert sind Sie kein passiver Vertragspartner mehr — Sie werden zur regulierten Entität.

Dieser Post vergleicht NIS2 und KRITIS-DG strukturell, erklärt wo die Überschneidungen liegen, wo die echten Unterschiede sind, und was SaaS-Anbieter konkret bis zum 17. Juli 2026 tun müssen.

Die Architektur: Wie NIS2 und KRITIS-DG zusammenhängen

Bevor wir in die Unterschiede gehen, ist es wichtig das Verhältnis beider Regelwerke zu verstehen. Sie sind keine Konkurrenten — KRITIS-DG baut auf NIS2 auf und verschärft es für den deutschen Kontext.

NIS2: EU-Mindestrahmen für Betreiber

NIS2 (Richtlinie 2022/2555/EU) legt EU-weit Mindestsicherheitsanforderungen für Betreiber wesentlicher und wichtiger Einrichtungen fest. Die Richtlinie wurde in Deutschland durch das NIS2-Umsetzungsgesetz (NIS2UmsuCG) in nationales Recht überführt.

Kernprinzip NIS2: Die regulierte Entität ist der Betreiber des wesentlichen Dienstes. Der Betreiber muss sicherstellen, dass seine Lieferkette sicher ist — aber die Regelung richtet sich an ihn, nicht an seine Lieferanten direkt.

Art. 21 NIS2 fordert vom Betreiber unter anderem:

• Risikoanalyse und Sicherheitskonzepte
• Incident Response
• Business Continuity Management
• Lieferkettensicherheit (Art. 21 Abs. 2 lit. d)
• Sicherheit beim Erwerb, der Entwicklung und Wartung von IKT-Systemen

Der entscheidende Punkt bei Art. 21 Abs. 2 lit. d: Der Betreiber muss Lieferkettensicherheit gewährleisten. Das bedeutet in der Praxis: Er prüft seine SaaS-Anbieter. Aber die regulatorische Pflicht liegt beim Betreiber — nicht beim SaaS-Anbieter selbst.

KRITIS-DG: Deutsches Recht mit direkter Lieferantenhaftung

Das KRITIS-Dachgesetz (BGBl. I 2024, ausgefertigt 26. Juli 2024) geht konzeptionell weiter. §17 KRITIS-DG schafft direkte Sicherheitsanforderungen für kritische Komponenten und deren Hersteller/Lieferanten.

Kernprinzip KRITIS-DG §17: Hersteller und Anbieter kritischer Komponenten müssen den KRITIS-Betreibern auf Anfrage Sicherheitsnachweise vorlegen. Die Norm richtet sich an beide Seiten der Lieferbeziehung.

NIS2 vs. KRITIS-DG: Die Unterschiede im Detail

1. Wer ist die regulierte Entität?

2. Sektoren und Schwellenwerte

NIS2 und KRITIS-DG definieren Sektoren unterschiedlich und verwenden unterschiedliche Schwellenwerte.

NIS2 Sektoren (Anhang I + II):

• Energie, Transport, Bankwesen, Finanzmarktinfrastruktur
• Gesundheit, Trinkwasser, Abwasser
• Digitale Infrastruktur, IKT-Dienstleistungen (B2B)
• Öffentliche Verwaltung, Weltraum
• Schwellenwert: Mittlere Unternehmen (>50 MA oder >€10M Umsatz) in wesentlichen Sektoren

KRITIS-DG kritische Sektoren (§2 KRITIS-DG):

• Energie, Wasser/Abwasser, Transport/Verkehr
• Gesundheit, digitale Infrastruktur, Raumfahrt
• Ernährung, öffentliche Verwaltung, Siedlungsabfallentsorgung
• Schwellenwert: Anlage-basiert (spezifische Versorgungskapazitäten pro Sektor)

Wichtiger Unterschied: KRITIS-DG verwendet anlagebasierte Schwellenwerte statt Unternehmensgröße. Ein kleines Wasserwerk das 500.000 Menschen versorgt fällt unter KRITIS-DG — ein großes Tech-Unternehmen mit 10.000 Mitarbeitern aber ohne kritische Anlagen nicht.

3. Die §17-Sicherheitsnachweispflicht: Kein NIS2-Äquivalent

Das ist der fundamentale Unterschied für B2B-SaaS-Anbieter.

NIS2 Lieferkettensicherheit (Art. 21 Abs. 2 lit. d):

Verpflichteter: BETREIBER
Pflicht: Sicherheit in der Lieferkette, 
         einschließlich sicherheitsbezogener 
         Aspekte der Beziehungen zwischen 
         jedem Einrichtung und ihren 
         unmittelbaren Anbietern
Konsequenz für SaaS-Anbieter: Kein direkter 
  Regulierungsadressat. Prüfung nur über 
  Betreiber-Anfragen (vertraglich).

KRITIS-DG §17 (Sicherheit kritischer Komponenten):

Verpflichteter: HERSTELLER/LIEFERANT kritischer 
                Komponenten (direkt!)
Pflicht: Auf Anfrage des Betreibers einen 
         Nachweis über die Sicherheit ihrer 
         kritischen Komponenten zu erbringen
         
Nachweis-Instrumente (§17 Abs. 2):
- BSI C5 Typ II Testat
- ISO/IEC 27001 Zertifizierung
- SOC 2 Typ II (mit Einschränkungen)
- BSI-Prüfung (§18 KRITIS-DG)

Konsequenz für SaaS-Anbieter: Direkte 
  Regulierungspflicht — kein Umweg über 
  den Betreiber.

4. Was ist eine "kritische Komponente"?

§2 Abs. 18 KRITIS-DG definiert kritische Komponenten als Hard- und Software sowie IKT-Dienstleistungen, die wesentliche Funktion für den Betrieb einer kritischen Anlage erfüllen.

Für SaaS-Anbieter relevant:

• Wesentliche Funktion = direkter Einfluss auf Verfügbarkeit, Integrität oder Authentizität des KRITIS-Betriebs
• Beispiele: SCADA-Monitoring-SaaS, ITSM für kritische Systeme, Identitätsmanagementsysteme für Anlagenbetreiber, SIEM/SOC-as-a-Service für Energie- oder Gesundheitsinfrastruktur
• Nicht per se erfasst: HR-Software, Buchhaltungs-SaaS, allgemeine Kommunikationstools (sofern keine Verbindung zu Betriebsabläufen)

Die Grenze ist in der Praxis fließend. Als Faustregel gilt: Wenn Ihr SaaS-Produkt in einem Sicherheits- oder Betriebskonzept eines KRITIS-Betreibers als systemrelevant auftaucht, sollten Sie von einer Einstufung als kritische Komponente ausgehen.

Was B2B-SaaS-Anbieter konkret anders machen müssen als bei NIS2

Szenario 1: SaaS-Anbieter ist nur unter NIS2 tätig

Wenn Ihr Unternehmen selbst ein wesentlicher IKT-Dienstleister im Sinne von NIS2 Anhang I Punkt 8 ist (Cloud-Provider, Rechenzentrum, Content Delivery Network, DNS-Anbieter, TLD-Register, OES), müssen Sie NIS2-Pflichten direkt erfüllen. Das umfasst:

• Registrierung bei BSI (Deutschland)
• Risikomanagement nach Art. 21
• Meldepflichten (Art. 23): 24h Early Warning, 72h Incident Report, 1 Monat Final Report
• Sicherheitsmaßnahmen technisch und organisatorisch

Szenario 2: SaaS-Anbieter beliefert KRITIS-Betreiber (§17 KRITIS-DG)

Das ist der neue Bereich den NIS2 nicht abdeckt. Zusätzlich zu NIS2 (wenn anwendbar) gilt:

Pflicht 1: Sicherheitsnachweis auf Anfrage

Sie müssen in der Lage sein, auf Anfrage eines KRITIS-Betreibers einen qualifizierten Sicherheitsnachweis zu erbringen. "Auf Anfrage" klingt passiv — aber in der Praxis bedeutet das: Sie brauchen den Nachweis bevor Sie ihn brauchen, nicht danach.

Akzeptierte Nachweisformen nach §17 Abs. 2:

1. BSI C5 Typ II (bevorzugt für Cloud/SaaS-Anbieter in Deutschland)
2. ISO/IEC 27001 (international anerkannt, aber weniger KRITIS-spezifisch)
3. SOC 2 Typ II (US-Standard, in DE eingeschränkt anerkannt — kein vollständiges Äquivalent)
4. BSI-eigene Prüfung nach §18 (für Komponenten ohne passenden Standard)

Pflicht 2: Sicherheitspolitik für die Lieferkette

§17 Abs. 3 KRITIS-DG verlangt vom Betreiber, Maßnahmen zur Lieferkettensicherheit zu ergreifen — das schlägt direkt auf die Vertragsbeziehungen durch. Betreiber werden Sicherheitsklauseln in ihre SaaS-Verträge aufnehmen, die explizit auf §17 Bezug nehmen.

Pflicht 3: Keine CLOUD Act-Unterwerfung für kritische Daten

Das ist der Punkt wo US-SaaS strukturell scheitert. §17 KRITIS-DG erfordert implizit, dass kritische Betriebsdaten nicht dem Zugriff ausländischer Behörden unterliegen. Ein US-SaaS-Anbieter unter dem CLOUD Act kann diese Anforderung nicht erfüllen — unabhängig von Rechenzentrumsstandort oder vertraglichen Zusagen.

Der CLOUD Act im KRITIS-Kontext: Warum EU-Rechenzentren nicht reichen

Der Kern des Problems: CLOUD Act (18 U.S.C. §2713) verpflichtet US-Anbieter, gespeicherte Kommunikation und Daten auf richterliche Anordnung herausgeben — unabhängig vom Speicherort.

Für KRITIS-nahe Daten bedeutet das:

Die NIS2-Konformität eines US-SaaS-Anbieters (z.B. ISO 27001 Zertifikat) löst dieses strukturelle Problem nicht. Das Zertifikat beschreibt interne Sicherheitspraktiken — nicht die externe Abschirmung vor US-Behörden.

Was BSI dazu sagt

Das BSI hat in seinem C5-Kriterienkatalog (C5:2020) unter Kriterium PS-08 explizit aufgeführt, dass Subdienstleister und deren rechtliche Rahmenbedingungen Teil des Prüfumfangs sind. US-SaaS-Anbieter die BSI C5 anstreben, müssen erklären wie sie mit CLOUD-Act-Anfragen umgehen — und "wir bestreiten vor US-Gerichten" ist keine ausreichende Antwort.

Praxis-Vergleich: NIS2-Checkliste vs. KRITIS-DG-Checkliste für SaaS-Anbieter

NIS2-Pflichten (für wesentliche/wichtige Einrichtungen oder deren direkte Lieferanten im IKT-Sektor)

KRITIS-DG-Zusatzpflichten (§17 für ICT-Lieferanten)

Drei Szenarien: Wie KRITIS-DG §17 in der Praxis trifft

Szenario A: ITSM-SaaS für Energieversorger

Situation: Ein deutsches Energieversorgungsunternehmen (KRITIS-Betreiber) nutzt ServiceNow für Incident-Management seiner Energieanlagen.

NIS2: ServiceNow muss als Subdienstleister in der Lieferkettensicherheit des Betreibers berücksichtigt werden. Der Betreiber trägt die Compliance-Last.

KRITIS-DG §17: ServiceNow ist eine kritische Komponente — Incident-Tickets dokumentieren Vorfälle an KRITIS-Anlagen. ServiceNow muss auf Anfrage einen §17-konformen Sicherheitsnachweis erbringen. Da ServiceNow ein US-Unternehmen ist (Delaware C-Corp), unterliegt es dem CLOUD Act — das ist ein §17-Problem das sich nicht wegzertifizieren lässt.

Ausweg: EU-native ITSM-Lösungen (Jira Service Management on-premises, Matrix42, OTRS) oder ServiceNow mit schriftlicher CLOUD Act-Risikoakzeptanz durch den Betreiber (rechtlich und regulatorisch fragwürdig).

Szenario B: IAM/SSO-SaaS für Krankenhausgruppe

Situation: Eine Krankenhausgruppe (KRITIS-Betreiber Sektor Gesundheit) nutzt Okta für Identitäts- und Zugriffsmanagement.

NIS2: Okta muss als kritischer Lieferant im ISMS des Krankenhauses dokumentiert sein.

KRITIS-DG §17: Okta verwaltet Zugangsdaten zu medizinischen Systemen und Patientendaten. CLOUD Act Exposition: Okta (Delaware C-Corp, San Francisco) könnte per NSL oder richterlicher Anordnung zur Herausgabe von Zugangsdaten und IAM-Logs verpflichtet werden — das sind die Schlüssel zu KRITIS-Anlagen.

Ausweg: Keycloak (Red Hat, open source), Microsoft Entra (mit expliziter EU-Daten-Grenze, aber weiterhin CLOUD Act exponiert), Cidaas (DE, BSI-zertifiziert).

Szenario C: SaaS-Entwicklungsplattform für Wasserversorger

Situation: Ein kommunaler Wasserversorger (KRITIS-Betreiber) nutzt GitHub/GitLab für den Quellcode seiner SCADA-Schnittstellen.

NIS2: Quellcode-Repositories als Teil der Entwicklungssicherheit (Art. 21 Abs. 2 lit. e).

KRITIS-DG §17: Quellcode von SCADA-Schnittstellen ist eine kritische Komponente. GitHub (Microsoft Corp., Redmond WA) unterliegt dem CLOUD Act. US-Behörden könnten den Quellcode kritischer Wasserinfrastruktur anfordern.

Ausweg: GitLab CE self-hosted, Forgejo/Gitea on-premises, oder Codeberg (DE, gemeinnützig).

Zeitplan bis 17. Juli 2026: Was SaaS-Anbieter jetzt tun müssen

Mit heute (26. Mai 2026) bleiben noch 52 Tage bis zum KRITIS-DG Inkrafttreten.

In den nächsten 4 Wochen (bis 23. Juni)

1. Kritische-Komponenten-Analyse: Prüfen Sie für jeden Ihrer Kunden: Sind das KRITIS-Betreiber? Wird Ihr Produkt für kritische Anlagen eingesetzt? Führen Sie eine interne Liste und kategorisieren Sie Ihren Kundenstamm.

Fragen die Sie beantworten müssen:

• Haben wir Kunden in Energie, Wasser, Transport, Gesundheit, digitale Infrastruktur?
• Wird unser Produkt in operativen (OT/IT-Schnittstellen) oder sicherheitsrelevanten (IAM, SIEM, ITSM) Prozessen eingesetzt?
• Haben Kunden explizit auf KRITIS-Relevanz hingewiesen?

2. Sicherheitsnachweis-Gap-Analyse: Welche Zertifikate haben Sie heute?

• ISO 27001? → Gut, aber nicht ausreichend für §17 KRITIS-DG allein
• BSI C5? → Optimal für deutschen Markt
• SOC 2 Typ II? → Eingeschränkt anerkannt in DE
• Keine? → Kritisch — BSI C5 Audit starten (dauert 3-6 Monate, Sie kommen nicht rechtzeitig fertig)

3. CLOUD Act-Exposure prüfen:

• Wo ist Ihr Unternehmen inkorporiert?
• Wo sind Ihre US-Muttergesellschaft, US-Tochtergesellschaften?
• Welche US-Subdienstleister nutzen Sie für KRITIS-Kundendaten?

In der letzten Woche vor dem 17. Juli

1. Kommunikation an KRITIS-Kunden: Schreiben Sie Ihren KRITIS-Betreiber-Kunden proaktiv:

• Welche §17-Nachweise Sie erbringen können
• Wie Sie mit CLOUD-Act-Anfragen umgehen
• Ob Sie als kritische Komponente eingestuft sind (oder ob Sie das für unklar halten)

2. Vertragsnachträge: Fügen Sie in neue und bestehende Verträge mit KRITIS-Betreibern eine §17-Klausel ein:

"Der Auftragnehmer verpflichtet sich, auf Anforderung des Auftraggebers 
einen §17 KRITIS-DG-konformen Sicherheitsnachweis vorzulegen. 
Als Nachweis gilt: [BSI C5 Typ II / ISO 27001 + ergänzende Prüfung / 
gemäß §18 KRITIS-DG]."

3. Incident-Response-Planung: Klären Sie mit KRITIS-Kunden: Was passiert wenn Ihr SaaS-Dienst für kritische Anlagen ausfällt? Ist das ein KRITIS-DG Meldepflicht-Incident? Wer meldet was an wen?

EU-native Alternativen: Compliance by Architecture

Die sauberste Lösung für KRITIS-exponierten B2B-SaaS ist EU-nativer Stack. Kein CLOUD Act, keine US-Incorporation, volle GDPR-Konformität.

sota.io ist explizit für diesen Use Case gebaut: EU-Hosting, keine US-Muttergesellschaft, keine CLOUD Act Exposition. Wenn Sie KRITIS-Betreiber als Kunden haben und nach einer PaaS-Lösung suchen die §17-kompatibel ist, ist das der direkte Weg.

Die Prüffragen für Ihr KRITIS-Compliance-Assessment

Bevor der 17. Juli ankommt, sollten Sie diese Fragen beantworten können:

Frage 1: Sind meine Kunden KRITIS-Betreiber? Prüfen Sie: In welchen Sektoren sind Ihre Kunden tätig? Betreiben sie kritische Anlagen nach KRITIS-DG §2?

Frage 2: Ist mein Produkt eine kritische Komponente? Kriterium: Wesentliche Funktion für den Betrieb einer kritischen Anlage. Zweifeln Sie im Zweifelsfall auf der sicheren Seite.

Frage 3: Kann ich einen §17-Nachweis erbringen? Akzeptable Nachweise: BSI C5 Typ II, ISO 27001 + ergänzende KRITIS-spezifische Prüfung, BSI §18-Prüfung.

Frage 4: Habe ich CLOUD Act-Exposition? Prüfen Sie Ihre Incorporation, US-Subdienstleister, US-Parent-Company. Wenn ja: strukturelle Lösung oder schriftliche Risikoakzeptanz durch den Betreiber.

Frage 5: Haben meine KRITIS-Kunden-Verträge §17-Klauseln? Falls nein: Nachrüsten bevor der Betreiber eine Anforderung stellt.

Fazit: NIS2 ist die Pflicht, KRITIS-DG ist die Kür — aber die Kür ist jetzt Pflicht

NIS2 und KRITIS-DG lösen zwei verschiedene Probleme:

• NIS2 setzt EU-weit den Mindestsicherheitsrahmen für Betreiber kritischer Dienste. Wer NIS2 erfüllt hat eine solide Basis — aber nichts mehr.

• KRITIS-DG §17 macht Sie als Lieferant zum direkten Regulierungsadressaten. Das ist konzeptionell neu im deutschen Recht und hat keine direkte NIS2-Entsprechung.

Für B2B-SaaS-Anbieter mit KRITIS-Betreiber-Kunden in Deutschland ist das Fazit klar:

1. NIS2 allein reicht nicht aus — §17 KRITIS-DG schafft zusätzliche, direkte Pflichten
2. BSI C5 Typ II ist der effizienteste Weg zum §17-konformen Nachweis
3. CLOUD Act-Exposition ist ein strukturelles Problem das durch Zertifikate nicht gelöst wird
4. Die Frist ist der 17. Juli 2026 — 52 Tage. Ein BSI C5 Audit dauert 3-6 Monate. Wer jetzt nicht anfängt, wird am Stichtag nicht fertig.

Wenn Sie EU-native SaaS als §17-kompatible Alternative für Ihre KRITIS-exponierten Kunden suchen: sota.io — gebaut in Deutschland, betrieben in Deutschland, ohne CLOUD Act Exposition.

Weitere Posts in dieser Serie:

• Post #1: KRITIS-Dachgesetz 2026: CLOUD Act Risiken für SaaS im kritischen Infrastruktur-Umfeld
• Post #3: §17 Sicherheitsnachweis Step-by-Step für ICT-Lieferanten (erscheint demnächst)
• Post #4: KRITIS-DG Supply Chain Compliance 2026 (erscheint demnächst)
• Post #5: EU KRITIS Stack — EU-native Alternativen im Vergleich (erscheint demnächst)