NIS2-Lieferkettensicherheit: Was Art. 21 Nr. 4 von Ihnen verlangt
Der SolarWinds-Angriff 2020 zeigte der Welt, dass die Schwächen der eigenen IT oft bei den Dienstleistern liegen – nicht im eigenen Rechenzentrum. Die NIS2-Richtlinie zieht daraus die regulatorische Konsequenz: Art. 21 Nr. 4 macht Lieferkettensicherheit zur Pflicht jedes betroffenen Unternehmens.
Dieser Artikel erklärt, was "Lieferkettensicherheit" unter NIS2 konkret bedeutet, welche Dienstleister betroffen sind und wie Unternehmen ein funktionierendes Third-Party-Risk-Management aufbauen, ohne jeden Kaffeelieferanten zu auditieren.
1. Was Art. 21 Nr. 4 wirklich verlangt
Der Wortlaut:
"Sicherheit der Lieferkette, einschließlich sicherheitsbezogener Aspekte betreffend die Beziehungen zwischen den einzelnen Einrichtungen und ihren direkten Anbietern oder Dienstleistern."
Wichtig ist das Wort direkt. NIS2 verlangt keine vollständige N-Tier-Lieferantenprüfung (das wäre unmöglich), sondern fokussiert auf First-Tier-Anbieter mit relevanter Auswirkung auf Ihre Cybersicherheit.
Die Kommission und ENISA haben dies in Leitlinien konkretisiert — betroffen sind:
- Cloud- und Hosting-Dienstleister
- Managed Service Provider (MSP, MSSP)
- Software-Lieferanten mit kritischer Rolle im Betrieb
- Hardware-Lieferanten für sicherheitsrelevante Komponenten
- Outsourcing-Partner mit Zugriff auf Systeme oder Daten
- Wartungsdienstleister
2. Die fünf Pflichten
Aus Art. 21 Nr. 4 und den Durchführungsverordnungen ergeben sich fünf konkrete Pflichten:
a) Dienstleister-Inventar
Vollständiges, aktuelles Register aller ICT-Dienstleister mit mindestens:
- Name, Rolle, Zugriffsumfang
- Kritikalitätsbewertung (hoch / mittel / niedrig)
- Standort (EU / Drittstaat)
- Verträge, Laufzeiten, Kündigungsfristen
b) Risikobewertung pro Dienstleister
Strukturierte Bewertung nach folgenden Kriterien:
- Kritikalität für eigene Geschäftsprozesse
- Zugriffsumfang auf eigene Systeme/Daten
- Sicherheitsniveau des Dienstleisters (Zertifizierungen, Audits)
- Ersetzbarkeit im Notfall
c) Vertragliche Mindestanforderungen
NIS2-konforme Verträge müssen enthalten:
- Sicherheitsstandards (z.B. "mindestens ISO 27001 zertifiziert" oder äquivalent)
- Incident-Meldepflicht des Dienstleisters an Sie
- Audit-Rechte (physisch und/oder durch unabhängige Dritte)
- Subcontractor-Regelungen
- Datenlokalisierung (wichtig für Drittstaaten-Transfers)
- Exit-Regelungen
d) Kontinuierliche Überwachung
Einmalige Due Diligence reicht nicht. Gefordert sind:
- Jährliche Re-Assessments der kritischen Dienstleister
- Echtzeit-Überwachung auf Cybersecurity-Incidents (Breach-Notices, öffentliche Sicherheitsmeldungen)
- Überprüfung gültiger Zertifikate
e) Integration in Incident-Management
Bei einem Sicherheitsvorfall bei einem Dienstleister:
- Übernahme in das eigene Incident-Management
- Meldung an BSI (wenn signifikant) innerhalb 24h/72h
- Koordination der Response zwischen eigenen Teams und Dienstleister
3. Konzentrationsrisiko und kritische Dienstleister
Ein Spezialfall: Wenn mehrere Dienstleister auf denselben Cloud-Provider setzen (z.B. AWS, Azure), entsteht Konzentrationsrisiko. NIS2 erwartet Transparenz über diese Abhängigkeiten. Für DORA-regulierte Banken ist das explizit in Art. 28 geregelt; für NIS2 ergibt es sich aus der Risikobewertung.
4. Praktischer Fünf-Schritte-Aufbau
Schritt 1: Inventar (2-3 Wochen)
- Einkauf + IT + Datenschutz fragen nach Dienstleisterverzeichnissen
- Mit Finanzbuchhaltung abgleichen (welche Rechnungen gibt es?)
- Mit SSO/Zugriffsberichten abgleichen (wer hat Zugang?)
- Ergebnis: vollständiges Inventar mit Kritikalitätsbewertung
Schritt 2: Bestandsverträge auditieren (2 Wochen)
- Für die 10-20 kritischsten Dienstleister: haben wir NIS2-konforme Vertragsklauseln?
- Lücken dokumentieren und priorisieren
Schritt 3: Nachverhandlungen (3-6 Monate)
- Standard-Addendum erstellen mit NIS2-Mindestklauseln (Audit-Rechte, Incident-Meldepflicht, Zertifizierungsnachweise, Exit)
- Bei Vertragsverlängerungen einfordern
- Bei neuen Verträgen: NIS2-Klauseln sind Pflicht
Schritt 4: Ongoing-Prozess (laufend)
- Jährliches Re-Assessment der kritischen Dienstleister
- Auto-Alert bei Zertifikatsablauf
- News-Monitoring auf Dienstleister-Incidents
Schritt 5: Software-Unterstützung
Ein händisches Third-Party-Register skaliert nicht. Eine Multi-Framework-GRC-Plattform wie Matproof bietet:
- Automatisierten Import von SSO-/ERP-Daten
- Vordefinierte Fragenkataloge (basierend auf Shared Assessments, CAIQ, SIG)
- Dienstleister-Portal: Anbieter füllen selbst aus
- Auto-Mapping zwischen NIS2, DORA, ISO 27001 (gleiche Daten, mehrere Frameworks)
5. Häufige Fehler
- Einkauf wird nicht einbezogen — die Cybersecurity-Anforderungen müssen in die Vergabeprozesse, sonst bleibt alles Theorie
- Nur die Top-10 werden betrachtet — ein vernachlässigter Dienstleister mit privilegiertem Zugriff kann die größte Schwachstelle sein
- Vertragsklauseln ohne Durchsetzung — Audit-Rechte sind wertlos, wenn sie nie genutzt werden
- Drittstaaten-Dienstleister ignoriert — besonders schwierig bei US-basierten SaaS-Anbietern
- Subdienstleister werden vergessen — der Dienstleister Ihres Dienstleisters ist oft das Problem
Fazit
Lieferkettensicherheit ist nicht der auffälligste, aber einer der aufwändigsten Teile von NIS2. Der Aufbau eines funktionierenden Third-Party-Risk-Managements dauert 6-12 Monate für ein mittelständisches Unternehmen.
Der Aufwand lohnt sich: Eine saubere Dienstleister-Governance ist gleichzeitig die Grundlage für DORA (bei Banken), ISO 27001, DSGVO und den EU AI Act. Das Multi-Framework-Mapping ist der eigentliche Produktivitätsgewinn.
Weiterführend: