Compliance · 20. Oktober 2026

NIS2 erreicht Softwarehäuser über Verträge, nicht über das Gesetz

NIS2 trifft Softwarelieferanten indirekt: Kunden fordern SBOM, MFA und Auditrechte vertraglich ein.

Christian Lohse · CEO & Founder

Softwarehäuser, die selbst nicht unter das NIS2-Umsetzungsgesetz fallen, bekommen dessen Anforderungen zunehmend über Kundenverträge zu spüren. Eine am 16. Oktober 2026 veröffentlichte Fachanalyse beschreibt, wie NIS2-pflichtige Unternehmen Sicherheitsanforderungen an ihre Softwarelieferanten weiterreichen (sdh.global). Für IT-Dienstleister und Softwarehäuser im deutschsprachigen Raum heißt das: Sicherheitsfragebögen und Auditklauseln werden zum festen Bestandteil des Vertriebsprozesses.

Das Wichtigste in Kürze

NIS2 verpflichtet nicht jedes Softwarehaus direkt, wirkt aber über Vertragsklauseln von NIS2-pflichtigen Kunden auf deren Lieferanten.
Kunden fragen zunehmend nach SBOM, MFA für privilegierte Zugänge, Schwachstellenprozessen, Auditrechten und Unterauftragnehmerlisten.
Eine gesetzlich vorgeschriebene, einheitliche Fragebogenstruktur gibt es nicht – die konkrete Ausgestaltung hängt vom Kunden und seiner Risikoeinschätzung ab.
Vertragliche 24-Stunden-Meldefristen sind nicht automatisch die gesetzliche Pflicht des Lieferanten, sondern eine Weitergabe, damit der Kunde seine eigene Meldepflicht einhalten kann.
NIS2, DORA und CRA lassen sich mit einem gemeinsamen Schwachstellen- und Vorfallprozess bedienen, statt getrennte Nachweise zu pflegen.

Warum nicht regulierte Softwarehäuser trotzdem betroffen sind

Das BSIG verlangt von NIS2-pflichtigen Einrichtungen geeignete, verhältnismäßige Maßnahmen zur Absicherung der Lieferkette, schreibt aber keinen bestimmten Fragebogen und keine generelle Zertifizierung vor (BSI-FAQ zu NIS-2). Genau diese Offenheit führt dazu, dass jedes regulierte Unternehmen seine eigenen Anforderungen formuliert und sie vertraglich an Softwarelieferanten weitergibt (BSI-Infopaket Lieferkette). Der naheliegende Irrtum vieler Softwarehäuser: „Wir sind nicht NIS2-pflichtig, also betrifft uns das nicht.“ Tatsächlich entscheidet nicht die eigene Betroffenheit, sondern die des Kunden, welche Nachweise im Vertrag landen.

Betroffen sind vor allem Softwareanbieter und IT-Dienstleister mit technischem Zugriff auf Kundensysteme – vom Software-as-a-Service-Anbieter über den Managed-Service-Provider bis zum Entwicklungsdienstleister. Wer heute schon Rahmenverträge mit mittelständischen oder größeren Kunden verhandelt, trifft zunehmend auf Sicherheitsanhänge, die vor zwei Jahren noch nicht Standard waren.

Welche Nachweise konkret gefragt werden

In der Praxis wiederholen sich bestimmte Themenfelder, auch wenn die genauen Fragen von Kunde zu Kunde variieren (BSI-Sicherheitsmaßnahmen):

Sicherheitsmaßnahmen über den gesamten Lebenszyklus von Erwerb, Entwicklung und Wartung.
Schwachstellenmanagement mit Bewertung, Behebungsfristen und koordinierter Offenlegung.
Multifaktor-Authentifizierung speziell für privilegierte Zugriffe und Fernzugänge, nicht nur für normale Nutzerkonten.
Software-Bill-of-Materials (SBOM) als Nachweis über eingesetzte Komponenten, insbesondere bei risikoreichen Produkten.
Audit- und Informationsrechte einschließlich Zertifikaten oder unabhängigen Prüfberichten.
Angaben zu Unterauftragnehmern und deren Sicherheitsniveau.

Ein häufiger Fehler liegt bei der SBOM: Sie wird als einmalige Excel-Liste verstanden statt als releasebezogener, aktualisierbarer Prozess. Transitive Abhängigkeiten, Containerbestandteile und Build-Komponenten fehlen dann, obwohl genau diese Tiefe von Kunden erwartet wird (Checkliste Lieferkette, BSI). Ebenso wird Auditfähigkeit oft mit einem Zertifikat verwechselt: ISO 27001 oder BSI C5 erleichtern Nachweise, ersetzen aber keine kundenspezifischen Vorfallberichte oder Unterauftragnehmerlisten (bsigroup.com).

Bei den Vertragsklauseln selbst lohnt ein genauer Blick auf Umfang, Vorankündigung, Kosten und Remote-Option von Auditrechten sowie auf die Frage, ob nur kundenrelevante Vorfälle oder sämtliche Vorfälle gemeldet werden müssen (complycheck.de, PWC-Vertragsanhang Lieferkettensicherheit).

Vorfallfristen: Was realistisch erfüllbar ist

Für erhebliche Sicherheitsvorfälle sieht die NIS2-Logik eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats vor (tuev-nord.de). Kunden reichen diese Fristen häufig unverändert oder sogar verkürzt an ihre Lieferanten weiter. Entscheidend ist dabei ein Missverständnis zu vermeiden: Eine 24-Stunden-Frist verlangt eine strukturierte Erstmeldung mit gesicherten Fakten und vorläufiger Bewertung – nicht eine vollständige Ursachenanalyse. Wer das vertraglich nicht klarstellt, verspricht mehr, als organisatorisch leistbar ist.

Was jetzt zu tun ist:

Heute: Prüfen, welche aktuellen Kundenverträge bereits Sicherheitsanhänge, Meldefristen oder Auditrechte enthalten, und diese sammeln.
Diese Woche: Eine zentrale Ablage für Sicherheitsnachweise aufbauen – ISMS-Status, Schwachstellenprozess, SBOM-Fähigkeit, MFA-Abdeckung bei privilegierten Zugängen.
Mittelfristig: Eine interne Meldekette für Sicherheitsvorfälle mit klaren Fristen (24 Stunden Erstmeldung, 72 Stunden erweiterte Bewertung) einrichten und mit Vertriebs- und Rechtsabteilung abstimmen, welche Zusagen vertraglich tragbar sind.
Mittelfristig: SBOM-Erstellung in den Release-Prozess integrieren, statt sie nachträglich pro Kundenanfrage zu erzeugen.

Außerdem wichtig in dieser Woche

Ein am 18. Oktober 2026 veröffentlichter Beitrag stellt NIS2, DORA und den Cyber Resilience Act als zusammenhängende Anforderungen an Softwareteams dar (tacticaledgeai.com). Gemeinsam sind unter anderem Lieferkettensicherheit, dokumentiertes Änderungsmanagement und Schwachstellenbehandlung; der CRA bringt seit September 2026 eigene Meldepflichten für aktiv ausgenutzte Schwachstellen mit, die nicht identisch mit der NIS2-Abschlussfrist von einem Monat sind (alev-b.com). Für Softwarehäuser mit Kunden aus Finanzsektor oder Produktgeschäft lohnt es sich, Schwachstellenregister und Release-Nachweise so aufzubauen, dass sie für mehrere Regelwerke gleichzeitig verwendbar sind, statt separate Prozesse für jeden Kundentyp zu pflegen. Handlungsschritt: Ein gemeinsames Schwachstellen- und Vorfallregister mit Zeitstempeln für Entdeckung, Bewertung, Erstinformation und Abschluss anlegen, das unabhängig vom jeweiligen Regelwerk nutzbar ist.

Einordnung aus Sicht von jalotiqo

Nachweise für Kunden entstehen idealerweise aus dem laufenden Betrieb – etwa aus einer abgeschlossenen Schwachstellenbehebung oder einem dokumentierten Release – statt zusätzlich von Hand für jeden Sicherheitsfragebogen erstellt zu werden. jalotiqo ONE führt Tickets, IT-Inventar, Lizenzen und Sicherheitskontrollen in einer Datenbasis zusammen, sodass ein Nachweis direkt aus der Arbeit entsteht und über eine Hash-Kette gegen nachträgliche Änderung gesichert ist. Wer die eigene NIS2-Betroffenheit grob einschätzen will, findet unter jalotiqo.one/nis2-check eine erste Orientierung.