NIS2 Sichere Entwicklung: Abschnitt 6 im Anhang der CIR 2024/2690 und § 30 BSIG im SDLC umsetzen

Viele Unternehmen behandeln NIS2-Konformität als Sammlung isolierter Projekte – ein Risikomanagementrahmen hier, ein Incident-Response-Plan dort. Abschnitt 6 des Anhangs zur Durchführungsverordnung (EU) 2024/2690 zeigt, warum dieser Ansatz zu kurz greift: Die Verordnung behandelt den IKT-Lebenszyklus zusammenhängend, von der Beschaffungsentscheidung (6.1) über den Entwicklungsprozess (6.2) bis zum Sicherheitspatch-Management (6.6) und zur Behandlung von Schwachstellen (6.10). Wer diese Einheit zerstückelt, riskiert Lücken, die oft erst bei einer Prüfung oder nach einem Sicherheitsvorfall sichtbar werden.

Dieser Leitfaden zeigt, welche konkreten Maßnahmen Abschnitt 6 verlangt, für welche Einrichtungen er verbindlich ist, wie BSI IT-Grundschutz (CON.8, APP.7) und die BSI TR-03185 bei der Umsetzung helfen können und welche sieben Nachweise sich für die Dokumentation von Abschnitt 6 anbieten.

Dieser Artikel dient der allgemeinen Information und stellt keine Rechts- oder Compliance-Beratung dar. Anforderungen variieren je nach Einrichtungstyp, Sektor und nationalem Umsetzungsrecht. Konsultieren Sie für Ihren konkreten Fall einen qualifizierten Rechts- oder Compliance-Experten.

Rechtlicher Rahmen: Wer muss Abschnitt 6 umsetzen?

Artikel 21 Absatz 2 Buchstabe e der NIS2-Richtlinie (EU) 2022/2555 verlangt von wesentlichen und wichtigen Einrichtungen Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen – einschließlich Management und Offenlegung von Schwachstellen. In Deutschland setzt § 30 Abs. 2 Satz 2 Nr. 5 BSIG dies um: Besonders wichtige und wichtige Einrichtungen müssen „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen“ ergreifen [8]. Die Durchführungsverordnung (EU) 2024/2690 (CIR 2024/2690) konkretisiert diese Vorgabe technisch – allerdings nur für eine klar abgegrenzte Gruppe von Einrichtungen.

Wer ist direkt durch CIR 2024/2690 gebunden?

Die CIR 2024/2690 gilt nach ihrem Artikel 1 für elf Einrichtungsarten: DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Content Delivery Networks (CDN), Managed Service Provider (MSP), Managed Security Service Provider (MSSP), Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke sowie Vertrauensdiensteanbieter [1][6]. Für diese Einrichtungsarten hat die Durchführungsverordnung nach § 30 Abs. 3 BSIG Vorrang [8].

Alle anderen besonders wichtigen und wichtigen Einrichtungen – etwa Krankenhäuser, Wasserversorger, Verkehrsunternehmen oder Hersteller – unterliegen § 30 BSIG in der Fassung des NIS2UmsuCG (in Kraft seit 6. Dezember 2025), ohne dass die CIR 2024/2690 für sie rechtsverbindlich ist. Das BSI stellt klar: „Alle anderen Sektoren sind nicht von der Durchführungsverordnung betroffen“ [6]. Für einige Gruppen gelten zudem Sonderregeln: Für Finanzunternehmen im Anwendungsbereich von DORA, für Betreiber öffentlicher Telekommunikationsnetze und Anbieter öffentlich zugänglicher Telekommunikationsdienste sowie für Energieanlagen- und Netzbetreiber, die den §§ 5c bis 5e EnWG unterliegen, gilt § 30 BSIG nach § 28 Abs. 5 und 6 BSIG nicht. Als Orientierungshilfe ist Abschnitt 6 dennoch nützlich: Das BSI gliedert die Standard-Übersicht in seinem #nis2know-Infopaket zu § 30 Abs. 2 Satz 2 Nr. 5 BSIG nach den Unterabschnitten der CIR – ausdrücklich nur zur „verbesserten Darstellung des Mappings“ [2].

Abschnitt 6 im Überblick – zehn Unterabschnitte

Abschnitt 6 gliedert sich in zehn Unterabschnitte, die den gesamten IKT-Lebenszyklus abdecken (Bezeichnungen nach der amtlichen deutschen Fassung) [1]:

• 6.1 Sicherheitsmaßnahmen beim Erwerb von IKT-Diensten oder IKT-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
• 6.10 Behandlung und Offenlegung von Schwachstellen

Dieser Leitfaden behandelt schwerpunktmäßig 6.1 bis 6.6 – die Unterabschnitte, die den Lebenszyklus von der Beschaffungsentscheidung bis zur Wartung abdecken. Einen vollständigen Überblick über die Verordnung bietet unser Leitfaden zur NIS2-Durchführungsverordnung. Die zehn Risikomanagementmaßnahmen nach Artikel 21, darunter Maßnahme (e) zur Beschaffungs- und Entwicklungssicherheit, erläutert unser Artikel zu den NIS2-Anforderungen.

Abschnitt 6.1 – Sicherheit in der IKT-Beschaffung

Bevor eine Einrichtung ein IKT-Produkt erwirbt oder einen IKT-Dienst beauftragt, muss sie nach Nummer 6.1.1 Prozesse festlegen und umsetzen, mit denen sie die Risiken aus dem Erwerb von IKT-Diensten oder IKT-Produkten für sicherheitskritische Komponenten steuert – gestützt auf die Risikobewertung nach Nummer 2.1 und über den gesamten Lebenszyklus. Die Grundannahme: Viele Sicherheitslücken entstehen nicht intern, sondern werden durch unsichere Drittkomponenten eingeschleppt. Abschnitt 6.1 soll diesen Einfallsweg an der Quelle schließen [1].

Erstens müssen die Prozesse Sicherheitsanforderungen an die zu erwerbenden Produkte und Dienste enthalten – einschließlich Anforderungen an Sicherheitsupdates während der gesamten Lebensdauer oder an einen Austausch nach Ende des Supportzeitraums (6.1.2 Buchst. a und b). Die entscheidende Prüffrage lautet: Wie lange liefert der Anbieter Sicherheits-Patches? Was geschieht beim End-of-Life?

Zweitens verlangt 6.1.2 Informationen über die verwendeten Hardware- und Softwarekomponenten sowie über die implementierten Cybersicherheitsfunktionen und die für einen sicheren Betrieb erforderliche Konfiguration (Buchst. c und d) – ein naheliegender Anknüpfungspunkt für Software-Stücklisten (SBOM), auf die wir im Abschnitt zu DevSecOps zurückkommen. Drittens müssen die Prozesse sowohl eine Zusicherung vorsehen, dass die Produkte die Sicherheitsanforderungen erfüllen (Buchst. e), als auch Methoden, mit denen die Einrichtung validiert, ob die gelieferten Produkte und Dienste den Anforderungen entsprechen, und die Ergebnisse dokumentiert (Buchst. f). Eine Zusicherung des Anbieters allein genügt also nicht [1].

Nach Nummer 6.1.3 sind die Beschaffungsprozesse in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen zu überprüfen und gegebenenfalls zu aktualisieren. Anbieter, die heute sichere Produkte liefern, tun dies nicht zwangsläufig in drei Jahren – das Risikobild ändert sich. Einen festen Turnus schreibt die Verordnung nicht vor; viele Einrichtungen überprüfen kritische Lieferantenbeziehungen etwa jährlich und legen das Intervall risikobasiert fest.

Abschnitt 6.2 – Sicherer Entwicklungszyklus: Die sechs Pflichtmaßnahmen

Abschnitt 6.2 ist der regulatorische Kern der sicheren Entwicklung nach NIS2. Die Vorgabe: Vor der Entwicklung eines Netz- und Informationssystems, einschließlich Software, müssen Vorschriften für die sichere Entwicklung festgelegt und angewendet werden – sowohl bei interner Entwicklung als auch bei der Auslagerung an externe Dienstleister [1].

6.2.1 – Sicherheitsvorschriften für alle Entwicklungsphasen

Die Vorschriften gelten für alle Entwicklungsphasen, einschließlich Spezifikation, Konzeption, Entwicklung, Umsetzung und Tests. Eine bestimmte Vorgehensmethodik schreibt die Verordnung nicht vor – Wasserfall, Agile und DevOps sind gleichermaßen möglich. Entscheidend ist, dass Sicherheit in jeder Phase adressiert wird und dies nachvollziehbar dokumentiert ist [1].

6.2.2 – Die sechs Pflichtmaßnahmen im Detail

Nummer 6.2.2 verpflichtet die betreffenden Einrichtungen zu sechs Maßnahmen (Buchstaben a bis f) [1]:

1. Analyse der Sicherheitsanforderungen in der Spezifikations- und Entwurfsphase (a): Sie ist für jedes Entwicklungs- oder Beschaffungsvorhaben vorzunehmen, das die Einrichtung selbst oder in ihrem Auftrag durchführt – nicht als nachträglicher Audit-Punkt. Methoden wie Threat Modeling (etwa nach STRIDE oder PASTA) machen in dieser Phase sichtbar, welche Angriffsflächen eine geplante Systemarchitektur eröffnet und wo kritische Abhängigkeiten entstehen. Die Verordnung schreibt keine bestimmte Methode vor; ein Threat Model vor dem ersten Code-Commit ist aber in der Regel deutlich günstiger als die Behebung einer Schwachstelle nach dem Deployment.
2. Grundsätze für sichere Systeme und sicheres Programmieren (b): Bei allen Entwicklungstätigkeiten sind Grundsätze für den Aufbau sicherer Systeme und für sicheres Programmieren anzuwenden. Die Verordnung nennt beispielhaft („wie etwa“) die Förderung konzeptintegrierter Cybersicherheit (Security by Design) und Null-Vertrauen-Architekturen (Zero Trust). Zero Trust bedeutet: Kein System, kein Nutzer, keine Komponente erhält automatisch Vertrauen – jede Verbindung wird authentifiziert und autorisiert, unabhängig vom Netzwerksegment oder Standort. Dieser Ansatz ersetzt die überholte Perimeter-Annahme, dass alles innerhalb des Unternehmensnetzes sicher sei.
3. Sicherheitsanforderungen an Entwicklungsumgebungen (c): Entwicklungsumgebungen sind ein häufig übersehener Einstiegspunkt für Angreifer. Kompromittierte Build-Systeme oder Code-Repositories können Schadcode in die Produktionssoftware einschleusen, ohne dass Entwickler es bemerken (Supply-Chain-Angriff). Die Verordnung verlangt, dass Sicherheitsanforderungen an Entwicklungsumgebungen festgelegt werden; typische Inhalte sind abgesicherte Build-Systeme, geschützte Code-Repositories und rollenbasierte Zugriffskontrolle. Ergänzend verlangt Nummer 6.8.2 Buchst. h, Produktionssysteme von Entwicklungs- und Testsystemen zu trennen.
4. Sicherheitstestverfahren im Entwicklungszyklus (d): Sicherheitstests sind in den Entwicklungsablauf einzuführen und umzusetzen – nicht nur als abschließendes Sicherheits-Review. In der Praxis gehören dazu häufig statische Codeanalyse (SAST) und dynamische Anwendungstests (DAST). Je später eine Schwachstelle gefunden wird, desto aufwendiger ist in der Regel ihre Behebung.
5. Daten über Sicherheitstests (e): Daten über bzw. für Sicherheitstests sind angemessen auszuwählen, zu schützen und zu verwalten. Testergebnisse und Befunde können selbst sensible Informationen über Schwachstellen enthalten.
6. Bereinigung und Anonymisierung von Testdaten (f): Testdaten sind entsprechend der Risikobewertung nach Nummer 2.1 zu bereinigen und zu anonymisieren. Wer personenbezogene Produktionsdaten unverändert zu Testzwecken nutzt, riskiert zudem Probleme nach der DSGVO.

6.2.3 – Ausgelagerte Entwicklung

Wird Entwicklung extern vergeben, wenden Einrichtungen zusätzlich die Grundsätze und Verfahren aus Nummer 5 (Sicherheit der Lieferkette) und Nummer 6.1 (Erwerb von IKT-Diensten und IKT-Produkten) an [1]. In der Praxis bedeutet das meist, dass Entwicklungsverträge Sicherheitsanforderungen an den Entwicklungsprozess ausdrücklich regeln – etwa Secure-Coding-Vorgaben, Testpflichten und die Lieferung von Komponenteninformationen bzw. einer SBOM durch den Dienstleister.

6.2.4 – Regelmäßige Überprüfung

Die Vorschriften für die sichere Entwicklung sind in geplanten Zeitabständen zu überprüfen und erforderlichenfalls zu aktualisieren [1]. Das Bedrohungsumfeld ändert sich schnell – eine Entwicklungsrichtlinie von 2022 ist 2026 möglicherweise nicht mehr ausreichend. Ein konkretes Intervall legt die Verordnung nicht fest; ein jährlicher Review-Zyklus der SDLC-Sicherheitsrichtlinie ist ein verbreiteter Ansatz.

Konfiguration, Änderungsmanagement und Patches – Abschnitte 6.3, 6.4 und 6.6

Diese drei Unterabschnitte verlängern die Sicherheitsanforderungen in den Betrieb. Sie sind konzeptionell Teil des Entwicklungslebenszyklus: Was entwickelt und beschafft wird, muss auch sicher konfiguriert, kontrolliert geändert und zeitnah gepflegt werden [1].

6.3 Konfigurationsmanagement: Konfigurationen, einschließlich Sicherheitskonfigurationen von Hardware, Software, Diensten und Netzen, müssen festgelegt, dokumentiert, umgesetzt und überwacht werden (6.3.1). Nach 6.3.2 sind zudem Prozesse und Werkzeuge erforderlich, die die festgelegten sicheren Konfigurationen sowohl bei neu installierten Systemen als auch im laufenden Betrieb durchsetzen. Typische Maßnahmen nennt das BSI in seinem Infopaket: Änderung von Standardkonfigurationen und Standardpasswörtern sowie Deaktivierung oder Entfernung nicht benötigter Dienste, Schnittstellen und Benutzerkonten [2]. Konfigurationen sind in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen oder erheblichen Änderungen des Betriebs oder der Risiken zu überprüfen (6.3.3).

6.4 Änderungsmanagement: Die Verfahren gelten für Releases, Modifikationen und Notfalländerungen an Software und Hardware im Betrieb sowie für Konfigurationsänderungen. Änderungen müssen dokumentiert und – auf Grundlage der Risikobewertung – vor der Umsetzung getestet und auf ihre möglichen Auswirkungen bewertet werden (6.4.2). Konnte das reguläre Verfahren wegen eines Notfalls nicht eingehalten werden, sind das Ergebnis der Änderung und die Begründung für die Abweichung zu dokumentieren (6.4.3). Undokumentierte Änderungen sind ein klassischer Prüfungsbefund.

6.6 Sicherheitspatch-Management: Sicherheitspatches müssen innerhalb einer angemessenen Frist nach ihrer Verfügbarkeit eingespielt, vor dem Einsatz in Produktionssystemen getestet und auf vertrauenswürdige Herkunft und Integrität geprüft werden (6.6.1). Ist ein Patch nicht verfügbar oder wird er nicht eingespielt, sind zusätzliche Maßnahmen umzusetzen und Restrisiken zu akzeptieren. Auf einen Patch verzichten darf eine Einrichtung, wenn die Nachteile die Vorteile für die Cybersicherheit überwiegen – sie muss dies aber ordnungsgemäß dokumentieren und begründen (6.6.2). Bekannte Schwachstellen ohne dokumentierte Entscheidung oder Behebungsplan sind daher bei Prüfungen ein naheliegender Kritikpunkt [1].

BSI IT-Grundschutz und TR-03185 als Umsetzungsrahmen

Für deutsche Einrichtungen bietet das BSI zwei komplementäre Rahmenwerke, die bei der praktischen Umsetzung von Abschnitt 6 helfen können.

BSI IT-Grundschutz: CON.8 und APP.7

Der Baustein CON.8 (Software-Entwicklung) des IT-Grundschutz-Kompendiums (Edition 2023) behandelt die auftragnehmende Seite, also die Institution, die Software entwickelt. APP.7 (Entwicklung von Individualsoftware) behandelt die auftraggebende Seite: Welche Sicherheitsanforderungen sind bei Planung und Entwicklung von Individualsoftware zu berücksichtigen, die eine Institution selbst oder durch Dritte entwickeln lässt [9]?

Zusammen decken CON.8 und APP.7 beide Konstellationen aus 6.2.1 und 6.2.3 ab: eigene ebenso wie ausgelagerte Entwicklung. Eine Gap-Analyse gegen alle zehn Unterabschnitte von Abschnitt 6 – nicht nur 6.2 – bleibt dennoch sinnvoll. Eine Analyse von secuvera kommt zu dem Ergebnis, dass sich die überwiegende Zahl der Anforderungen des CIR-Anhangs Elementen des BSI-Grundschutzes zuordnen lässt, die Zuordnung aber „nicht immer treffsicher oder abdeckend“ ist [7]. Auch das BSI weist darauf hin, dass die Umsetzung bestehender Standards nicht automatisch bedeutet, dass die Anforderungen nach § 30 BSIG vollständig erfüllt sind [2].

BSI TR-03185 – Sicherer Software-Lebenszyklus

Die Technische Richtlinie BSI TR-03185 „Sicherer Software-Lebenszyklus“ (Teil 1, Version 1.0 vom 6. August 2024) wurde ausgehend von den Grundschutz-Anforderungen an sichere Software-Entwicklungsprozesse erstellt; Teil 2 für Open-Source-Software folgte 2025. Die TR ist freiwillig; das BSI bietet Zertifizierungen nach Teil 1 an. Sie gliedert ihre Anforderungen in zwei Perspektiven – den Hersteller als Anwender von Software und den Hersteller als Software-Produzent. Für die Produzentenperspektive ergibt sich folgende Zuordnung zu Abschnitt 6 der CIR 2024/2690 (eigene Zuordnung, keine amtliche Mapping-Tabelle) [3]:

Bereich (TR-03185, Produzent)	Themen (Auswahl)	Bezug in CIR 2024/2690
Projektmanagement	Allgemeine Projektanforderungen, Personal	6.2.1, 6.2.2 Buchst. a
Dokumentation	Projekt- und Benutzerdokumentation	6.2.1, 6.1.2 Buchst. d
Entwicklung	Entwurf, Bedrohungsmodellierung, entwicklungsbegleitende Tests, Drittkomponenten, Code-Management, Build-Werkzeuge, Inventarisierung	6.2.2 Buchst. a bis d
Test und Freigabe	Tests und Freigabe, auch für Patches und Updates	6.2.2 Buchst. d, 6.5, 6.6
Auslieferung	Sichere Auslieferung	6.6.1 Buchst. c
Schwachstellenmanagement	Umgang mit Schwachstellen und Meldungen	6.10
Außerbetriebnahme	Geordnete Außerbetriebnahme	6.1.2 Buchst. b (Supportende)

Einrichtungen, die BSI TR-03185 umsetzen, schaffen damit eine strukturierte Grundlage für die Anforderungen aus Abschnitt 6.2 – ein Vorteil bei der Audit-Vorbereitung. Die Konformität mit der CIR oder mit § 30 BSIG ist damit allerdings nicht automatisch nachgewiesen [3].

DevSecOps in der Praxis: SAST, DAST und SBOM

SAST und DAST als Bausteine der Entwicklungspipeline

Die Anforderung aus 6.2.2 Buchst. d – Sicherheitstestverfahren im Entwicklungszyklus – lässt sich unter anderem über zwei komplementäre Testmethoden umsetzen; die Verordnung selbst schreibt keine bestimmten Verfahren oder Werkzeuge vor:

SAST (Static Application Security Testing) analysiert den Quellcode oder kompilierten Code ohne Ausführung der Anwendung. SAST-Tools identifizieren Schwachstellenklassen wie SQL-Injection, unsichere Kryptografie oder Pufferüberläufe direkt im Code – bevor das System deployed wird. In modernen CI/CD-Pipelines kann SAST automatisch bei jedem Code-Commit laufen und liefert so frühes Feedback an den Entwickler.

DAST (Dynamic Application Security Testing) testet die laufende Anwendung von außen, wie ein Angreifer es täte. DAST findet Laufzeitfehler, die SAST nicht sieht – unsichere Session-Verwaltung, Konfigurationsprobleme, Zugriffskontrollfehler im Betrieb. Beide Verfahren sind komplementär: SAST findet Fehler früh im Zyklus, DAST findet Fehler, die erst in der laufenden Anwendung auftreten. Zusammen bilden sie eine solide Grundlage für entwicklungsbegleitende Sicherheitstests; das BSI empfiehlt zusätzlich Code Reviews und Penetrationstests bereits während der Entwicklungsphase [2].

SBOM – Software Bill of Materials als regulatorischer Nachweis

Eine Software Bill of Materials (SBOM) ist eine maschinenlesbare Auflistung der Softwarekomponenten, Abhängigkeiten, Versionen und Lizenzen eines Produkts. BSI TR-03183-2 (erstmals veröffentlicht im August 2023, aktuell Version 2.1.0 von 2025) definiert formelle und fachliche Vorgaben für SBOMs; nach Angabe des BSI ist die TR-03183 eine Hilfestellung ohne verbindlichen Charakter [4].

Der Bezug zu Abschnitt 6: Nummer 6.1.2 Buchst. c verlangt Informationen über die Hardware- und Softwarekomponenten beschaffter Produkte und Dienste, und für die Behandlung von Schwachstellen nach 6.10 müssen Einrichtungen wissen, welche Komponenten in ihren Systemen stecken. Ohne SBOM oder vergleichbare Komponentenübersicht lässt sich weder validieren, was ein Lieferant tatsächlich liefert, noch bestimmen, welche Drittkomponenten in eigener Entwicklung stecken – und damit auch nicht, welche Schwachstellenwarnungen für das eigene System relevant sind.

Die regulatorische Entwicklung verstärkt den Bedarf: Nach dem Cyber Resilience Act (Verordnung (EU) 2024/2847) müssen Hersteller von Produkten mit digitalen Elementen ab dem 11. Dezember 2027 die Komponenten ihrer Produkte ermitteln und dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten abbildet; die Meldepflichten des CRA gelten bereits seit dem 11. September 2026 [5]. Veröffentlichen müssen Hersteller die SBOM nicht. TR-03183-2 empfiehlt, SBOMs idealerweise digital zu signieren, damit Empfänger ihre Authentizität prüfen können [4]. Frühzeitig SBOM-fähige Build-Prozesse einzurichten ist daher strategisch sinnvoll.

Rollen und Verantwortlichkeiten: Eine Zuständigkeitsmatrix

Abschnitt 6 der CIR 2024/2690 richtet sich an die Einrichtung als Ganzes; wie sie die Aufgaben intern verteilt, legt die Verordnung nicht fest. Für die Geschäftsleitung gilt in Deutschland § 38 Abs. 1 BSIG: Sie muss die nach § 30 zu ergreifenden Risikomanagementmaßnahmen umsetzen und ihre Umsetzung überwachen; bei schuldhafter Pflichtverletzung haftet sie der Einrichtung nach den gesellschaftsrechtlichen Regeln ihrer Rechtsform (§ 38 Abs. 2 BSIG). Die folgende Matrix zeigt eine mögliche Zuordnung:

Rolle	Hauptpflicht nach Abschnitt 6	Praktische Aufgabe	Nachweis für Prüfer
CISO / IT-Sicherheitsbeauftragter	6.2.1: Sicherheitsvorschriften festlegen und pflegen	SDLC-Sicherheitsrichtlinie erstellen, in geplanten Abständen überprüfen (6.2.4)	Richtliniendokument + Review-Protokoll
Entwicklungsteam	6.2.2: Sichere Entwicklung, Tests, Testdaten	SAST/DAST in CI/CD integrieren, Testdaten bereinigen und anonymisieren	Test-Protokolle, CI/CD-Konfiguration
Einkauf / Beschaffung	6.1: Sicherheitsanforderungen in Beschaffungsprozessen	Sicherheitskriterien in Ausschreibungen und Verträge aufnehmen	Verträge, Lieferanten-Validierungsberichte
Dienstleistermanagement	6.2.3 und 6.1: Externe Entwicklung absichern	Sicherheitsanforderungen in Entwicklungsverträge schreiben	Vertragsklauseln, SBOM-Lieferpflichten
Compliance Officer	6.2.4, 6.5.3 und weitere Überprüfungspflichten	Audit-Plan erstellen, interne Reviews koordinieren	Review-Protokolle, Maßnahmen-Tracking
Geschäftsleitung	§ 38 Abs. 1 BSIG: Maßnahmen nach § 30 umsetzen und Umsetzung überwachen	Sicherheitsrichtlinien verabschieden (empfehlenswert, gesetzlich keine Billigungspflicht), Budget bereitstellen, Umsetzung überwachen	Beschlüsse, Sitzungsprotokolle

Prüfnachweis: Was Prüfer für Abschnitt 6 sehen wollen

Für Prüfungen und für die Dokumentationspflicht nach § 30 Abs. 1 Satz 3 BSIG bieten sich für Abschnitt 6 die folgenden sieben Kernnachweise an:

1. SDLC-Sicherheitsrichtlinie (6.2.1, 6.2.4): Schriftliche Richtlinie, die alle Entwicklungsphasen abdeckt, mit Datum der letzten Überprüfung und – empfehlenswert – Freigabe durch die Leitungsebene
2. Secure-Coding-Standard (6.2.2 Buchst. b): Dokumentierte Grundsätze für sicheres Programmieren und sichere Systemarchitektur – etwa auf Basis der OWASP Top 10, ergänzt um Security-by-Design- und Zero-Trust-Prinzipien
3. Testprotokolle (6.2.2 Buchst. d, 6.5): SAST/DAST-Ergebnisse und Penetrationstest-Berichte; nach 6.5.2 Buchst. c sind Art, Umfang, Zeitpunkt und Ergebnisse der Tests einschließlich Kritikalitätsbewertung und Abhilfemaßnahmen für jeden Befund zu dokumentieren
4. Konfigurationsbaseline (6.3): Dokumentierte Sicherheitskonfigurationen für alle kritischen Systeme mit Nachweis der Abweichungsbehandlung
5. Änderungsmanagement-Protokolle (6.4): Nachweise, dass Änderungen dokumentiert, risikobasiert getestet und bewertet wurden – bei Notfalländerungen mit Ergebnis und Begründung für die Abweichung vom regulären Verfahren
6. Patch-Management-Protokolle (6.6): Nachweis der Patch-Einspielung innerhalb angemessener Frist bzw. dokumentierter und begründeter Ausnahmen samt zusätzlicher Maßnahmen
7. SBOM oder Komponentendokumentation (6.1.2 Buchst. c, 6.10): Für beschaffte und selbst entwickelte kritische Systeme

Einzelne Stichproben ohne nachvollziehbare Dokumentation reichen dafür in der Regel nicht aus, denn die Verordnung verlangt, Tests, Änderungen und Patch-Entscheidungen zu dokumentieren. Für die Vorbereitung Ihrer NIS2-Compliance empfehlen wir unsere NIS2-Compliance-Checkliste, die sich an den zehn Maßnahmenbereichen nach Artikel 21 orientiert.

Häufige Fragen

Gilt CIR 2024/2690 Abschnitt 6 für alle NIS2-Unternehmen?

Nein. Die CIR 2024/2690 ist nur für die in ihrem Artikel 1 genannten elf Einrichtungsarten verbindlich (u. a. DNS-Diensteanbieter, Cloud-Anbieter, MSP, MSSP und Vertrauensdiensteanbieter). Für alle anderen besonders wichtigen und wichtigen Einrichtungen gelten Artikel 21 Absatz 2 Buchstabe e NIS2 bzw. in Deutschland § 30 Abs. 2 Satz 2 Nr. 5 BSIG; das BSI stellt klar, dass alle anderen Sektoren nicht von der Durchführungsverordnung betroffen sind. Als Orientierungshilfe und Benchmark kann Abschnitt 6 dennoch nützlich sein – das BSI nutzt seine Gliederung etwa, um bestehende Standards den Anforderungen zuzuordnen.

Müssen wir eine SBOM für eigene Software erstellen?

Eine ausdrückliche SBOM-Pflicht enthalten weder NIS2 noch § 30 BSIG. Für Einrichtungen im Anwendungsbereich der CIR verlangt Nummer 6.1.2 Buchst. c aber Informationen über die Hardware- und Softwarekomponenten beschaffter Produkte und Dienste, und die Behandlung von Schwachstellen nach 6.10 setzt eine Komponentenübersicht praktisch voraus. Hersteller, die Produkte mit digitalen Elementen in der EU in Verkehr bringen, müssen nach dem Cyber Resilience Act ab dem 11. Dezember 2027 unter anderem eine SBOM erstellen. Frühzeitig SBOM-fähige Build-Prozesse einzurichten ist daher strategisch sinnvoll.

Reicht BSI IT-Grundschutz als Umsetzungsnachweis für Abschnitt 6?

BSI IT-Grundschutz (CON.8 und APP.7) deckt viele Anforderungen aus Abschnitt 6.2 ab; BSI TR-03185 ergänzt als strukturierter Lebenszyklus-Leitfaden. Das BSI weist jedoch darauf hin, dass die Umsetzung bestehender Standards nicht automatisch die vollständige Erfüllung von § 30 BSIG bedeutet. Sinnvoll ist daher eine Gap-Analyse gegen alle zehn Unterabschnitte von Abschnitt 6 – insbesondere Konfigurationsmanagement (6.3), Sicherheitspatch-Management (6.6) und die Behandlung von Schwachstellen (6.10) sollten gesondert geprüft werden.

Quellen

• [1] Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024, Anhang Nr. 6 (amtliche deutsche Fassung). EUR-Lex: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/deu
• [2] BSI: #nis2know – Sicherheitsmaßnahmen und Schwachstellenmanagement. BSI.bund.de: bsi.bund.de – NIS-2-Infopaket Sicherheitsmaßnahmen
• [3] BSI: Technische Richtlinie BSI TR-03185 – Sicherer Software-Lebenszyklus. BSI.bund.de: bsi.bund.de/dok/TR-03185
• [4] BSI: Technische Richtlinie BSI TR-03183 – Cyber-Resilienz-Anforderungen (Teil 2: SBOM). BSI.bund.de: bsi.bund.de – TR-03183
• [5] Verordnung (EU) 2024/2847 (Cyber Resilience Act), Art. 71 und Anhang I Teil II. EUR-Lex: eur-lex.europa.eu/eli/reg/2024/2847/oj/deu
• [6] BSI: NIS-2 für IT und TK – Durchführungsverordnung (EU) 2024/2690. BSI.bund.de: bsi.bund.de – NIS-2 für IT und TK
• [7] NIS-2 konkret: Durchführungsverordnung und BSI-Grundschutz. Secuvera: secuvera.de
• [8] § 30 BSIG – Risikomanagementmaßnahmen besonders wichtiger Einrichtungen und wichtiger Einrichtungen. Gesetze im Internet: gesetze-im-internet.de/bsig_2025/__30.html
• [9] BSI IT-Grundschutz-Kompendium, Edition 2023: Baustein APP.7 Entwicklung von Individualsoftware (mit Abgrenzung zu CON.8 Software-Entwicklung). BSI.bund.de: bsi.bund.de – APP.7 (PDF)