Was müssen NIS2-konforme Lieferantenverträge enthalten?

Stand: 18.09.2026 · ComplyCheck-Redaktion · Keine Rechtsberatung iSd RDG § 2.

Worum es geht

NIS2 hat die Lieferketten-Sicherheit zur eigenständigen Mindestmaßnahme erhoben. Hintergrund: erfolgreiche Angriffe der letzten Jahre (SolarWinds, Kaseya, MOVEit) zeigten, dass die Sicherheit eines Unternehmens nur so stark ist wie die seiner kritischsten Lieferanten.

Der Wortlaut von Art. 21 Abs. 2 lit. d NIS2 bzw. § 30 Abs. 2 Nr. 4 BSIG ist offen: Die Einrichtung muss „sicherheitsbezogene Aspekte" der Lieferantenbeziehungen adressieren. Orientierung bietet das BSI mit dem Infopaket „#nis2know – Sichere Lieferkette".

Die Pflicht trifft die NIS2-Einrichtung gegenüber ihren unmittelbaren Anbietern (Tier-1). Sub-Anbieter (Tier-2+) erfasst das Gesetz nicht ausdrücklich. Wer sie einbeziehen will, kann das vertraglich über sogenannte „Pass-through-Klauseln" tun, die den Tier-1-Anbieter verpflichten, vergleichbare Anforderungen an seine eigenen Anbieter zu stellen.

Risiko-Klassifikation als Ausgangspunkt

Bevor Verträge konkretisiert werden, muss eine Risiko-Klassifikation der Lieferanten stehen. Übliche Klassen-Logik:

Die Klassifikation sollte dokumentiert, regelmäßig überprüft und im Lieferanten-Inventar verfügbar sein. § 30 Abs. 1 Satz 3 BSIG verlangt, die Einhaltung der Risikomanagementpflichten zu dokumentieren; dazu gehört auch die Sicherheit der Lieferkette nach § 30 Abs. 2 Nr. 4 BSIG.

Die zehn Klauseln im Detail

Klausel 1: Sicherheits-Standards

Verpflichtung, ein anerkanntes Sicherheits-Standard-Niveau einzuhalten. Beispiel-Formulierung: „Der Auftrag-Nehmer verpflichtet sich, ein Informations-Sicherheits-Management-System (ISMS) zu betreiben, das den Anforderungen der ISO/IEC 27001:2022 (oder BSI-IT-Grundschutz, oder gleichwertig) entspricht. Auf Anforderung ist ein gültiges Zertifikat oder vergleichbarer Nachweis vorzulegen."

Für kritische Lieferanten oft mit konkreten Zertifikats-Pflichten verschärft. Für Standard-Lieferanten genügt eine Selbstauskunft zu Sicherheits-Praktiken.

Klausel 2: Authentifizierung (MFA)

Verpflichtung, alle Zugänge zu Kunden-Daten oder Kunden-Systemen mit Multi-Faktor-Authentifizierung abzusichern. Bei kritischen Zugängen Phishing-resistente Verfahren (Hardware-Token, Passkeys). Ob SMS als zweiter Faktor zulässig ist, sollte der Vertrag ausdrücklich regeln.

Klausel 3: Patch-Verpflichtung

Verpflichtung, Sicherheits-Patches zeitnah einzuspielen. Gesetzliche Fristen dafür gibt es nicht; die Fristen für kritische und normale Updates sind vertraglich festzulegen und an der Risiko-Klasse des Lieferanten auszurichten.

Bei Software-Lieferanten zusätzlich: Verpflichtung zur Bereitstellung von Sicherheits-Patches während der vereinbarten Support-Laufzeit. CRA-Verbindung: Die Anforderungen an die Schwachstellenbehandlung nach Anhang I Teil II der Verordnung (EU) 2024/2847 gelten ab 11.12.2027; die Meldepflichten der Hersteller nach Art. 14 gelten bereits seit 11.09.2026.

Klausel 4: Incident-Meldung an den Kunden

Die zentrale NIS2-spezifische Klausel. Pflichten:

• Meldung von Sicherheits-Vorfällen, die Kunden-Daten oder -Systeme betreffen, binnen 24 Stunden an den Kunden, damit dieser seine eigene Meldepflicht nach Art. 23 NIS2 bzw. § 32 BSIG (frühe Erstmeldung binnen 24 Stunden, Meldung binnen 72 Stunden nach Kenntniserlangung, Abschlussmeldung spätestens einen Monat nach der Meldung) erfüllen kann.
• Bereitstellung von Forensik-Daten auf Anforderung.
• Aktive Mitwirkung bei der Wieder-Anlauf-Steuerung.
• Berichts-Pflicht zu Maßnahmen, mit denen Wieder-holung ausgeschlossen wird.

Empfehlung: eine 24h-Frist für die Lieferanten-Meldung an den Kunden, damit der Kunde seine 24h-Frist gegenüber der gemeinsamen Meldestelle von BSI und BBK (§ 32 Abs. 1 BSIG) sicher einhalten kann.

Klausel 5: Audit-Rechte

Kunden-Recht, beim Lieferanten Sicherheits-Audits durchzuführen, entweder selbst oder durch beauftragte Dritte. Zu regeln sind unter anderem:

• Ankündigungs-Frist (Dauer vertraglich festlegen).
• Maximal ein Audit pro Jahr ohne besonderen Anlass.
• Anlass-bezogene Audits nach Vorfällen unbeschränkt.
• Audit-Berichte mit Maßnahmen-Plänen.

Für SaaS-Lieferanten oft modifiziert: statt direkter Audits Bereitstellung von SOC-2-Berichten, ISO-Zertifikaten und Penetration-Test-Zusammenfassungen.

Klausel 6: Sub-Anbieter-Genehmigung und Pass-through

Verpflichtung, den Einsatz von Sub-Anbietern (mit Zugang zu Kunden-Daten oder -Systemen) vorab durch den Kunden genehmigen zu lassen. Plus „Pass-through-Klausel": der Lieferant überträgt vergleichbare Sicherheits-Pflichten in seine eigenen Sub-Anbieter-Verträge.

Bei großen Cloud-Anbietern oft als „Liste genehmigter Sub-Anbieter" formuliert, über deren Änderungen der Anbieter vorab informiert.

Klausel 7: Datenschutz und Auftrags-Verarbeitung

Wenn der Lieferant personenbezogene Daten verarbeitet: Auftragsverarbeitungs-Vertrag (AVV) nach Art. 28 DSGVO als Anlage. Spezifisch für NIS2: Verknüpfung der DSGVO-72h-Meldepflicht mit der NIS2-24h-Meldepflicht, damit beide Fristen aus einer Quelle bedienbar sind.

Klausel 8: Verschwiegenheits-Pflicht

Verpflichtung zur Geheim-Haltung von Geschäfts-Informationen und Sicherheits-Konfigurationen über die Vertrags-Laufzeit hinaus. Die Nachwirkungsdauer ist vertraglich festzulegen.

Klausel 9: Exit-Klauseln

Pflichten bei Vertrags-Beendigung:

• Sichere Rück-Übertragung oder Löschung von Kunden-Daten.
• Nachweis der Löschung mit definierten Standards (z. B. NIST SP 800-88).
• Mitwirkungs-Pflicht beim Provider-Wechsel (Daten-Migration in standardisierten Formaten).
• Übergangs-Zeit für kritische Dienste (Dauer vertraglich festlegen).

Klausel 10: Haftung

Haftungs-Klauseln für Sicherheits-Vorfälle. Übliche Strukturen:

• Haftungs-Höchst-Beträge an Auftrags-Volumen orientiert.
• Spezielle Haftung für Daten-Schutz-Verletzungen.
• Versicherungs-Pflicht des Lieferanten (Cyber-Haftpflicht).
• Verschuldens- vs. Garantie-Haftung sauber abgegrenzt.

Wichtig: in Standard-Lieferanten-Verträgen oft pauschal begrenzt. Bei kritischen Lieferanten muss die Haftung dem tatsächlichen Schadens-Risiko entsprechen, sonst trägt die NIS2-Einrichtung das Restrisiko.

SLA für Sicherheits-Bereiche

Sicherheits-spezifische SLAs sollten messbar formuliert sein. Die folgenden Werte sind Beispielwerte ohne gesetzliche oder BSI-Vorgabe und je nach Dienst zu verhandeln:

• Vorfall-Meldung an Kunden: binnen 24 Stunden nach Kenntnis.
• Erst-Reaktion bei kritischen Vorfällen: binnen 4 Stunden, dokumentiert.
• Wieder-Anlauf-Zeit (RTO) für kritische Dienste: je nach Service-Klasse 4-72 Stunden.
• Daten-Wiederherstellung (RPO): je nach Datenart 1-24 Stunden.
• Vulnerability-Disclosure: kritische Schwachstellen binnen 7 Tagen kommuniziert, mit Patch-Plan binnen 30 Tagen.
• Audit-Bericht-Bereitstellung: binnen 30 Tagen nach Anforderung.

Bei Nicht-Einhaltung der SLAs: gestaffelte Konventional-Strafen oder Service-Credit-Modelle, abgestuft nach Schwere der Abweichung.

Audit-Rechte praktisch durchsetzen

Ein vertragliches Audit-Recht hat nur Wert, wenn es auch ausgeübt wird. Mögliches Vorgehen:

• Risiko-priorisiert: kritische Lieferanten häufiger prüfen als wichtige; den Turnus je Klasse festlegen und dokumentieren.
• Vor-Audit-Check: Self-Assessment-Fragebogen vor jedem Audit, um den Aufwand zu reduzieren.
• Audit-Pool: mehrere Kunden eines Lieferanten können Audits vertraglich poolen, um Aufwand und Kosten zu teilen.
• Audit-Berichte als Akzeptanz: SOC 2 Type II, ISO-27001-Zertifikate oder PCI-DSS-Berichte werden in der Praxis oft als alternativer Nachweis akzeptiert.

FAQ

Müssen alle Lieferantenverträge ab sofort nachverhandelt werden?

Nicht alle und nicht sofort. Priorisierung nach Risiko-Klasse: kritische Lieferanten zuerst, wichtige im Standard-Zyklus der Vertrags-Erneuerungen, Standard-Lieferanten beim nächsten Update. Wie lange die Umstellung dauert, hängt von Zahl und Laufzeit der Verträge ab; organisatorisch gehört das Programm in Einkauf und Compliance.

Können wir bei großen Cloud-Anbietern auf NIS2-Klauseln bestehen?

Mit großen Hyperscalern (AWS, Microsoft Azure, Google Cloud) lassen sich die Standard-Verträge in der Regel kaum zu spezifischen NIS2-Klauseln umverhandeln. Die Anbieter stellen standardisierte Unterlagen bereit, etwa Compliance-Berichte (SOC 2, ISO 27001) und Data Processing Addenda. Ob diese die eigenen NIS2-Anforderungen, etwa an die Vorfall-Meldung, abdecken, ist im Einzelfall zu prüfen. Praktisch: die Standard-Bedingungen prüfen und gegen die eigene Lieferanten-Anforderung halten. Lücken dokumentieren und im Risiko-Register vermerken.

Was, wenn ein wichtiger Lieferant die Klauseln verweigert?

Dokumentierte Risiko-Akzeptanz-Entscheidung mit Begründung, ggf. kompensierende Maßnahmen auf eigener Seite (zusätzliche Detection, Monitoring, Daten-Minimierung). Falls die Risiko-Akzeptanz nicht zu rechtfertigen ist: Lieferanten-Wechsel als Eskalation.

Wie passen NIS2-Klauseln zum LkSG (Liefer-Ketten-Sorgfaltspflichten-Gesetz)?

Das LkSG adressiert Menschenrechte und Umwelt, NIS2 adressiert Cyber-Sicherheit. Beide laufen parallel. Lieferketten-Verträge haben oft separate Klausel-Pakete für beide Themen, die aus organisatorischer Sicht aber im gleichen Lieferanten-Onboarding zu pflegen sind.

Wie verifiziert man Lieferanten-Compliance über die Zeit?

Drei Mechanismen kombiniert: jährliche Self-Assessments mit Fragebogen, regelmäßige Audit-Berichte (eigene oder Drittpartei), Trigger-basierte Reviews bei Sicherheits-Vorfällen oder Vertrags-Erneuerungen. Wer den Aufwand minimieren will: Tools wie SecurityScorecard, BitSight oder UpGuard bieten kontinuierliche externe Bewertungen, die als zusätzliches Signal genutzt werden können, sie ersetzen aber nicht eigene Audits bei kritischen Lieferanten.