Zuletzt verifiziert: März 2026. Basierend auf ENISA Technical Implementation Guidance v1.0 (Juni 2025), Commission Implementing Regulation (EU) 2024/2690 und Directive (EU) 2022/2555 (NIS2).
Im Juni 2025 veröffentlichte die Agentur der Europäischen Union für Cybersicherheit (ENISA) das wohl bedeutendste praxisorientierte Dokument zur NIS2-Compliance bis dato: die Technical Implementation Guidance on Cybersecurity Risk Management Measures — ein 170-seitiges Begleitdokument zur Commission Implementing Regulation (EU) 2024/2690.
Wenn Sie verstehen möchten, was NIS2 von Ihnen konkret verlangt — und nicht nur, was darin steht — ist dieses Dokument die maßgebliche Antwort. Dieser Artikel fasst alle 13 Abschnitte der ENISA-Leitlinien zusammen, extrahiert die wichtigsten umsetzbaren Empfehlungen und erläutert die Zuordnung zu Ihren Compliance-Pflichten. Ohne dass Sie selbst 170 Seiten amtlicher Leitlinien lesen müssen.
Was sind die ENISA Technical Implementation Guidance?
Die ENISA-Leitlinien sind ein unverbindliches Begleitdokument zur Commission Implementing Regulation (EU) 2024/2690 (der CIR). Während die CIR festlegt, welche Sicherheitsmaßnahmen Einrichtungen umsetzen müssen (und rechtsverbindlich ist), erläutern die ENISA-Leitlinien, wie diese Maßnahmen in der Praxis umzusetzen sind.
Betrachten Sie das Dokument als offizielles, von der EU gebilligtes Umsetzungshandbuch. ENISA hat aktuelle Standards ausgewertet, die Fachkenntnisse der Mitgliedstaaten über die NIS-Kooperationsgruppe einbezogen, eine öffentliche Konsultation (November 2024 – Januar 2025) durchgeführt und Umsetzungsansätze erarbeitet, die verhältnismäßig, risikobasiert und auditierbar sind.
Wesentliche Fakten zu den Leitlinien:
- Veröffentlicht: 26. Juni 2025 (Version 1.0)
- Herausgeber: ENISA, in Zusammenarbeit mit der Europäischen Kommission und den EU-Mitgliedstaaten
- Vollständiger Titel: Technical Implementation Guidance on Cybersecurity Risk Management Measures
- Umfang: ca. 170 Seiten
- Rechtsstatus: Unverbindlich — empfohlene Best Practice, ausdrücklich beschrieben als “kein rechtsverbindliches Dokument”
- Struktur: Folgt der exakten 13-Abschnitte-Struktur des CIR-Anhangs
- Referenzierte Standards: ISO 27001/27002, NIST CSF 2.0, BSI Grundschutz, ANSSI-Leitlinien, IEC 62443, ETSI EN 319 401, CEN/TS 18026:2024
- Begleitdokumente: Mapping Table (Excel, v1.2 — ordnet CIR-Anforderungen ISO 27001, NIST CSF 2.0 und ETSI-Standards zu) sowie Cybersecurity Roles and Skills for NIS2 Essential and Important Entities
Obwohl die Leitlinien unverbindlich sind und “nicht beabsichtigen, von Mitgliedstaaten bereitgestellte Rahmenwerke zu ersetzen”, wird allgemein erwartet, dass die nationalen zuständigen Behörden in der gesamten EU sie als primären Maßstab heranziehen, wenn sie beurteilen, ob eine Einrichtung “geeignete und verhältnismäßige Sicherheitsmaßnahmen” umgesetzt hat. ENISA selbst bezeichnet das Dokument als “lebendes Dokument”, das künftig aktualisiert wird, sobald Umsetzungserfahrungen vorliegen. In der Praxis handelt es sich damit um den nächstmöglichen offiziellen Compliance-Standard, den NIS2 derzeit bietet [1] [2].
Eine vollständige Übersicht der zugrunde liegenden Richtlinienpflichten finden Sie in unserem Leitfaden NIS2-Richtlinie erklärt. Die detaillierten rechtlichen Anforderungen finden Sie in der Übersicht der NIS2-Anforderungen.
Für wen sind diese Leitlinien bestimmt?
Die CIR 2024/2690 gilt speziell für eine definierte Gruppe von Einrichtungstypen, und die ENISA-Leitlinien richten sich technisch gesehen an dieselben Einrichtungen. ENISA empfiehlt die Leitlinien jedoch ausdrücklich als nützlich für alle NIS2-Einrichtungen, unabhängig von Sektor oder Einrichtungstyp.
Einrichtungen, die direkt der CIR unterliegen (und für die die Befolgung der Leitlinien in der Praxis am nächsten an eine Pflicht heranreicht):
- DNS-Dienstanbieter
- Registrierungsstellen für Domänennamen der obersten Stufe (TLD)
- Anbieter von Cloud-Computing-Diensten
- Rechenzentrumsbetreiber
- Anbieter von Content Delivery Networks (CDN)
- Anbieter verwalteter Dienste (MSPs)
- Anbieter verwalteter Sicherheitsdienste (MSSPs)
- Online-Marktplätze
- Online-Suchmaschinen
- Plattformen sozialer Netzwerke
- Vertrauensdiensteanbieter
Einrichtungen, die nicht direkt der CIR unterliegen (für die ENISA die Leitlinien jedoch empfiehlt):
- Alle anderen wesentlichen und wichtigen Einrichtungen gemäß NIS2 — Energie, Verkehr, Bankwesen, Gesundheitswesen, Wasser, digitale Infrastruktur und mehr
- KMU, denen die interne Cybersicherheitskompetenz fehlt, um NIS2-Anforderungen eigenständig zu interpretieren
- Organisationen, die sich auf NIS2-Audits oder Lieferantenbewertungen vorbereiten
Für KMU insbesondere sind die ENISA-Leitlinien wertvoll, weil sie abstrakte regulatorische Sprache in konkrete Maßnahmen übersetzen und auf etablierte Standards verweisen. Damit entfällt die Interpretationslast, die andernfalls teure externe Beratung erfordern würde.
Nationale Behörden werden diese Leitlinien voraussichtlich auch bei Aufsichtsprüfungen heranziehen. Wenn Ihre Umsetzung weitgehend mit den ENISA-Empfehlungen übereinstimmt, belegen Sie damit guten Willen und verhältnismäßige Bemühungen — was entscheidend ist, wenn Behörden die Compliance gemäß Article 21 NIS2 beurteilen. Prüfen Sie zunächst, ob Ihre Organisation in den NIS2-Anwendungsbereich fällt.
Zuordnung der Leitlinien zu CIR 2024/2690
Die ENISA-Leitlinien spiegeln den CIR-Anhang Abschnitt für Abschnitt wider. Für jede Anforderung der CIR stellen die Leitlinien drei Elemente bereit:
- Leitlinien — zusätzliche Hinweise, Erläuterungen von Konzepten und Tipps zu Aspekten, die bei der Umsetzung jeder Anforderung zu berücksichtigen sind
- Nachweisbeispiele — was Sie Prüfern oder Aufsichtsbehörden vorlegen könnten, um die Compliance nachzuweisen
- Tipps — praxisorientierte Empfehlungen und häufige Fallstricke, die es zu vermeiden gilt
Die nachstehende Tabelle zeigt die strukturelle Zuordnung zwischen dem CIR-Anhang, den Maßnahmen gemäß NIS2 Article 21 und den wesentlichen Ergänzungen, die ENISA bereitstellt:
| CIR-Anhang-Abschnitt | Thema | Art. 21 Ref. | Wesentliche ENISA-Ergänzungen |
|---|---|---|---|
| Section 1 | Sicherheitsrichtlinien | 21(2)(a) | Hierarchisches Richtlinienrahmenwerk; Genehmigung durch das Management; jährlicher Überprüfungszyklus |
| Section 2 | Risikomanagement | 21(2)(a) | Asset-basierte Methodik; Integration von Bedrohungsdaten; Auslöser für Überprüfungen |
| Section 3 | Incident-Handling | 21(2)(b) | SIEM/Protokollverwaltung; Schweregrad-Matrix; Playbooks; Nachbesprechung von Vorfällen |
| Section 4 | Betriebskontinuität | 21(2)(c) | BIA-gestützte RTOs/RPOs; 3-2-1-Backup-Regel; Tabletop-Übungen |
| Section 5 | Lieferkette | 21(2)(d) | Stufenweise Klassifizierung; Prüfungsrecht; kontinuierliches Monitoring; FOSS-Erwägungen |
| Section 6 | Sichere Entwicklung | 21(2)(e) | Secure SDLC; SAST/DAST in CI/CD; Schwachstellenoffenlegung; CIS/DISA-Härtung |
| Section 7 | Wirksamkeitsbewertung | 21(2)(f) | KPIs/KRIs pro Bereich; vierteljährlicher Zyklus; unabhängiges Audit jährlich |
| Section 8 | Schulung und Sensibilisierung | 21(2)(g) | Rollenbasierte Matrix; Phishing-Simulation; managementspezifische Schulung |
| Section 9 | Kryptografie | 21(2)(h) | Zugelassene Algorithmen-Liste; Schlüssel-Lebenszyklus; Post-Quantum-Roadmap |
| Section 10 | Personalsicherheit | 21(2)(i) | Überprüfung vor der Einstellung; JML-Prozess; Sicherheit in Stellenbeschreibungen |
| Section 11 | Zugangskontrolle | 21(2)(i)(j) | Zero-Trust-Prinzipien; verpflichtende MFA; vierteljährliche Zugriffsüberprüfungen |
| Section 12 | Asset-Management | 21(2)(i) | Automatisierte Erkennung; 4-stufige Klassifizierung; CMDB mit Eigentümerzuordnung |
| Section 13 | Physische Sicherheit | — | Sicherheitszonen; Umgebungsüberwachung; Besuchermanagement |
ENISA veröffentlicht außerdem eine begleitende Mapping Table (Excel-Format, v1.2 vom September 2025), die jede CIR-Anforderung den entsprechenden Kontrollen in ISO 27001:2022, NIST CSF 2.0 und ETSI EN 319 401 zuordnet. ENISA weist ausdrücklich darauf hin, dass diese Zuordnung “nicht als Äquivalenznachweis zu interpretieren ist” — sie zeigt relevante Anforderungen auf, ohne zu beurteilen, ob diese die CIR-Anforderungen vollständig abdecken [1].
Den vollständigen Text jeder CIR-Anforderung finden Sie in unserer Übersicht der NIS2-Anforderungen.
Wesentliche Empfehlungen nach Abschnitt
Nachfolgend finden Sie die ENISA-Empfehlungen für jeden der 13 Abschnitte — die praxisorientierte Substanz hinter jeder Anforderung.
Section 1 — Sicherheitsrichtlinien
ENISA empfiehlt ein hierarchisches Richtlinienrahmenwerk: eine übergeordnete Informationssicherheitsrichtlinie, die von der Geschäftsleitung formell genehmigt wurde und mit themenspezifischen Richtlinien verknüpft ist (Zugangskontrolle, Incident Response, Kryptografie usw.). Richtlinien sollten mindestens in einem jährlichen Zyklus überprüft werden, oder nach schwerwiegenden Vorfällen bzw. Infrastrukturänderungen, wobei für jedes Dokument ein benannter Richtlinienverantwortlicher zuständig ist. Ein Richtlinien-Sensibilisierungsprogramm sollte sicherstellen, dass alle relevanten Mitarbeitenden die für sie geltenden Richtlinien gelesen und bestätigt haben. ENISA weist ausdrücklich darauf hin, dass Richtlinien das tatsächliche Risikoumfeld der Organisation widerspiegeln sollten und keine generischen Vorlagen sein dürfen — ein Punkt, den nationale Behörden genau prüfen werden. Die notwendigen Ressourcen (Personal, Finanzmittel, Prozesse, Werkzeuge) müssen explizit bereitgestellt werden [1].
Section 2 — Risikomanagement
ENISA empfiehlt eine dokumentierte Risikobeurteilungsmethodik mit expliziten Kriterien für die Risikoakzeptanz und vier definierten Behandlungsoptionen: Vermeidung, Minderung, Transfer/Teilung und Akzeptanz. Die Methodik sollte einen gefahrenübergreifenden Ansatz verfolgen, der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit berücksichtigt. Bedrohungsdaten sollten integriert werden — ENISA nennt MITRE ATT&CK und sektorspezifische Bedrohungsberichte als Eingaben. Die Auslöser für Überprüfungen gehen über den jährlichen Zyklus hinaus: Risikobeurteilungen sollten auch nach schwerwiegenden Vorfällen, größeren Infrastrukturänderungen oder beim Auftreten neuer relevanter Bedrohungsdaten erneut vorgenommen werden. Unabhängige Überprüfungen, die Personen, Prozesse und Technologien umfassen, werden in geplanten Intervallen erwartet [1].
Section 3 — Incident Handling
ENISA empfiehlt zentralisiertes Log-Management oder SIEM als Grundlage für die Erkennungsfähigkeit. Ein Kategorisierungssystem basierend auf betrieblicher Auswirkung, Datensensibilität, Umfang und Angriffstyp sollte eingerichtet werden, bevor ein Vorfall eintritt. Vorab erstellte Playbooks für häufige Vorfalltypen (Ransomware, Phishing, Datenpanne, DDoS) werden nachdrücklich empfohlen. Nachbesprechungen von Vorfällen sollten gewonnene Erkenntnisse erfassen und sowohl in das Risikoregister als auch in Erkennungsanwendungsfälle einfließen. Die Leitlinien betonen die Kohärenz zwischen den Incident-Handling-Verfahren und dem NIS2-Meldefristen (24-Stunden-Frühwarnung, 72-Stunden-Meldung, Abschlussbericht nach 1 Monat) sowie den Notfallplänen zur Betriebskontinuität [1].
Section 4 — Betriebskontinuität
ENISA empfiehlt eine Business Impact Analysis (BIA) als Grundlage für das BCM, mit dokumentierten Recovery Time Objectives (RTOs) und Recovery Point Objectives (RPOs) pro kritischem Dienst. Die Backup-Strategie sollte der 3-2-1-Regel folgen: drei Kopien, auf zwei verschiedenen Medientypen, mit einer Kopie an einem externen Standort — zuzüglich mindestens einer unveränderlichen (schreibgeschützten) Kopie zum Schutz vor Ransomware. Die Integrität externer Backups muss regelmäßig überprüft werden. Krisenmanagement wird als eigenständiger Prozess vom Betriebskontinuitätsmanagement unterschieden und befasst sich mit Bedrohungen für die organisatorische Überlebensfähigkeit. Tabletop-Übungen sollten mindestens einmal jährlich durchgeführt werden. Die Leitlinien orientieren sich an ISO 22301, ISO 22313 und NIST SP 800-34 Rev. 1 [1].
Section 5 — Lieferkettensicherheit
ENISA empfiehlt eine stufenweise Lieferantenklassifizierung: Kategorisieren Sie Lieferanten nach ihrem Zugang zu Ihren Systemen und Daten, mit verschärften Anforderungen für kritische und hochriskante Lieferanten. Auswahlkriterien sollten Cybersicherheitspraktiken in den Vordergrund stellen. Verträge mit kritischen Lieferanten sollten Prüfungsrechtsklauseln und Anforderungen zur Meldung von Sicherheitsvorfällen enthalten. Kontinuierliches Monitoring der Sicherheitslage kritischer Lieferanten wird empfohlen, anstatt nur Momentaufnahmen durchzuführen. Bemerkenswert ist, dass ENISA anerkennt, dass vertragliche Sicherheitspflichten möglicherweise nicht für Free/Open Source Software (FOSS)-Gemeinschaften gelten — eine praktische Realität, die Beschaffungsrichtlinien berücksichtigen müssen. Einrichtungen sollten ein aktuelles Register aller direkten Lieferanten und Dienstleister führen [1].
Section 6 — Sichere Entwicklung und Beschaffung
Dies ist der umfangreichste Abschnitt der ENISA-Leitlinien und umfasst mehrere Unterabschnitte: sichere Beschaffung, Secure Software Development Lifecycle (SSDLC), Konfigurationsmanagement, Änderungsmanagement, Sicherheitstests, Patch-Management, Netzwerksicherheit, Netzwerksegmentierung, Malware-Schutz, Schwachstellenmanagement und Legacy-Systeme. Wesentliche Highlights: Automatisierte Sicherheitstests (SAST/DAST) sollten in CI/CD-Pipelines integriert werden. Die Konfigurationshärtung sollte den CIS Benchmarks oder DISA STIGs folgen, mit dokumentierten sicheren Basiskonfigurationen. Kritische Systeme sollten monatlich überprüft werden. Für extern zugängliche Systeme wird eine Richtlinie zur Schwachstellenoffenlegung empfohlen. Für Legacy-Systeme, die nicht gepatcht werden können, sind kompensierende Maßnahmen einschließlich Netzwerksegmentierung, Angriffserkennung und erweitertem Schwachstellen-Scanning erforderlich [1].
Section 7 — Wirksamkeitsbewertung
ENISA empfiehlt die Definition von KPIs und KRIs pro Sicherheitsbereich — beispielsweise mittlere Erkennungszeit (MTTD), mittlere Reaktionszeit (MTTR), Prozentsatz der Systeme mit aktuellen Patches, Klickraten bei Phishing-Simulationen. Zu den Methoden gehören Selbstbewertung, Benchmarking, Penetrationstests, Code-Review und formale Audits. Eine unabhängige Bewertung sollte mindestens einmal jährlich stattfinden. Die Ergebnisse sollten direkt in den Risikomanagementprozess einfließen und Korrekturmaßnahmen auslösen. Richtlinien sollten mindestens alle zwei Jahre überprüft werden [1].
Section 8 — Schulung und Sensibilisierung
ENISA empfiehlt eine rollenbasierte Schulungsmatrix: Sicherheitsbewusstseinstraining für alle Mitarbeitenden, das sicheres E-Mail-Verhalten, Phishing-Erkennung, mobile Sicherheit, Patching und Telearbeit abdeckt — sowie spezialisierte Schulungen für IT-/Sicherheitsteams und managementspezifische Schulungen zu NIS2-Pflichten und persönlicher Haftung. Ein Phishing-Simulationsprogramm wird ausdrücklich empfohlen. Neuen Mitarbeitenden sollte zeitnah eine Sicherheitseinführungsschulung angeboten werden. Die Schulungseffektivität sollte durch Vor-/Nachtests und Klickraten-Trends gemessen werden. Die Leitlinien unterscheiden zwischen breiter Sensibilisierung (alle Beschäftigten) und gezielten Sicherheitsschulungen (Personen mit Sicherheitsverantwortung) [1].
Section 9 — Kryptografie und Schlüsselmanagement
ENISA empfiehlt die Festlegung von Typ-, Stärke- und Qualitätsanforderungen für ruhende und übertragene Daten und die Pflege einer Liste zugelassener Algorithmen, die an den technischen Richtlinien des BSI, den ANSSI-Empfehlungen und NIST-Standards ausgerichtet ist. Ein “kryptografischer Agilitätsansatz” wird empfohlen — die Fähigkeit, Algorithmen zu wechseln, wenn Schwachstellen entdeckt werden oder sich Standards ändern. Das Schlüssel-Lifecycle-Management sollte Generierung, Speicherung, Verteilung, Rotation, Widerruf, Wiederherstellung und Vernichtung umfassen. Das Zertifikatsmanagement sollte automatisiertes Erneuerungsmonitoring beinhalten, um auslaufungsbedingte Ausfälle zu verhindern. ENISA weist ausdrücklich auf die Notwendigkeit hin, eine Post-Quantum-Kryptografie-Roadmap zu entwickeln, und erkennt an, dass Migrationszeiträume lang sind und die Planung jetzt beginnen sollte [1].
Section 10 — Personalsicherheit
ENISA empfiehlt eine Überprüfung vor der Einstellung, die der Sensibilität der Rolle angemessen ist, mit erweiterter Überprüfung (Hintergrundverifizierung) für Stellen mit Zugang zu kritischen Systemen oder sensiblen Daten. Sicherheitsverantwortlichkeiten sollten in allen Stellenbeschreibungen dokumentiert sein und nicht nachträglich ergänzt werden. Der Joiner-Mover-Leaver (JML)-Prozess ist eine zentrale Empfehlung: definierte Verfahren für die Bereitstellung von Zugang beim Eintritt, die Anpassung von Zugang bei einem Rollenwechsel und die unverzügliche Sperrung von Zugang beim Ausscheiden. Verantwortlichkeiten bleiben nach Beschäftigungsänderungen oder Beendigung des Arbeitsverhältnisses gültig. Ein klares Disziplinarverfahren bei Verstößen gegen Sicherheitsrichtlinien sollte eingerichtet und kommuniziert werden [1].
Section 11 — Zugangskontrolle
ENISA empfiehlt die Anwendung von Zero-Trust-Prinzipien wo durchführbar — als Standardansatz Need-to-know, minimale Zugriffsrechte und Aufgabentrennung. Verpflichtende MFA ist für alle privilegierten Zugänge (Admin-Konten) und alle Remote-Zugänge erforderlich — ohne Ausnahmen. Dedizierte Admin-Konten müssen von regulären Benutzerkonten getrennt sein. Gemeinsam genutzte Identitäten sollten nur mit ausdrücklicher dokumentierter Genehmigung erlaubt sein. Der Zugang zu kritischen Systemen sollte vierteljährlich überprüft werden. Privileged Access Workstations (PAWs) werden für administrative Aufgaben empfohlen. Das Sitzungsmanagement sollte eine automatische Beendigung nach Inaktivität umfassen. Ein Register aller gewährten Zugriffsrechte muss geführt werden [1].
Section 12 — Asset-Management
ENISA empfiehlt die Führung eines vollständigen, genauen und kontinuierlich aktualisierten Asset-Inventars — vorzugsweise mithilfe automatisierter Erkennungstools anstatt manueller Tabellenkalkulationen. Assets sollten anhand definierter Stufen basierend auf Vertraulichkeit, Integrität, Authentizität und Verfügbarkeit klassifiziert werden, mit Handhabungsanforderungen pro Stufe. Das Asset-Lifecycle-Management sollte die Beschaffung bis hin zur sicheren Entsorgung umfassen — einschließlich unwiderruflicher Löschung oder physischer
