Die NIS-2-Richtlinie der Europäischen Union (Richtlinie (EU) 2022/2555 vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union) sei ein Beispiel dafür, wie weit politische Erwartung und operative Realität in der EU-Compliance-Welt auseinanderdriften könnten. Der ursprüngliche Umsetzungs-Termin in nationales Recht (17. Oktober 2024) sei in mehreren Mitgliedstaaten — Deutschland eingeschlossen — überschritten worden; das deutsche NIS-2-Umsetzungs- und Cybersicherheits-Stärkungs-Gesetz (NIS2UmsuCG) sei nach einem mehrjährigen Gesetzgebungs-Prozess erst Anfang 2025 in Kraft getreten. Im Frühjahr 2026 sei die Frage daher nicht mehr, ob NIS-2 die deutsche Hosting-Welt erreicht habe, sondern wie sie sich operativ niedergeschlagen habe.

Wen NIS-2 trifft

Die Richtlinie unterscheide zwei Kategorien: „wesentliche Einrichtungen” (essential entities) und „wichtige Einrichtungen” (important entities). Für die Hosting-Welt seien beide Kategorien relevant:

• Wesentliche Einrichtungen umfassten unter anderem Anbieter:innen öffentlich zugänglicher elektronischer Kommunikationsdienste, Anbieter:innen vertrauenswürdiger Dienste (eIDAS), TLD-Name-Registries, DNS-Diensteanbieter:innen sowie Cloud-Computing-Diensteanbieter:innen oberhalb bestimmter Schwellenwerte.
• Wichtige Einrichtungen umfassten unter anderem Anbieter:innen von Rechenzentrumsdiensten, Content-Delivery-Network-Anbieter:innen und Anbieter:innen verwalteter Dienste (Managed Services).

Die deutschen Schwellenwerte (über das NIS2UmsuCG in die Praxis übersetzt) orientierten sich an den EU-Standardgrößen: 50 Mitarbeitende und mehr als 10 Millionen Euro Jahresumsatz für die „wichtigen Einrichtungen”, 250 Mitarbeitende und mehr als 50 Millionen Euro für die „wesentlichen”. Für die deutsche Hosting-Mittelschicht heiße das praktisch: Die meisten etablierten Anbieter:innen fielen mindestens in die Kategorie der wichtigen Einrichtungen, ein erheblicher Teil sogar in die Wesentlich-Kategorie.

Die Frage „Sind wir NIS-2-pflichtig?” sei in der Hosting-Branche im Stand 2026 weitgehend abgearbeitet — die Frage „Wie genau setzen wir das im Alltag um?” sei es nicht.

Die zentralen Pflichten

Die NIS-2-Pflichten ließen sich in vier Blöcke gruppieren:

Risikomanagement-Maßnahmen (Art. 21 der Richtlinie): Eine technisch-organisatorische Cybersecurity-Architektur mit Risiko-Analyse, Incident-Handling, Business-Continuity, Lieferketten-Sicherheit, Schwachstellen-Behandlung, Wirksamkeits-Bewertung, Hygiene-Praktiken, Verschlüsselung-Architektur, Personalsicherheit, Zutritts- und Asset-Management. Der Katalog sei breit und bewusst ergebnisoffen formuliert — was im Einzelfall angemessen sei, hänge von Größe und Risiko-Profil der Einrichtung ab.

Meldepflichten (Art. 23): Erheblicher Sicherheitsvorfall — Frühwarnung innerhalb von 24 Stunden, Vorfalls-Meldung innerhalb von 72 Stunden, Abschluss-Bericht innerhalb eines Monats. Diese Fristen seien deutlich enger als die DSGVO-Meldepflicht (Art. 33 DSGVO mit 72 Stunden) und in der praktischen Anwendung eine der größten Reibungspunkte zwischen Compliance-Anspruch und operativer Realität.

Geschäftsleitung-Verantwortung (Art. 20): Die Geschäftsleitung der Einrichtung sei persönlich für die Genehmigung und Überwachung der NIS-2-Maßnahmen verantwortlich. Geschäftsleiter:innen müssten an Schulungen teilnehmen und entsprechende Kenntnisse vorweisen. Bei Verstößen drohten persönliche Haftungs-Folgen — ein Aspekt, der die Compliance-Diskussion in vielen mittelständischen Hosting-Unternehmen schlagartig beschleunigt habe.

Sanktionsrahmen (Art. 34): Bußgelder bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes für wesentliche Einrichtungen, bis zu 7 Millionen Euro oder 1,4 Prozent für wichtige Einrichtungen. Diese Größenordnung sei bewusst an die DSGVO-Bußgelder angelehnt und schaffe eine vergleichbare Drohkulisse.

Die KRITIS-Architektur des BSI

Vor NIS-2 habe die deutsche Cybersecurity-Architektur in der KRITIS-Welt (Kritische Infrastruktur nach BSI-Gesetz und BSI-Kritis-Verordnung) ihren Schwerpunkt gehabt. Die KRITIS-Verordnung des BSI definiere für die einzelnen Sektoren (Energie, Wasser, Ernährung, IT/TK, Gesundheit, Finanz, Transport, Verkehr, Siedlungsabfall, Staat) Schwellenwerte, oberhalb derer eine Anlage als „kritische Infrastruktur” gelte und entsprechenden BSI-Pflichten unterliege.

Für die Hosting-Welt seien insbesondere die IT/TK-Schwellenwerte relevant: Rechenzentren mit einer durchschnittlich vertraglich vereinbarten Leistung von 3,5 Megawatt und mehr fielen unter die KRITIS-Verordnung; Domain-Registrare ab einer bestimmten Anzahl verwalteter Domains; DNS-Resolver-Anbieter:innen oberhalb bestimmter Anfrage-Volumina.

Die Interaktion zwischen KRITIS und NIS-2 sei nicht trivial. Das NIS2UmsuCG habe versucht, die beiden Welten in ein gemeinsames System zu überführen, mit einem erweiterten BSI-Aufsichts-Rahmen und harmonisierten Melde-Verfahren. In der Praxis kämpften viele Compliance-Abteilungen weiterhin damit, welche Pflicht aus welcher Quelle stamme, welche Behörde welche Meldung erwarte und in welcher Reihenfolge die Sicherheits-Architekturen aufzubauen seien.

Die AVV-Frage in Hosting-Verträgen

Auf einer anderen Ebene interagiere NIS-2 mit der DSGVO. Die Auftragsverarbeitungs-Vereinbarung (AVV) nach Art. 28 DSGVO sei für Hosting-Anbieter:innen die zentrale Rechtsgrundlage gegenüber ihren Kund:innen, sobald diese personenbezogene Daten auf dem Hosting-Stack verarbeiten — was praktisch jede Web-Site, jede Datenbank, jede Mailbox einschließe.

Die NIS-2-Pflichten flössen in die AVV-Praxis auf zwei Ebenen ein. Erstens müssten Hosting-Anbieter:innen ihre Sub-Auftragsverarbeiter (Datacenter-Provider, Backup-Anbieter, Monitoring-Dienste) auf NIS-2-Konformität prüfen und in der Vertrags-Kette absichern. Zweitens müsse die Vorfalls-Melde-Architektur zwischen Hoster und Kund:in im AVV-Vertrag so geregelt sein, dass die DSGVO-Frist (72 Stunden gegenüber der Aufsichtsbehörde, ggf. unverzügliche Mitteilung an Betroffene) und die NIS-2-Frist (24 Stunden Frühwarnung, 72 Stunden Vorfalls-Meldung) beide eingehalten werden könnten.

In der Praxis bedeute das: AVV-Vorlagen, die vor 2025 erstellt worden seien, müssten in den meisten Fällen überarbeitet werden. Mehrere Branchen-Verbände (eco Verband der Internetwirtschaft, BITKOM, EuroCloud) hätten Muster-Vorlagen mit NIS-2-Anpassungen veröffentlicht, die im Stand 2026 in der mittelständischen Hosting-Welt breit eingesetzt würden.

Die Schrems-II- und TADPF-Schicht

Eine dritte Compliance-Schicht, die mit NIS-2 interagiere, sei die Drittstaaten-Daten-Übermittlung. Das EuGH-Urteil Schrems II (16. Juli 2020, C-311/18) habe den Privacy-Shield gekippt; das Trans-Atlantic Data Privacy Framework (TADPF) sei seit dem 10. Juli 2023 die Ersatz-Konstruktion, gegen die eine erneute EuGH-Klage des Schrems-Lagers bereits anhängig sei.

Für die NIS-2-Praxis heiße das konkret: Wer als deutscher Hosting-Anbieter US-Cloud-Komponenten in seinen Stack einbinde (klassisch: AWS-S3 für Backups, Cloudflare für DDoS-Schutz, Datadog für Monitoring, GitHub für Source-Repos), der müsse diese Übermittlungen sowohl unter DSGVO-Standards (TADPF oder Standardvertragsklauseln plus Transfer-Impact-Assessment) als auch unter NIS-2-Lieferketten-Sicherheitspflichten dokumentieren. Die Verzahnung sei in der Beratungs-Praxis aufwendig, in der internen Compliance-Praxis vieler Hosting-Anbieter ein anhaltender Reibungspunkt.

Die Frage, ob ein US-Cloud-Service in einem deutschen Hosting-Stack „NIS-2-tauglich” sei, lasse sich nicht binär beantworten. Sie hänge von der konkreten Vertragsgestaltung, der Risiko-Architektur und der Lieferketten-Dokumentation ab.

Die Aufsichts-Praxis 2026

Die zuständige Aufsichtsbehörde für NIS-2 sei in Deutschland das BSI (Bundesamt für Sicherheit in der Informationstechnik), für bestimmte Sektoren ergänzt um Sektor-spezifische Behörden (BNetzA für TK-Anbieter, BaFin für Finanzsektor). Die Aufsichts-Praxis des ersten anwendbaren Jahres (2025) habe sich nach übereinstimmenden Branchen-Berichten als zurückhaltend gezeigt — das BSI habe vorrangig auf Registrierungs-Vollständigkeit, auf Vorfalls-Melde-Disziplin und auf grundlegende Risiko-Management-Architekturen geschaut, ohne in die Detail-Tiefe einzelner technischer Maßnahmen einzusteigen.

Diese Zurückhaltung dürfte sich im Lauf des Jahres 2026 ändern. Mehrere Branchen-Stimmen erwarteten, dass das BSI im zweiten und dritten Jahr der NIS-2-Anwendbarkeit gezieltere Audits durchführen werde, möglicherweise mit sektor-spezifischen Schwerpunkten. Die ersten größeren NIS-2-Bußgeld-Verfahren in anderen EU-Mitgliedstaaten (insbesondere in den Niederlanden und in Italien) deuteten an, dass die Aufsichts-Behörden europaweit allmählich von der Aufbau- in eine Durchsetzungs-Phase überträten.

Die ISO-27001-Brücke

Eine pragmatische Frage, die die Hosting-Praxis seit dem Inkrafttreten von NIS-2 beschäftige, sei das Verhältnis zu bestehenden Sicherheits-Standards. ISO 27001 (mit der grundlegenden Überarbeitung 2022 und der ergänzenden ISO 27002:2022 als Maßnahmen-Katalog) sei in der Hosting-Branche der mit Abstand am weitesten verbreitete Zertifizierungs-Standard; viele Anbieter:innen seien seit Jahren zertifiziert und führten ein eingespieltes Informations-Sicherheits-Management-System (ISMS) nach den entsprechenden Annex-A-Controls.

Die operativ relevante Frage lautete daher in vielen Hosting-Anwesen 2024 und 2025: In welchem Maß könnten die NIS-2-Pflichten aus dem bestehenden ISO-27001-Stack abgeleitet werden? Die Antwort der Branchen-Beratungs-Praxis sei differenziert: Die Risikomanagement-Architektur und die technisch-organisatorischen Maßnahmen nach Art. 21 NIS-2 ließen sich in weiten Teilen aus einem ISO-27001-konformen ISMS heraus bedienen. Die spezifische NIS-2-Vorfalls-Melde-Architektur, die Geschäftsleitung-Persönlich-Pflichten und die Lieferketten-Dokumentation gingen aber über ISO 27001 hinaus und erforderten ergänzende Prozesse.

Mehrere Branchen-Verbände hätten in den vergangenen Monaten Mapping-Tabellen veröffentlicht, die die NIS-2-Anforderungen auf die ISO-27001-Annex-A-Controls und auf den BSI-IT-Grundschutz herunterbrächen. Diese Mappings seien in der Praxis hilfreich, ersetzten aber nicht die einzelfallbezogene rechtliche Bewertung, ob die konkrete Compliance-Architektur eines Unternehmens den NIS-2-Anforderungen genüge.

Die CRA-Schicht für Software-Komponenten

Ergänzend zu NIS-2 sei eine zweite EU-Verordnung in die Hosting-Praxis eingezogen: der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847). Während NIS-2 die organisatorische Cybersecurity der Anbieter:innen adressiere, ziele der CRA auf die Sicherheits-Anforderungen an Produkte mit digitalen Elementen — also auf die Software- und Hardware-Komponenten, die in den Hosting-Stack eingebaut würden.

Für die Hosting-Welt habe der CRA eine zwiespältige Wirkung. Auf der einen Seite verbessere er die Sicherheits-Verantwortung der Software-Hersteller:innen entlang der Lieferkette — was die NIS-2-Lieferketten-Pflichten der Hosting-Anbieter:innen indirekt erleichtere. Auf der anderen Seite habe der CRA in den vergangenen Jahren eine erhebliche Diskussion in der Open-Source-Welt ausgelöst — die Frage, wie kleinere Open-Source-Projekte mit den CRA-Anforderungen umgehen könnten, ohne die ehrenamtliche Maintainer-Basis zu überfordern, sei zwar in den finalen Verordnungs-Text eingeflossen, in der praktischen Auslegung aber noch nicht abschließend geklärt.

Die operative Bilanz

Wer in der deutschen Hosting-Welt im Frühjahr 2026 mit Compliance-Verantwortlichen spreche, höre eine wiederkehrende Beobachtung: NIS-2 sei in der Vorbereitungs-Phase überschätzt und in der operativen Phase unterschätzt worden. Die großen Architektur-Diskussionen der Jahre 2023 und 2024 (welcher Standard? welcher Risiko-Rahmen? welche ISO-27001-Brücke?) hätten sich in der Praxis als handhabbar erwiesen. Was sich als anstrengender herausstelle, sei die kontinuierliche Pflege der Vorfalls-Melde-Disziplin, die Aktualität der Lieferketten-Dokumentation und die organisatorische Verankerung der Geschäftsleitung-Verantwortung.

Die Frage, ob NIS-2 die Cybersecurity-Lage der europäischen Hosting-Welt tatsächlich verbessert habe, sei seriös erst nach mehreren Anwendungs-Jahren zu beantworten. Die operative Wirkung — eine breitere Verankerung des Risikomanagements in der mittelständischen Hosting-Welt — sei im Stand 2026 jedenfalls sichtbar. Ob das gegen die Bedrohungs-Realität der Mitte des Jahrzehnts (Ransomware-Wellen, Supply-Chain-Attacken, staatlich gestützte APT-Operationen) genüge, werde sich in den nächsten Jahren zeigen.