Die NIS2-Richtlinie ist seit dem 6. Dezember 2025 deutsches Recht – ohne Übergangsfrist, ohne Schonfrist. Was für viele Unternehmen noch als künftiges Compliance-Thema galt, ist längst Gegenwart. Und während sich die Diskussion oft auf direkt betroffene Unternehmen konzentriert, sind Software-Lieferanten und IT-Dienstleister über die Lieferkettenpflichten indirekt, aber unmittelbar betroffen.
Wen NIS2 direkt trifft
NIS2 gilt für Unternehmen ab 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz in kritischen und wichtigen Sektoren – das sind in Deutschland rund 29.500 Unternehmen. Direkt betroffen sind Energie, Transport, Gesundheit, Finanzwesen, digitale Infrastruktur und öffentliche Verwaltung. Wer direkt betroffen ist, muss sich registrieren, Sicherheitsmaßnahmen nachweisen und Vorfälle innerhalb von 24 Stunden melden.
Die Lieferkettenpflicht: Warum alle Software-Lieferanten relevant sind
Der entscheidende Punkt für Entwickler und IT-Dienstleister: NIS2 verpflichtet betroffene Unternehmen, ihre gesamte Lieferkette zu überprüfen. Artikel 21 der Richtlinie schreibt vor, dass Sicherheitsmaßnahmen auch für „Lieferanten und Dienstleister" gelten müssen. In der Praxis bedeutet das: Wer Software an ein NIS2-pflichtiges Unternehmen liefert, wird von dessen Compliance-Team unter die Lupe genommen – und muss nachweisen können, dass die eigene Software sicher entwickelt wurde.
Security by Design: Was es in der Softwareentwicklung konkret bedeutet
Security by Design ist kein neues Konzept – aber NIS2 macht es zur nachweisbaren Anforderung. Es geht nicht darum, am Ende eines Projekts einen Penetrationstest zu machen und die gefundenen Lücken zu schließen. Es geht darum, Sicherheit von Anfang an in den Entwicklungsprozess zu integrieren.
Threat Modelling vor dem ersten Commit
Vor Beginn der Entwicklung: Welche Angriffsvektoren gibt es? Welche Daten sind schützenswert? Welche Schnittstellen können missbraucht werden? Das Threat Model muss nicht komplex sein – aber es muss existieren und die Design-Entscheidungen beeinflussen. OWASP bietet kostenlose Threat-Modelling-Methodiken, die für KMU-Projekte geeignet sind.
Sichere Entwicklungspraktiken dokumentiert nachweisen
Was in der Entwicklung nachgewiesen werden muss: Eingabevalidierung an allen System-Grenzen, keine hartkodierten Credentials, verschlüsselte Übertragung sensibler Daten, Abhängigkeits-Scanning (SCA) und regelmäßige Security-Reviews im Code. Das ist kein Extra-Aufwand – es ist professionelle Entwicklung. Wer das bisher nicht dokumentiert hat, muss damit anfangen.
Patch-Fähigkeit und Update-Prozesse
Der Cyber Resilience Act – ein Schwestergesetz zu NIS2 – geht noch weiter: Produkte mit digitalen Elementen müssen über ihren gesamten Lebenszyklus mit Sicherheits-Updates versorgt werden. Für Software bedeutet das: klare Update-Prozesse, kommunizierte Support-Zeiträume und die Fähigkeit, kritische Sicherheitslücken schnell zu schließen und auszurollen.
Management-Haftung: Was Geschäftsführer wissen müssen
NIS2 enthält eine Klausel, die viele unterschätzen: Geschäftsführer haften persönlich für die Einhaltung der Sicherheitsanforderungen. Das bedeutet nicht, dass jede Geschäftsleitung IT-Sicherheitsexperte werden muss – aber dass Nichtwissen keine Entschuldigung mehr ist. Eine dokumentierte Sicherheitsstrategie, regelmäßige Sicherheitstrainings für Mitarbeiter und ein Incident-Response-Plan sind nicht optional, sondern Mindestanforderung.
Was jetzt zu tun ist
Für Software-Entwickler und IT-Dienstleister ergibt sich eine klare Handlungsreihenfolge: Zunächst klären, ob man selbst unter NIS2 fällt. Dann prüfen, welche Kunden direkt betroffen sind und welche Anforderungen diese an ihre Lieferanten stellen werden. Danach den eigenen Entwicklungsprozess auf Security-by-Design-Prinzipien ausrichten und dokumentieren.
NIS2 ist kein Papiertiger. Die Behörden haben Durchgriffsrechte, und erste Bußgelder gegen nicht-konforme Unternehmen werden erwartet. Wer jetzt handelt, hat einen Wettbewerbsvorteil – denn die Überprüfung der Lieferkette durch NIS2-pflichtige Unternehmen beginnt jetzt.