NIS2 für Cloud- und digitale Dienstleister: CIR-Pflichten und technische Anforderungen

Cloud-Anbieter, Managed Service Provider und Betreiber von Rechenzentren gehören zu den Einrichtungstypen, für die das NIS2-Regime besonders weitgehend europäisch vereinheitlicht ist. Während für die meisten NIS2-pflichtigen Unternehmen nationale Umsetzungsgesetze – in Deutschland das NIS2UmsuCG – den konkreten Rahmen setzen, gilt für bestimmte digitale Dienstleister zusätzlich ein unmittelbar anwendbarer EU-Rechtsakt: die Durchführungsverordnung (EU) 2024/2690 der Kommission (häufig als CIR abgekürzt). Als EU-Verordnung ist sie in jedem Mitgliedstaat direkt verbindlich – ohne nationalen Umsetzungsspielraum. Das bedeutet: Die technischen und methodischen Anforderungen an die Cybersicherheitsmaßnahmen sind für diese Anbieter europäisch einheitlich, unabhängig davon, wo ein Cloud-Anbieter ansässig ist oder seine Kunden betreut. Dieser Leitfaden erklärt, welche Unternehmen betroffen sind, welche Pflichten die CIR konkret auferlegt und was eine praxisgerechte Umsetzung bedeutet. Den übergeordneten Rahmen der technischen und organisatorischen Mindestanforderungen beschreiben die NIS2-Sicherheitsanforderungen.

Welche Cloud- und digitalen Dienstleister fallen unter NIS2?

Anders als oft dargestellt, fallen Cloud-Anbieter und die meisten anderen digitalen Dienstleister nicht unabhängig von ihrer Größe unter NIS2. Nach Artikel 2 Absatz 1 der NIS-2-Richtlinie (EU) 2022/2555 gilt die Richtlinie grundsätzlich für Einrichtungen der in Anhang I oder II genannten Art, die mindestens mittlere Unternehmen sind. Im deutschen BSIG (§ 28) bedeutet das in der Regel: mindestens 50 Beschäftigte oder ein Jahresumsatz und eine Jahresbilanzsumme von jeweils über 10 Millionen Euro. Größenunabhängig erfasst Artikel 2 Absatz 2 NIS2 unter den digitalen Diensten nur wenige Anbietertypen, darunter Vertrauensdiensteanbieter, TLD-Namenregister und DNS-Diensteanbieter. Die Durchführungsverordnung (EU) 2024/2690 gilt für die folgenden Anbietertypen – soweit nicht anders vermerkt, erst ab mittlerer Unternehmensgröße:

• Cloud-Computing-Dienstleister – Dienstmodelle wie IaaS (Infrastructure as a Service), PaaS (Platform as a Service) und SaaS (Software as a Service)
• Rechenzentrumsbetreiber (Anbieter von Rechenzentrumsdiensten, etwa Colocation)
• Anbieter von Content Delivery Networks (CDN)
• Managed Service Provider (MSP), die IT-Dienste für Dritte betreiben oder verwalten
• Managed Security Service Provider (MSSP), die Sicherheitsdienste wie Überwachung oder Incident-Response erbringen
• Anbieter von DNS-Diensten und Registrierungsstellen für Top-Level-Domains (TLD) – unabhängig von der Größe
• Online-Marktplätze, Online-Suchmaschinen und Social-Networking-Plattformen (Anhang II NIS2 bzw. Anlage 2 BSIG)
• Vertrauensdiensteanbieter (qualifiziert und nicht qualifiziert) im Sinne der eIDAS-Verordnung – unabhängig von der Größe

Die genaue Abgrenzung, ob ein Unternehmen als Cloud-Anbieter im Sinne von NIS2 gilt, richtet sich nach dem erbrachten Dienst – nicht nach der Rechtsform oder dem Unternehmensgegenstand. Ein Softwareunternehmen, das sein Produkt als SaaS betreibt, kann ebenfalls in den Anwendungsbereich fallen. Maßgeblich ist die Legaldefinition in Artikel 6 Nummer 30 NIS2 bzw. § 2 Nummer 4 BSIG: ein digitaler Dienst, der auf Abruf die Verwaltung und den umfassenden Fernzugang zu einem skalierbaren und elastischen Pool gemeinsam nutzbarer Rechenressourcen ermöglicht. Für die Dienst- und Bereitstellungsmodelle verweist Erwägungsgrund 33 der Richtlinie auf die Norm ISO/IEC 17788:2014. Einen vollständigen Überblick, welche Einrichtungen betroffen sind, bietet die NIS2-Betroffenheitsprüfung.

Ein häufiges Missverständnis: NIS2 gilt für Anbieter von Cloud-Diensten, nicht für Unternehmen, die Cloud-Dienste lediglich nutzen. Ein mittelständischer Fertigungsbetrieb, der Microsoft Azure als Kunde verwendet, unterliegt als Nutzer keiner gesonderten Cloud-spezifischen Pflicht – er unterliegt NIS2 gegebenenfalls aufgrund seines Sektors und seiner Größe, aber nicht aufgrund der Cloud-Nutzung. Die Cloud-spezifischen Pflichten treffen Azure, AWS, Google Cloud und vergleichbare Anbieter als Betreiber der Plattform.

Die CIR 2024/2690 – Direkt anwendbare EU-Verordnung ohne nationalen Spielraum

Artikel 21 Absatz 5 der NIS-2-Richtlinie verpflichtete die Europäische Kommission, bis zum 17. Oktober 2024 Durchführungsrechtsakte mit technischen und methodischen Anforderungen für bestimmte Einrichtungstypen zu erlassen. Dem ist die Kommission mit der Durchführungsverordnung (EU) 2024/2690 vom 17. Oktober 2024 nachgekommen. Die Verordnung legt für die in ihrem Artikel 1 abschließend genannten Anbietertypen (siehe Liste oben) in ihrem Anhang fest, welche konkreten Anforderungen die zehn Maßnahmen des Artikel 21 Absatz 2 Buchstaben a bis j NIS2 umfassen. Zusätzlich bestimmt sie auf Grundlage von Artikel 23 Absatz 11 NIS2, wann ein Sicherheitsvorfall bei diesen Anbietern als erheblich gilt.

Der entscheidende Unterschied zur NIS-2-Richtlinie selbst: Als EU-Verordnung gemäß Artikel 288 AEUV gilt die CIR in allen 27 Mitgliedstaaten unmittelbar und bedarf keiner nationalen Umsetzung. Während die NIS-2-Richtlinie in Deutschland durch das NIS2UmsuCG umgesetzt wurde und die Mitgliedstaaten beim „Wie“ der Umsetzung Gestaltungsspielraum hatten, lässt die CIR diesen Spielraum nicht zu. Ein Cloud-Anbieter mit Sitz in Deutschland, Irland oder Polen unterliegt denselben technischen und methodischen Anforderungen.

Die CIR tritt neben das nationale Umsetzungsrecht. Für Deutschland regelt § 30 Absatz 3 BSIG das Verhältnis ausdrücklich: Der nach Artikel 21 Absatz 5 Unterabsatz 1 NIS2 erlassene Durchführungsrechtsakt „hat für die vorgenannten Einrichtungsarten Vorrang“ vor den allgemeinen Vorgaben zu Risikomanagementmaßnahmen in § 30 BSIG. Registrierung, Meldepflichten und Geschäftsleitungspflichten (§ 38 BSIG) richten sich daneben weiter nach dem BSIG; Anforderungen aus beiden Rechtsquellen sind also gleichzeitig zu erfüllen. Die Wechselwirkungen zwischen Richtlinie, CIR und nationalem Recht erklärt der Artikel zur NIS2-Durchführungsverordnung im Detail.

Technische Mindestanforderungen für Cloud-Anbieter nach CIR

Der Anhang der CIR 2024/2690 gliedert seine Anforderungen in 13 Abschnitte, die den zehn Maßnahmen aus Artikel 21 Absatz 2 NIS2 zugeordnet sind. Cloud-spezifische Sonderregeln enthält er nicht. Die folgende Tabelle gibt einen Überblick – die rechte Spalte enthält Praxishinweise, keine ausdrücklichen Vorgaben der Verordnung:

Sicherheitsbereich (Art. 21 Abs. 2 NIS2)	CIR-Anforderung (Anhang, Kurzfassung)	Praxishinweis für Cloud-Anbieter
Risikoanalyse und Sicherheitsrichtlinien	Sicherheitskonzept und Risikomanagementrahmen (Nr. 1 und 2); Überprüfung mindestens jährlich (Nr. 1.1.2, 2.1.4); unabhängige Überprüfung (Nr. 2.3)	Risiken der gemeinsam genutzten Infrastruktur (Mandantentrennung) in die Risikobewertung einbeziehen
Behandlung von Sicherheitsvorfällen	Konzept, Protokollierung, Klassifizierung, Reaktion, Nachbereitung (Nr. 3)	Erheblichkeitsschwellen aus Art. 7 CIR im Klassifizierungsschema abbilden
Business Continuity und Krisenmanagement	Notfallplan, Backup- und Redundanzmanagement mit Wiederherstellungstests, Krisenmanagement (Nr. 4)	Geografisch verteilte Zonen als mögliche Umsetzung
Sicherheit der Lieferkette	Auswahlkriterien, vertragliche Sicherheitsanforderungen, Anbieterverzeichnis (Nr. 5)	MSP/MSSP: Sicherheitsanforderungen an Sub-Dienstleister vertraglich weitergeben
Sicherheit bei Beschaffung und Entwicklung	Sicherer Entwicklungszyklus, Patch-Management, Netzsegmentierung, Schwachstellenbehandlung (Nr. 6)	Hypervisor, Container-Plattformen und Basis-Images in das Patch-Management einbeziehen
Bewertung der Wirksamkeit von Sicherheitsmaßnahmen	Konzepte und Verfahren zur Wirksamkeitsbewertung (Nr. 7)	Externe Zertifizierung (z. B. ISO 27001, SOC 2) als möglicher Nachweisbaustein
Grundlegende Cyber-Hygiene	Sensibilisierung, grundlegende Cyberhygiene-Verfahren, Sicherheitsschulungen (Nr. 8)	Automatisiertes Patch-Deployment für Cloud-Infrastruktur kann die Umsetzung erleichtern
Kryptografie und Verschlüsselung	Kryptokonzept für gespeicherte und übermittelte Daten, Schlüsselmanagement, Krypto-Agilität (Nr. 9)	Mandantengetrennte Schlüsselverwaltung (BYOK/HYOK-Optionen) als bewährte Praxis
Personalsicherheit, Zugriffskontrolle und Asset-Management	Zuverlässigkeitsüberprüfung soweit durchführbar, Zugriffskonzept, Inventar (Nr. 10–12)	Dynamisches Asset-Management für skalierbare Cloud-Ressourcen
Multi-Faktor-Authentifizierung und gesicherte Kommunikation	Mehrfaktor- oder kontinuierliche Authentifizierung, soweit angemessen (Nr. 11.7)	MFA für alle administrativen Zugänge zur Plattform

Die Anforderungen sind risikobasiert anzuwenden: Nach Artikel 2 Absatz 2 CIR tragen die Einrichtungen dem Ausmaß ihrer Risikoexposition, ihrer Größe sowie der Wahrscheinlichkeit und Schwere von Sicherheitsvorfällen Rechnung. Sieht der Anhang eine Anforderung nur „soweit angemessen“ vor und hält eine Einrichtung sie für nicht anwendbar, muss sie die Begründung nachvollziehbar dokumentieren. Ein globaler Cloud-Hyperscaler mit Millionen von Kunden wird in praktisch allen Bereichen strengere interne Standards anlegen als ein regionaler Mittelklasse-Hostinganbieter – NIS2 und CIR verlangen genau diesen risikobasierten Ansatz.

Besondere Anforderungen für Cloud-Infrastruktur und Mehrmandantenbetrieb

Cloud-Infrastrukturen sind durch einen Konstruktionsgrundsatz geprägt, der besondere Sicherheitsherausforderungen mit sich bringt: Mehrmandantenfähigkeit (Multi-Tenancy). Viele Kunden teilen sich dieselbe physische und virtualisierte Infrastruktur. Eigene Multi-Tenancy-Vorschriften enthält die CIR nicht; aus ihren allgemeinen Vorgaben (etwa Nr. 4.2, 6.8, 9 und 11) ergeben sich in Verbindung mit der Risikobewertung jedoch typische Schwerpunkte:

Datenisolation zwischen Mandanten

In der Praxis sollten Cloud-Anbieter sicherstellen, dass kein Mandant auf Daten, Konfigurationen oder Netzwerkverkehr anderer Mandanten zugreifen kann. Das umfasst:

• Hypervisor-Isolation: Strikte Trennung virtueller Maschinen auf physischer Ebene; keine seitlichen Bewegungen (Lateral Movement) über Hypervisor-Schwachstellen
• Netzwerksegmentierung: Mandantengetrennte virtuelle Netzwerke (VPC/VLANs), keine ungewollten Routing-Pfade zwischen Tenants
• Storage-Isolation: Sichere Löschung von Speicherbereichen bei Mandantenwechsel; keine Residualdaten auf wiederverwendeten Speichermedien
• Container-Isolation: Für PaaS-Plattformen: Namespacing, cGroup-Grenzen und Security Policies (AppArmor/SELinux) für Container

Geografische Redundanz und Verfügbarkeit

Die CIR verlangt Notfall- und Sicherungspläne mit Wiederherstellungszielen und -zeiten (Nr. 4.1.2, 4.2.2), in der Praxis meist als Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) definiert. Sicherungskopien sind außerhalb des Systemnetzes und ausreichend weit vom Hauptstandort entfernt aufzubewahren; zudem ist eine zumindest teilweise Redundanz von Systemen, Betriebsstätten, Personal und Kommunikationskanälen vorgesehen (Nr. 4.2.4). Für kritische Dienste bietet sich Redundanz über mehrere geografische Zonen an. Wiederherstellungen sind regelmäßig zu testen (Nr. 4.2.6) – Sicherungen also nicht nur zu erstellen, sondern auch tatsächlich zurückzuspielen.

Schlüsselverwaltung und Verschlüsselung

Die CIR verlangt ein Kryptokonzept einschließlich Schlüsselmanagement (Nr. 9.2). Eine mandantengetrennte Schlüsselverwaltung – etwa per Bring Your Own Key (BYOK) oder Hold Your Own Key (HYOK) – schreibt sie nicht ausdrücklich vor; für Cloud-Anbieter mit höherer Risikoeinstufung ist sie aber eine naheliegende Umsetzung. Konkrete Protokollversionen nennt die CIR nicht; Orientierung zum Einsatz von TLS bietet in Deutschland die Technische Richtlinie BSI TR-02102-2.

MSP und MSSP: Besondere Bedeutung der Lieferkettenposition

Managed Service Provider und Managed Security Service Provider nehmen in der digitalen Lieferkette eine besondere Stellung ein: Sie haben technischen Zugriff auf Systeme und Daten ihrer Kunden und erbringen Dienste, die oft tief in die IT-Infrastruktur der betreuten Unternehmen integriert sind. Rechtlich gelten für sie dieselben CIR-Anforderungen wie für andere erfasste Anbieter; Lieferkette und Zugriffskontrolle haben für sie aber besonderes Gewicht.

Sicherheitsanforderungen an die Lieferkette (Art. 21 Abs. 2 lit. d NIS2)

MSP und MSSP müssen die Sicherheit ihrer eigenen Lieferkette aktiv managen. Nach Nr. 5 des CIR-Anhangs bedeutet das unter anderem:

• Dienstleisterbewertung: Festgelegte Kriterien für die Auswahl direkter Anbieter, etwa deren Cybersicherheitsverfahren (Nr. 5.1.2)
• Vertragliche Anforderungen: Verträge sollen – soweit angemessen – Cybersicherheitsanforderungen, Prüfrechte oder das Recht auf Prüfberichte sowie die Pflicht zur unverzüglichen Meldung relevanter Sicherheitsvorfälle enthalten (Nr. 5.1.4)
• Subunternehmer-Management: Wenn ein MSSP seinerseits Dienste bei weiteren Anbietern bezieht („Nested MSP“), sollten Verträge Anforderungen an die Unterauftragsvergabe und an Unterauftragnehmer festlegen (Nr. 5.1.4 Buchst. g)
• Softwarelieferkette: Überprüfung der Integrität eingesetzter Software-Komponenten; SBOMs (Software Bill of Materials) als empfohlene Praxis

Kundendatenisolation und Zugriffsmanagement

Weil MSP-Mitarbeiter privilegierten Zugriff auf Kundensysteme haben, sind strenge Zugriffskontrollen angezeigt. Bewährte Praxis sind:

• Kein gemeinsamer Zugang zu Kundensystemen verschiedener Mandanten vom selben Jump Server
• Zeitlich begrenzte Privilegien (Just-in-Time-Access) für alle Verwaltungszugänge
• Protokollierung und Überwachung aller privilegierten Aktionen; die CIR verlangt, Protokolle vor unbefugten Zugriffen oder Änderungen zu schützen (Nr. 3.2.5)
• MFA für alle Mitarbeiterzugänge, die auf Kundensysteme zugreifen

Vorfallmeldung bei Kundenvorfällen

Eine der schwierigsten Abgrenzungsfragen für MSP und MSSP ist: Wer meldet an welche Behörde, wenn ein Sicherheitsvorfall beim Kunden durch ein MSP-System oder eine MSP-Zugangskompromittierung verursacht wurde? In der Regel gilt: Das MSP meldet an die für es zuständige Stelle (in Deutschland über die gemeinsame Meldestelle von BSI und BBK), wenn der Vorfall das MSP selbst als NIS2-Einrichtung erheblich betrifft. Der Kunde meldet seinerseits, wenn er selbst NIS2-pflichtig ist. Vertragliche Regelungen zwischen MSP und Kunden können die Koordination der Meldewege konkretisieren.

Meldepflichten: Fristen und Adressaten für Cloud-Anbieter

Cloud-Anbieter und andere digitale Dienstleister unterliegen denselben gestuften Meldepflichten wie alle besonders wichtigen und wichtigen Einrichtungen (§ 32 BSIG, Artikel 23 NIS2). Auf Ersuchen des BSI ist zusätzlich eine Zwischenmeldung abzugeben:

Meldestufe	Frist	Inhalt
Frühe Erstmeldung (Frühwarnung)	Unverzüglich, spätestens 24 Stunden nach Kenntniserlangung	Angabe, ob der Verdacht besteht, dass der erhebliche Sicherheitsvorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist oder grenzüberschreitende Auswirkungen haben könnte
Meldung (Vorfallmeldung)	Unverzüglich, spätestens 72 Stunden nach Kenntniserlangung	Bestätigung oder Aktualisierung der Erstmeldung, erste Bewertung mit Schweregrad und Auswirkungen, gegebenenfalls Kompromittierungsindikatoren (IoC)
Abschlussmeldung	Spätestens 1 Monat nach der Meldung; bei andauerndem Vorfall zunächst Fortschrittsmeldung	Ausführliche Beschreibung mit Schweregrad und Auswirkungen, Art der Bedrohung bzw. zugrunde liegende Ursache, getroffene und laufende Abhilfemaßnahmen, gegebenenfalls grenzüberschreitende Auswirkungen

Für Cloud-Anbieter mit Kunden in mehreren EU-Mitgliedstaaten gilt eine wichtige Besonderheit: Nach Artikel 26 NIS2 und § 60 BSIG unterliegen DNS-Diensteanbieter, TLD-Namenregister, Cloud-, Rechenzentrums- und CDN-Anbieter, MSP, MSSP sowie Online-Marktplätze, Suchmaschinen und soziale Netzwerke der Zuständigkeit des Mitgliedstaates ihrer Hauptniederlassung in der EU. Als Hauptniederlassung gilt der Mitgliedstaat, in dem die Entscheidungen zum Cybersicherheits-Risikomanagement vorwiegend getroffen werden; hilfsweise gelten nachrangige Kriterien. Liegt die Hauptniederlassung in Deutschland, ist das BSI (Bundesamt für Sicherheit in der Informationstechnik) für die Einrichtung EU-weit zentral zuständig. Ein Cloud-Anbieter mit Hauptniederlassung in Irland unterliegt dagegen der irischen Zuständigkeit und meldet an die dort zuständige Stelle, nicht an das BSI – selbst wenn der Vorfall hauptsächlich deutsche Kunden betrifft. Die Behörden koordinieren sich über das CSIRTs-Netzwerk und – bei Sicherheitsvorfällen großen Ausmaßes – über EU-CyCLONe.

Besonders relevant für Cloud-Infrastrukturanbieter ist die Frage, ab wann ein Vorfall „erheblich“ ist. Die CIR 2024/2690 legt dafür konkrete Kriterien fest. Allgemein gilt ein Vorfall nach Artikel 3 unter anderem als erheblich, wenn er einen direkten finanziellen Verlust von mehr als 500.000 Euro oder 5 % des Jahresumsatzes (der niedrigere Wert) verursacht oder verursachen kann oder ein erfolgreicher, mutmaßlich böswilliger und unbefugter Zugriff vorliegt, der schwerwiegende Betriebsstörungen verursachen kann. Für Cloud-Dienste nennt Artikel 7 zusätzlich: vollständige Nichtverfügbarkeit eines Dienstes für mehr als 30 Minuten; eingeschränkte Verfügbarkeit für mehr als 5 % der Nutzer in der EU oder mehr als 1 Million Nutzer (der niedrigere Wert) für mehr als eine Stunde; Beeinträchtigung der Datenintegrität, -vertraulichkeit oder -authentizität durch eine mutmaßlich böswillige Handlung oder mit Auswirkungen auf mehr als 5 % bzw. 1 Million Nutzer. Für Rechenzentren, CDN sowie MSP und MSSP gelten eigene Kriterien (Artikel 8 bis 10); wiederholte Vorfälle mit derselben Ursache können zusammengerechnet werden (Artikel 4).

Einstufung als wesentliche oder wichtige Einrichtung

Cloud-Anbieter, MSP, MSSP und Rechenzentrumsbetreiber werden nach NIS2 entweder als wesentliche Einrichtungen (essential entities; im BSIG „besonders wichtige Einrichtungen“) oder als wichtige Einrichtungen (important entities) eingestuft. Die Einstufung hängt von Größe und Art des Dienstleisters ab (§ 28 BSIG):

• Besonders wichtige (wesentliche) Einrichtung: Cloud-, Rechenzentrums- und CDN-Anbieter, MSP und MSSP (Anlage 1 BSIG) mit mindestens 250 Beschäftigten oder einem Jahresumsatz von über 50 Mio. Euro und zugleich einer Jahresbilanzsumme von über 43 Mio. Euro; außerdem qualifizierte Vertrauensdiensteanbieter, TLD-Registrierungsstellen und DNS-Diensteanbieter unabhängig von der Größe sowie Betreiber kritischer Anlagen
• Wichtige Einrichtung: Anbieter aus Anlage 1 unterhalb dieser Schwelle, aber mit mindestens 50 Beschäftigten oder einem Jahresumsatz und einer Jahresbilanzsumme von jeweils über 10 Mio. Euro; Online-Marktplätze, Suchmaschinen und soziale Netzwerke (Anlage 2) ab derselben Schwelle; nicht qualifizierte Vertrauensdiensteanbieter unabhängig von der Größe

Die Einstufung wirkt sich auf Behördenbefugnisse und Sanktionshöhe aus. Gegenüber besonders wichtigen Einrichtungen kann das BSI auch ohne konkreten Anlass Audits, Prüfungen oder Zertifizierungen durch unabhängige Stellen anordnen (§ 61 BSIG); wichtige Einrichtungen werden in der Regel anlassbezogen überprüft, wenn Tatsachen auf Pflichtverstöße hindeuten (§ 62 BSIG). Bei bestimmten Verstößen, etwa gegen die Risikomanagement- oder Meldepflichten, kann das BSI Bußgelder verhängen (§ 65 BSIG):

• Besonders wichtige Einrichtungen: bis zu 10 Millionen Euro; bei einem weltweiten Gesamtumsatz von mehr als 500 Mio. Euro bis zu 2 Prozent des Gesamtumsatzes
• Wichtige Einrichtungen: bis zu 7 Millionen Euro; bei einem weltweiten Gesamtumsatz von mehr als 500 Mio. Euro bis zu 1,4 Prozent des Gesamtumsatzes

Einen vollständigen Überblick über Einstufungskriterien und die Unterschiede zwischen wesentlichen und wichtigen Einrichtungen ermöglicht der NIS2-Anwendungsbereich-Leitfaden.

Compliance-Fahrplan für Cloud-Anbieter in der Praxis

Die folgende Schrittfolge gibt eine praxisnahe Orientierung für Cloud-Anbieter, MSP und Rechenzentrumsbetreiber, die ihre NIS2- und CIR-Compliance systematisch angehen möchten:

Schritt 1: Betroffenheitsprüfung durchführen. Prüfen Sie, ob Ihr Dienst einer der in Anlage 1 oder 2 BSIG genannten Einrichtungsarten zuzuordnen ist und ob die Größenschwellen nach § 28 BSIG erreicht sind. Wer IaaS, PaaS oder SaaS anbietet und die Schwellen erreicht, ist in der Regel betroffen. Die Hilfestellung zur Selbstprüfung bietet der Leitfaden zum NIS2-Anwendungsbereich.

Schritt 2: Gap-Analyse gegenüber den Anforderungen des CIR-Anhangs. Ermitteln Sie, welche der zehn Maßnahmenbereiche und der zugehörigen Anforderungen des CIR-Anhangs in Ihrer Organisation bereits abgedeckt sind und wo Lücken bestehen. Dokumentieren Sie den Ist-Zustand strukturiert – diese Dokumentation wird bei Audits benötigt.

Schritt 3: BSI-Registrierung. Einrichtungen, für die das BSI nach § 60 BSIG zuständig ist (Hauptniederlassung in Deutschland), müssen sich nach § 33 BSIG im BSI-Portal registrieren und zusätzlich die Angaben nach § 34 BSIG übermitteln (u. a. Niederlassungen und öffentliche IP-Adressbereiche). Für Einrichtungen, die bereits beim Inkrafttreten des NIS2UmsuCG am 6. Dezember 2025 betroffen waren, endete die Registrierungsfrist am 6. März 2026. Wer sich noch nicht registriert hat, sollte dies unverzüglich nachholen; eine nicht oder nicht rechtzeitig übermittelte Registrierung kann nach § 65 BSIG mit einem Bußgeld von bis zu 500.000 Euro geahndet werden.

Schritt 4: Technische Maßnahmen nach dem CIR-Anhang implementieren. Priorisieren Sie die Umsetzung nach Risikohöhe. Typische Quick Wins für Cloud-Anbieter: MFA-Einführung für alle privilegierten Zugänge, automatisiertes Patch-Management, Verschlüsselung at-rest und in-transit, Netzwerksegmentierung per Mandant.

Schritt 5: Incident-Response-Prozess aufsetzen. Dokumentieren Sie den gestuften Meldeprozess (24h/72h/1 Monat), legen Sie die Schwellenwerte aus Artikel 3 bis 10 CIR in Ihrem Klassifizierungsschema fest und benennen Sie einen Ansprechpartner für NIS2-Meldungen, der möglichst rund um die Uhr erreichbar ist. Die Registrierung im BSI-Portal sollte abgeschlossen sein, bevor ein Ernstfall eintritt.

Schritt 6: Dokumentation und kontinuierliche Verbesserung. NIS2 ist kein einmaliges Projekt. Nach dem CIR-Anhang sind Risikobewertung und Risikobehandlungsplan mindestens jährlich sowie bei wesentlichen Änderungen oder erheblichen Sicherheitsvorfällen zu überprüfen (Nr. 2.1.4). Interne Audits, Penetrationstests und Schulungsmaßnahmen sind dauerhaft in den Betrieb zu integrieren.

Häufig gestellte Fragen

Gilt NIS2 auch für kleine Cloud-Anbieter ohne feste Mitarbeiterzahl?

In der Regel nicht. Cloud-Computing-Dienstleister, Rechenzentrumsbetreiber, CDN-Anbieter, MSP und MSSP fallen nach Artikel 2 Absatz 1 NIS2 und § 28 BSIG erst ab mittlerer Unternehmensgröße unter NIS2, also grundsätzlich ab 50 Beschäftigten oder einem Jahresumsatz und einer Jahresbilanzsumme von jeweils über 10 Millionen Euro. Ein kleines Startup, das IaaS-Dienste anbietet und diese Schwellen nicht erreicht, ist daher grundsätzlich nicht erfasst – anders als DNS-Diensteanbieter, TLD-Registrierungsstellen und Vertrauensdiensteanbieter, für die keine Größenschwelle gilt. Bei Konzernstrukturen sind Partner- und verbundene Unternehmen grundsätzlich mitzuzählen (§ 28 Absatz 4 BSIG). Mittlere Anbieter gelten als „wichtige Einrichtungen“, deren Aufsicht in der Regel anlassbezogen erfolgt.

Was unterscheidet IaaS, PaaS und SaaS unter NIS2?

Alle drei Cloud-Schichten fallen grundsätzlich unter NIS2, aber die spezifischen Risiken und damit die priorisierten Sicherheitsmaßnahmen unterscheiden sich. IaaS-Anbieter tragen die Verantwortung für die physische und virtualisierte Infrastruktur; PaaS-Anbieter zusätzlich für Laufzeitumgebungen, Middleware und Entwickler-APIs; SaaS-Anbieter für die gesamte Applikationsschicht bis zum Endnutzer. Das Shared-Responsibility-Modell, das Cloud-Anbieter gegenüber ihren Kunden kommunizieren, ist auch intern für die NIS2-Compliance relevant: Jede Schicht muss ihre eigene Compliance dokumentieren.

Sind Cloud-Kunden durch NIS2 geschützt, wenn ihr Anbieter einen Vorfall hat?

NIS2 verpflichtet Cloud-Anbieter zu Sicherheitsmaßnahmen und zur Meldung erheblicher Vorfälle an Behörden. Eine automatische Informationspflicht gegenüber allen Kunden besteht in Deutschland nicht; nach § 35 Absatz 1 BSIG kann das BSI aber anordnen, dass Einrichtungen die Empfänger ihrer Dienste über einen erheblichen Sicherheitsvorfall unterrichten. Anbieter aus den Sektoren digitale Infrastruktur und Verwaltung von IKT-Diensten müssen potenziell betroffenen Kunden zudem bei einer erheblichen Cyberbedrohung mögliche Abhilfemaßnahmen mitteilen, soweit die Interessen der Kunden überwiegen (§ 35 Absatz 2 BSIG). Weitere Pflichten können sich aus Verträgen (SLA, Auftragsverarbeitungsvertrag) oder der DSGVO ergeben. Kunden sollten in ihren Cloud-Verträgen explizit Meldeklauseln bei NIS2-relevanten Vorfällen vereinbaren.

Wie verhält sich NIS2 zu ISO 27001 für Cloud-Anbieter?

ISO 27001 und NIS2 sind komplementär, aber nicht identisch. Die CIR stützt ihre Anforderungen nach Erwägungsgrund 3 unter anderem auf ISO/IEC 27001 und ISO/IEC 27002; eine ISO-27001-Zertifizierung kann daher viele Anforderungen abdecken, insbesondere im Bereich Risikomanagement, Asset-Management und Zugriffskontrolle. Sie ist jedoch kein vollständiger Compliance-Nachweis für NIS2: Die spezifischen Meldepflichten, die BSI-Registrierung und bestimmte CIR-Anforderungen (z. B. zur Lieferkettensicherheit) gehen über den ISO-27001-Scope hinaus. Eine Zuordnung der CIR-Anforderungen zu gängigen Standards bietet die Technical Implementation Guidance der ENISA.

Ab wann gelten die CIR-Anforderungen für in Deutschland ansässige Cloud-Anbieter?

Die CIR 2024/2690 wurde am 17. Oktober 2024 erlassen, am 18. Oktober 2024 im Amtsblatt veröffentlicht und ist am zwanzigsten Tag danach in Kraft getreten; als EU-Verordnung gilt sie unmittelbar. In Deutschland gelten die BSIG-Pflichten seit dem Inkrafttreten des NIS2UmsuCG am 6. Dezember 2025 ohne Übergangsfrist; erfasste Cloud-Anbieter müssen die CIR-Anforderungen daher bereits heute umsetzen. Warten ist kein risikofreier Ansatz.

Dieser Artikel stellt allgemeine Informationen bereit und stellt keine Rechts- oder Regulierungsberatung dar. Die Anforderungen können je nach Einrichtungstyp, Größe und konkretem Dienstleistungsangebot variieren. Für eine auf Ihre Situation zugeschnittene Einschätzung empfehlen wir die Hinzuziehung eines qualifizierten Rechtsanwalts oder NIS2-Compliance-Spezialisten.

Quellen

1. Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 – Technische und methodische Anforderungen der Risikomanagementmaßnahmen im Bereich der Cybersicherheit und erhebliche Sicherheitsvorfälle — EUR-Lex, Amtsblatt der Europäischen Union, insbesondere Art. 1–14 und Anhang
2. Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau (NIS-2-Richtlinie) — EUR-Lex, insbesondere Art. 2, 3, 21, 23 und 26
3. NIS-2-regulierte Unternehmen – Registrierung, Betroffenheitsprüfung und Informationsangebote — Bundesamt für Sicherheit in der Informationstechnik (BSI)
4. NIS2 Technical Implementation Guidance — European Union Agency for Cybersecurity (ENISA)
5. Gesetz über das Bundesamt für Sicherheit in der Informationstechnik und über die Sicherheit in der Informationstechnik von Einrichtungen (BSI-Gesetz – BSIG), insbesondere §§ 28, 30, 32–35, 60–62, 65 — Bundesministerium der Justiz, Gesetze im Internet