NIS2: Sichere Lieferkette für IKT-Drittdienstleister nach § 30 BSIG

Wer NIS2-pflichtig ist und seine Cloud-Infrastruktur, seine SaaS-Tools oder seinen IT-Dienstleister als reines Beschaffungsthema behandelt, hat 2026 ein Problem. Die Lieferkette ist in der Cybersicherheit angekommen, und § 30 Abs. 2 lit. e BSIG macht das auch formal deutlich. Die Norm verlangt nicht nur, dass die eigenen Risikomanagement­maßnahmen funktionieren – sie verlangt auch, dass die Maßnahmen der IKT-Drittdienstleister in dieses Rahmenwerk passen.

Der Beitrag führt operativ durch das, was die Norm von NIS2-Betroffenen verlangt, wie Verträge mit Cloud- und IT-Dienstleistern aussehen sollten, und welche operativen Schritte bis Ende 2026 sinnvoll sind. Er baut auf dem Beitrag zur NIS2-Registrierung und dem Beitrag zur Geschäftsleiter-Haftung auf. Stand: 19. August 2026.

Warum die Lieferkette in den Fokus rückt

Drei Viertel aller schwerwiegenden Cybersicherheits­vorfälle der letzten zwei Jahre hatten eine Lieferketten-Komponente – sei es ein gehackter Software-Hersteller, ein kompromittierter Cloud-Provider oder ein unsicherer IT-Dienstleister. Das BSI hat das in seiner Lageberichterstattung 2025 mehrfach hervorgehoben, und die ersten NIS2-Aufsichtsfälle, die 2026 sichtbar werden, betreffen regelmäßig die Schnittstelle zu Drittdienstleistern, nicht die eigene IT-Infrastruktur.

NIS2 macht das zur Pflicht: wer die eigene Cybersicherheit aufbaut, muss die Cybersicherheit der Lieferkette mitdenken. Das ist kein neues Prinzip – BAIT, VAIT und DORA haben das für den Finanzsektor schon länger verlangt –, aber NIS2 ist die erste horizontale Regulierung, die das branchenübergreifend für die meisten KRITIS-Betreiber und wichtigen Einrichtungen verbindlich macht.

Was § 30 Abs. 2 lit. e BSIG konkret verlangt

§ 30 Abs. 2 lit. e BSIG ist Teil des Katalogs der Risikomanagement­maßnahmen, die besonders wichtige und wichtige Einrichtungen umsetzen müssen. Die Norm verlangt die Berücksichtigung der Sicherheit der Lieferkette einschließlich der Sicherheit der Beziehung zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern. Konkret bedeutet das: NIS2-Betroffene müssen bei der Auswahl, beim Vertrag, im Betrieb und bei Vorfällen mit Drittdienstleistern nachweisen können, dass sie die Risiken im Griff haben.

Was das in der Praxis heißt: vor der Auswahl eine Sicherheitsbewertung des Anbieters durchführen, im Vertrag Mindestanforderungen an die Cybersicherheit verankern, im Betrieb die Einhaltung überwachen und bei Vorfällen die Eskalations­wege klären. Das klingt nach einer Selbstverständlichkeit – in der Praxis scheitern viele NIS2-Betroffene schon am ersten Punkt, weil sie keine strukturierte Due-Diligence-Methodik haben.

Was die Norm nicht abschließend regelt: welche Mindestanforderungen konkret gelten. Hier hilft der Blick auf die einschlägigen Standards – ISO 27001, BSI IT-Grundschutz, der kommende NIS2-Implementierungs­standard – und auf das, was das BSI in seinen Orientierungshilfen veröffentlicht. Wer sich an diesen Standards orientiert, ist auf der sicheren Seite.

Wer unter IKT-Drittdienstleister fällt

Die Norm spricht von „unmittelbaren Anbietern oder Diensteanbietern“, die IKT-bezogene Dienste erbringen. Konkret umfasst das: Cloud-Anbieter (IaaS, PaaS, SaaS), Rechenzentrums­betreiber, Telekommunikations­anbieter, IT-Dienstleister, Software-Hersteller mit Wartungs­zugang, Managed-Service-Provider und Sicherheits­dienstleister. Was darunter fällt, hängt von der tatsächlichen Geschäfts­beziehung ab – nicht von der Etikettierung.

Was die wenigsten wissen: auch Berater und Dienstleister, die produktiven Zugriff auf die IT des Unternehmens haben, fallen darunter. Ein Steuerberater mit Zugriff auf das ERP-System ist ein IKT-Drittdienstleister im Sinne der Norm. Ein Reinigungs­dienst, der abends die Räume reinigt, nicht – solange er keinen IT-Zugang hat.

Was die Tiefe der Anforderungen angeht: NIS2 verlangt die Berücksichtigung der „unmittelbaren“ Anbieter. Wer eine lange Subunternehmer-Kette hat, muss nicht jeden Sub-Sub-Sub-Dienstleister einzeln prüfen – muss aber sicherstellen, dass die unmittelbaren Anbieter ihre eigenen Lieferketten im Griff haben. Das ist ein Kaskaden-Prinzip, das in der Praxis oft als Vertragsklausel („der Anbieter verpflichtet sich, seine Subunternehmer angemessen zu prüfen“) abgebildet wird.

Auswahl: Due Diligence vor Vertragsschluss

Wer einen neuen Cloud-Anbieter oder IT-Dienstleister auswählt, sollte die Sicherheits­reife vor Vertrags­schluss bewerten. Das ist keine Pflichtübung – es ist der einzige Hebel, der vor Vertrags­schluss wirkt. Was die wenigsten tun: eine strukturierte Bewertung mit klaren Kriterien. Stattdessen wird nach Bauchgefühl entschieden, nach Anschaffungspreis, oder schlicht nach der Empfehlung des Einkaufs.

Was eine belastbare Due Diligence umfasst: aktuelle Zertifikate (ISO 27001, SOC 2, BSI C5), unabhängige Audit-Berichte, den Cybervorfall-Verlauf der letzten zwei Jahre, die Sicherheits­architektur und das Patch-Management, die Subunternehmer-Struktur, das Notfall- und Wiederanlauf­konzept, und – ganz praktisch – die Reaktionszeit bei Sicherheits­vorfällen. Wer hier keine Antworten bekommt, sollte das als Warnsignal werten.

In der Mandatspraxis fällt mir auf, dass die wenigsten NIS2-Betroffenen strukturierte Fragebögen haben. Wer zum ersten Mal eine Bewertung durchführt, ringt zwei Wochen um die richtige Form. Wer den Fragebogen einmal hat, beschleunigt die nächsten Auswahl­prozesse erheblich. Die Investition in eine einmalige Vorlage zahlt sich mehrfach aus.

Vertragliche Anforderungen an Cloud & IT-Dienstleister

Im Vertrag selbst müssen eine Reihe von Mindest­pflichten stehen, die NIS2-Betroffene gegenüber dem Dienstleister durchsetzen können. Dazu gehören: Sicherheits­maßnahmen nach Stand der Technik, Meldung von Sicherheits­vorfällen binnen definierter Frist, Audit-Rechte des Auftraggebers, Standort­anforderungen für Daten und Backups, Klarheit über Subunternehmer, Ausstiegs­regelungen mit Datenmitnahme.

Was viele Verträge nicht enthalten: eine konkrete Frist für die Vorfallsmeldung. „Unverzüglich“ ist juristisch unscharf; „binnen 24 Stunden“ ist konkret und messbar. Wer seinen Cloud-Anbieter an die eigene NIS2-Meldepflicht nach § 32 BSIG koppeln will, braucht eine vertragliche Frist, die kürzer ist als die eigene gesetzliche Frist – sonst bekommt man die Meldung zu spät.

Subunternehmer-Klauseln sind der zweite Hebel. Wer einen Cloud-Anbieter beauftragt, der seinerseits wieder Subunternehmer einsetzt, sollte wissen, wer das ist und welche Anforderungen an diese Subunternehmer gestellt werden. In der Praxis reicht eine pauschale Zustimmungs­pflicht – der Cloud-Anbieter muss jeden Wechsel eines Subunternehmers melden, und der Auftraggeber hat ein Widerspruchs­recht. Das ist Standard in den Verträgen der großen Hyperscaler, weniger verbreitet bei kleineren Anbietern.

Audit-Rechte sind der dritte Hebel. NIS2 verlangt nicht zwingend jährliche Audits beim Dienstleister, aber das Recht, Audit-Berichte zu verlangen oder eigene Audits durchzuführen. In der Praxis verlassen sich die meisten NIS2-Betroffenen auf die Standard-Audit-Berichte (SOC 2, ISO 27001) und führen nur bei Anlässen eigene Audits durch. Das ist pragmatisch, solange man weiß, dass die Berichte keine operative Tiefe haben.

Überwachung im laufenden Betrieb

Die Auswahl und der Vertrag sind die halbe Miete; die andere Hälfte ist die laufende Überwachung. Wer einen Cloud-Anbieter oder IT-Dienstleister einmal ausgewählt hat und dann drei Jahre nicht hinschaut, hat das Risiko nicht im Griff. Das fängt bei Sicherheits­vorfällen an, geht über veränderte Subunternehmer weiter und endet bei verschlechterten SLAs.

Praktisch heißt das: mindestens jährlich eine Bewertung der Sicherheits­lage des Dienstleisters, ein Abgleich der aktuellen Zertifikate, ein Blick auf die öffentlich verfügbaren Vorfall-Meldungen, und – bei größeren Dienstleistern – die regelmäßige Teilnahme an Kunden­foren oder Webinaren, in denen der Anbieter über Veränderungen informiert. Wer das nicht macht, hat im Audit eine Lücke.

Was in der Praxis unterschätzt wird: die Beziehung zwischen Lieferkette und eigenem IKT-Risikomanagement. Wer als NIS2-Betroffener ein IKT-Risiko­register führt, muss die Risiken aus der Lieferkette dort abbilden. Das klingt trivial, ist aber die häufigste Lücke in der ersten Welle von Audits: das IKT-Risikomanagement bewertet nur die eigenen Systeme, die Subunternehmer­risiken sind in einem separaten Dokument, das niemand liest.

Vorfälle beim Dienstleister – was melden?

Wenn der Cloud-Anbieter einen Sicherheits­vorfall meldet, beginnt die NIS2-Uhr für den Kunden zu laufen. Wer hier zu lange wartet, um zu prüfen, ob der Vorfall die eigene NIS2-Meldepflicht auslöst, riskiert, die Frist nach § 32 BSIG zu reißen. Konkret: ab Kenntnisnahme eines erheblichen Vorfalls beim Dienstleister, der Auswirkungen auf die eigene NIS2-Einrichtung haben kann, läuft die 24-Stunden-Frist. Wer sich erst drei Tage Zeit nimmt, um das Ausmaß zu prüfen, hat verloren.

In der Mandatspraxis haben sich drei Grundsätze bewährt: erstens, beim Cloud-Anbieter eine SLA-gestützte Meldung binnen weniger Stunden vertraglich verankern. Zweitens, im internen IKT-Risikomanagement die typischen Cloud-Vorfälle vorab durchspielen. Drittens, bei jeder Meldung vom Cloud-Anbieter binnen 24 Stunden eine NIS2-Bewertung vornehmen und das BSI informieren – auch wenn die Bewertung ergibt, dass kein erheblicher Vorfall vorliegt. Lieber einmal zu viel gemeldet als zu wenig.

Schnittstelle zum Cyber Resilience Act

Wer NIS2-pflichtig ist und gleichzeitig Produkte mit digitalen Elementen einsetzt – und das ist heute fast jedes Unternehmen –, bekommt die Schnittstelle zum Cyber Resilience Act (CRA). Der CRA verpflichtet Hersteller solcher Produkte zu Sicherheits­anforderungen über den gesamten Produktlebenszyklus, einschließlich Schwachstellen­management und Meldung an die Marktüberwachungs­behörden.

Was das für die Lieferketten-Sicherheit bedeutet: wer als NIS2-Betroffener Hardware oder Software mit digitalen Elementen einsetzt, muss prüfen, ob der Hersteller CRA-konform ist. Das ist nicht trivial – der CRA ist erst seit Anfang 2025 in Kraft und die Konformitäts­verfahren sind noch im Aufbau. Wer aber sicherheits­kritische Komponenten einsetzt, sollte die CRA-Konformität aktiv nachfragen.

In der Mandatspraxis sehe ich, dass die wenigsten NIS2-Betroffenen die CRA-Schnittstelle explizit im IKT-Risikomanagement abbilden. Das wird sich in der zweiten Jahreshälfte 2026 ändern, wenn die ersten CRA-Konformitäts­bewertungen marktreif werden und die Aufsichtsbehörden anfangen, danach zu fragen.

Audit-Rechte und Nachweise

NIS2 verlangt, dass das IKT-Risikomanagement regelmäßig überprüft wird. Dazu gehört auch, dass die Lieferketten-Sicherheit überprüft wird. In der Praxis heißt das: mindestens jährlich ein Statusbericht zur Sicherheitslage der wichtigsten Drittdienstleister, der dokumentiert, welche Audits stattgefunden haben, welche Zertifikate aktualisiert wurden, welche Vorfälle aufgetreten sind.

Was eine BaFin- oder BSI-Prüfung konkret verlangt: die Liste der kritischen Drittdienstleister, die vertraglichen Sicherheits­vereinbarungen, die Bewertungs­berichte, die Eskalations­wege bei Vorfällen. Wer das alles in einem Audit-Bericht zusammenführt, hat im Zweifel Ruhe. Wer jedes Dokument einzeln such muss, hat schon verloren.

Ein pragmatischer Ansatz, der sich in der Praxis bewährt hat: ein Lieferketten-Dossier pro kritischem Dienstleister, in dem alle relevanten Informationen gebündelt sind – Vertrag, Zertifikate, Audit-Berichte, Vorfall-Historie, Risiko­bewertung. Wer ein solches Dossier pro Anbieter führt, kann im Audit binnen Minuten antworten.

Praktische Checkliste für 2026

Wer seine Lieferketten-Sicherheit 2026 auf ein belastbares Niveau bringen will, kann mit folgenden Schritten anfangen.

Inventur der Drittdienstleister. Wer ist im Einsatz, welche Dienste erbringen sie, welche Daten verarbeiten sie, welche Klassifizierung (kritisch / nicht kritisch) haben sie. Ohne diese Liste geht nichts.

Klassifizierung nach Kritikalität. Welche Anbieter dürfen bei Ausfall die kritischen Funktionen des Unternehmens beeinträchtigen? Diese werden prioritär behandelt.

Bestandsaufnahme der Verträge. Welche Sicherheits­klauseln sind heute schon drin, welche fehlen. Wer fehlende Klauseln identifiziert, kann sie bei der nächsten Vertragsverhandlung oder Vertragsverlängerung einbringen.

Due-Diligence-Vorlage entwickeln. Einmal investieren, mehrfach nutzen. Wer eine Vorlage hat, beschleunigt die nächsten Auswahl­prozesse erheblich.

Audit-Berichte einholen. SOC 2, ISO 27001 oder BSI C5 – was der Anbieter hat, sollte regelmäßig angefordert werden. Veraltete Berichte sind kein ausreichender Nachweis.

Eskalations­wege etablieren. Wer meldet einen Vorfall beim Dienstleister, wer bewertet intern, wer meldet an das BSI. Schriftlich fixiert, nicht in einem Sharepoint, der im Notfall nicht zugänglich ist.

Jährliche Statusberichte. Wer die Lieferketten-Sicherheit einmal jährlich zusammengefasst dokumentiert, kann gegenüber der Aufsicht antworten und gegenüber der Geschäftsleitung berichten.

Einordnung im NIS2-Gesamtsystem

Die Lieferketten-Sicherheit ist nicht ein eigenständiges Programm, sondern Teil des IKT-Risikomanagements nach § 30 BSIG. Wer das Risikomanagement sauber aufgesetzt hat, kann die Lieferketten-Komponenten darin abbilden; wer separate Dokumenten-Silos pflegt, bekommt bei der ersten NIS2-Aufsicht die typische Rückfrage: „Zeigen Sie uns, wie das zusammenhängt.“ Ergänzend sind die 12 NIS2-Musterklauseln und das Lieferanten-Fragebogen-Tool operative Pflicht-Bausteine.

Was die NIS2-Geschäftsleiter-Haftung angeht: die Geschäftsleitung haftet persönlich dafür, dass die Risikomanagement­maßnahmen umgesetzt und überwacht werden. Dazu gehört die Lieferkette. Wer als Geschäftsführer eines NIS2-betroffenen Unternehmens die Lieferketten-Sicherheit nicht im Griff hat, hat ein persönliches Haftungs­risiko – unabhängig davon, ob der konkrete Vorfall vom eigenen Unternehmen oder vom Dienstleister ausgeht. Die NIS2-Cyber-Versicherung deckt zumindest die finanzielle Seite ab.

Fazit

Die Lieferketten-Sicherheit nach NIS2 ist eine operative Pflicht, die in der Mandatspraxis die größte Schwachstelle ist. Wer seine eigenen Systeme gut im Griff hat, aber die Dienstleister nicht systematisch bewertet und überwacht, wird im Ernstfall trotzdem getroffen – und hat im Audit eine Lücke, die nur schwer zu schließen ist.

Sieben Bausteine entscheiden: Inventur, Klassifizierung, Vertragsanalyse, Due-Diligence-Vorlage, Audit-Berichte, Eskalations­wege, Statusbericht. Wer diese sieben im August 2026 hat, ist gut aufgestellt. Wer sie bis Ende 2026 nicht hat, fängt an, in der Geschäftsleitungssitzung unangenehme Fragen zu beantworten. Die Aufsicht ist da, die ersten Bußgelder werden folgen – die Frage ist nicht ob, sondern wann.