NIS 2 sichere Entwicklung und Beschaffung nach Artikel 21(2)(e)
NIS 2 verlangt Sicherheit über Beschaffung, Entwicklung und Wartung hinweg. Artikel 21(2)(e) ist die Klammer. CIR (EU) 2024/2690 §6 gliedert das in zehn Unterabschnitten. Deutschland setzt das über §30(2)(5) BSIG um.
Die Kurzfassung
Artikel 21(2)(e) ist die Klammer für Sicherheit über den gesamten IT-Lebenszyklus. Nicht nur Code. Nicht nur Patches. Der ganze Weg: ein System kaufen, bauen, konfigurieren, ändern, testen, patchen, betreiben, abschalten. Die Regel gilt EU-weit gleich.
CIR (EU) 2024/2690 liefert die Details. Annex §6 hat zehn Unterabschnitte (§6.1 bis §6.10), die die Pflicht operationalisieren. Diese Seite behandelt die Entwicklungs- und Änderungsseite: Beschaffung (§6.1), sicherer Entwicklungszyklus (§6.2), Konfigurationsmanagement (§6.3), Änderungsmanagement (§6.4), Sicherheitsprüfung (§6.5) und Sicherheitspatch-Management (§6.6). Netzsicherheit, Netzsegmentierung, Schutz gegen Schadsoftware und Schwachstellenmanagement (§6.7 bis §6.10) haben eigene Seiten.
Deutschland setzt die Regel über §30(2)(5) BSIG ins nationale Recht um. Der Wortlaut ist nahezu deckungsgleich mit dem EU-Text. Diese Seite geht Richtlinie, EU-Durchführungsverordnung und deutsche Umsetzung in dieser Reihenfolge durch.
Artikel 21(2)(e) NIS-2-Richtlinie (2022/2555)
Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen.
Buchstabe (e) auf der Liste der zehn Cybersicherheitsmaßnahmen, die jede wesentliche und wichtige Einrichtung umsetzen muss. Es ist der einzige Punkt der Liste, der explizit von der Bestellung bis zur Außerbetriebnahme reicht.
CIR (EU) 2024/2690, Annex §6
Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen (Artikel 21 Absatz 2 Buchstabe e der Richtlinie (EU) 2022/2555).
Weil das eine Verordnung ist (keine Richtlinie), ist sie unmittelbar geltendes EU-Recht. Keine nationale Umsetzung nötig. Sie bindet die im Annex genannten Sektoren: DNS-Anbieter, TLD-Registries, Cloud-Anbieter, Rechenzentren, Managed Service Provider und weitere. §6 hat zehn nummerierte Unterabschnitte mit je einer konkreten Pflicht.
§30(2)(5) BSIG (Deutschland)
Sicherheit beim Erwerb, der Entwicklung und der Wartung informationstechnischer Systeme einschließlich Management und Offenlegung von Schwachstellen.
Deutschland übernimmt den EU-Text nahezu wortgleich. 'Informationstechnische Systeme' statt 'Netz- und Informationssysteme' ist Formulierung, nicht Bedeutung. Das BSI verweist auf die Grundschutz-Bausteine CON.8 (Software-Entwicklung) und OPS.1.1.3 (Patch- und Änderungsmanagement) als praktischen Weg.
Sicherheitsanforderungen in jede Beschaffung
Bevor Sie ein IT-Produkt oder einen IT-Dienst kaufen, schreiben Sie die Sicherheitsanforderungen auf. Authentifizierung, Logging, Update-Unterstützung, Offenlegung von Schwachstellen, Standort des Hostings, wo die Daten liegen. Danach prüfen Sie, ob der Anbieter die Anforderungen erfüllt. Diese Pflicht liegt bei der einkaufenden Einrichtung, nicht beim Anbieter. 'Wir nutzen SaaS' verschiebt die Pflicht nicht.
Sicherer Entwicklungszyklus (SDLC)
Sicherheitsanforderungen werden in Spezifikation und Design analysiert. Sichere Programmierprinzipien gelten, einschließlich konzeptintegrierter Cybersicherheit (Security by Design) und Zero-Trust-Architekturen. Entwicklungsumgebungen sind selbst abgesichert. Sicherheitsprüfungen finden vor der Freigabe statt. Testdaten werden sorgfältig behandelt, nicht aus der Produktion kopiert. Der ganze Zyklus ist dokumentiert, nicht nur ein, zwei Praktiken.
Patches im angemessenen Zeitraum, vorher testen
Sicherheitspatches werden innerhalb eines angemessenen Zeitraums (CIR-Wortlaut) eingespielt, abhängig von der Schwere der Schwachstelle. Patches werden vor Produktion getestet. Notfall-Patches sind dokumentiert. 'Wenn das Team Zeit hat' ist kein Zeitraum. Eine Kadenz festlegen, aufschreiben, Einhaltung belegen.
Sicherheit von Beschaffung bis Außerbetriebnahme
§6 meint nicht Entwicklung im engen Sinn. Er deckt den gesamten Lebenszyklus ab: wie Sie auswählen, was Sie kaufen, wie Sie bauen, wie Sie konfigurieren, wie Sie testen, wie Sie patchen, wie Sie ändern, wie Sie abschalten. Ein Mittelständler, der 95 Prozent seiner Software zukauft, ist trotzdem für §6.1 (Beschaffungsanforderungen) und §6.6 (Patch-Management) verantwortlich. Aus dem Lebenszyklus auszusteigen, nur weil man keinen Code schreibt, geht nicht.
Änderungsdisziplin: keine ungetrackten Produktionsänderungen
§6.4 ist klar: Änderungen an der Produktion werden gesteuert, dokumentiert und geprüft. Notfalländerungen werden ebenfalls dokumentiert, nur nachträglich statt vorab. Eine Änderung ohne Ticket, ohne Freigeber und ohne Rollback-Plan erfüllt die Anforderung nicht, auch wenn sie funktioniert. Prüfer gleichen den Änderungslog mit dem Ticketsystem ab. Wenn sie nicht nachvollziehen können, wer wann was geändert hat, ist die Maßnahme nicht umgesetzt.
BSI / IT-Grundschutz CON.8 + OPS.1.1.3
Das BSI bildet §30(2)(5) BSIG auf zwei Grundschutz-Bausteine ab. CON.8 'Software-Entwicklung' deckt den SDLC ab: Anforderungen, sichere Programmierung, Test, Freigabe. OPS.1.1.3 'Patch- und Änderungsmanagement' deckt die Änderungs- und Patch-Seite ab. Wer CON.8 und OPS.1.1.3 umsetzt, liegt im Rahmen von §30 BSIG.
ENISA Technical Implementation Guidance
ENISA, die EU-Cybersicherheitsagentur, veröffentlicht eine Technical Implementation Guidance (TIG), die den abstrakten CIR-§6-Text in praktische Schritte übersetzt. Sie bildet jeden Unterabschnitt auf ISO/IEC-27001:2022-Controls ab (A.8.25 bis A.8.32 für sichere Entwicklung, A.5.20 bis A.5.23 für Lieferantenbeziehungen), sodass bestehende Zertifizierungen einen Vorsprung geben.
Nationale Umsetzungsgesetze
Jeder Mitgliedstaat hat sein eigenes Umsetzungsgesetz (Niederlande: Cyberbeveiligingswet, Österreich: NISG, Belgien: NIS2-Wet). Die Pflichten aus Artikel 21(2)(e) sind gleich, weil die Richtlinie einen EU-weiten Standard setzt. Unterschiedlich ist nur, auf welches nationale Rahmenwerk der jeweilige Regulator als praktischen Weg verweist.
Wir nutzen SaaS, sichere Entwicklung ist Sache des Anbieters.
Halb richtig. Der Anbieter besitzt den Code. Sie behalten §6.1: dokumentierte Sicherheitsanforderungen für jedes IT-Produkt und jeden IT-Dienst, plus Nachweis, dass der Anbieter sie erfüllt. Authentifizierung, Logging, Update-Unterstützung, Datenstandort, Breach-Benachrichtigung. Wenn die Beschaffungsakte leer ist, ist die Pflicht nicht erfüllt, auch wenn der Anbieter exzellent ist.
Wir machen Code-Reviews, damit ist der SDLC-Teil erledigt.
Code-Review ist eine Praktik. §6.2 verlangt den dokumentierten Gesamtzyklus: Sicherheitsanforderungen in der Spezifikation, sichere Programmierprinzipien (inkl. Security by Design und Zero Trust), abgesicherte Entwicklungsumgebungen, Sicherheitsprüfungen vor Freigabe, sorgfältige Testdatenbehandlung. Eine einzelne Praktik auf einem undokumentierten Prozess erfüllt den Abschnitt nicht.
Wir patchen, wenn das Team Zeit hat.
§6.6 verlangt einen angemessenen Zeitraum, gebunden an die Schwere, plus Test vor Produktion und Dokumentation für Notfall-Patches. 'Wenn Zeit ist' ist kein Zeitraum. Eine Kadenz festlegen (z. B. kritisch innerhalb 72 Stunden, hoch innerhalb 14 Tage), aufschreiben, Einhaltung im Änderungslog belegen. Ein Prüfer rekonstruiert Ihre Patch-Historie aus dem Ticketsystem.
Die meisten Mittelstands-IT-Landschaften sehen so aus: 90 Prozent Standardsoftware (ERP, Lohn, Mail, Fileshare, CRM), ein bisschen Integrationsklebstoff, gelegentlich interne Skripte. Die große §6-Aufgabe ist für dieses Profil nicht der SDLC. Es sind §6.1 Beschaffung und §6.6 Patch-Management.
Schreiben Sie die Vorlage für Sicherheitsanforderungen einmal. Authentifizierung, Logging, Offenlegung von Schwachstellen, Update-Unterstützung, Hosting-Region, Datenexport, Breach-Benachrichtigung. Wenden Sie sie bei jeder Neubeschaffung und jeder Verlängerung an. Kombinieren Sie das mit einer schriftlichen Patch-Kadenz (kritisch / hoch / mittel mit je einem Zeitraum) und einem Änderungslog, den alle nutzen. Das deckt den größten Teil von §6 für einen typischen Mittelständler ab, ohne einen Softwaresicherheitsspezialisten einzustellen.
Wir haben §6.1 Beschaffungsanforderungen, §6.2 SDLC-Dokumentation, §6.4 Änderungslog und §6.6 Patch-Kadenz in das PRO-Modul der Plattform eingebaut. Die Beschaffungsvorlage füllen Sie einmal und nutzen sie wieder. Jedes neue IT-Produkt und jeder neue IT-Dienst läuft durch dieselbe Sicherheitscheckliste mit Freigabe.
Änderungslog und Patch-Kadenz laufen auf demselben Audit-Trail wie der Rest der Plattform: Ticket, Freigeber, Rollback-Plan, Nachweisdatei. Notfalländerungen bekommen das nachträgliche Formular. Sie pflegen keinen separaten Compliance-Log. Wenn ein Prüfer fragt, wie Sie eine CVE gepatcht haben, ist die Antwort eine Abfrage, nicht drei Tabellen.
- Richtlinie (EU) 2022/2555 (NIS 2), Artikel 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Durchführungsverordnung (EU) 2024/2690 (CIR), Annex §6 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI-Gesetz (BSIG), §30(2)(5) in der Fassung des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes
- BSI IT-Grundschutz-Bausteine CON.8 'Software-Entwicklung' und OPS.1.1.3 'Patch- und Änderungsmanagement'
- ENISA Technical Implementation Guidance zur CIR (EU) 2024/2690 (Stand Mai 2026)