NIS2-Lieferantenfragebögen: Was Kunden wirklich nachweisen müssen

Warum NIS2 mehr Lieferantenfragebögen auslöst

Artikel 21 der NIS2-Richtlinie verlangt von wesentlichen und wichtigen Einrichtungen angemessene und verhältnismäßige Cybersecurity-Risikomanagementmaßnahmen. Dazu gehören ausdrücklich die Sicherheit der Lieferkette und sicherheitsbezogene Aspekte der Beziehungen zu direkten Lieferanten und Diensteanbietern.

Das Gesetz schreibt kein universelles Fragebogenformat vor. In der Praxis übersetzen Einkauf, Security und Compliance diese Pflicht in Due-Diligence-Fragen, Vertragsanforderungen und regelmäßige Neubewertungen. Deshalb erhält ein Anbieter von verschiedenen Kunden oft ähnliche Fragen in völlig unterschiedlichen Tabellen.

• Welche Produkte, Services und Unterauftragnehmer sind für den Kunden kritisch?
• Welche Schwachstellen-, Incident- und Eskalationsprozesse existieren tatsächlich?
• Welche Business-Continuity- und Recovery-Nachweise sind aktuell?
• Wie werden Zugriffe, Verschlüsselung, sichere Entwicklung und Lieferantenrisiken gesteuert?
• Welche Zusagen gelten vertraglich und welche sind nur interne Ziele?

Ein Fragebogen ist keine NIS2-Zertifizierung

NIS2 etabliert kein allgemeines Produktzertifikat, das ein Lieferant mit einem einzelnen Dokument nachweisen könnte. Ein Kundenfragebogen ist zunächst ein Instrument der Risikobewertung des Kunden. Umfang und Tiefe sollten sich an Kritikalität, Abhängigkeit und realem Risiko orientieren.

Auch ein ISO-27001-Zertifikat kann wertvoll sein, ersetzt aber nicht automatisch produktbezogene Angaben. Entscheidend ist, ob Zertifizierungs-Scope, kontrollierte Umgebung und angefragter Service tatsächlich zusammenpassen.

Welche Nachweise eine belastbare Antwort tragen

Die stärkste Antwort verbindet eine präzise Aussage mit der passenden Dokumentstelle und – falls Wirksamkeit gefragt ist – mit einem aktuellen operativen Record. Eine Policy beweist eine Vorgabe; sie beweist nicht automatisch, dass eine Aktivität fristgerecht ausgeführt wurde.

• freigegebene Informationssicherheits- und Lieferantenrichtlinien
• Incident-Response-Plan, Eskalationsmatrix und Übungsprotokolle
• Business-Continuity- und Disaster-Recovery-Tests
• Vulnerability-Management-Prozess, Scan- oder Patch-Nachweise
• Access Reviews, Rollenmodelle und Joiner-Mover-Leaver-Records
• Secure-Development-Vorgaben, Change Records und technische Architektur
• Subprozessorenliste, relevante Verträge und Verantwortlichkeiten

Ein review-fähiger Workflow in sechs Schritten

1. 1. Frage und Behauptung trennen

   Zerlegen Sie mehrteilige Zeilen in einzelne Aussagen. Ein pauschales Ja darf nicht vier unterschiedliche Kontrollen verdecken.

2. 2. Kunden- und Service-Scope bestimmen

   Klären Sie Gesellschaft, Produkt, Region, Deployment und Unterauftragnehmer, bevor eine Quelle zugeordnet wird.

3. 3. Risiko und Kritikalität berücksichtigen

   Priorisieren Sie Fragen, die für den konkreten Service, Datenzugriff und die Abhängigkeit des Kunden relevant sind.

4. 4. Primärquelle plus Record zuordnen

   Nutzen Sie Richtlinien für Anforderungen und operative Evidenz, wenn Ausführung oder Wirksamkeit belegt werden soll.

5. 5. Lücken sichtbar lassen

   Fehlende Evidenz wird als Missing Evidence markiert, einem Owner zugewiesen und nicht durch überzeugend klingenden Text ersetzt.

6. 6. Aussage freigeben und versionieren

   Security, Legal, Datenschutz oder der technische Owner genehmigt die externe Aussage; Quelle, Version und Status bleiben nachvollziehbar.

Wo KI hilft – und wo sie nicht entscheiden darf

KI kann wiederkehrende Fragen gruppieren, passende Dokumentstellen vorschlagen, frühere freigegebene Antworten finden und einen ersten Entwurf erstellen. Das spart besonders bei heterogenen Excel-Dateien Recherchezeit.

Sie kann jedoch weder die rechtliche Betroffenheit eines Kunden noch die Kritikalität eines Lieferanten zuverlässig bestimmen. Ebenso darf sie nicht aus einer allgemeinen Policy auf eine konkrete technische Umsetzung schließen. Scope, Evidenzqualität, Ausnahmen und vertragliche Zusagen brauchen menschliche Verantwortung.

Häufige Fehler bei NIS2-Supplier-Assessments

• jede Frage wird mit demselben Zertifikat beantwortet
• geplante Maßnahmen werden als bereits implementiert beschrieben
• Produkt- und Hosting-Scope bleiben unklar
• alte Antworten werden ohne Quellen- und Versionsprüfung wiederverwendet
• mehrteilige Fragen erhalten ein Ja, obwohl nur ein Teil belegt ist
• fehlende Evidenz wird sprachlich kaschiert
• Sales versendet risikoreiche Zusagen ohne fachliche Freigabe

Definition of Done für den Response Pack

• jede wesentliche Behauptung hat eine passende Quelle oder eine sichtbare Lücke
• Service-, Standort- und Unterauftragnehmer-Scope sind klar
• operative Records ergänzen Policies, wenn Wirksamkeit gefragt ist
• Ausnahmen und Teilabdeckung sind ausdrücklich beschrieben
• Owner und Freigabestatus sind nachvollziehbar
• die Antwort ist präzise, verhältnismäßig und wiederverwendbar