NIS2-Lieferanten: bin ich indirekt betroffen?

Begriff: Lieferant im NIS2-Sinn

NIS2 selbst definiert „Lieferant" nicht eng. Art. 21 Abs. 2 lit. d verlangt von erfassten Einrichtungen, „Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren direkten Anbietern oder Dienstleistern" zu adressieren.

Praktisch heißt das: jeder, der direkt eine Leistung an eine NIS2-Einrichtung erbringt, ist im Scope der Lieferketten-Maßnahme — egal ob Software, Hardware, IT-Dienstleistung, Wartung oder Beratung.

Die Pflicht trifft nicht den Lieferanten direkt. Sie trifft die NIS2-Einrichtung, die die Lieferketten-Sicherheit „sicherstellen muss". Der Mechanismus zur Sicherstellung ist üblicherweise vertraglich.

Das hat eine wichtige Konsequenz: Du als Lieferant musst NIS2 nicht erfüllen. Du musst nur die vertraglichen Pflichten erfüllen, die dein Kunde dir auferlegt. Diese Pflichten orientieren sich aber meist eng an den NIS2-Mindestmaßnahmen.

Wann betrifft mich das?

Indirekte Betroffenheit entsteht typischerweise, wenn mindestens eines zutrifft:

• Du lieferst IT-Dienstleistungen (Managed Services, Cloud, Software-Wartung, Hosting) an Unternehmen aus den NIS2-Sektoren.
• Du lieferst Software mit potenziellem Sicherheits-Impact (ERP, CRM, Branchen-Lösungen, IoT-Firmware).
• Du lieferst kritische Hardware (Netzwerk-Komponenten, Embedded Systems, Steuerungs-Technik).
• Du übernimmst Wartung oder Fernzugriff auf Systeme deiner Kunden.

Eine grobe Faustregel: wenn dein Kunde NIS2-pflichtig ist und du Zugang zu seinen IT-Systemen oder Daten hast, kommt die Klausel.

Branchen-Beispiele:

Beispiel 1: IT-Dienstleister mit Krankenhaus-Kunden

Ein 30-MA-IT-Systemhaus, das mehrere Krankenhäuser betreut, ist selbst nicht NIS2-pflichtig (Sektor erfasst, aber unter dem Schwellwert von 50 MA / 10 Mio. € Umsatz). Der Krankenhaus-Kunde fällt aber unter „Gesundheitswesen" und damit unter NIS2. Folge: das Krankenhaus wird vertraglich verlangen, dass das Systemhaus Audits zulässt, Vorfälle binnen 24 Stunden meldet und nachweisbare Sicherheitsmaßnahmen umsetzt.

Beispiel 2: SaaS-Anbieter mit Energie-Kunden

Ein 80-MA-SaaS-Anbieter mit Branchen-Lösung für Stadtwerke ist je nach Tätigkeit selbst NIS2-pflichtig (Sektor „Digitale Infrastruktur" oder „IKT-Dienste-Management"). Selbst wenn nicht, werden die Stadtwerke-Kunden (Sektor „Energie") NIS2-Klauseln in Verträge schreiben — typisch: SBOM-Pflicht, Patch-Management mit SLAs, Penetrationstest-Nachweise.

Beispiel 3: Maschinenbauer als Lieferant für Lebensmittelproduktion

Ein 200-MA-Maschinenbauer liefert Steuerungstechnik an einen Lebensmittelhersteller. Der Hersteller fällt unter NIS2 (Anhang II — Lebensmittelproduktion). Der Maschinenbauer ist nicht direkt erfasst, bekommt aber Anforderungen an die Cyber-Resilience seiner Steuerungstechnik (langfristige Sicherheits-Updates, sichere Default-Konfiguration, Schwachstellen-Reporting).

Beispiel 4: Spedition für Logistik-Kunden

Eine 60-MA-Spedition mit Kunden in Pharma- und Lebensmittel-Logistik. Direkte NIS2-Betroffenheit nur, wenn Verkehrs-Sektor anwendbar ist. Indirekt: Kunden aus „Gesundheitswesen" oder „Lebensmittelproduktion" können Anforderungen an die digitale Track-and-Trace-Infrastruktur stellen (Stand-der-Technik-Authentisierung, Datenintegrität).

Beispiel 5: Marketing-Agentur mit Banken-Kunden

Eine 25-MA-Agentur mit Banken-Kunden. Banken fallen unter NIS2 (Sektor „Bankwesen") und unter DORA. Auch eine Agentur ohne Zugang zu kritischen Banken-Systemen wird in die vertraglichen Sicherheitsanforderungen einbezogen — typisch: Geheimhaltung, Sub-Auftrags-Klauseln, Penetrationstest bei Web-Portalen, Awareness-Schulungen.

Was du als Lieferant typischerweise unterschreiben sollst

Marktübliche Klauseln in NIS2-Lieferanten-Verträgen (Stand 2026, mit erheblicher Bandbreite):

• Sicherheits-Mindeststandards: Verweis auf ISO 27001, BSI-IT-Grundschutz oder vergleichbar.
• Vorfalls-Meldung: binnen 24-72 Stunden bei sicherheitsrelevanten Vorfällen, die den Kunden betreffen können.
• Audit-Recht: einmal jährlich, mit Vorlauf, gegebenenfalls durch unabhängige Dritte.
• Patch- und Schwachstellen-Management: definierte Fristen für Sicherheits-Patches (z.B. kritisch ≤ 7 Tage).
• Software-Stückliste (SBOM): bei Software-Lieferungen oder eingebetteter Firmware. Die BSI TR-03183 wird zunehmend als Referenz herangezogen.
• Sub-Auftrags-Klauseln: dein Recht, Sub-Unternehmer einzusetzen, wird beschränkt; Kunden-Genehmigung wird verlangt.
• Schadensersatz-Klauseln: erweiterte Haftung bei Sicherheits-Vorfällen, die Bußgelder des Kunden auslösen.

Wichtig: Diese Klauseln sind verhandelbar. Eine vollständige Übernahme der Kunden-NIS2-Pflichten ist unverhältnismäßig — du erfüllst die Klauseln im Umfang deiner Leistung, nicht für das ganze Unternehmen des Kunden.

Was Tier-2- und Tier-3-Zulieferer wissen sollten

Wer als Sub-Sub-Lieferant (Tier 2/3) tätig ist — z.B. als Komponenten-Hersteller, der über einen Systemintegrator an einen NIS2-Kunden liefert — wird die Klauseln verzögert sehen. Der Mechanismus:

1. NIS2-Einrichtung (Tier 0) verlangt Sicherheits-Standards vom Hauptlieferanten (Tier 1).
2. Tier 1 reicht die Anforderungen vertraglich an seine eigenen Lieferanten weiter (Tier 2).
3. Tier 2 muss seine Unter-Lieferanten in die Verantwortung nehmen (Tier 3).

In der Praxis verwässert sich die Anforderung mit jeder Stufe. Ein Tier-3-Komponenten-Hersteller wird selten die volle NIS2-Klausel-Pakete sehen, aber zunehmend:

• Anfragen zur Cyber-Resilience seiner Produkte (langfristige Update-Zusagen).
• SBOM-Anforderungen bei Software- oder Firmware-Komponenten.
• Vorfalls-Meldepflichten in einer abgeschwächten Variante (z.B. „Mitteilung über bekannte Schwachstellen mit CVSS ≥ 7 binnen 14 Tagen").

Wer als Tier-2/3-Lieferant strategisch denkt, profitiert von einem einmal sauber aufgestellten Sicherheits-Basis-Niveau, statt 20-mal Kunden-individuelle Anforderungen abzuarbeiten. Eine Self-Disclosure mit dokumentierten Maßnahmen, Schulungs-Nachweisen und Vorfalls-Prozess hilft mehr als individuelle Audit-Antworten.

Praxis: Was Lieferanten jetzt tun sollten

1. NIS2-Exponierung quantifizieren: Welcher Umsatz-Anteil kommt aus NIS2-pflichtigen Kunden-Sektoren? Liegt der über 20-30 %, lohnt sich proaktive Aufstellung.
2. Kunden-Verträge auf NIS2-Klauseln scannen: existieren bereits Sicherheits-Anhänge in Bestandsverträgen? Was wird gefordert?
3. Eigene Mindestmaßnahmen prüfen: ohne selbst NIS2 voll umzusetzen, sollte das Niveau der elf Mindestmaßnahmen (siehe „NIS2-Mindestmaßnahmen — die elf Pflichten kompakt") als Maßstab dienen.
4. Sicherheits-Selbstauskunft vorbereiten: ein 4-6-seitiges Standard-Dokument („Cybersecurity Posture Statement"), das den IT-Sicherheits-Stand zusammenfasst. Spart bei jeder Kunden-Anfrage Zeit.
5. Vertragsverhandlungen vorbereiten: marktübliche Klauseln kennen, eigene Position formulieren. Nicht jede Kunden-Klausel ist verhältnismäßig.

Wer ohnehin in Richtung ISO 27001 oder BSI-IT-Grundschutz arbeitet, hat eine starke Verhandlungsposition.

FAQ

Bin ich als Lieferant rechtlich verpflichtet, NIS2 umzusetzen?

Direkt: nein. Du fällst nur dann unter die direkten NIS2-Pflichten, wenn dein eigener Sektor erfasst ist und die Größen-Schwellwerte greifen. Indirekt: ja, wenn deine Kunden NIS2-pflichtig sind und ihre Pflichten vertraglich an dich weiterreichen. Die Pflichten ergeben sich dann aus dem Vertrag, nicht direkt aus NIS2.

Was ist, wenn ich die geforderten Klauseln ablehne?

Möglich, aber riskant für die Geschäftsbeziehung. NIS2-Einrichtungen sind aufsichtsrechtlich verpflichtet, ihre Lieferanten-Sicherheit zu adressieren — sie können bei Verweigerung den Auftrag entziehen oder auf alternative Lieferanten umsteigen. Pragmatischer ist die Verhandlung: Klauseln auf den tatsächlichen Leistungsumfang begrenzen, unrealistische Anforderungen relativieren, Mehraufwand einpreisen.

Muss ich als Lieferant eine SBOM bereitstellen?

Bei Software-Lieferungen ist das zunehmend Standard. Die BSI TR-03183 liefert eine Referenz für das geforderte Format. Auch der EU Cyber Resilience Act (CRA) — separat zu NIS2 — wird SBOM für vernetzte Produkte verbindlich machen. Wer Software liefert, sollte ohnehin in CycloneDX- oder SPDX-Format investieren.

Gilt das auch für Cloud- und SaaS-Anbieter?

Ja, mit erheblicher Praxis-Relevanz. SaaS-Anbieter sind oft selbst NIS2-pflichtig (Sektor „Digitale Infrastruktur"). Wer es nicht ist, bekommt durch NIS2-Kunden umfassende Anforderungen — typischerweise zu Auditierbarkeit, Datenlokalität, Verschlüsselung at Rest, Schlüssel-Verwaltung, Vorfalls-Meldepflicht. Cloud-Anbieter haben das in der Regel schon adressiert; reine SaaS-Anbieter müssen oft nachziehen.

Was passiert mit Verträgen, die vor NIS2 geschlossen wurden?

Bestehende Verträge laufen weiter — NIS2 hat keine rückwirkende Vertragsänderungs-Pflicht. Aber bei Verlängerung, Erweiterung oder neuen Bestellungen werden NIS2-pflichtige Kunden ihre Sicherheits-Anhänge nachziehen. Vorausschauend ist es sinnvoll, das eigene Sicherheits-Posture so aufzustellen, dass die Klauseln nicht zum Engpass werden.

Wo finde ich eine konkrete Lieferanten-Self-Assessment-Vorlage?

Das BSI hat noch keine offizielle Vorlage publiziert (Stand 2026-05-15). ENISA-Material zur „Supply Chain Cybersecurity" liefert Strukturen, ist aber nicht NIS2-spezifisch normiert. ComplyCheck plant für Phase 2 einen kostenlosen Lieferanten-Self-Disclosure-Generator (verlinkt im Tool-Index, sobald verfügbar). Bis dahin können Anwender den eigenen Self-Disclosure an den 11 Art.-21-Maßnahmen orientieren.