NIS2 Lieferkettensicherheit: Drittparteienrisiko steuern

Die meisten NIS2-Diskussionen richten den Blick nach innen — Registrierung, interne Kontrollen, die 24-Stunden-Frühwarnung. Doch die Pflicht, die Engineering- und Security-Verantwortliche am häufigsten überrascht, weist nach außen: die Sicherheit der Lieferkette. Nach dem NIS2UmsG ist die Steuerung des Cyberrisikos, das Ihre Lieferanten und IKT-Dienstleister einbringen, keine bloße gute Praxis — sie ist eine ausdrückliche, verpflichtende Risikomanagementmaßnahme, und Ihre Geschäftsleitung haftet persönlich dafür. Dieser Beitrag zeigt, wie wir das in der Praxis für Mandanten angehen, die es belastbar machen müssen, nicht nur vorzeigbar.

TL;DR / Kernaussagen

Lieferkettensicherheit ist eine ausdrücklich benannte, verpflichtende NIS2-Risikomanagementmaßnahme. Sie sind für die Steuerung des von Lieferanten eingebrachten Risikos verantwortlich, auch wenn ein Vorfall beim Lieferanten entsteht.
Direkte Betroffenheit und vertragliche Pflicht sind verschiedene Fragen. Ein Lieferant kann aus eigenem Recht betroffen sein oder schlicht die Anforderungen erben, die Ihr Vertrag weitergibt — oft beides.
Die Pflicht ist risikobasiert und verhältnismäßig. Stufen Sie Lieferanten nach Kritikalität und Zugriff; konzentrieren Sie Bewertung, vertragliche Kontrollen und Überwachung auf die kritische Stufe.
Das IKT-Lieferkettenrisiko ist technisch, nicht nur kommerziell. Es umfasst Cloud-Plattformen, Managed Services, Softwarekomponenten und die Sicherheitsqualität der dahinterstehenden Anbieter.
Der Nachweis ist das Ergebnis. Eine dokumentierte Methodik, ein gestuftes Verzeichnis, Vertragsklauseln und eine durch die Geschäftsleitung genehmigte Aufsicht erwartet das BSI — Bußgelder erreichen 10 Mio. EUR oder 2 % des weltweiten Umsatzes.

Warum die Lieferkette die unterschätzte Pflicht ist

Wenn Organisationen den NIS2-Katalog der Risikomanagementmaßnahmen zum ersten Mal lesen, ziehen die vertrauten Punkte die Aufmerksamkeit auf sich: Zugriffskontrolle, Verschlüsselung, Vorfallsbehandlung, Geschäftskontinuität. Die Sicherheit der Lieferkette steht unauffällig in derselben Liste — und sie skaliert am schlechtesten, weil sie ein Risiko betrifft, das Sie nicht unmittelbar kontrollieren.

Die Logik ist einfach und unbequem. Ein modernes Unternehmen läuft auf einem dichten Geflecht aus Cloud-Plattformen, Managed-Service-Anbietern, Softwarebibliotheken und Hardwarelieferanten. Jeder davon ist ein potenzielles Einfallstor, und mehrere der schädlichsten europäischen Vorfälle der letzten Jahre breiteten sich über einen vertrauenswürdigen Lieferanten aus, nicht über den Perimeter. NIS2 reagiert, indem es den Kunden für die Steuerung dieser Exposition verantwortlich macht. Sie können das Risiko nicht zusammen mit der Leistung auslagern.

Vor diesem Regime behandelten viele Sicherheitsteams das Drittparteienrisiko informell — ein Fragebogen im Einkauf, vielleicht ein Zertifikat in der Akte. NIS2 macht daraus eine Pflicht, die Sie mit derselben Stringenz wie Ihre internen Kontrollen verteidigen können müssen. Ob Ihre Organisation überhaupt erfasst ist, klärt unser NIS2-Schwellenwert-Test nach dem NIS2UmsG.

Was NIS2 zur Lieferkette tatsächlich verlangt

Es hilft, drei oft vermischte Pflichten zu trennen.

Pflicht	Was sie praktisch bedeutet	Wo sie greift
Lieferantenrisiko bewerten	Das Sicherheitsrisiko jedes Lieferanten und IKT-Dienstleisters verstehen, verhältnismäßig zur Kritikalität	Einkauf, Sicherheitsarchitektur
Anforderungen setzen und weitergeben	Sicherheitsanforderungen definieren und in Verträgen, Auditrechten und Meldeklauseln verankern	Recht, Lieferantenmanagement
Überwachen und verantworten	Aufsicht aktuell halten und Lieferantenvorfälle in eigene Meldung und Governance einspeisen	Security Operations, Geschäftsleitung

Zwei Punkte werden leicht übersehen. Erstens erstreckt sich die Pflicht auf die Sicherheitsqualität der Lieferanten selbst und ihrer Entwicklungspraktiken — nicht nur auf die kommerziellen Konditionen. NIS2 erwartet, dass Sie berücksichtigen, wie ein Anbieter sein Produkt baut und absichert, was deutlich anspruchsvoller ist als eine Preis- und SLA-Verhandlung. Zweitens reicht die Pflicht die Kette hinab: Die Subunternehmer eines kritischen Lieferanten gehören zu Ihrem IKT-Lieferkettenrisiko, obwohl Sie zu ihnen keine direkte Beziehung haben.

Direkte Betroffenheit versus weitergegebene Pflicht

Eine hartnäckige Verwechslung betrifft die Frage, ob Ihre Lieferanten selbst reguliert sind. Manche sind es — ein Lieferant, der eigenständig die Sektor- und Größenkriterien erfüllt, fällt aus eigenem Recht in den Anwendungsbereich. Viele aber sind nicht direkt reguliert und erben dennoch Pflichten, weil betroffene Kunden Sicherheitsanforderungen, Auditrechte und Meldefristen in deren Verträge drücken. Wir haben wiederholt erlebt, dass mittelständische Software- und Managed-Service-Häuser NIS2 nicht über die eigene Betroffenheitsanalyse, sondern über den überarbeiteten Vertrag eines Kunden zum ersten Mal begegneten. Behandeln Sie direkte Betroffenheit und Lieferantenrisiko nach NIS2 als zwei getrennte Fragen und beantworten Sie beide.

Ein praxiserprobter Ansatz für NIS2-Lieferkettensicherheit

Die Programme, die einer Prüfung standhalten, haben eine gemeinsame Gestalt. Hier die Abfolge, die wir anwenden.

Loading diagram...

1. Ein einheitliches Lieferantenverzeichnis aufbauen

Sie können nicht steuern, was Sie nicht erfasst haben. Erstellen Sie ein maßgebliches Verzeichnis der Lieferanten und IKT-Dienstleister — einschließlich Subunternehmer mit Zugriff auf betroffene Systeme oder Daten — und halten Sie fest, was jeder liefert, welche Daten und Zugriffe er hält und wie er angebunden ist. Schatten-IT und abteilungseigenes SaaS sind die typische Bruchstelle; das Verzeichnis muss real sein, nicht die optimistische Sicht des Einkaufssystems.

2. Nach Kritikalität und Zugriff einstufen

Risikobasiert heißt selektiv. Bewerten Sie jeden Lieferanten auf zwei Achsen: die Auswirkung bei Ausfall oder Kompromittierung und den Zugriff oder die Berechtigung, die er hält. Daraus ergibt sich eine belastbare Trennung zwischen einer Handvoll kritischer Lieferanten — Ihre Cloud-Plattform, Ihr Identitätsanbieter, Ihre Kern-Managed-Services — und einem langen Schwanz wenig kritischer Anbieter. Die kritische Stufe verdient tiefe Bewertung; der Schwanz erhält eine verhältnismäßige, leichtere Behandlung. Zu dokumentieren, warum ein Lieferant in einer Stufe liegt, ist ebenso wichtig wie die Stufe selbst.

3. Die kritische Stufe gründlich bewerten

Gehen Sie bei kritischen Lieferanten über den Fragebogen hinaus. Prüfen Sie Zertifizierungen (ISO 27001, BSI C5, SOC 2), aber lesen Sie sie auf Geltungsbereich und Aktualität, statt ein Kästchen abzuhaken — ein Zertifikat, das die relevante Leistung ausschließt, sagt wenig aus. Bewerten Sie Konzentrationsrisiko, Datenstandort, Transparenz über Unterauftragsverarbeiter sowie die Vorfallshistorie und Meldedisziplin des Lieferanten. Wo ein Lieferant Identität oder Netzwerkzugriff trägt, sollte diese Bewertung unmittelbar an Ihre Zero-Trust-Architektur anknüpfen; unsere Seite zu Zero-Trust-Leistungen beschreibt, wie wir Lieferantenzugriff standardmäßig als nicht vertrauenswürdig behandeln.

4. Anforderungen vertraglich weitergeben

Bewertung ohne vertragliche Durchsetzbarkeit ist Theater. Verankern Sie mindestens: Sicherheitsanforderungen verhältnismäßig zur Stufe des Lieferanten; das Recht auf Audit oder unabhängige Prüfnachweise; Transparenz über Subunternehmer; und — entscheidend — Meldefristen, die es Ihnen erlauben, Ihre eigenen Fristen einzuhalten. Wenn Sie binnen 24 Stunden eine Frühwarnung absetzen müssen, ist eine Lieferantenklausel mit 72 Stunden Meldefrist widersprüchlich. Stimmen Sie die Lieferantenmeldung auf Ihre Pflichten gemäß unserem 24/72-Stunden-Meldeleitfaden ab.

5. Überwachen, überprüfen, steuern

Lieferkettenrisiko ist keine Momentaufnahme. Etablieren Sie periodische Neubewertung der kritischen Stufe, wo möglich kontinuierliche Überwachung und einen definierten Weg, über den Lieferantenvorfälle in Ihre eigene Meldung und Governance fließen. Entscheidend: Die Geschäftsleitung muss den Lieferkettenrisikoansatz als Teil der gesamten Risikomanagementmaßnahmen genehmigen und überwachen, denn nach dem NIS2UmsG haftet die Leitung für diese Aufsicht persönlich.

Einordnung neben DORA, EU-KI-Verordnung und Registrierung

Sind Sie von mehr als einem europäischen Regime betroffen, widerstehen Sie der Versuchung paralleler Programme. DORA legt Finanzunternehmen und ihren IKT-Dienstleistern ein strengeres, registerbasiertes Drittparteienregime auf; die EU-KI-Verordnung ergänzt Pflichten entlang der KI-Wertschöpfungskette; die DSGVO verlangt bereits Auftragsverarbeiter-Sorgfalt. Diese überschneiden sich stark in der zugrunde liegenden Tätigkeit — Lieferanten kennen, bewerten, sauber vertraglich binden, überwachen. Der effiziente Entwurf ist ein einziges Drittparteienrisiko-Rahmenwerk mit regulierungsspezifischen Ergänzungen, das ein Verzeichnis und eine Nachweisbasis teilt. Die Arbeit über Silos zu duplizieren, führt zu drei halb gepflegten Registern und keiner schlüssigen Antwort, wenn ein Prüfer eine einfache Frage stellt.

Ihre Lieferketten-Nachweise sollten zudem vor der Registrierung bereitstehen, da die Registrierung Sie der Aufsicht zuführt. Falls dieser Schritt noch aussteht, behandelt unser BSI-Registrierungsleitfaden die Mechanik.

Häufige Fehler, die wir sehen

Behandlung als Einkaufs-Häkchen. Ein beim Onboarding abgelegter und nie überprüfter Fragebogen ist kein Risikomanagement, sondern Papierkram.
Pauschale Gleichbehandlung aller Lieferanten. Alle identisch zu bewerten verschwendet Aufwand auf den Schwanz und vernachlässigt die kritische Stufe. Die Stufung ist der ganze Sinn.
Meldeklauseln, die Ihre eigene Uhr aushebeln. Lieferantenfristen, die Ihre 24/72-Stunden-Pflichten nicht bedienen, machen Sie strukturell nicht regelkonform.
Subunternehmer ignorieren. Die Abhängigkeiten Ihres kritischen Lieferanten sind Ihre Abhängigkeiten. Fordern Sie Transparenz.
Keine Spur zur Geschäftsleitung. Ohne dokumentierte Genehmigung und Aufsicht der Leitung haben Sie eine operative Lücke und ein persönliches Haftungsrisiko.

Fazit

Lieferkettensicherheit ist der Punkt, an dem NIS2 aufhört, ein internes Compliance-Projekt zu sein, und zur Frage nach dem gesamten Ökosystem wird, von dem Sie abhängen. Gut gemacht, ist sie keine bürokratische Last, sondern echte Resilienz — und sie bringt regelmäßig reale Architekturrisiken ans Licht, die innerhalb des Perimeters unsichtbar waren. Wir haben solche Programme für europäische Unternehmen aufgebaut und verteidigt, und das funktionierende Muster ist stets dasselbe: ein reales Verzeichnis, ehrliche Stufung, Verträge mit Durchsetzungskraft und eine Geschäftsleitung, die nachweisen kann, dass sie hingesehen hat.

Wenn Sie einen zweiten Blick auf Ihren Ansatz zum Drittparteien- und IKT-Lieferkettenrisiko wünschen: Unsere Zero-Trust- und Cybersicherheitspraxis arbeitet mit CISOs und Enterprise-Architekten daran, ihn zugleich belastbar und wirksam zu machen.

FAQ

Macht uns NIS2 für die Sicherheit unserer Lieferanten verantwortlich?

NIS2 macht Sie verantwortlich für die Steuerung des Risikos, das Ihre Lieferanten und Dienstleister einbringen, nicht unmittelbar für deren interne Sicherheit. Die Sicherheit der Lieferkette ist eine verpflichtende Risikomanagementmaßnahme — Sie müssen Lieferantenrisiken bewerten, verhältnismäßige Sicherheitsanforderungen setzen und diese vertraglich sowie durch Überwachung umsetzen. Verantwortlich bleibt Ihre Einrichtung, auch wenn ein Vorfall bei einem Lieferanten entsteht.

Sind unsere Lieferanten ebenfalls direkt von NIS2 betroffen?

Manche ja, manche nicht. Ein Lieferant, der eigenständig die Sektor- und Größenkriterien des NIS2UmsG erfüllt, fällt aus eigenem Recht in den Anwendungsbereich. Viele kleinere Lieferanten sind nicht direkt reguliert, spüren das Regime aber dennoch, weil betroffene Kunden Sicherheitsanforderungen, Auditrechte und Meldeklauseln vertraglich weitergeben. Behandeln Sie direkte Betroffenheit und vertragliche Pflicht als zwei getrennte Fragen.

Was genau ist das IKT-Lieferkettenrisiko nach NIS2?

Es ist das Risiko, dass die Produkte, Dienste und Komponenten Ihres IKT-Stacks — Cloud-Plattformen, Managed Services, Softwarebibliotheken, Hardware und die dahinterstehenden Anbieter — Schwachstellen, Abhängigkeiten oder Single Points of Failure einbringen. NIS2 erwartet, dass Sie die Sicherheitsqualität der Lieferanten und ihrer Entwicklungspraktiken berücksichtigen, nicht nur die kommerziellen Konditionen.

Müssen wir jeden einzelnen Lieferanten bewerten?

Nein, und der Versuch wäre kontraproduktiv. NIS2 ist risikobasiert und verhältnismäßig. Sie stufen Lieferanten nach der Kritikalität ihrer Leistung und ihrem Zugriff ein und wenden tiefere Bewertung, vertragliche Kontrollen und Überwachung auf die kritische Stufe an. Lieferanten mit geringer Auswirkung erhalten eine leichtere Behandlung. Die Pflicht besteht in einer belastbaren, dokumentierten Methodik, nicht in der Gleichbehandlung aller Lieferanten.

Wie verhält sich die NIS2-Lieferkettenpflicht zu DORA und der EU-KI-Verordnung?

Sie überschneiden sich, sind aber nicht identisch. DORA legt Finanzunternehmen und ihren IKT-Dienstleistern ein strengeres, registerbasiertes Drittparteienregime auf. Die EU-KI-Verordnung ergänzt Pflichten entlang der KI-Wertschöpfungskette. Für mehrfach betroffene Organisationen ist ein einziges Drittparteienrisiko-Rahmenwerk mit regulierungsspezifischen Ergänzungen der effiziente Weg — nicht parallele Programme, die Nachweise duplizieren.

Welche Nachweise erwartet das BSI zur Lieferkettensicherheit?

Rechnen Sie damit, eine dokumentierte Methodik zur Lieferantenrisikobewertung, ein nach Kritikalität gestuftes Verzeichnis kritischer Lieferanten, die gesetzten Sicherheitsanforderungen samt Verifizierung, Vertragsklauseln zu Sicherheit und Meldung sowie Aufzeichnungen laufender Überwachung vorzulegen. Auch die Genehmigung des gesamten Risikomanagementansatzes durch die Geschäftsleitung ist nachzuweisen, da diese persönlich haftet.