NIS2-Durchführungsverordnung (CIR 2024/2690): Vollständiger Leitfaden zu den technischen Anforderungen

Zuletzt verifiziert: Oktober 2026. Die Durchführungsverordnung (EU) 2024/2690 der Kommission wurde am 17. Oktober 2024 erlassen, am 18. Oktober 2024 im Amtsblatt der EU veröffentlicht und ist gemäß ihrem Art. 16 am zwanzigsten Tag nach der Veröffentlichung, also am 7. November 2024, in Kraft getreten. Sie gilt unmittelbar in jedem Mitgliedstaat, ohne dass eine nationale Umsetzung erforderlich ist — allerdings nur für die in Art. 1 genannten elf Einrichtungsarten.

Die meisten online verfügbaren NIS2-Leitfäden enden auf der Ebene der Richtlinie: eine Zusammenfassung der zehn Maßnahmen gemäß Article 21, eine Bußgeldtabelle und eine allgemeine Implementierungs-Checkliste. Was in der Compliance-Landschaft nahezu vollständig fehlt, ist eine detaillierte, praxisnahe Aufschlüsselung der Durchführungsverordnung (EU) 2024/2690 der Kommission — des Dokuments, das mit technischer und methodischer Präzision festlegt, was diese zehn Maßnahmen in der Praxis konkret erfordern.

Dieser Leitfaden schließt diese Lücke. Wenn Sie als Compliance-Beauftragter, CISO oder leitende Führungskraft für die NIS2-Implementierung verantwortlich sind und nicht nur wissen möchten, dass Article 21 „Sicherheit der Lieferkette“ vorschreibt, sondern genau verstehen müssen, welche Richtlinien, Verzeichnisse, Verfahren und Vertragsklauseln damit gemeint sind — sind Sie hier richtig.

Die CIR ist eines der wichtigsten Dokumente für die technische NIS2-Umsetzung — und eines, das viele Verantwortliche noch nicht vollständig gelesen haben. Am Ende dieses Leitfadens haben Sie einen Überblick über alle 13 Annex-Abschnitte, erkennen, wo die CIR über den Wortlaut von Article 21 hinausgeht, wissen, an welchen Anforderungen sich unsere Vorlagendokumente orientieren, und verstehen, wie die Implementierung angegangen werden kann. Wenn Sie noch prüfen, ob eine Organisation in den NIS2-Anwendungsbereich fällt, beginnen Sie zunächst mit unserem NIS2-Leitfaden zum Anwendungsbereich.

Was ist CIR 2024/2690 und warum ist sie bedeutsam

Die NIS2-Richtlinie (EU) 2022/2555 legt zehn Kategorien von Cybersicherheits-Risikomanagementmaßnahmen fest, die wesentliche und wichtige Einrichtungen gemäß Article 21 umsetzen müssen. Die Richtlinie ist bewusst breit angelegt — sie gilt für Organisationen von kleinen Managed-Service-Providern bis hin zu großen Energieinfrastrukturbetreibern in allen 27 EU-Mitgliedstaaten. Der Wortlaut von Article 21 Abs. 2 spiegelt diese Breite wider: „Sicherheit der Lieferkette“, „grundlegende Verfahren im Bereich der Cyberhygiene“, „Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung“. Er definiert, was adressiert werden muss, nicht wie.

Die Durchführungsverordnung (EU) 2024/2690 der Kommission — allgemein als CIR oder NIS2-Durchführungsverordnung bezeichnet — schließt diese Lücke für einen bestimmten Kreis von Einrichtungen. Es handelt sich um einen Durchführungsrechtsakt (keinen delegierten Rechtsakt), gestützt auf Article 21 Abs. 5 Unterabs. 1 und Article 23 Abs. 11 Unterabs. 2 der Richtlinie, erlassen am 17. Oktober 2024. Ihr amtlicher Titel beschreibt, was sie leistet: „mit Durchführungsbestimmungen zur Richtlinie (EU) 2022/2555 im Hinblick auf die technischen und methodischen Anforderungen der Risikomanagementmaßnahmen im Bereich der Cybersicherheit und die Präzisierung der Fälle, in denen ein Sicherheitsvorfall […] als erheblich gilt“ — jeweils in Bezug auf die im Titel aufgezählten Anbieterarten.

Die CIR überführt jede Maßnahme gemäß Article 21 in spezifische, umsetzbare technische Anforderungen. Wo die Richtlinie „Sicherheit der Lieferkette“ vorschreibt, verlangt die CIR ein Konzept für die Sicherheit der Lieferkette mit Kriterien für die Auswahl von Anbietern (Nr. 5.1.2), ein aktuelles Verzeichnis der direkten Anbieter und Diensteanbieter mit Kontaktstellen und den bereitgestellten IKT-Produkten, -Diensten und -Prozessen (Nr. 5.2) sowie — soweit angemessen und auf Basis der Risikobewertung — vertragliche Sicherheitsanforderungen an Anbieter (Nr. 5.1.4 Buchst. a bis h). Wo die Richtlinie „Konzepte für die Zugriffskontrolle“ nennt, konkretisiert die CIR die Vergabe von Rechten nach den Grundsätzen Need-to-know, Need-to-use und Aufgabentrennung (Nr. 11.2.2), das Management privilegierter Konten (Nr. 11.3), das Identitätsmanagement (Nr. 11.5) sowie die Multifaktor-Authentifizierung, die — soweit angemessen — im Einklang mit der Klassifizierung der jeweiligen Anlagen und Werte einzusetzen ist (Nr. 11.7).

Drei Merkmale machen die CIR einzigartig bedeutsam

• Unmittelbar anwendbares EU-Recht: Anders als die NIS2-Richtlinie selbst, die von jedem Mitgliedstaat in nationales Recht umgesetzt werden musste (mit Unterschieden zwischen den Rechtsordnungen), ist die CIR eine EU-Verordnung. Sie ist seit dem 7. November 2024 in Kraft und gilt unmittelbar in jedem Mitgliedstaat, ohne auf nationale Umsetzung warten zu müssen. In Deutschland stellt § 30 Abs. 3 BSIG klar, dass dieser Durchführungsrechtsakt für die dort genannten Einrichtungsarten Vorrang hat.
• Spezifität auf Kontrollebene: Die CIR legt Anforderungen deutlich detaillierter fest als die Richtlinie. Compliance-Teams können jeden Annex-Unterabschnitt lesen und daraus das erforderliche Konzept, das Verfahren oder die technische Kontrolle ableiten. Zugleich bleibt Raum für Verhältnismäßigkeit: Nach Art. 2 Abs. 2 berücksichtigen die Einrichtungen ihre Risikoexposition, ihre Größe sowie Eintrittswahrscheinlichkeit und Schwere von Sicherheitsvorfällen; viele Anforderungen gelten nur, „soweit angemessen“, und ein Abweichen ist dann nachvollziehbar zu begründen und zu dokumentieren.
• Orientierungsmaßstab über den Anwendungsbereich hinaus: Die CIR gilt formell nur für die 11 in Art. 1 genannten Einrichtungsarten. ENISA weist in ihrer Umsetzungsleitlinie darauf hin, dass die Leitlinie auch für andere öffentliche oder private Stellen nützliche Hinweise zur Verbesserung ihrer Cybersicherheit liefern kann. Für alle übrigen Einrichtungen ist die CIR damit eine Orientierungshilfe, keine Rechtspflicht und kein Ersatz für die Pflichten aus § 30 BSIG.

Der Annex der CIR enthält 13 Abschnitte mit insgesamt 47 Unterabschnitten mit eigener Überschrift (etwa 6.5 „Sicherheitsprüfung“ oder 11.7 „Multifaktor-Authentifizierung“); die Abschnitte 7 und 9 sind ohne Zwischenüberschriften in die Nummern 7.1–7.3 und 9.1–9.3 gegliedert. Einen umfassenderen Überblick über alle Verpflichtungen gemäß Article 21 und das vollständige NIS2-Compliance-Bild finden Sie in unserem Leitfaden zu den NIS2-Anforderungen.

Für wen gilt die CIR

Die CIR ist formell auf eine bestimmte Teilmenge von NIS2-Einrichtungen beschränkt — die in Art. 1 der CIR (und gleichlautend in Article 21 Abs. 5 Unterabs. 1 der NIS2-Richtlinie) aufgezählten „betreffenden Einrichtungen“, vorwiegend Anbieter digitaler Infrastrukturen und digitaler Dienste. Es sind genau elf Einrichtungsarten:

1. DNS-Diensteanbieter
2. TLD-Namenregister (Top Level Domain Name Registries)
3. Anbieter von Cloud-Computing-Diensten
4. Anbieter von Rechenzentrumsdiensten
5. Betreiber von Inhaltszustellnetzen (Content Delivery Networks, CDN)
6. Managed-Service-Provider (MSPs)
7. Managed-Security-Service-Provider (MSSPs)
8. Anbieter von Online-Marktplätzen
9. Anbieter von Online-Suchmaschinen
10. Anbieter von Plattformen für Dienste sozialer Netzwerke
11. Vertrauensdiensteanbieter

Das deutsche Recht greift dieselbe Liste auf: Nach § 30 Abs. 3 BSIG hat der von der Kommission gemäß Article 21 Abs. 5 Unterabs. 1 NIS2 erlassene Durchführungsrechtsakt für DNS-Diensteanbieter, Top Level Domain Name Registries, Cloud-Computing-Dienstleister, Anbieter von Rechenzentrumsdiensten, Betreiber von Content Delivery Networks, Managed Service Provider, Managed Security Service Provider, Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke sowie Vertrauensdiensteanbieter „für die vorgenannten Einrichtungsarten Vorrang“. Gezählt sind das ebenfalls elf Einrichtungsarten.

Für Einrichtungen, die einer dieser Kategorien angehören, ist die CIR unmittelbar geltendes Recht. Deren Cybersicherheits-Risikomanagementmaßnahmen sind an den technischen und methodischen Anforderungen der 13 Annex-Abschnitte auszurichten, und die zuständige Behörde — in Deutschland in der Regel das BSI — kann die Umsetzung anhand dieser Anforderungen prüfen. Ob eine Einrichtung überhaupt unter NIS2 fällt, richtet sich weiterhin nach § 28 BSIG.

Warum die CIR auch dann relevant ist, wenn sie nicht rechtlich verbindlich ist

Ist eine Organisation eine besonders wichtige oder wichtige Einrichtung, gehört aber nicht zu den 11 oben genannten Kategorien — etwa ein Krankenhaus, ein Wasserversorgungsunternehmen, ein Fertigungsunternehmen oder ein Logistikbetreiber —, ist die CIR für sie rechtlich nicht verbindlich. Ihre Pflichten ergeben sich aus Article 21 NIS2 in der deutschen Umsetzung, also insbesondere aus § 30 Abs. 1 und 2 BSIG. Die CIR kann dennoch als Orientierungshilfe dienen:

• Gleiche Struktur wie § 30 Abs. 2 BSIG: Die 13 Annex-Abschnitte konkretisieren dieselben zehn Maßnahmenbereiche, die § 30 Abs. 2 BSIG für alle besonders wichtigen und wichtigen Einrichtungen vorgibt. Sie eignen sich daher als detaillierte Gliederungshilfe für ein eigenes Sicherheitskonzept.
• ENISA-Leitlinie mit Hinweisen für weitere Stellen: Die ENISA-Umsetzungsleitlinie zur CIR (Juni 2025, Version 1.0) richtet sich an die von der CIR erfassten Einrichtungen, weist aber ausdrücklich darauf hin, dass sie auch anderen öffentlichen oder privaten Stellen nützliche Hinweise zur Verbesserung ihrer Cybersicherheit geben kann. Eine Empfehlung, die CIR als verbindlichen Maßstab für alle NIS2-Einrichtungen anzuwenden, enthält sie nicht.
• Bezug zu anerkannten Normen: Laut Erwägungsgrund 3 der CIR beruhen ihre Anforderungen auf europäischen und internationalen Normen wie ISO/IEC 27001, ISO/IEC 27002 und ETSI EN 319401 sowie auf technischen Spezifikationen wie CEN/TS 18026:2024. Wer bereits mit diesen Normen arbeitet, findet in der CIR viele bekannte Strukturen wieder.

Unsere Einschätzung: Für Einrichtungen außerhalb des CIR-Anwendungsbereichs kann die CIR als Orientierung für die Ausgestaltung der Maßnahmen nach § 30 BSIG dienen — nicht als Rechtspflicht und nicht als Garantie dafür, dass die Aufsicht eine bestimmte Umsetzung als ausreichend ansieht. Maßgeblich bleiben Risikoanalyse, Verhältnismäßigkeit und der Stand der Technik nach § 30 BSIG; Präzisierungen per Rechtsverordnung nach § 30 Abs. 5 BSIG bleiben vorbehalten.

Übersicht aller 13 CIR-Annex-Abschnitte

Der CIR-Annex ist in 13 Abschnitte gegliedert, von denen jeder eine oder mehrere der Cybersicherheits-Risikomanagementmaßnahmen gemäß Article 21 umsetzt. Zu beachten ist, dass Article 21(2)(a) durch zwei separate Abschnitte (Richtlinie und Risikomanagement) adressiert wird und Article 21(2)(i) in vier Abschnitten konkretisiert wird (Personalsicherheit, Zugangskontrolle, Asset-Management und physische Sicherheit; Abschnitt 13 dient zugleich Article 21(2)(c) und (e)), was die Bereiche widerspiegelt, in denen die CIR die detailliertesten und operativ bedeutsamsten Anforderungen enthält.

Abschnitt	Titel	NIS2 Art. 21 Maßnahme	Unteranforderungen	Unsere Vorlagen
1	Sicherheitsrichtlinie	Art. 21(2)(a)	2	#4, #11, #34
2	Risikomanagement	Art. 21(2)(a)	3	#5, #6, #7, #8, #9, #10
3	Umgang mit Sicherheitsvorfällen	Art. 21(2)(b)	6	#21, #48, #49, #50, #51, #52
4	Business Continuity & Krisenmanagement	Art. 21(2)(c)	3	#23, #35, #36, #37, #38, #39, #40, #41
5	Sicherheit der Lieferkette	Art. 21(2)(d)	2	#42, #43, #44, #45
6	Beschaffung, Entwicklung & Wartung	Art. 21(2)(e)	10	#20, #22, #31, #32
7	Bewertung der Wirksamkeit	Art. 21(2)(f)	3*	#40, #41, #46, #47
8	Cyberhygiene & Schulungen	Art. 21(2)(g)	2	#3, #12, #19, #20
9	Kryptografie	Art. 21(2)(h)	3*	#25, #27
10	Personalsicherheit	Art. 21(2)(i) teilweise	4	#33, #34, #44
11	Zugangskontrolle	Art. 21(2)(i) teilweise & (j)	7	#13, #14, #25, #28, #29, #30
12	Asset-Management	Art. 21(2)(i) teilweise	5	#16, #17, #18, #26
13	Physische und umgebungsbezogene Sicherheit	Art. 21(2)(c), (e) und (i) teilweise	3	#12, #15

* Die Abschnitte 7 und 9 haben keine Unterabschnitte mit eigener Überschrift, sondern die Nummern 7.1–7.3 bzw. 9.1–9.3. Die obenstehende Tabelle bietet Compliance-Teams eine Einzelreferenzansicht der vollständigen CIR-Struktur. Die nachfolgenden Abschnitte erläutern jeden davon im Detail. Eine Checkliste, die alle Anforderungen dem Umsetzungsstatus zuordnet, finden Sie in der NIS2-Compliance-Checkliste.

Anforderungen Abschnitt für Abschnitt

Die folgende Aufschlüsselung behandelt jeden der 13 CIR-Annex-Abschnitte: was er in verständlicher Sprache erfordert, seine wesentlichen Unteranforderungen, Umsetzungshinweise für KMU sowie die Vorlagen, an denen sich die Dokumentation orientieren kann.

Abschnitt 1 — Konzept für die Sicherheit von Netz- und Informationssystemen

Was er erfordert: Ein dokumentiertes übergeordnetes Konzept (Richtlinie) zur Steuerung der Sicherheit der Netz- und Informationssysteme der Organisation. Dies ist das grundlegende Governance-Dokument, aus dem die themenspezifischen Konzepte (etwa zur Zugriffskontrolle) ihren Rahmen ableiten.

Wesentliche Unteranforderungen:

• 1.1 Konzept für die Sicherheit von Netz- und Informationssystemen: Nach Nr. 1.1.1 legt das Konzept unter anderem den Ansatz für das Sicherheitsmanagement, die Sicherheitsziele, eine Verpflichtung zur kontinuierlichen Verbesserung und zur Bereitstellung angemessener Ressourcen, die Liste der themenspezifischen Konzepte, Indikatoren zur Überwachung der Umsetzung sowie das Datum der förmlichen Genehmigung durch die Leitungsorgane fest (Buchst. a bis k). Nach Nr. 1.1.2 wird es von den Leitungsorganen mindestens jährlich sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken überprüft und — soweit angemessen — aktualisiert; das Ergebnis der Überprüfung wird dokumentiert. In Deutschland sind die Leitungsorgane nach § 38 Abs. 1 BSIG verpflichtet, die Risikomanagementmaßnahmen nach § 30 BSIG umzusetzen und ihre Umsetzung zu überwachen.
• 1.2 Rollen, Verantwortlichkeiten und Weisungsbefugnisse: Verantwortlichkeiten werden festgelegt, Rollen zugeordnet und den Leitungsorganen mitgeteilt. Mindestens eine Person muss gegenüber den Leitungsorganen direkt für Fragen der Sicherheit von Netz- und Informationssystemen verantwortlich sein (Nr. 1.2.3); widerstrebende Pflichten werden — soweit anwendbar — getrennt (Nr. 1.2.5). Die Leitungsorgane überprüfen die Rollen in geplanten Zeitabständen und anlassbezogen (Nr. 1.2.6).

KMU-Umsetzungshinweis: Viele kleinere Organisationen verwechseln das Sicherheitskonzept mit einem Dokument zu technischen Kontrollen. Abschnitt 1 verlangt ein übergeordnetes Governance-Dokument, das von den Leitungsorganen förmlich genehmigt wird; der Umfang ist nicht vorgegeben. Die technischen Details gehören in die nachgeordneten Konzepte und Verfahren, die in den Abschnitten 3 bis 13 behandelt werden. Für Kleinstunternehmen, die widerstrebende Pflichten nicht trennen können, nennt Erwägungsgrund 5 Ausgleichsmaßnahmen wie eine gezielte Beaufsichtigung durch das Management oder eine verstärkte Überwachung und Protokollierung.

Vorlagen: Dok 04 (Informationssicherheitsrichtlinie), Dok 11 (IT-Sicherheitsrichtlinie), Dok 34 (Erklärung zur Annahme von Cybersicherheitsdokumenten).

Abschnitt 2 — Risikomanagement

Was er erfordert: Einen systematischen, dokumentierten Ansatz zur Ermittlung, Analyse, Bewertung und Behandlung von Risiken für die Sicherheit der Netz- und Informationssysteme — ergänzt um die Überwachung der Einhaltung und unabhängige Überprüfungen.

Wesentliche Unteranforderungen:

• 2.1 Risikomanagementrahmen: Risikobewertungen werden durchgeführt und dokumentiert; auf dieser Grundlage wird ein Risikobehandlungsplan erstellt, umgesetzt und überwacht. Ergebnisse der Risikobewertung und Restrisiken werden von den Leitungsorganen oder von rechenschaftspflichtigen und befugten Personen akzeptiert (Nr. 2.1.1). Das Verfahren umfasst unter anderem eine Risikomanagementmethodik, eine Risikotoleranzschwelle, Risikokriterien, die Festlegung von Verantwortlichen und Zeitpunkten für Behandlungsmaßnahmen sowie die Begründung für das Eingehen von Restrisiken (Nr. 2.1.2 Buchst. a bis j). Risikobewertung und Behandlungsplan werden in geplanten Zeitabständen und mindestens jährlich sowie bei wesentlichen Änderungen oder erheblichen Sicherheitsvorfällen überprüft (Nr. 2.1.4).
• 2.2 Überwachung der Einhaltung: Regelmäßige Überprüfung der Einhaltung der Konzepte und Berichterstattung an die Leitungsorgane über den Stand der Netz- und Informationssicherheit.
• 2.3 Unabhängige Überprüfung: Der Sicherheitsansatz wird durch Personen mit angemessener Prüfungskompetenz unabhängig überprüft; interne Prüfer dürfen nicht dem Personal des geprüften Bereichs unterstellt sein, wobei kleinere Einrichtungen alternative Maßnahmen zur Sicherung der Unparteilichkeit ergreifen können (Nr. 2.3.2).

KMU-Umsetzungshinweis: Die CIR schreibt keine bestimmte Risikobeurteilungsmethodik vor — etablierte Ansätze wie ISO/IEC 27005 oder BSI-Standard 200-3 können als Grundlage dienen. Entscheidend ist, dass die Methodik dokumentiert, konsistent angewendet und in den vorgesehenen Intervallen überprüft wird. Einen praktischen Methodikleitfaden finden Sie in unserem NIS2-Leitfaden zur Risikobeurteilung.

Vorlagen: Dok 05 (Risikobeurteilungsmethodik), Dok 06 (Risikobeurteilungstabelle), Dok 07 (Risikobehandlungstabelle), Dok 08 (Akzeptanz von Restrisiken), Dok 09 (Bericht zur Risikobeurteilung und -behandlung), Dok 10 (Risikobehandlungsplan).

Abschnitt 3 — Umgang mit Sicherheitsvorfällen

Was er erfordert: Durchgängige Verfahren zur Erkennung, Analyse, Eindämmung, Reaktion, Wiederherstellung, Dokumentation und Meldung von Sicherheitsvorfällen. Abschnitt 3 ist einer der operativ bedeutsamsten Teile der CIR und gliedert sich in sechs Unterabschnitte. Die Meldefristen selbst (24-Stunden-Frühwarnung, 72-Stunden-Meldung, Abschlussbericht nach einem Monat) stehen nicht in der CIR, sondern in Article 23 NIS2 bzw. § 32 BSIG; die CIR präzisiert in Art. 3 bis 14, wann ein Vorfall für die erfassten Einrichtungen als erheblich gilt.

Wesentliche Unteranforderungen:

• 3.1 Konzept für die Bewältigung von Sicherheitsvorfällen: Rollen, Verantwortlichkeiten und Verfahren, abgestimmt auf den Notfallplan nach Nr. 4.1, mit einem Kategorisierungssystem für Sicherheitsvorfälle, Kommunikationsplänen (auch für Eskalation und Meldung), Rollenzuweisungen und Arbeitsdokumenten wie Reaktionsanleitungen, Eskalationsschemata, Kontaktlisten und Vorlagen (Nr. 3.1.2). Die CIR schreibt keine bestimmte Zahl von Schweregradstufen vor.
• 3.2 Überwachung und Protokollierung: Verfahren und Instrumente zur Überwachung und Protokollierung, soweit durchführbar automatisiert. Nr. 3.2.3 nennt, soweit angemessen, zu protokollierende Inhalte (Buchst. a bis l), etwa relevanten Netzverkehr, Authentifizierungsereignisse, privilegierte Zugriffe und Zugriffe auf Backup-Dateien. Protokolle werden für einen vorab festgelegten Zeitraum aufbewahrt und vor unbefugtem Zugriff geschützt (Nr. 3.2.5). In dieser Detailtiefe geht die CIR deutlich über den Wortlaut von Article 21 hinaus.
• 3.3 Meldung von Ereignissen: Ein einfacher Mechanismus, über den Mitarbeitende, Anbieter und Kunden verdächtige Ereignisse melden können.
• 3.4 Bewertung und Klassifizierung von Ereignissen: Bewertung anhand vorab festgelegter Kriterien und einer Triage; zudem ist vierteljährlich zu bewerten, ob wiederholte Sicherheitsvorfälle nach Art. 4 vorliegen (Nr. 3.4.2 Buchst. b).
• 3.5 Reaktion auf Sicherheitsvorfälle: Dokumentierte Reaktionsverfahren mit den Phasen Eindämmung, Beseitigung und erforderlichenfalls Wiederherstellung, Kommunikationspläne für die Meldung an CSIRTs bzw. zuständige Behörden, Protokollierung der Reaktionstätigkeiten sowie Tests der Verfahren in geplanten Zeitabständen. Das vollständige Meldeverfahren finden Sie in unserem NIS2-Leitfaden zur Vorfallsmeldung.
• 3.6 Überprüfungen nach Sicherheitsvorfällen: Nach der Wiederherstellung — soweit angemessen — eine nachträgliche Überprüfung, die möglichst die Ursache ermittelt und die gezogenen Lehren dokumentiert; die Ergebnisse fließen in Konzept, Risikobehandlung und Verfahren ein.

Vorlagen: Dok 21 (Verfahren zur Protokollierung und Überwachung), Dok 48 (Richtlinie zum Umgang mit Vorfällen), Dok 49 (Verfahren zur Reaktion auf geringfügige Vorfälle), Dok 50 (Vorfallsprotokoll), Dok 51 (Formulare zur Vorfallsmeldung und -benachrichtigung), Dok 52 (Register der Korrekturmaßnahmen).

Abschnitt 4 — Business Continuity und Krisenmanagement

Was er erfordert: Pläne und Verfahren zur Aufrechterhaltung und Wiederherstellung des Betriebs bei Sicherheitsvorfällen, mit Anforderungen an Backup- und Redundanzmanagement, getestete Wiederherstellung und Krisenmanagement.

Wesentliche Unteranforderungen:

• 4.1 Notfallplan für die Aufrechterhaltung und Wiederherstellung des Betriebs: Beruht auf der Risikobewertung und umfasst — soweit angemessen — unter anderem Rollen und Verantwortlichkeiten, Kontaktangaben und Kommunikationskanäle, Bedingungen für Aktivierung und Deaktivierung, die Reihenfolge der Wiederherstellung, Wiederherstellungspläne mit Wiederherstellungszielen sowie erforderliche Ressourcen (Nr. 4.1.2). Eine Analyse der betrieblichen Auswirkungen (BIA) ist durchzuführen (Nr. 4.1.3); Erwägungsgrund 13 ermuntert dazu, dabei etwa maximal tolerierbare Ausfallzeiten sowie Wiederherstellungszeit- und Wiederherstellungspunktziele zu erfassen. Der Plan wird in geplanten Zeitabständen und anlassbezogen getestet und überprüft.
• 4.2 Backup-Sicherungs- und Redundanzmanagement: Sicherungspläne mit Wiederherstellungszeiten, vollständigen und genauen Kopien (einschließlich Konfigurationsdaten und Cloud-Daten), Speicherung (online oder offline) an sicheren Orten, die nicht im selben Netz wie das System liegen und ausreichend weit entfernt sind, Zugangskontrollen und Aufbewahrungsfristen (Nr. 4.2.2). Hinzu kommen regelmäßige Integritätsprüfungen (Nr. 4.2.3) und — entscheidend — regelmäßige Tests der Wiederherstellung, deren Ergebnisse dokumentiert werden (Nr. 4.2.6).
• 4.3 Krisenmanagement: Ein Krisenmanagementverfahren, das mindestens Rollen und Verantwortlichkeiten (soweit angemessen auch der Anbieter), geeignete Kommunikationsmittel zwischen der Einrichtung und den zuständigen Behörden sowie Maßnahmen zur Aufrechterhaltung der Sicherheit in Krisensituationen abdeckt (Nr. 4.3.2). Hinzu kommen ein Verfahren für den Umgang mit Informationen von CSIRTs oder zuständigen Behörden (Nr. 4.3.3) und Tests des Krisenmanagementplans (Nr. 4.3.4).

Vorlagen: Dok 23 (Backup-Richtlinie), Dok 35 (BIA-Methodik), Dok 36 (BIA-Fragebogen), Dok 37 (Business-Continuity-Strategie), Dok 38 (Business-Continuity-Plan), Dok 39 (Krisenmanagementplan), Dok 40 (Übungs- und Testplan), Dok 41 (Übungs- und Testbericht).

Abschnitt 5 — Sicherheit der Lieferkette

Was er erfordert: Ein Konzept für die Sicherheit der Lieferkette, das die Beziehungen zu direkten Anbietern und Diensteanbietern regelt.

• 5.1 Konzept für die Sicherheit der Lieferkette: Auswahlkriterien wie die Cybersicherheitsverfahren der Anbieter, ihre Fähigkeit, festgelegte Spezifikationen zu erfüllen, die Qualität und Resilienz der IKT-Produkte und die Möglichkeit, Versorgungsquellen zu diversifizieren (Nr. 5.1.2). Nr. 5.1.4 nennt in acht Buchstaben (a bis h), was — soweit angemessen — vertraglich festzulegen ist: Cybersicherheitsanforderungen, Schulungs- und Qualifikationsanforderungen, Zuverlässigkeitsüberprüfungen, unverzügliche Meldung von Sicherheitsvorfällen, Prüfrechte oder Prüfberichte, Behebung von Schwachstellen, Regeln zur Unterauftragsvergabe sowie Pflichten bei Vertragsende.
• 5.2 Verzeichnis der Anbieter und Diensteanbieter: Ein aktuelles Verzeichnis mit Kontaktstellen und der Liste der bereitgestellten IKT-Produkte, -Dienste und -Prozesse.

Vorlagen: Dok 42 (Richtlinie zur Lieferantensicherheit), Dok 43 (Sicherheitsklauseln für Lieferanten), Dok 44 (Vertraulichkeitserklärung), Dok 45 (Lieferantenverzeichnis).

Abschnitt 6 — Sicherheit bei Erwerb, Entwicklung und Wartung

Was er erfordert: Mit zehn Unterabschnitten ist Abschnitt 6 der umfangreichste Teil des Annex: 6.1 Sicherheit beim Erwerb von IKT-Diensten oder -Produkten, 6.2 sicherer Entwicklungszyklus, 6.3 Konfigurationsmanagement, 6.4 Änderungsmanagement, Reparatur und Wartung, 6.5 Sicherheitsprüfung, 6.6 Sicherheitspatch-Management, 6.7 Netzsicherheit, 6.8 Netzsegmentierung, 6.9 Schutz gegen Schadsoftware und nicht genehmigte Software sowie 6.10 Behandlung und Offenlegung von Schwachstellen.

• 6.5 Sicherheitsprüfung: Notwendigkeit, Umfang, Häufigkeit und Art der Sicherheitstests werden auf Basis der Risikobewertung festgelegt; Art, Umfang und Ergebnisse werden dokumentiert, kritische Feststellungen führen zu Risikominderungsmaßnahmen.
• 6.6 Sicherheitspatch-Management: Patches werden innerhalb einer angemessenen Frist eingespielt, vorher getestet und auf Integrität geprüft; ein Verzicht ist nur bei überwiegenden Nachteilen und mit dokumentierter Begründung möglich (Nr. 6.6.2).
• 6.7 Netzsicherheit: Unter anderem eine aktuelle Dokumentation der Netzarchitektur, Kontrollen für den Fernzugriff, Verbindungen von Diensteanbietern nur nach Genehmigung und befristet sowie Durchführungspläne für den Übergang zur neuesten Generation der Netzwerkprotokolle und für moderne E-Mail-Sicherheitsstandards (Nr. 6.7.2 Buchst. j und k).
• 6.10 Schwachstellen: Verfolgung von Schwachstelleninformationen, soweit angemessen Schwachstellen-Scans, unverzügliche Behebung kritischer Schwachstellen und ein Verfahren zur koordinierten Offenlegung.

Vorlagen: Dok 20 (Verfahren für Schwachstellen- und Patch-Management), Dok 22 (Verfahren für IKT-Änderungsmanagement), Dok 31 (Richtlinie für Erwerb, Entwicklung und Wartung von IKT), Dok 32 (Anhang IKT-Sicherheitsanforderungen).

Abschnitt 7 — Bewertung der Wirksamkeit

Was er erfordert: Ein Konzept und Verfahren, um zu bewerten, ob die Risikomanagementmaßnahmen wirksam umgesetzt und aufrechterhalten werden (Nr. 7.1). Festzulegen ist unter anderem, was mit welchen Methoden überwacht und gemessen wird, wann und durch wen, und wer die Ergebnisse analysiert (Nr. 7.2 Buchst. a bis f). Konzept und Verfahren werden in geplanten Zeitabständen und anlassbezogen überprüft (Nr. 7.3).

Vorlagen: Dok 40 (Übungs- und Testplan), Dok 41 (Übungs- und Testbericht), Dok 46 (Methodik zur Messung der Cybersicherheit), Dok 47 (Bericht zur Messung der Cybersicherheit).

Abschnitt 8 — Cyberhygiene und Schulungen

Was er erfordert: 8.1 ein Sensibilisierungsprogramm für Mitarbeitende, ausdrücklich einschließlich der Mitglieder der Leitungsorgane, und — soweit angemessen — für direkte Anbieter, das wiederholt angeboten und das regelmäßig wiederholt und auf seine Wirksamkeit getestet wird;mdash; soweit angemessen das regelmäßig wiederholt und auf seine Wirksamkeit getestet wird;mdash; auf seine Wirksamkeit getestet wird; 8.2 Sicherheitsschulungen für Mitarbeitende, deren Rollen sicherheitsrelevante Fähigkeiten erfordern, einschließlich Schulungen bei Rollenwechseln (Nr. 8.2.4).

Vorlagen: Dok 03 (Erstschulungsplan), Dok 12 (Clear-Desk- und Clear-Screen-Richtlinie), Dok 19 (Netzwerksicherheitsrichtlinie), Dok 20 (Verfahren für Schwachstellen- und Patch-Management).

Abschnitt 9 — Kryptografie

Was er erfordert: Ein Konzept und Verfahren für Kryptografie, ausgerichtet an der Klassifizierung der Anlagen und Werte und der Risikobewertung (Nr. 9.1). Festzulegen sind Art, Stärke und Qualität der kryptografischen Maßnahmen, zugelassene Protokolle und Algorithmen — soweit angemessen nach einem Krypto-Agilitätsansatz — sowie das Schlüsselmanagement von der Generierung bis zur Vernichtung (Nr. 9.2 Buchst. c, Ziffern i bis xii). Die Überprüfung berücksichtigt den Stand der Technik (Nr. 9.3).

Vorlagen: Dok 25 (Richtlinie für sichere Kommunikation), Dok 27 (Richtlinie zu Verschlüsselung und kryptografischen Kontrollen).

Abschnitt 10 — Sicherheit des Personals

Was er erfordert: 10.1 Mechanismen, damit Mitarbeitende, Administratoren und Mitglieder der Leitungsorgane ihre Sicherheitsverantwortung verstehen, mit einer Überprüfung der Rollenzuweisung mindestens einmal jährlich (Nr. 10.1.3); 10.2 Zuverlässigkeitsüberprüfungen, soweit durchführbar und für die jeweilige Rolle erforderlich; 10.3 Pflichten, die nach Beendigung oder Änderung des Beschäftigungsverhältnisses fortgelten, etwa Vertraulichkeitsklauseln; 10.4 ein Disziplinarverfahren bei Verstößen gegen die Sicherheitskonzepte.

Vorlagen: Dok 33 (HR-Sicherheitsrichtlinie), Dok 34 (Erklärung zur Annahme von Cybersicherheitsdokumenten), Dok 44 (Vertraulichkeitserklärung).

Abschnitt 11 — Zugriffskontrolle

Was er erfordert: Sieben Unterabschnitte: 11.1 Konzept für die Zugriffskontrolle (logisch und physisch, für Personen und Systeme), 11.2 Management von Zugangs- und Zugriffsrechten nach Need-to-know, Need-to-use und Aufgabentrennung mit Überprüfung in geplanten Zeitabständen, 11.3 privilegierte Konten und Systemverwaltungskonten mit starker Authentifizierung (z. B. Multifaktor-Authentifizierung) und separaten Administrationskonten, 11.4 Systemverwaltungssysteme, 11.5 Identifizierung (eindeutige Kennungen, Lebenszyklus, gemeinsame Kennungen nur mit ausdrücklicher Genehmigung), 11.6 Authentifizierung (unter anderem Sperrung nach erfolglosen Anmeldeversuchen und Beendigung inaktiver Sitzungen) sowie 11.7 Multifaktor-Authentifizierung oder kontinuierliche Authentifizierung — soweit angemessen und im Einklang mit der Klassifizierung der Anlage bzw. des Werts, auf die zugegriffen wird.

Vorlagen: Dok 13 (Richtlinie für mobile Geräte und Telearbeit), Dok 14 (BYOD-Richtlinie), Dok 25 (Richtlinie für sichere Kommunikation), Dok 28 (Zugriffskontrollrichtlinie), Dok 29 (Authentifizierungsrichtlinie), Dok 30 (Passwortrichtlinie).

Abschnitt 12 — Anlagen- und Wertemanagement (Asset-Management)

Was er erfordert: 12.1 Klassifizierungsstufen für alle Anlagen und Werte auf Basis von Vertraulichkeit, Integrität, Authentizität und Verfügbarkeit, 12.2 ein Konzept für die Behandlung von Anlagen und Werten über den gesamten Lebenszyklus, 12.3 ein Konzept für Wechseldatenträger (technische Sperrung, sofern keine organisatorischen Gründe für die Nutzung vorliegen), 12.4 ein vollständiges und aktuelles Inventar sowie 12.5 die Rückgabe oder Löschung von Anlagen und Werten bei Beendigung des Beschäftigungsverhältnisses.

Vorlagen: Dok 16 (Richtlinie zur Informationsklassifizierung), Dok 17 (Verfahren für das Asset-Management), Dok 18 (IT-Asset-Register), Dok 26 (Richtlinie zu Entsorgung und Vernichtung).

Abschnitt 13 — Sicherheit des Umfelds und physische Sicherheit

Was er erfordert: 13.1 Schutz vor Ausfällen unterstützender Versorgungsleistungen wie Strom, Telekommunikation und Klimatisierung, einschließlich Verträgen über die Notversorgung, 13.2 Schutz vor physischen Bedrohungen und Bedrohungen des Umfelds mit festgelegten Mindest- und Höchstkontrollwerten und 13.3 Sicherheitsperimeter und physische Zutrittskontrolle. Abschnitt 13 dient zugleich Article 21 Abs. 2 Buchst. c, e und i.

Vorlagen: Dok 12 (Clear-Desk- und Clear-Screen-Richtlinie), Dok 15 (Richtlinie zur physischen Sicherheit).

CIR vs. Article 21: Wesentliche Unterschiede

Article 21 NIS2 (in Deutschland § 30 BSIG) nennt die zehn Maßnahmenbereiche, die CIR konkretisiert sie für die erfassten Einrichtungen. Einige Präzisierungen, die sich nicht aus dem Wortlaut der Richtlinie ergeben:

• Feste Überprüfungsintervalle: Sicherheitskonzept (Nr. 1.1.2), Risikobewertung und Risikobehandlungsplan (Nr. 2.1.4) sowie die Rollenzuweisung des Personals (Nr. 10.1.3) sind mindestens jährlich zu überprüfen.
• Konkrete Protokollierungsinhalte: Nr. 3.2.3 listet zwölf Kategorien zu protokollierender Ereignisse auf.
• Vierteljährliche Prüfung wiederholter Vorfälle: Nr. 3.4.2 Buchst. b in Verbindung mit Art. 4.
• Vertragsinhalte für Anbieter: Nr. 5.1.4 Buchst. a bis h.
• Netzprotokolle und E-Mail-Standards: Durchführungspläne nach Nr. 6.7.2 Buchst. j und k.
• Dokumentierte Abweichungen: Wo eine Anforderung nur „soweit angemessen, anwendbar oder durchführbar“ gilt und eine Einrichtung sie nicht anwendet, muss sie die Begründung nachvollziehbar dokumentieren (Art. 2 Abs. 2 Unterabs. 2).

Wann ein Sicherheitsvorfall als erheblich gilt (Art. 3 bis 14)

Für die erfassten Einrichtungen präzisiert die CIR, wann ein Vorfall im Sinne von Article 23 Abs. 3 NIS2 erheblich ist. Nach Art. 3 Abs. 1 genügt eines der allgemeinen Kriterien, unter anderem: ein direkter finanzieller Verlust von mehr als 500 000 EUR oder 5 % des Jahresumsatzes des Vorjahres — je nachdem, welcher Wert niedriger ist —, der Abfluss von Geschäftsgeheimnissen, der Tod oder eine schwere Gesundheitsschädigung einer Person oder ein erfolgreicher, mutmaßlich böswilliger und unbefugter Zugriff, der schwerwiegende Betriebsstörungen verursachen kann. Nach Art. 4 gelten wiederholte Vorfälle als erheblich, wenn sie innerhalb von sechs Monaten mindestens zweimal mit derselben offensichtlichen Ursache auftreten und zusammen das Finanzkriterium erfüllen. Art. 5 bis 14 enthalten dienstspezifische Schwellen, zum Beispiel:

• DNS-Diensteanbieter, Cloud-Anbieter, CDN-Betreiber, Managed (Security) Service Provider: vollständige Nichtverfügbarkeit des Dienstes für mehr als 30 Minuten (Art. 5, 7, 9, 10);
• Cloud, CDN, MSP/MSSP: eingeschränkte Verfügbarkeit für mehr als 5 % der Nutzer in der Union oder mehr als 1 Mio. Nutzer — je nachdem, welche Zahl niedriger ist — für mehr als eine Stunde (Art. 7, 9, 10);
• Vertrauensdiensteanbieter: vollständige Nichtverfügbarkeit eines Vertrauensdienstes für mehr als 20 Minuten oder mehr als eine Stunde Nichtverfügbarkeit innerhalb einer Kalenderwoche (Art. 14).

Planmäßige Wartungsunterbrechungen gelten nicht als erhebliche Sicherheitsvorfälle (Art. 3 Abs. 2). Für Einrichtungen außerhalb des CIR-Anwendungsbereichs gelten diese Schwellenwerte nicht unmittelbar; maßgeblich ist dort die Begriffsbestimmung in § 2 Nr. 11 BSIG.

Beziehung zur technischen Umsetzungsleitlinie der ENISA

Am 26. Juni 2025 veröffentlichte ENISA ihre NIS2 Technical Implementation Guidance (Version 1.0) — ein nicht bindendes Dokument mit Umsetzungshinweisen, Beispielen für Nachweise und Zuordnungen der Anforderungen zu Normen und nationalen Rahmenwerken für jeden der 13 Abschnitte der CIR. Das Verhältnis der drei Ebenen lässt sich so beschreiben:

1. NIS2 Directive Article 21 (in Deutschland § 30 BSIG) — die rechtliche Verpflichtung (übergeordnet, prinzipienbasiert)
2. CIR 2024/2690 Annex — die technischen und methodischen Anforderungen (spezifisch und unmittelbar anwendbar für die 11 erfassten Einrichtungsarten, jedoch stellenweise noch prinzipienbasiert)
3. ENISA Technical Implementation Guidance — Umsetzungshinweise, Nachweisbeispiele und Normen-Mappings (nicht bindend)

Die ENISA-Leitlinie ordnet jede Anforderung Normen und Rahmenwerken wie ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST Cybersecurity Framework 2.0, ETSI EN 319 401 und CEN/TS 18026:2024 sowie nationalen NIS2-Rahmenwerken zu; die Zuordnungstabelle stellt ENISA als Excel-Datei bereit. ENISA betont, dass dieses Mapping nicht als Gleichwertigkeit der Normen zu verstehen ist und nicht bewertet, ob eine Norm die Anforderungen der Verordnung vollständig abdeckt. Für Organisationen mit ISO/IEC-27001-Zertifizierung ist das Mapping dennoch ein praktischer Ausgangspunkt, um verbleibende Lücken zu ermitteln.

Die Dokumente in unserem Vorlagenpaket orientieren sich an den Anforderungen der CIR und an den Hinweisen der ENISA-Leitlinie. Sie ersetzen keine einrichtungsspezifische Risikoanalyse und Anpassung. Eine detaillierte Zusammenfassung der spezifischen Empfehlungen der ENISA, Abschnitt für Abschnitt, finden Sie in unserem Artikel zur ENISA Technical Implementation Guidance.

Zuordnung unserer Vorlagen zu den CIR-Anforderungen

Die häufigste Frage von Compliance-Teams lautet: “Welche Dokumente muss ich tatsächlich erstellen?” Die nachstehende Tabelle ordnet jeden Abschnitt des CIR Annex den Dokumenten in unserem NIS2-Vorlagenpaket zu, die sich an seinen Anforderungen orientieren. Die Vorlagen bieten einen strukturierten Ausgangspunkt; sie müssen an die jeweilige Einrichtung angepasst werden und ersetzen keine eigene Prüfung, ob alle Anforderungen erfüllt sind.

CIR Annex-Abschnitt	Dokumentennummer und -titel
1. Sicherheitsrichtlinie (1.1–1.2)	Doc 04: Information Security Policy • Doc 11: IT Security Policy • Doc 34: Statement of Acceptance of Cybersecurity Documents
2. Risikomanagement (2.1–2.3)	Doc 05: Risk Assessment Methodology • Doc 06: Risk Assessment Table • Doc 07: Risk Treatment Table • Doc 08: Acceptance of Residual Risks • Doc 09: Risk Assessment and Treatment Report • Doc 10: Risk Treatment Plan
3. Behandlung von Sicherheitsvorfällen (3.1–3.6)	Doc 21: Logging and Monitoring Procedure • Doc 48: Incident Handling Policy • Doc 49: Minor Incident Response Procedure • Doc 50: Incident Log • Doc 51: Incident Notification and Reporting Forms • Doc 52: Corrective Actions Register
4. Geschäftskontinuität (4.1–4.3)	Doc 23: Backup Policy • Doc 35: BIA Methodology • Doc 36: BIA Questionnaire • Doc 37: Business Continuity Strategy • Doc 38: Business Continuity Plan • Doc 39: Crisis Management Plan • Doc 40: Exercising and Testing Plan • Doc 41: Exercising and Testing Report
5. Sicherheit in der Lieferkette (5.1–5.2)	Doc 42: Supplier Security Policy • Doc 43: Supplier Security Clauses • Doc 44: Confidentiality Statement • Doc 45: Supplier Directory
6. Beschaffung, Entwicklung & Wartung (6.1–6.10)	Doc 20: Vulnerability and Patch Management Procedure • Doc 22: ICT Change Management Procedure • Doc 31: ICT Acquisition, Development and Maintenance Policy • Doc 32: ICT Security Requirements Appendix
7. Bewertung der Wirksamkeit (7.1–7.3)	Doc 40: Exercising and Testing Plan • Doc 41: Exercising and Testing Report • Doc 46: Cybersecurity Measurement Methodology • Doc 47: Cybersecurity Measurement Report
8. Cyber-Hygiene & Schulung (8.1–8.2)	Doc 03: Initial Training Plan • Doc 12: Clear Desk and Clear Screen Policy • Doc 19: Network Security Policy • Doc 20: Vulnerability and Patch Management Procedure
9. Kryptografie (9.1–9.3)	Doc 25: Secure Communication Policy • Doc 27: Encryption and Cryptographic Controls Policy
10. Personalsicherheit (10.1–10.4)	Doc 33: HR Security Policy • Doc 34: Statement of Acceptance of Cybersecurity Documents • Doc 44: Confidentiality Statement
11. Zugangskontrolle (11.1–11.7)	Doc 13: Mobile Device and Remote Work Policy • Doc 14: BYOD Policy • Doc 25: Secure Communication Policy • Doc 28: Access Control Policy • Doc 29: Authentication Policy • Doc 30: Password Policy
12. Asset-Management (12.1–12.5)	Doc 16: Information Classification Policy • Doc 17: Asset Management Procedure • Doc 18: IT Asset Register • Doc 26: Disposal and Destruction Policy
13. Physische & Umgebungssicherheit (13.1–13.3)	Doc 12: Clear Desk and Clear Screen Policy • Doc 15: Physical Security Policy

Jedem Abschnitt des CIR Annex ist mindestens ein Vorlagendokument zugeordnet. Für die umfangreichsten Abschnitte — Risikomanagement, Behandlung von Sicherheitsvorfällen, Geschäftskontinuität — enthält das Paket mehrere miteinander verknüpfte Dokumente, die sich an den jeweiligen Unteranforderungen orientieren. Einen schrittweisen Implementierungsansatz finden Sie in der NIS2-Compliance-Checkliste.

Häufig gestellte Fragen

Gilt die CIR für alle NIS2-Einrichtungen verbindlich?

Nein. Unmittelbar verbindlich ist sie nur für die 11 Einrichtungsarten nach Art. 1 CIR bzw. Article 21 Abs. 5 Unterabs. 1 NIS2 — vorwiegend Anbieter digitaler Infrastrukturen und Dienste (DNS, TLD-Namenregister, Cloud, Rechenzentren, CDN, MSP, MSSP, Online-Marktplätze, Online-Suchmaschinen, Plattformen für soziale Netzwerke) sowie Vertrauensdiensteanbieter. § 30 Abs. 3 BSIG räumt der CIR für genau diese Einrichtungsarten Vorrang ein. Für alle anderen besonders wichtigen und wichtigen Einrichtungen gilt § 30 Abs. 1 und 2 BSIG; die CIR kann ihnen lediglich als Orientierung dienen.

Wie verhält sich die CIR zu ISO 27001?

Es bestehen erhebliche Überschneidungen: Laut Erwägungsgrund 3 beruhen die Anforderungen der CIR unter anderem auf ISO/IEC 27001 und ISO/IEC 27002. Eine ISO-27001-Zertifizierung belegt die CIR-Konformität aber nicht automatisch. Die CIR enthält zusätzliche Präzisierungen, etwa mindestens jährliche Überprüfungen von Sicherheitskonzept und Risikobewertung, konkrete Protokollierungsinhalte, die vierteljährliche Prüfung wiederholter Vorfälle, Vertragsinhalte für Anbieter (Nr. 5.1.4) und Schwellenwerte für erhebliche Sicherheitsvorfälle (Art. 3 bis 14). Die ENISA-Leitlinie bietet ein Mapping zu ISO/IEC 27001:2022 und weiteren Normen, betont aber, dass es keine Gleichwertigkeit ausdrückt.

Wann ist die CIR in Kraft getreten?

Erlassen am 17. Oktober 2024, veröffentlicht im Amtsblatt der EU am 18. Oktober 2024, in Kraft getreten gemäß Art. 16 am zwanzigsten Tag nach der Veröffentlichung, also am 7. November 2024. Als Verordnung ist sie in allen ihren Teilen verbindlich und gilt unmittelbar in jedem Mitgliedstaat — eine nationale Umsetzung ist weder erforderlich noch zulässig, um ihre Anforderungen zu modifizieren.

Können wir die CIR als vollständiges Compliance-Rahmenwerk verwenden?

Nur teilweise. Für die 11 erfassten Einrichtungsarten konkretisiert die CIR die technischen und methodischen Anforderungen an die Maßnahmen nach Article 21. Meldepflichten (§ 32 BSIG), Registrierung (§ 33 BSIG) und die Pflichten der Geschäftsleitung (§ 38 BSIG) sind gesondert zu erfüllen. Für Einrichtungen außerhalb des Anwendungsbereichs kann die 13-gliedrige Struktur der CIR als Orientierung für die Maßnahmen nach § 30 BSIG dienen — ohne Rechtspflicht und ohne Gewähr, dass die Aufsicht eine bestimmte Umsetzung als ausreichend ansieht.

Was ist mit sektorspezifischen Anforderungen, die über die CIR hinausgehen?

Nach Article 4 NIS2 finden die einschlägigen NIS2-Bestimmungen keine Anwendung, soweit sektorspezifische EU-Rechtsakte Risikomanagement- oder Meldepflichten vorsehen, die in ihrer Wirkung mindestens gleichwertig sind; Erwägungsgrund 28 nennt DORA (Verordnung (EU) 2022/2554) als solchen Rechtsakt für Finanzunternehmen. In Deutschland nimmt § 28 Abs. 5 BSIG unter anderem Betreiber öffentlicher Telekommunikationsnetze bzw. -dienste und Betreiber von Energieversorgungsnetzen, Energieanlagen oder digitalen Energiediensten, die den §§ 5c bis 5e EnWG unterliegen, von § 30 BSIG aus — vorbehaltlich der dort geregelten Ausnahmen. Einrichtungen sollten daher zunächst prüfen, welches Regelwerk für sie maßgeblich ist.

Dieser Artikel dient ausschließlich der allgemeinen Information und stellt keine Rechts- oder Regulierungsberatung dar. Die Anforderungen können je nach Rechtsraum und Organisationstyp variieren. Ziehen Sie für eine auf Ihre Situation zugeschnittene Beratung einen qualifizierten Rechts- oder Compliance-Spezialisten hinzu.

Quellen

• Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024, ABl. L, 2024/2690, 18.10.2024 — Volltext (ELI/EUR-Lex)
• Richtlinie (EU) 2022/2555 (NIS2-Richtlinie), insbesondere Art. 4, 20, 21 und 23 — Volltext (ELI/EUR-Lex)
• BSI-Gesetz (BSIG) in der Fassung des NIS2UmsuCG, insbesondere §§ 2, 28, 30, 32, 33 und 38 — gesetze-im-internet.de
• ENISA: NIS2 Technical Implementation Guidance, Version 1.0, 26. Juni 2025 — ENISA-Publikationen