Warum die Lieferkette der blinde Fleck der NIS2-Debatte ist
Die NIS2-Berichterstattung des Jahres 2026 dreht sich fast vollständig um zwei Punkte: die Registrierung beim BSI und die gestaffelten Meldefristen. Beides ist wichtig — und beides ist gut dokumentiert, unter anderem in unserem Leitfaden zu den NIS2-Meldepflichten für Website-Betreiber. Artikel 21 der Richtlinie zählt aber zehn Mindestmaßnahmen auf, und die Lieferkette ist eine davon. Sie ist die Maßnahme, die am seltensten in Projekten auftaucht, obwohl sie für Website-Betreiber die größte Angriffsfläche beschreibt.
Die Zahlen stützen das. Die ENISA hat für ihren Threat Landscape 2025 4.875 Vorfälle im Zeitraum 1. Juli 2024 bis 30. Juni 2025 ausgewertet (ENISA Threat Landscape 2025). Auf Lieferkettenrisiken entfallen dabei 10,6 Prozent der Bedrohungskategorien — Angreifer nutzen also gezielt den indirekten Weg über Drittanbieter und Abhängigkeiten (ENISA Threat Landscape 2025). Zum Vergleich: Web-Bedrohungen liegen bei 27,3 Prozent, Bedrohungen mobiler Systeme bei 42,4 Prozent (ENISA Threat Landscape 2025). Als Erstzugangsvektor dominiert Phishing mit 60 Prozent, gefolgt vom Ausnutzen von Schwachstellen mit 21,3 Prozent (ENISA Threat Landscape 2025) — beides Wege, die genauso gut beim Dienstleister beginnen können wie im eigenen Haus.
Der wirtschaftliche Rahmen ist ebenfalls messbar. Der Bitkom beziffert den Gesamtschaden für die deutsche Wirtschaft aus Diebstahl, Spionage und Sabotage auf 289,2 Milliarden Euro — ein Plus von rund 8 Prozent gegenüber dem Vorjahr (Bitkom, Wirtschaftsschutz 2025). Der Anteil, der auf Cyberangriffe entfällt, ist von 67 auf 70 Prozent gestiegen und entspricht 202,4 Milliarden Euro (Bitkom, Wirtschaftsschutz 2025). 87 Prozent der befragten Unternehmen berichten überhaupt von Vorfällen, 34 Prozent waren von Ransomware betroffen — 2022 waren es noch 12 Prozent (Bitkom, Wirtschaftsschutz 2025).
Viele Betriebe halten die Lieferkette für erledigt, weil Auftragsverarbeitungsverträge nach Artikel 28 DSGVO vorliegen. Das ist eine andere Frage. Der Auftragsverarbeitungsvertrag regelt die Verarbeitung personenbezogener Daten. Artikel 21 Absatz 2 Buchstabe d NIS2 fragt nach der Sicherheit der Netz- und Informationssysteme — auch dort, wo gar keine personenbezogenen Daten fließen, etwa bei einem CDN, einem DNS-Anbieter oder einer Schriftarten-Auslieferung. Beide Regelwerke überschneiden sich, ersetzen sich aber nicht.
Was Artikel 21 Absatz 2 Buchstabe d konkret verlangt
Der Richtlinientext ist knapp. Artikel 21 Absatz 2 Buchstabe d der Richtlinie (EU) 2022/2555 verlangt Maßnahmen zur Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern. Das deutsche BSIG übernimmt die Formulierung in § 30 Absatz 2 Nummer 4 nahezu wörtlich (BSIG in der seit 06.12.2025 geltenden Fassung). § 30 Absatz 1 BSIG verlangt dabei geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen — die Verhältnismäßigkeit ist also im Gesetz angelegt und nicht bloß ein Trost für kleine Betriebe (BSIG in der seit 06.12.2025 geltenden Fassung).
Konkret wird es erst eine Ebene tiefer. Die Durchführungsverordnung (EU) 2024/2690 vom 17. Oktober 2024, veröffentlicht am 18. Oktober 2024, übersetzt die zehn Maßnahmen aus Artikel 21 in technische und methodische Anforderungen. Ihr Anhang gliedert sich in 13 Themenbereiche; Nummer 5 heißt Sicherheit der Lieferkette (Durchführungsverordnung (EU) 2024/2690). Wichtig für die Einordnung: Die Verordnung ist unmittelbar verbindlich nur für bestimmte digitale Dienste — DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing- und Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste, Online-Marktplätze, Suchmaschinen, soziale Netzwerke sowie Vertrauensdiensteanbieter (Durchführungsverordnung (EU) 2024/2690).
Für alle anderen Sektoren ist die Verordnung formal nicht anwendbar — praktisch ist sie der einzige verfügbare Maßstab dafür, was Aufsichtsbehörden unter angemessenen Lieferkettenmaßnahmen verstehen. Wer sich daran orientiert, arbeitet erfahrungsgemäß näher an der Erwartungshaltung als jemand, der eine eigene Systematik erfindet (Projekterfahrung). Die ENISA hat dazu am 26. Juni 2025 ihre Technical Implementation Guidance on Cybersecurity Risk-Management Measures in Version 1.0 veröffentlicht: ein unverbindliches Dokument, das die Struktur des Verordnungsanhangs spiegelt und je Anforderung Umsetzungshinweise sowie Beispiele für Nachweise nennt, die einem Prüfer vorgelegt werden können (ENISA Technical Implementation Guidance 2025).
- 5.1.1 — Lieferkettensicherheitskonzept: Die Einrichtung legt ein Konzept fest, das die Beziehungen zu unmittelbaren Anbietern und Diensteanbietern regelt, und kommuniziert ihre eigene Rolle in der Lieferkette an diese Anbieter (ENISA Technical Implementation Guidance 2025).
- 5.1.2 — Auswahlkriterien: Cybersicherheitspraktiken des Anbieters inklusive sicherer Entwicklungsverfahren, Fähigkeit zur Erfüllung eigener Vorgaben, Qualität und Resilienz der Produkte sowie die Möglichkeit, Bezugsquellen zu diversifizieren und Anbieterbindung zu begrenzen (Durchführungsverordnung (EU) 2024/2690).
- 5.1.4 — Vertragsinhalte: acht Punkte, von Sicherheitsanforderungen bis zu Pflichten bei Vertragsende — der Kern dieses Artikels (Durchführungsverordnung (EU) 2024/2690).
- 5.1.6 und 5.1.7 — laufende Beobachtung: Überprüfung des Konzepts in geplanten Intervallen und bei erheblichen Änderungen, Auswertung von SLA-Berichten, Prüfung von Vorfällen bei Anbietern, außerplanmäßige Reviews (Durchführungsverordnung (EU) 2024/2690).
- 5.2 — Verzeichnis der Anbieter: ein aktuell gehaltenes Register mit Kontaktstellen je Anbieter und einer Liste der gelieferten IKT-Produkte, -Dienste und -Prozesse (Durchführungsverordnung (EU) 2024/2690).
Die ENISA stellt klar: Gemeinschaften und Projekte, die freie und quelloffene Software entwickeln und verteilen, gelten in der Regel nicht als unmittelbare Anbieter, solange keine vertragliche Beziehung über die Einhaltung einer standardisierten Lizenz hinaus besteht (ENISA Technical Implementation Guidance 2025). Das entbindet nicht von der Sorgfalt: Für Abhängigkeiten empfiehlt die ENISA, den unmittelbaren Anbieter zu verpflichten, quelloffene Komponenten regelmäßig zu aktualisieren und bekannte Schwachstellen zu schließen. Die Bestandsseite dieser Aufgabe beschreibt unser Beitrag zur Software-Stückliste nach dem Cyber Resilience Act.
Betroffenheit hängt an Sektor und Schwellenwert, nicht am Bauchgefühl
Bevor jemand ein Register anlegt, gehört die naheliegendste Frage geklärt: Gilt NIS2 überhaupt? Das BSI geht von rund 29.500 Unternehmen und Einrichtungen der Bundesverwaltung aus, die unter die neuen Pflichten fallen (BSI 2026). Zuvor waren nach dem alten BSI-Gesetz etwa 4.500 Organisationen reguliert (BSI 2026). Erfasst sind 18 Sektoren — von Energie über Verkehr und Gesundheit bis zur digitalen Infrastruktur. Maßgeblich ist die Kombination aus Sektor und Größenschwelle nach § 28 BSIG, nicht die Selbstwahrnehmung.
| Kategorie | Typische Schwelle im Regelfall | Bußgeldrahmen nach § 65 BSIG |
|---|---|---|
| Besonders wichtige Einrichtungen | ab 250 Beschäftigte oder über 50 Mio. EUR Umsatz und über 43 Mio. EUR Bilanzsumme | bis 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes |
| Wichtige Einrichtungen | ab 50 Beschäftigte oder über 10 Mio. EUR Umsatz und Bilanzsumme | bis 7 Mio. EUR oder 1,4 % des weltweiten Jahresumsatzes |
| Nicht erfasste Zulieferer | unterhalb der Schwellen oder außerhalb der Anlagen 1 und 2 | kein direktes Bußgeld — Anforderungen kommen vertraglich |
Die dritte Zeile ist der Punkt, den dieser Artikel ernst nimmt. Nicht jede Firma ist eine wesentliche oder wichtige Einrichtung — das ist keine Panikmache-Zone. Wer aber Zulieferer einer betroffenen Einrichtung ist, bekommt die Anforderungen vertraglich durchgereicht. Genau das ist der Mechanismus, den Artikel 21 Absatz 2 Buchstabe d bewusst auslöst: Die erfasste Einrichtung muss ihre unmittelbaren Anbieter vertraglich binden, also wandern Meldepflichten, Auditrechte und Sicherheitsanforderungen die Kette hinunter. Für Agenturen, Hoster und Managed-Service-Anbieter ist NIS2 damit auch dann relevant, wenn sie selbst weit unter jeder Schwelle liegen (Projekterfahrung).
Die Registrierungslage zeigt, wie zäh der Einstieg ist. Die gesetzliche Frist nach § 33 BSIG lief am 6. März 2026 ab. Bis Ende Mai 2026 hatten sich von den rund 29.500 erwarteten Einrichtungen erst etwa 18.500 registriert (BSI, Stand Ende Mai 2026). Das BSI hat daraufhin angekündigt, verspätete Registrierungen bis zum 31. Juli 2026 zu dulden — juristisch eine Vollzugskulanz, keine Änderung der gesetzlichen Frist (BSI 2026). Die fehlende Registrierung ist nach § 65 BSIG ein eigenständiger Bußgeldtatbestand mit einem Rahmen bis zu 500.000 Euro (BSIG in der seit 06.12.2025 geltenden Fassung).
Erst die Betroffenheitsprüfung — Sektor nach den Anlagen 1 und 2 BSIG, Beschäftigtenzahl, Umsatz, Bilanzsumme. Dann die Registrierung, falls einschlägig. Erst danach das Lieferketten-Register. Wer umgekehrt startet, dokumentiert unter Umständen monatelang eine Kette, ohne zu wissen, welche Nachweistiefe überhaupt gefordert ist. Das BSI stellt für die Betroffenheitsprüfung Hinweise und ein Starterpaket bereit (BSI 2026). Eine strukturierte Selbsteinschätzung über die zehn Maßnahmenbereiche bietet die NIS2-Readiness-Funktion von XICTRAQ — als Vorbereitungshilfe, nicht als Rechtsberatung.
Schritt 1: Das Dienstleister-Inventar für Website-Betreiber
Nummer 5.2 des Verordnungsanhangs ist die konkreteste Anforderung im ganzen Abschnitt. Die Einrichtung führt ein aktuell gehaltenes Verzeichnis ihrer unmittelbaren Anbieter und Diensteanbieter, das mindestens Kontaktstellen je Anbieter und eine Liste der gelieferten IKT-Produkte, -Dienste und -Prozesse enthält (Durchführungsverordnung (EU) 2024/2690). Die ENISA ergänzt als Hinweis, zusätzlich Vertragsbeginn und -ende sowie die Region je Anbieter aufzunehmen, und das Register mindestens jährlich oder bei erheblichen Änderungen zu überprüfen (ENISA Technical Implementation Guidance 2025).
Für eine Website ist diese Liste länger, als die meisten erwarten. Sie besteht nicht nur aus den Vertragspartnern, die in der Buchhaltung auftauchen, sondern aus allem, was zur Laufzeit mitspielt. Der Anhaltspunkt aus der Praxis: Alles, was eine eigene Domain im Netzwerk-Wasserfall der Startseite hat oder ohne dessen Verfügbarkeit die Seite nicht funktioniert, gehört geprüft (Projekterfahrung).
Webhoster, Datenbank, Objektspeicher, Backup-Ziel. Standort und Vertragslaufzeit gehören ins Register, weil die ENISA die Region ausdrücklich als Zusatzfeld empfiehlt.
Inhaltszustellnetz, autoritative Nameserver, Registrar. Diese Anbieter sind zum Teil selbst NIS2-reguliert — was die Nachweisbeschaffung erleichtert.
Entwicklungsagentur, Managed-Service-Anbieter, Freelancer mit Zugang. Hier zählt auch die Anforderung an Schulung und Hintergrundprüfung des Personals.
Zahlungsabwicklung, Consent-Management, Formular- und Versanddienste. Hoher Datenzugriff, oft direkter Skript-Einbau in die Seite.
Chat, Karten, Schriftarten, Tag-Container, Analytics. Der am häufigsten übersehene Teil — Details im Beitrag zum Risiko eingebundener Dritt-Skripte.
CMS-Erweiterungen, Bibliotheken, Build-Abhängigkeiten. Wo eine vertragliche Beziehung besteht, ist der Hersteller unmittelbarer Anbieter.
Ein praktischer Zusatznutzen: Wer das Register aus dem tatsächlichen Netzwerkverkehr der Seite herleitet statt aus der Vertragsablage, findet regelmäßig Dienste, die niemand mehr auf dem Schirm hatte — ein Widget aus einer alten Kampagne, ein Tracking-Pixel eines beendeten Dienstleisters, eine Schriftart von einer fremden Domain (Projekterfahrung). Diese Funde sind für die Aufsicht unspektakulär, für die eigene Angriffsfläche aber relevant.
Schritt 2: Risikobasierte Einstufung statt Gleichbehandlung
Ein Register ohne Einstufung ist eine Liste. Die ENISA empfiehlt, unmittelbare Anbieter zu klassifizieren, und nennt als mögliche Merkmale die Sensibilität der bezogenen Werte, das Volumen, Verfügbarkeitsanforderungen, anwendbare Regularien sowie das inhärente und das gemilderte Risiko (ENISA Technical Implementation Guidance 2025). Als Beispielkategorien schlägt sie kritisch, strategisch und routine vor und empfiehlt, die Einstufung jährlich oder bei erheblichen Änderungen zu überprüfen (ENISA Technical Implementation Guidance 2025).
Für Website-Betreiber lässt sich das an zwei Fragen festmachen: Welche Daten sieht der Dienst? und Was passiert, wenn er ausfällt? Aus der Kombination ergibt sich die Prüftiefe — und damit auch, wie viel Aufwand die Nachweisführung rechtfertigt.
| Klasse | Merkmal | Beispiel im Website-Umfeld | Prüftiefe |
|---|---|---|---|
| kritisch | Ausfall stoppt den Betrieb oder der Dienst sieht sensible Daten | Hoster, DNS, Zahlungsdienst | laufende technische Überwachung, Auditrecht, dokumentierte Reviews |
| strategisch | hoher Wertbeitrag, breite Wirkung, aber verzögert spürbar | CDN, Agentur, Managed Service | regelmäßige Reviews, SLA-Berichte, Meldung von Änderungen |
| routine | begrenzte Ausfallwirkung, kein sensibler Datenzugriff | Karten-Widget, Schriftarten-Dienst | Bestandsführung, Stichproben, jährliche Sichtung |
Die Einstufung ist kein Selbstzweck. Die ENISA formuliert als Nachweisbeispiel ausdrücklich, dass die Einrichtung belegen können sollte, dass sie Risiken je Anbieterkategorie bewertet und die Maßnahmen entsprechend zuschneidet — kritische Anbieter erhalten mehr Aufmerksamkeit und eigene Vorgaben (ENISA Technical Implementation Guidance 2025). Wer alle Dienstleister gleich behandelt, produziert entweder zu viel Papier oder zu wenig Substanz.
Nummer 5.1.2 Buchstabe d der Durchführungsverordnung nennt die Fähigkeit, Bezugsquellen zu diversifizieren und Anbieterbindung zu begrenzen als Auswahlkriterium (Durchführungsverordnung (EU) 2024/2690). Die ENISA konkretisiert das mit Parametern wie der Nutzung offener und interoperabler Standards, offener Datenformate sowie dem Verzicht auf langfristige Bindungen ohne klare Ausstiegsstrategie (ENISA Technical Implementation Guidance 2025). Sie empfiehlt zudem, eine kurze Liste von Alternativen für den Fall bereitzuhalten, dass ein Anbieter ausfällt.
Schritt 3: Die acht Vertragspunkte, die die Verordnung nennt
Nummer 5.1.4 des Anhangs ist der Abschnitt, den man ausdrucken und neben den Vertragsentwurf legen kann. Die Einrichtungen stellen sicher, dass ihre Verträge mit Anbietern und Diensteanbietern — soweit angemessen über Dienstgütevereinbarungen — die folgenden Punkte festlegen (Durchführungsverordnung (EU) 2024/2690):
- Cybersicherheitsanforderungen an den Anbieter, einschließlich der Anforderungen an die Sicherheit bei der Beschaffung von IKT-Diensten oder -Produkten nach Nummer 6.1 des Anhangs.
- Anforderungen an Bewusstsein, Fähigkeiten und Schulung sowie, soweit angemessen, an Zertifizierungen der Beschäftigten des Anbieters.
- Anforderungen an die Überprüfung des Hintergrunds der Beschäftigten des Anbieters.
- Eine Pflicht des Anbieters, die Einrichtung ohne unangemessene Verzögerung über Sicherheitsvorfälle zu unterrichten, die ein Risiko für deren Netz- und Informationssysteme darstellen.
- Das Recht auf Prüfung oder auf Erhalt von Prüfberichten — also Auditrecht oder Auditbericht.
- Eine Pflicht zur Behandlung von Schwachstellen, die ein Risiko für die Systeme der Einrichtung darstellen.
- Anforderungen an die Unterauftragsvergabe und, soweit erlaubt, Cybersicherheitsanforderungen an Unterauftragnehmer entsprechend Punkt 1.
- Pflichten bei Vertragsende, etwa Rückgabe und Löschung der Informationen, die der Anbieter bei der Aufgabenerfüllung erhalten hat.
Punkt 4 ist der Anschluss an das eigene Meldewesen — und der Punkt, an dem die meisten Standardverträge scheitern. Ohne unangemessene Verzögerung ist keine Zahl. Wer selbst der 24-Stunden-Frühwarnung nach Artikel 23 der Richtlinie unterliegt, braucht vom kritischen Anbieter eine Meldefrist, die davor liegt — sonst ist die eigene Frist rechnerisch nicht mehr zu halten. Die ENISA nennt als zusätzliche Vertragselemente unter anderem Kontakte und Berichtswege, die Pflicht zur vollständigen Zusammenarbeit mit den zuständigen Behörden sowie die Pflicht des Anbieters, im Falle eines durch sein Produkt verursachten Vorfalls ohne Zusatzkosten oder zu vorab bestimmten Kosten Unterstützung zu leisten (ENISA Technical Implementation Guidance 2025).
Die Einrichtung bleibt in vollem Umfang verantwortlich für die Integrität, Verfügbarkeit und Vertraulichkeit der von Anbietern erbrachten Dienste. Dienstgütevereinbarungen müssen klar definiert, aktiv gesteuert und auf die Betriebskontinuitäts-, Sicherheits- und Compliance-Pflichten der Einrichtung abgestimmt sein.
— ENISA, Technical Implementation Guidance on Cybersecurity Risk-Management Measures, Version 1.0, Juni 2025 (sinngemäß übersetzt)
Diese Klarstellung entkräftet das häufigste Missverständnis in Vertragsgesprächen: Die Verantwortung wandert nicht mit dem Auftrag zum Dienstleister. Sie bleibt bei der Einrichtung. Der Vertrag ist das Werkzeug, um Informationen und Rechte zu bekommen — nicht, um Verantwortung abzugeben. Die ENISA weist zudem darauf hin, dass die Anforderungen aus Nummer 5.1.4 in allen einschlägigen neuen und verlängerten Verträgen enthalten sein sollten (ENISA Technical Implementation Guidance 2025). Bestandsverträge wandern also über die nächste Verlängerung in die Systematik, nicht über eine Sonderaktion.
Für kleinere Betriebe gegenüber großen Anbietern nennt die ENISA einen realistischen Werkzeugkasten, weil individuelles Verhandeln dort selten funktioniert: gebündelte Beschaffung mit Organisationen ähnlicher Größe, Vertretung durch einen Verband, rechtliche Prüfung des Vertrags, Anbieter, die ihre Sicherheits- und Zuverlässigkeitszusagen öffentlich veröffentlichen, Anbieter mit gängigen Zertifizierungen sowie Vertragsvorlagen und kostenfreie Checklisten von Verbänden oder Behörden (ENISA Technical Implementation Guidance 2025).
Schritt 4: Kontinuierliche Nachweisführung statt einmaligem Fragebogen
Hier liegt der eigentliche Bruch zwischen gängiger Praxis und dem, was der Verordnungsanhang beschreibt. Der übliche Ansatz ist ein Fragebogen beim Onboarding: Der Dienstleister kreuzt an, unterschreibt, die Antwort wandert in einen Ordner. Nummer 5.1.6 verlangt aber, dass die Einrichtung Änderungen in den Cybersicherheitspraktiken der Anbieter beobachtet, bewertet und nötigenfalls darauf reagiert — in geplanten Intervallen und bei erheblichen Änderungen des Betriebs, der Risiken oder bei erheblichen Vorfällen (Durchführungsverordnung (EU) 2024/2690).
Nummer 5.1.7 wird noch deutlicher und verlangt vier Dinge: regelmäßige Auswertung von Berichten zur Umsetzung der Dienstgütevereinbarungen, Prüfung von Vorfällen im Zusammenhang mit den Produkten und Diensten der Anbieter, die Bewertung des Bedarfs an außerplanmäßigen Reviews samt nachvollziehbarer Dokumentation der Ergebnisse sowie die Analyse der Risiken aus Änderungen an den bezogenen Produkten und Diensten (Durchführungsverordnung (EU) 2024/2690). Ein Fragebogen von vor achtzehn Monaten beantwortet keine dieser vier Fragen.
Der Ausweg ist nicht mehr Papier, sondern eine andere Art von Beleg. Ein Fragebogen behauptet einen Zustand zu einem Zeitpunkt. Ein datierter technischer Messwert belegt einen Zustand über einen Zeitraum — und genau danach fragt Nummer 5.1.7. Die ENISA führt als Nachweisbeispiele unter anderem Aufzeichnungen, die zeigen, dass Dienstgüte gemäß vereinbarter SLA überwacht wird, sowie eine Liste der Sicherheitsvorfälle im Zusammenhang mit Dritten auf (ENISA Technical Implementation Guidance 2025).
Das SLA verspricht eine Verfügbarkeit. Ein Beleg misst sie. Wer aus mehreren Regionen prüft, kann Ausfälle des Anbieters von eigenen Netzproblemen trennen — siehe Uptime-Monitoring.
Zertifikatslaufzeit, Kette, Protokollversion und Sperrstatus des Anbieter-Endpunkts sind objektiv messbar. Zum Wandel der Sperrprüfung siehe unseren Beitrag zum Ende von OCSP und der Rückkehr der CRL.
Ob HSTS, CSP und Co. gesetzt sind und gesetzt bleiben, ist ein wiederholbarer Messwert — Grundlagen im Beitrag zu den HTTP-Security-Headern.
Ein Prüfsummen-Vergleich des ausgelieferten Skripts zeigt Änderungen, die kein Fragebogen meldet. Dazu passt das Script-Integrity-Monitoring.
Der Fragebogen beantwortet die Frage Was behauptet der Anbieter?. Die kontinuierliche Messung beantwortet die Frage Was liefert der Anbieter tatsächlich aus — und seit wann?. Nur die zweite Antwort ist ein datierter Beleg, der in einer außerplanmäßigen Review nach Nummer 5.1.7 Buchstabe c etwas wert ist.
Was sich technisch überhaupt belegen lässt
Ehrlichkeit an dieser Stelle ist wichtig: Von außen lässt sich nicht alles prüfen, was Artikel 21 verlangt. Ob ein Hoster seine Beschäftigten schult, ob Hintergrundprüfungen laufen, ob es ein Notfallhandbuch gibt — das steht in Zertifikaten und Berichten, nicht im Netzwerkverkehr. Umgekehrt gibt es einen Bereich, in dem die externe Messung präziser ist als jede Selbstauskunft: alles, was der Anbieter tatsächlich ausliefert.
| Nachweisfrage | Einmaliger Fragebogen | Kontinuierlicher Beleg |
|---|---|---|
| Hält der Anbieter seine Verfügbarkeitszusage? | Selbstauskunft, meist ohne Messgrundlage | Messreihe je Prüfpunkt mit Zeitstempel |
| Ist die TLS-Konfiguration noch aktuell? | Zustand am Tag des Ausfüllens | Wiederholte Prüfung, Änderung datiert |
| Wurde das eingebundene Skript verändert? | Nicht abgedeckt | Prüfsummen-Vergleich je Abruf |
| Wann hat sich die Konfiguration geändert? | Unbekannt | Änderungshistorie mit Datum |
| Schult der Anbieter sein Personal? | Selbstauskunft oder Zertifikat | Nicht extern messbar — Vertrag und Bericht bleiben nötig |
| Gibt es einen Wiederanlaufplan? | Selbstauskunft oder Auditbericht | Nicht extern messbar — Auditrecht nutzen |
Die Tabelle zeigt die realistische Arbeitsteilung: Vertrag und Auditbericht decken die organisatorische Seite, laufende Messung die technische. Beides zusammen ergibt die Nachweislage, die Nummer 5.1.7 beschreibt. Wer nur das eine hat, hat eine halbe Antwort. Für die Bewertung neu bekannt gewordener Schwachstellen in den Komponenten der Anbieter lohnt zusätzlich der Blick auf die europäischen Feeds — dazu unser Beitrag zur EUVD und den CVE-Schwachstellen-Feeds.
Wenn der Dienstleister der Vorfall ist
Artikel 23 der Richtlinie (EU) 2022/2555 staffelt die Meldung eines erheblichen Sicherheitsvorfalls in drei Stufen: Frühwarnung binnen 24 Stunden, Meldung mit Erstbewertung binnen 72 Stunden, Abschlussbericht binnen eines Monats (Richtlinie (EU) 2022/2555). Die Fristen laufen ab Kenntnis des Vorfalls. Genau hier verbindet sich die Lieferkette mit dem Meldewesen: Wenn der Ausfall beim Hoster liegt, das manipulierte Skript beim Zahlungsdienst und die kompromittierte Konfiguration beim DNS-Anbieter, dann hängt der Beginn der eigenen Frist davon ab, wann man es erfährt.
Ein Anbieter meldet vertragsgemäß ohne unangemessene Verzögerung — in der Praxis nach 48 Stunden. Die eigene Frühwarnung ist nach 24 Stunden fällig. Diese Rechnung geht nicht auf. Für als kritisch eingestufte Anbieter gehört deshalb eine konkrete Stundenzahl in den Vertrag, die vor der eigenen Frist liegt. Parallel gilt: Eine eigene Erkennung, die nicht auf die Meldung des Anbieters wartet, verkürzt die Zeit bis zur Kenntnis erheblich (Projekterfahrung). Beides zusammen — vertragliche Frist und eigene Messung — ist belastbarer als jede der beiden Maßnahmen allein.
Praktisch heißt das: Der Ausfall eines kritischen Anbieters sollte im eigenen Haus auffallen, bevor die Statusseite des Anbieters ihn bestätigt. Dafür braucht es keine große Architektur — eine wiederkehrende Prüfung der Endpunkte, auf die man angewiesen ist, mit Alarmierung in einen Kanal, den jemand liest. Wer das mit einem DNS- und Domain-Monitoring und einer Änderungshistorie der Seite verbindet, hat neben dem Alarm auch gleich den datierten Beleg, der später in den Abschlussbericht gehört.
Häufige Fehler im Lieferketten-Register
Aus Projekten mit Website-Betreibern wiederholen sich einige Muster (Projekterfahrung). Sie sind alle leicht zu vermeiden, wenn man sie einmal gesehen hat.
- Register aus der Buchhaltung statt aus dem Netzwerkverkehr. Kostenlose Dienste ohne Rechnung fehlen dann systematisch — obwohl sie Skripte in die Seite laden.
- Unterauftragnehmer werden übersprungen. Nummer 5.1.4 Buchstabe g verlangt ausdrücklich Anforderungen an die Unterauftragsvergabe (Durchführungsverordnung (EU) 2024/2690). Der Hoster, der selbst im Rechenzentrum eines Dritten sitzt, ist der Regelfall, nicht die Ausnahme.
- Keine Kontaktstelle hinterlegt. Nummer 5.2 Buchstabe a nennt Kontaktstellen als Pflichtinhalt (Durchführungsverordnung (EU) 2024/2690). Im Vorfall ist eine allgemeine Support-Adresse zu wenig.
- Alle Anbieter gleich behandelt. Ohne Klassifizierung verteilt sich der Aufwand falsch — die ENISA empfiehlt ausdrücklich eine Kategorisierung nach Kritikalität (ENISA Technical Implementation Guidance 2025).
- Kein Ausstiegsprozess dokumentiert. Die ENISA nennt den Exit-Prozess ausdrücklich als Nachweisbeispiel: wie Dienste, Daten und Zugriffsrechte beim Ende einer Beziehung übergehen (ENISA Technical Implementation Guidance 2025).
- Register wird nach der Erstellung nicht mehr angefasst. Nummer 5.2 verlangt ein aktuell gehaltenes Verzeichnis; die ENISA empfiehlt eine Überprüfung mindestens jährlich oder bei erheblichen Änderungen (ENISA Technical Implementation Guidance 2025).
Die Lieferkette als Dauerprozess aufsetzen
Die Sicherheit der Lieferkette ist die Maßnahme aus Artikel 21, die sich am schlechtesten als Projekt abschließen lässt. Inventar, Einstufung und Verträge sind Einmalarbeit mit jährlicher Pflege. Die Nachweisführung aus Nummer 5.1.7 ist dagegen ein Dauerzustand — und genau deshalb scheitert sie, wenn sie an einem Kalendereintrag hängt statt an einem Prozess, der von selbst läuft.
Der pragmatische Zuschnitt für eine Einrichtung ab 50 Mitarbeitenden sieht in der Praxis so aus: Das Register lebt an einer Stelle, nicht in drei Tabellen. Die kritischen Anbieter haben eine vertragliche Meldefrist in Stunden. Die technisch messbaren Eigenschaften dieser Anbieter — Erreichbarkeit, TLS-Zustand, Header, Skript-Integrität, Änderungen — werden ohne manuelles Zutun geprüft und mit Zeitstempel abgelegt. Und die Meldefristen aus Artikel 23 hängen an einer Erinnerung, nicht am Gedächtnis einer einzelnen Person (Projekterfahrung).
Genau diese Bündelung ist der Zweck der NIS2-Readiness-Funktion: Sie führt das Lieferketten-Register, schlägt beim Scan erkannte Dritt-Dienste als Einträge vor, dokumentiert den Stand über die zehn Maßnahmenbereiche und rechnet bei einem erfassten Vorfall die Fristen von 24 Stunden, 72 Stunden und einem Monat aus, samt Erinnerung. Die technischen Belege liefern die Security-Scan-Funktion und das laufende Monitoring; welche Module in welchem Tarif enthalten sind, zeigt die Preisübersicht. Es bleibt eine Vorbereitungs- und Dokumentationshilfe — die rechtliche Bewertung gehört zu Fachkundigen und zur zuständigen Behörde.
Dieser Artikel stützt sich auf: Richtlinie (EU) 2022/2555 (NIS2), insbesondere Artikel 21 Absatz 2 Buchstabe d (Sicherheit der Lieferkette) und Artikel 23 (Berichtspflichten); NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) sowie BSIG in der seit dem 06.12.2025 geltenden Fassung, insbesondere § 28 (Einrichtungskategorien), § 30 (Risikomanagementmaßnahmen), § 33 (Registrierung) und § 65 (Bußgeldvorschriften); BSI — Registrierungs- und Meldeportal für NIS2-Einrichtungen (freigeschaltet am 06.01.2026) sowie BSI-Hinweise zur Betroffenheitsprüfung und zur Registrierungslage (Stand Ende Mai 2026); Durchführungsverordnung (EU) 2024/2690 vom 17.10.2024 mit den technischen und methodischen Anforderungen, Anhang Nummer 5 (Sicherheit der Lieferkette); ENISA — Technical Implementation Guidance on Cybersecurity Risk-Management Measures, Version 1.0 vom 26.06.2025; ENISA Threat Landscape 2025 (4.875 ausgewertete Vorfälle, Zeitraum 01.07.2024 bis 30.06.2025); Bitkom — Wirtschaftsschutz 2025 (Befragung von über 1.000 Unternehmen). Ergänzend fließen eigene Erfahrungswerte aus Monitoring-Projekten ein, gekennzeichnet als (Projekterfahrung). Dieser Beitrag ist eine redaktionelle Einordnung und ersetzt keine Rechtsberatung.