Cloud-Anbieter, Managed Service Provider und Betreiber von Rechenzentren gehören zu den Einrichtungstypen, für die die NIS-2-Richtlinie ein besonders strenges und europäisch vereinheitlichtes Regulierungsregime vorsieht. Während für die meisten NIS2-pflichtigen Unternehmen nationale Umsetzungsgesetze – in Deutschland das NIS2UmsuCG – den konkreten Rahmen setzen, gilt für digitale Infrastrukturdienstleister zusätzlich ein unmittelbar anwendbarer EU-Rechtsakt: die Durchführungsverordnung (EU) 2024/2690 der Kommission. Als EU-Verordnung ist sie in jedem Mitgliedstaat direkt verbindlich – ohne nationalen Umsetzungsspielraum. Das bedeutet: Die technischen Mindeststandards für Cybersicherheitsmaßnahmen sind 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?
Artikel 2 Absatz 2 der NIS-2-Richtlinie (EU) 2022/2555 enthält eine abschließende Liste von Einrichtungstypen, die unabhängig von ihrer Größe dem Anwendungsbereich unterliegen. Diese größenunabhängige Regulierung ist eine zentrale Besonderheit gegenüber anderen NIS2-Pflichtigen, für die Schwellenwerte von 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz gelten. Für die folgenden Dienstleistungstypen gilt NIS2 bereits ab dem ersten Kunden:
- Cloud-Computing-Dienstleister im Sinne von IaaS (Infrastructure as a Service), PaaS (Platform as a Service) und SaaS (Software as a Service)
- Rechenzentrumsbetreiber, die Colocation, Hosting oder andere Infrastrukturdienste erbringen
- 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 Sicherheitsüberwachung oder Incident-Response als Dienstleistung erbringen
- Anbieter von DNS-Diensten und Registrierungsstellen für Top-Level-Domains (TLD)
- Online-Marktplätze, Online-Suchmaschinen und Social-Networking-Plattformen ab einer bestimmten Nutzerbasis
- Vertrauensdiensteanbieter (qualifiziert und nicht qualifiziert) im Sinne der eIDAS-Verordnung
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. Entscheidend ist, ob der Dienst die ISO/IEC 17788-Definition von Cloud Computing erfüllt: On-demand-Ressourcenzugang, Netzwerkzugang, gemeinsam genutzte Ressourcen, schnelle Skalierbarkeit und messbare Dienste. 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 oder 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 ermächtigt die Europäische Kommission, im Wege von Durchführungsrechtsakten technische und methodische Anforderungen für bestimmte Einrichtungstypen festzulegen. Von dieser Ermächtigung hat die Kommission mit der Durchführungsverordnung (EU) 2024/2690 vom 17. Oktober 2024 Gebrauch gemacht. Die Verordnung präzisiert für alle in Artikel 2 Absatz 2 NIS2 genannten digitalen Dienstleister, welche konkreten Sicherheitsmaßnahmen die zehn Anforderungsbereiche des Artikel 21 Absatz 2 NIS2 im Minimum umfassen müssen.
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 Mindestanforderungen. Die CIR schafft damit einen echten europäischen Binnenmarkt für sichere digitale Infrastruktur.
Die CIR gilt ausdrücklich zusätzlich zu nationalen Umsetzungsgesetzen wie dem NIS2UmsuCG. Wo das nationale Recht strengere Anforderungen stellt, gilt das nationale Recht. Wo die CIR über nationale Anforderungen hinausgeht, gilt die CIR. Für betroffene Unternehmen bedeutet das: Compliance-Anforderungen aus beiden Rechtsquellen müssen gleichzeitig erfüllt werden. 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
Die CIR 2024/2690 strukturiert ihre Anforderungen entlang der zehn Sicherheitsbereiche aus Artikel 21 Absatz 2 NIS2. Für jeden Bereich legt sie konkrete Mindestmaßnahmen fest, die Cloud-Anbieter, MSP, MSSP und Rechenzentrumsbetreiber umsetzen müssen. Die folgende Tabelle gibt einen Überblick:
| Sicherheitsbereich (Art. 21 Abs. 2 NIS2) | CIR-Anforderung (Kurzfassung) | Besonderheit für Cloud-Anbieter |
|---|---|---|
| Risikoanalyse und Sicherheitsrichtlinien | Dokumentierte Methodik, risikobasierte Priorisierung, jährliche Überprüfung | Berücksichtigung der mandantenspezifischen Risikolandschaft |
| Behandlung von Sicherheitsvorfällen | Incident-Response-Prozess, Klassifikationsschema, Eskalationspfade | Vorfallmeldepflicht auch für Vorfälle, die Kundensysteme betreffen |
| Business Continuity und Krisenmanagement | BCP/DRP, RTO/RPO-Definitionen, regelmäßige Tests | Redundanzpflicht für Kerninfrastruktur; geografische Verteilung empfohlen |
| Sicherheit der Lieferkette | Lieferantenbewertung, vertragliche Sicherheitsanforderungen, Subunternehmerprüfung | MSP/MSSP: explizite Pflicht zur Kundendatenisolation bei Dritt-Dienstleistern |
| Sicherheit bei Beschaffung und Entwicklung | Secure SDLC, Schwachstellenmanagement in Software und Systemen | Patching-Pflicht für Hypervisor, Container-Plattformen, Basis-Images |
| Bewertung der Wirksamkeit von Sicherheitsmaßnahmen | Interne Audits, Penetrationstests, KPI-Messung | Externe Zertifizierung (z. B. ISO 27001, SOC 2) als Nachweisoption |
| Grundlegende Cyber-Hygiene | Patch-Management, Konfigurationsmanagement, Schulungen | Automatisiertes Patch-Deployment für Cloud-Infrastruktur erforderlich |
| Kryptografie und Verschlüsselung | Verschlüsselung at-rest und in-transit, schlüsselverwaltung | Mandantengetrennte Schlüsselverwaltung (BYOK/HYOK-Optionen) |
| Personalsicherheit und Zugriffskontrolle | Zugriffskonzept nach Least-Privilege, MFA-Pflicht für privilegierte Zugänge | Sicherheitsüberprüfung für Personal mit Zugriff auf Kundendaten |
| Asset-Management und MFA | Vollständiges Inventar aller Systeme, MFA als Standard | Dynamisches Asset-Management für skalierbare Cloud-Ressourcen |
Die CIR legt Mindestanforderungen fest, keinen abschließenden Katalog. Unternehmen müssen auf Basis ihrer individuellen Risikoanalyse zusätzliche Maßnahmen identifizieren, die über das Minimum hinausgehen. 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. Die CIR enthält dafür spezifische Anforderungen, die über allgemeine Sicherheitsstandards hinausgehen:
Datenisolation zwischen Mandanten
Cloud-Anbieter sind verpflichtet sicherzustellen, 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 von Cloud-Anbietern Business-Continuity-Pläne, die Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) definieren und durch regelmäßige Tests belegen. Für kritische Dienste wird erwartet, dass Redundanz nicht nur innerhalb eines Rechenzentrums, sondern über mehrere geografische Zonen hinweg besteht. Backup-Verfahren müssen in regelmäßigen Abständen auf Wiederherstellbarkeit geprüft werden – nicht nur erstellt, sondern aktiviert.
Schlüsselverwaltung und Verschlüsselung
Kryptografische Schlüssel müssen je Mandant getrennt verwaltet werden. Der Übergang zu mandantengetrennter Schlüsselverwaltung – entweder durch Bring Your Own Key (BYOK) oder Hold Your Own Key (HYOK) – ist keine Luxusoption mehr, sondern eine aus der CIR ableitbare Mindestanforderung für Cloud-Anbieter mit höherer Risikoeinstufung. Data at rest und Data in transit müssen nach aktuellen kryptografischen Standards verschlüsselt sein; TLS 1.2 ist die untere Grenze, TLS 1.3 der angestrebte Standard.
MSP und MSSP: Erweiterte Pflichten durch 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. Diese privilegierte Zugriffsposition begründet erweiterte Pflichten unter NIS2 und der CIR.
Sicherheitsanforderungen an die Lieferkette (Art. 21 Abs. 2 lit. d NIS2)
MSP und MSSP müssen die Sicherheit ihrer eigenen Lieferkette aktiv managen. Das bedeutet konkret:
- Dienstleisterbewertung: Alle Subunternehmer und Software-Lieferanten müssen nach einem dokumentierten Prozess auf ihre Cybersicherheitspraktiken hin bewertet werden
- Vertragliche Anforderungen: Verträge mit kritischen Dienstleistern müssen Sicherheitsklauseln, Auditrechte und Meldepflichten bei Vorfällen enthalten
- Subunternehmer-Management: Wenn ein MSSP seinerseits Dienste bei weiteren Anbietern bezieht („Nested MSP“), gelten dieselben Anforderungen an diese Unterlieferanten
- 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, müssen strenge Zugriffskontrollen eingehalten werden:
- 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; Logs müssen tamper-evident sein
- MFA-Pflicht 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? Nach aktuellem Stand gilt: Das MSP meldet an seine zuständige NIS2-Behörde (in Deutschland das BSI), wenn der Vorfall das MSP selbst als NIS2-Einrichtung betrifft. Der Kunde meldet seinerseits an seine Behörde, 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 dreistufigen Meldepflichten wie alle wesentlichen und wichtigen Einrichtungen unter NIS2:
| Meldestufe | Frist | Inhalt |
|---|---|---|
| Frühwarnung | 24 Stunden nach Kenntnisnahme | Vorläufige Einschätzung: erheblich oder nicht; ob Verdacht auf vorsätzlichen oder kriminellen Hintergrund |
| Erster Bericht | 72 Stunden nach Kenntnisnahme | Aktualisierte Einschätzung mit Schweregradsangaben, Angriffsvektor (falls bekannt), Indikatoren für Kompromittierung (IoC) |
| Abschlussbericht | 1 Monat nach erstem Bericht | Vollständige forensische Analyse, ergriffene und geplante Abwehrmaßnahmen, länderübergreifende Auswirkungen |
Für Cloud-Anbieter mit Kunden in mehreren EU-Mitgliedstaaten gilt eine wichtige Besonderheit: Meldepflichtig ist primär die Behörde des Mitgliedstaates, in dem der Anbieter seinen Hauptsitz oder seine Hauptniederlassung hat. In Deutschland ist das das BSI (Bundesamt für Sicherheit in der Informationstechnik). Ein in Irland ansässiger Cloud-Anbieter meldet primär an die irische NCSC, nicht an das BSI – selbst wenn der Vorfall hauptsächlich deutsche Kunden betrifft. Die Behörden koordinieren sich über das CSIRT-Netzwerk und CyCLONe bei übergreifenden Vorfällen.
Besonders relevant für Cloud-Infrastrukturanbieter ist die Frage, ab wann ein Vorfall „erheblich“ ist. Die CIR 2024/2690 enthält sektorspezifische Schwellenwerte: Für Cloud-Dienste gilt ein Vorfall als erheblich, wenn er die Verfügbarkeit, Integrität oder Vertraulichkeit von Cloud-Ressourcen für eine signifikante Anzahl von Nutzern über einen erheblichen Zeitraum beeinträchtigt – oder wenn finanzielle Verluste oder Reputationsschäden für betroffene Einrichtungen das Maß des Tolerierbaren übersteigen.
Einstufung als wesentliche oder wichtige Einrichtung
Cloud-Anbieter, MSP, MSSP und Rechenzentrumsbetreiber werden nach NIS2 entweder als wesentliche Einrichtungen (essential entities) oder als wichtige Einrichtungen (important entities) eingestuft. Die Einstufung hängt von Größe und Art des Dienstleisters ab:
- Wesentliche Einrichtung: Große Unternehmen (250+ Mitarbeiter oder 50 Mio. Euro Umsatz) in Anhang-I-Sektoren; außerdem Qualifizierte Vertrauensdienstleister und TLD-Registrierungsstellen unabhängig von der Größe
- Wichtige Einrichtung: Mittlere Unternehmen (50–249 Mitarbeiter oder 10–50 Mio. Euro Umsatz) in Anhang-II-Sektoren, darunter Cloud-Anbieter, MSP und Rechenzentrumsbetreiber unterhalb der Schwelle für wesentliche Einrichtungen
Die Einstufung wirkt sich auf Behördenbefugnisse und Sanktionshöhe aus. Wesentliche Einrichtungen können proaktiven Kontrollen durch das BSI unterliegen; wichtige Einrichtungen werden in der Regel reaktiv, also anlassbezogen, überprüft. Bei Verstößen drohen:
- Wesentliche Einrichtungen: bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes (der höhere Wert)
- Wichtige Einrichtungen: bis zu 7 Millionen Euro oder 1,4 Prozent des weltweiten Jahresumsatzes
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. Klären Sie, ob Ihr Dienst unter Artikel 2 Absatz 2 NIS2 fällt. Ausschlaggebend ist die Art des erbrachten Dienstes, nicht die Unternehmensgröße. Wenn Sie IaaS, PaaS oder SaaS für andere Unternehmen oder Privatpersonen anbieten, sind Sie grundsätzlich betroffen. Die Hilfestellung zur Selbstprüfung bietet der Leitfaden zum NIS2-Anwendungsbereich.
Schritt 2: Gap-Analyse gegenüber den zehn CIR-Sicherheitsbereichen. Ermitteln Sie, welche der zehn Sicherheitsbereiche in Ihrer Organisation bereits abgedeckt sind und wo Lücken bestehen. Dokument ieren Sie den Ist-Zustand strukturiert – diese Dokumentation wird bei Audits benötigt.
Schritt 3: BSI-Registrierung. Cloud-Anbieter und digitale Dienstleister mit Hauptniederlassung in Deutschland müssen sich beim BSI registrieren. Die Registrierungsfrist endete am 6. März 2026. Wer sich noch nicht registriert hat, sollte dies unverzüglich nachholen, um Bußgelder nach §65 BSIG zu vermeiden.
Schritt 4: Technische Maßnahmen nach CIR Annex 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 dreistufigen Meldeprozess (24h/72h/1 Monat), benennen Sie einen Ansprechpartner für NIS2-Meldungen und stellen Sie sicher, dass dieser 24/7 erreichbar ist. Das BSI-Meldeportal (MELDP) muss vorregistriert sein, bevor ein Ernstfall eintritt.
Schritt 6: Dokumentation und kontinuierliche Verbesserung. NIS2 ist kein einmaliges Projekt. Risikoanalysen müssen jährlich oder bei wesentlichen Änderungen der Bedrohungslage aktualisiert werden. 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?
Ja. Für die in Artikel 2 Absatz 2 NIS2 genannten Einrichtungstypen – darunter Cloud-Computing-Dienstleister, Rechenzentrumsbetreiber, MSP und MSSP – gelten keine Größenschwellen. Ein Startup, das IaaS-Dienste für Unternehmenskunden anbietet, ist mit dem ersten Unternehmenstag NIS2-pflichtig. Die Pflichten sind identisch, aber die Einstufung als „wichtige Einrichtung“ für Unternehmen unter 250 Mitarbeitern bedeutet, dass die Aufsicht in der Regel reaktiv (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 zur Implementierung von Sicherheitsmaßnahmen und zur Meldung erheblicher Vorfälle an Behörden. Eine direkte Informationspflicht gegenüber betroffenen Kunden ergibt sich aus NIS2 nicht automatisch; sie kann sich jedoch aus vertraglichen Vereinbarungen (Service Level Agreements, Datenschutzvertrag) oder aus der DSGVO ergeben, wenn personenbezogene Daten von einem Vorfall betroffen sind. 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 komplementar, aber nicht identisch. Eine ISO-27001-Zertifizierung deckt viele der NIS2-Anforderungen ab, 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 für MSP) gehen über den ISO-27001-Scope hinaus. Das BSI akzeptiert ISO-27001-Zertifikate als Teilnachweis, nicht als Vollständigkeitsnachweis.
Ab wann gelten die CIR-Anforderungen für in Deutschland ansässige Cloud-Anbieter?
Die CIR 2024/2690 ist am 17. Oktober 2024 erlassen worden und als EU-Verordnung unmittelbar seit ihrem Inkrafttreten in Deutschland anwendbar. In Verbindung mit dem deutschen NIS2UmsuCG, das ebenfalls in Kraft ist, sind Cloud-Anbieter bereits heute verpflichtet, die technischen Mindestanforderungen der CIR umzusetzen. Eine Übergangsregelung, die Umsetzungsfristen für bereits bestehende Dienste vorsieht, ist im deutschen Recht nicht explizit normiert; das BSI hat signalisiert, dass es bei laufenden Compliance-Bemühungen kooperativ vorgehen wird. Warten ist dennoch 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
- Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 – Technische und methodische Anforderungen für Cybersicherheitsrisikomanagementmaßnahmen — EUR-Lex, Amtsblatt der Europäischen Union
- Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau (NIS-2-Richtlinie) — EUR-Lex, insbesondere Art. 2 Abs. 2 und Art. 21
- NIS-2-Umsetzung in Deutschland – Orientierungshilfen für betroffene Unternehmen — Bundesamt für Sicherheit in der Informationstechnik (BSI)
- Cloud Security Guidelines for NIS2 Entities — European Union Agency for Cybersecurity (ENISA)
- BSIG (Bundessicherheitsgesetz – NIS2UmsuCG-Fassung), insbesondere §§ 28, 29, 32, 33, 65 — Bundesministerium der Justiz, Gesetze im Internet
