NIS2-Lieferantenverträge mit ISO 27001-Nachweisen

Es ist 07:40 Uhr an einem Montag. Der CISO einer cloudgestützten Logistikplattform öffnet eine E-Mail eines Managed-Detection-and-Response-(MDR)-Lieferanten. Die Nachricht ist kurz, vorsichtig formuliert und unangenehm: Der Lieferant hat verdächtige Zugriffe auf eine Support-Umgebung festgestellt, die von mehreren Kunden genutzt wird. Details sind begrenzt. Der Lieferant kündigt ein Update an, „sobald dies praktikabel ist“.

Um 08:15 Uhr fragt der Compliance-Manager, ob dies eine NIS2-Meldung auslösen könnte. Um 08:40 Uhr sucht die Beschaffung nach dem Vertrag. Um 09:10 Uhr fordert der Sekretär des Leitungsorgans eine Unterrichtung zur Rechenschaftspflicht des Managements. Um 10:00 Uhr fragt die Rechtsabteilung, ob der Vertrag eine 24-Stunden-Meldepflicht, Auditrechte, Kontrollen für Unterauftragnehmer, Zugriff auf Nachweise, Verpflichtungen zur Aufrechterhaltung des Geschäftsbetriebs sowie Bestimmungen zur Datenrückgabe und Löschung enthält.

Niemand möchte während eines laufenden Vorfalls feststellen, dass eine kritische Lieferantenvereinbarung lediglich „angemessene Sicherheitsmaßnahmen“ vorsieht.

An diesem Punkt sind NIS2-Lieferantenvertragsklauseln keine juristischen Standardformulierungen mehr, sondern operative Kontrollen. Für wesentliche und wichtige Einrichtungen ist Lieferanten-Governance heute Teil der Rechenschaftspflicht des Leitungsorgans, der Nachweisführung gegenüber Aufsichtsbehörden, der Vorfallsbereitschaft, der Vertrauensbildung bei Kunden, der Datenschutz-Compliance und der Resilienzplanung. Ein unterzeichneter Vertrag reicht nicht aus. Die Organisation muss nachweisen, dass Lieferantenrisiken identifiziert, genehmigt, behandelt, überwacht und belegt werden.

Der Ansatz von Clarysec beginnt mit einem einfachen Grundsatz: Wenn eine Lieferantenklausel nicht überwacht, nachgewiesen und getestet werden kann, ist sie keine Kontrolle.

Der Zenith Blueprint: 30-Schritte-Roadmap für Auditoren verortet Lieferantenbeziehungen in der Phase „Controls in Action“, Schritt 23, in der Vereinbarungen, Überwachung, Onboarding, Neubewertung und Auditnachweise in praktische ISMS-Arbeit überführt werden. Der Zenith Controls: Der Cross-Compliance-Leitfaden ordnet anschließend ISO/IEC 27002:2022-Lieferantenkontrollen NIS2, DORA, GDPR, NIST, COBIT 2019, unterstützenden ISO-Normen und Auditmethodiken zu.

Das Ergebnis ist ein Lieferanten-Governance-Modell, das Beschaffung, Recht, Sicherheit, Datenschutz und das Leitungsorgan gleichermaßen nutzen können.

Warum NIS2 Lieferantenverträge zu Nachweisaufzeichnungen macht

NIS2 Artikel 20 verpflichtet Leitungsorgane wesentlicher und wichtiger Einrichtungen, Maßnahmen zum Management von Cybersicherheitsrisiken zu genehmigen, ihre Umsetzung zu überwachen und für Verstöße verantwortlich zu sein. Artikel 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, darunter Risikoanalyse, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung und Wartung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Personalsicherheit, Zugriffskontrolle, Asset-Management und, soweit angemessen, MFA.

Artikel 21(3) macht die gebotene Sorgfalt gegenüber Lieferanten ausdrücklich. Organisationen müssen Schwachstellen berücksichtigen, die für direkte Lieferanten und Dienstleister spezifisch sind, ebenso die Gesamtqualität von Produkten und Cybersicherheitspraktiken sowie sichere Entwicklungsverfahren.

Diese Formulierung schafft eine praktische Pflicht: Lieferantenbeziehungen müssen risikobasiert, vertraglich durchsetzbar und überprüfbar sein. Ein in einem Ordner abgelegter Lieferantenfragebogen reicht nicht aus. Ein generischer Vertrag ohne Vorfallfrist, ohne Nachweisrechte und ohne Transparenz zu Unterauftragnehmern reicht nicht aus. Eine Lieferantenzertifizierung, die niemand geprüft hat, reicht nicht aus.

ISO/IEC 27001:2022 stellt das Betriebsmodell bereit. Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation ihren Kontext, interessierte Parteien, rechtliche und vertragliche Verpflichtungen, den ISMS-Geltungsbereich und Abhängigkeiten versteht. Die Klauseln 5.1 bis 5.3 verlangen Führung, Leitlinie, Rollen und Berichterstattung. Die Klauseln 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung und die Anwendbarkeitserklärung (SoA). Die Klauseln 8.1 bis 8.3 verlangen operative Steuerung, wiederholte Risikobeurteilungen und dokumentierte Ergebnisse.

Für Lieferanten-Governance zählen insbesondere die folgenden ISO/IEC 27002:2022-Kontrollen aus Anhang A:

• A.5.19 Informationssicherheit in Lieferantenbeziehungen
• A.5.20 Behandlung der Informationssicherheit in Lieferantenvereinbarungen
• A.5.21 Steuerung der Informationssicherheit in der IKT-Lieferkette
• A.5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten
• A.5.24 Planung und Vorbereitung des Vorfallmanagements
• A.5.25 Bewertung und Entscheidung zu Informationssicherheitsereignissen
• A.5.26 Reaktion auf Informationssicherheitsvorfälle
• A.5.27 Lernen aus Informationssicherheitsvorfällen
• A.5.28 Sammlung von Nachweisen
• A.5.29 Informationssicherheit bei Störungen
• A.5.30 IKT-Bereitschaft für die Aufrechterhaltung des Geschäftsbetriebs
• A.5.31 Gesetzliche, behördliche, regulatorische und vertragliche Anforderungen
• A.5.34 Datenschutz und Schutz personenbezogener Daten
• A.8.8 Management technischer Schwachstellen
• A.8.13 Informationssicherung durch Backups
• A.8.15 Protokollierung
• A.8.16 Überwachungstätigkeiten
• A.8.24 Einsatz von Kryptografie
• A.8.32 Änderungsmanagement

Entscheidend ist Verantwortlichkeit. Eine Klausel hat nur geringen Wert, wenn niemand das Risiko verantwortet, niemand die Nachweise prüft, niemand Ausnahmen verfolgt und niemand Nichteinhaltung eskaliert.

Die Enterprise-Richtlinie zur Lieferanten- und Drittparteiensicherheit macht dies ausdrücklich:

„Rechte zur Auditierung, Prüfung und Anforderung von Sicherheitsnachweisen“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.4.

Für KMU setzt die Richtlinie zur Lieferanten- und Drittparteiensicherheit für KMU dieselbe praktische Erwartung:

„Auditrechte oder die Verfügbarkeit von Nachweisen der Einhaltung“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.4.

Dieser Unterschied ist wichtig. Eine kleinere Organisation kann möglicherweise nicht jeden großen Cloud-Anbieter vor Ort auditieren, sie kann aber Zugriff auf Sicherheitsnachweise verlangen, etwa den Geltungsbereich der ISO/IEC 27001:2022-Zertifizierung, SOC-Berichte, Zusammenfassungen von Penetrationstests, Bestätigungen zur Schwachstellenbehebung, Vorfallszusammenfassungen, Testberichte zur Aufrechterhaltung des Geschäftsbetriebs und Bestätigungen zur Datenlöschung.

Das Rückgrat aus drei Kontrollen für die NIS2-Sicherstellung von Lieferanten

Im Cross-Compliance-Modell von Clarysec bilden drei ISO/IEC 27002:2022-Kontrollen das Rückgrat der NIS2-Lieferanten-Governance: 5.19, 5.20 und 5.22.

A.5.19 identifiziert das Lieferantenrisiko

Kontrolle A.5.19, Informationssicherheit in Lieferantenbeziehungen, ist die Grundlage. Sie verlangt, dass Organisationen Informationen und Assets schützen, auf die Lieferanten zugreifen oder die sie verarbeiten, speichern oder verwalten.

Zenith Controls kategorisiert dies als präventive Kontrolle für Vertraulichkeit, Integrität und Verfügbarkeit, mit dem Cybersicherheitskonzept „Identifizieren“ und der operativen Fähigkeit „Sicherheit von Lieferantenbeziehungen“. Es verbindet A.5.19 mit A.5.20, A.5.21, A.5.14, A.5.36 und A.5.10. Praktisch bedeutet das: Die Organisation identifiziert Lieferantenrisiken, definiert Sicherheitserwartungen, steuert die Exposition in der IKT-Lieferkette, schützt Informationsübertragungen, überwacht die Einhaltung und weitet Pflichten zur zulässigen Nutzung auf externe Parteien aus.

Für NIS2 lässt sich dies unmittelbar Artikel 21(2)(d) zur Sicherheit der Lieferkette und Artikel 21(3) zur gebotenen Sorgfalt gegenüber Lieferanten zuordnen. Für GDPR unterstützt es die Anforderung, Auftragsverarbeiter einzusetzen, die hinreichende Garantien bieten. Für DORA unterstützt es das Management von IKT-Drittparteienrisiken, vorvertragliche gebotene Sorgfalt, Kritikalitätsprüfung, Konzentrationsrisiko und Lebenszyklusaufsicht.

A.5.20 macht die Anforderung durchsetzbar

Kontrolle A.5.20, Behandlung der Informationssicherheit in Lieferantenvereinbarungen, überführt Sicherheitserwartungen in vertragliche Verpflichtungen. Zenith Controls erklärt die Beziehung zwischen A.5.19 und A.5.20 klar:

„5.20 dient der vertraglichen Formalisierung der unter 5.19 identifizierten Sicherheitsanforderungen und Risiken. Während 5.19 die Bewertung von Drittparteienrisiken und die Definition von Sicherheitserwartungen umfasst, stellt 5.20 sicher, dass diese Erwartungen durch Verträge oder Service Level Agreements (SLAs) rechtlich bindend werden. Ohne 5.20 fehlte den in 5.19 identifizierten Sicherheitsmaßnahmen die Durchsetzbarkeit.“

Hier werden NIS2-Risikoentscheidungen zu Klauseln: Meldung von Sicherheitsverletzungen, Audit- und Nachweisrechte, Verschlüsselung, Zugriffskontrolle, Schwachstellenmanagement, Genehmigung von Unterauftragnehmern, sichere Übertragung, Kontinuität, regulatorische Zusammenarbeit, Exit-Unterstützung und Datenlöschung.

A.5.22 weist nach, dass der Vertrag gelebt wird

Kontrolle A.5.22, Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten, verhindert, dass die Sicherstellung von Lieferanten zu einer einmaligen Onboarding-Übung wird. Zenith Controls verknüpft A.5.22 mit A.5.19 und A.5.20, aber auch mit A.5.29 Informationssicherheit bei Störungen, A.8.8 Management technischer Schwachstellen, A.5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit, A.5.15 Zugriffskontrolle sowie A.8.27 sichere Systemarchitektur und Engineering-Grundsätze.

Das ist relevant, weil sich Lieferantendienste ändern. Datenstandorte ändern sich. Unterauftragsverarbeiter ändern sich. Schwachstellen treten auf. Zertifizierungen laufen ab. Vorfallmuster entstehen. Ein Lieferant, der im Vorjahr akzeptabel war, kann heute zu riskant sein.

Was NIS2-Lieferantenvertragsklauseln enthalten sollten

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 23, liefert eine praxisnahe Auswahl von Bereichen für Lieferantenvereinbarungen:

„Zu den typischen Kernbereichen in Lieferantenvereinbarungen gehören:

✓ Vertraulichkeitspflichten, einschließlich Geltungsbereich, Dauer und Beschränkungen für Offenlegungen gegenüber Dritten; ✓ Verantwortlichkeiten für die Zugriffskontrolle, etwa wer auf Ihre Daten zugreifen darf, wie Zugangsdaten verwaltet werden und welche Überwachung eingerichtet ist; ✓ technische und organisatorische Maßnahmen für Datenschutz, Verschlüsselung, sichere Übertragung, Backup und Verfügbarkeitszusagen; ✓ Fristen und Protokolle zur Vorfallmeldung, häufig mit definierten Zeitfenstern (z. B. „Benachrichtigung innerhalb von 24 Stunden“); ✓ Auditrechte, einschließlich Häufigkeit, Geltungsbereich und Zugriff auf relevante Nachweise (z. B. Berichte zu Penetrationstests, SoA, Zertifizierungen); ✓ Kontrollen für Unterauftragnehmer, die den Lieferanten verpflichten, gleichwertige Sicherheitsverpflichtungen an seine nachgelagerten Partner weiterzugeben; ✓ Regelungen zum Vertragsende, etwa Datenrückgabe oder -vernichtung, Asset-Rückgabe und Kontodeaktivierung.“

Aus der Phase „Controls in Action“, Schritt 23: Organisatorische Maßnahmen.

Eine starke NIS2-Lieferantenklausel ist spezifisch genug, um getestet zu werden. „Der Lieferant wahrt angemessene Sicherheit“ ist schwach. „Der Lieferant benachrichtigt den Sicherheitskontakt des Kunden innerhalb von 24 Stunden über bestätigte oder vermutete Vorfälle, die Kundensysteme, Kundendaten, Serviceverfügbarkeit oder regulatorische Berichtspflichten betreffen“ ist auditierbar.

Vorfallklauseln müssen zum NIS2-Meldezeitplan passen

NIS2 Artikel 23 schafft ein gestuftes Meldemodell für erhebliche Sicherheitsvorfälle: eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, eine Vorfallmeldung innerhalb von 72 Stunden, Zwischenberichte auf Anforderung und einen Abschlussbericht innerhalb eines Monats nach der Vorfallmeldung. Ein erheblicher Sicherheitsvorfall liegt vor, wenn er schwere Betriebsstörungen, finanzielle Verluste oder erhebliche materielle oder immaterielle Schäden bei anderen verursacht hat oder verursachen kann.

Lieferantenverträge müssen diesen Zeitplan unterstützen. Wenn ein kritischer Managed Service Provider vier Tage benötigt, um zu bestätigen, ob Kundenumgebungen betroffen waren, kann der Kunde seine eigene regulatorische Frist verpassen.

Die Enterprise-Richtlinie zur Lieferanten- und Drittparteiensicherheit verlangt:

„Fristen zur Meldung von Verstößen (z. B. innerhalb von 24 oder 72 Stunden, abhängig von Kritikalität und regulatorischen Anforderungen)“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.3.

Die KMU-Richtlinie zur Lieferanten- und Drittparteiensicherheit für KMU verlangt ebenfalls definierte Fristen zur Meldung von Verstößen aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.3.

Für Datenschutzvorfälle verbindet die Enterprise-Richtlinie zum Management von Datenschutzvorfällen und Verletzungen des Schutzes personenbezogener Daten Cybersicherheits-, Finanzsektor-, Kunden- und Leistungsempfänger-Meldungen:

„[Bedingt] Der Privacy Lead / PIMS Manager MUSS jede erforderliche sektorale, Cybersicherheits-, Finanzsektor-, Kunden- oder Leistungsempfänger-Vorfallmeldung koordinieren, wenn ein Datenschutzvorfall mit hoher Tragweite einen anwendbaren Meldeschwellenwert erreicht, und MUSS Behörde, Empfänger, Zeitplan, Einreichung und Bestätigungsnachweis in REG01 und REG10 aufzeichnen.“

Aus dem Abschnitt „Benachrichtigung und Kommunikation“, Richtlinienklausel 4.4.6.

Das ist ausgereifte NIS2-Nachweisführung: nicht nur eine Benachrichtigungs-E-Mail, sondern eine Aufzeichnung zu Behörde, Empfänger, Zeitplan, Einreichung, Bestätigung, Auswirkungen, Ursachenanalyse und Folgemaßnahmen.

Datenschutz- und DORA-Ausrichtung ohne doppelte Lieferantenprogramme

Viele NIS2-Lieferanten verarbeiten auch personenbezogene Daten. GDPR Artikel 28 verlangt von Verantwortlichen, Auftragsverarbeiter einzusetzen, die hinreichende Garantien bieten, und die Pflichten des Auftragsverarbeiters in einem schriftlichen Vertrag festzulegen. GDPR Artikel 5 verlangt Rechenschaftspflicht für sichere und rechtmäßige Verarbeitung. Die GDPR-Pflichten bei Datenschutzverletzungen erfordern zudem schnelle Zusammenarbeit, wenn Lieferantenvorfälle personenbezogene Daten betreffen.

Die Enterprise-Richtlinie zum Management von Auftragsverarbeitern, Unterauftragsverarbeitern und Datenschutz bei Drittparteien definiert das Genehmigungsgate:

„[Beide] Der Lieferanten- / Beschaffungsverantwortliche MUSS vor der Genehmigung sicherstellen, dass Verträge mit Auftragsverarbeitern und Unterauftragsverarbeitern Datenschutzunterstützung, Sicherheitsnachweise, Vorfallschnittstelle über PII15, Rückgabe oder Löschung über PII10, Übermittlungsverknüpfung über PII13 sowie Audit- oder Nachweiszusammenarbeit enthalten.“

Aus dem Abschnitt „Vertrags- und dokumentierte Weisungskontrollen“, Richtlinienklausel 4.3.6.

Sie verlangt außerdem eine Nachweisprüfung vor Genehmigung:

„[Alle] Der Leiter Informationssicherheit MUSS Sicherheitsnachweise für jede Beziehung mit einem Auftragsverarbeiter, Unterauftragsverarbeiter oder einer Drittpartei mit Zugriff auf personenbezogene Daten oder Hosting vor der Genehmigung prüfen und das Ergebnis in REG08 oder REG12 aufzeichnen.“

Aus dem Abschnitt „Gebotene Sorgfalt und Risikobeurteilung“, Richtlinienklausel 4.2.2.

DORA fügt eine weitere Ebene hinzu, wenn der Lieferant ein Finanzunternehmen unterstützt. DORA Artikel 28 bis 30 verlangen Governance für IKT-Drittparteien, Register für IKT-Serviceverträge, risikobasierte gebotene Sorgfalt, Kritikalitätsbewertung, Analyse des Konzentrationsrisikos, Audit- und Inspektionsrechte, Kündigungsrechte, Exit-Strategien und verpflichtende Vertragsbestimmungen. Artikel 30 ist besonders relevant, weil er Vertragsinhalte zu Leistungsbeschreibungen, Standorten, Datenschutz, Zugriff und Wiederherstellung, Service Levels, Vorfallunterstützung, Zusammenarbeit mit Behörden, Auditrechten, Unterauftragsvergabe, Notfallmaßnahmen und Unterstützung beim Übergang verlangt.

Die praktische Antwort sind nicht drei getrennte Lieferantenprogramme für NIS2, GDPR und DORA. Es ist ein harmonisiertes Nachweismodell für Lieferanten, das rahmenwerksübergreifend zugeordnet wird.

NIST CSF 2.0 ist hilfreich, weil seine GOVERN-Funktion das Verständnis von Abhängigkeiten, rechtlichen Verpflichtungen, vertraglichen Verpflichtungen, Risikobereitschaft, Richtlinien, Rechenschaftspflicht und Aufsicht verlangt. Die Lieferkettenkategorie GV.SC umfasst Lieferantenrollen, Kritikalität, Vertragsanforderungen, gebotene Sorgfalt, Überwachung, Einbindung in Vorfälle, Lebenszyklusüberwachung und Regelungen zum Ende der Geschäftsbeziehung.

Ein Clarysec-Workflow für das Onboarding eines kritischen Lieferanten

Angenommen, Sie nehmen einen Anbieter verwalteter Sicherheitsdienste auf, der Endpoint-Telemetrie überwacht, Warnmeldungen mit Benutzerkennungen erhält und die Triage von Sicherheitsvorfällen für eine Organisation im NIS2-Geltungsbereich unterstützt.

Schritt 1: Lieferanten klassifizieren

Erfassen Sie den Lieferanten im Lieferantenregister mit Leistungsbeschreibung, zugreifenden Systemen und Daten, Beteiligung personenbezogener Daten, Unterstützung wesentlicher oder wichtiger Dienste, privilegiertem Zugriff, Ländern der Leistungserbringung, Unterauftragnehmern, Abhängigkeiten von Viertparteien, Kritikalitätseinstufung, Risikoverantwortlichem, Beschaffungsverantwortlichem und Prüfer der Informationssicherheit.

Damit werden ISO/IEC 27001:2022 Klauseln 4.2, 4.3, 6.1.2 und 8.1 umgesetzt, indem Anforderungen interessierter Parteien, Abhängigkeiten, Risikoverantwortung und operative Steuerung verbunden werden.

Schritt 2: Risiko der SoA zuordnen

Im Zenith Blueprint, Phase Risikomanagement, Schritt 13, empfiehlt Clarysec, Vorschriften im Risikoregister oder in der SoA querzuverweisen:

„Vorschriften querverweisen: Wenn bestimmte Kontrollen speziell zur Einhaltung von GDPR, NIS2 oder DORA umgesetzt werden, können Sie dies entweder im Risikoregister (als Teil der Begründung der Risikoauswirkungen) oder in den SoA-Notizen vermerken.“

Aus der Phase Risikomanagement, Schritt 13: Risikobehandlungsplanung und Anwendbarkeitserklärung.

Für den MSSP sollten mindestens A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 bis A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 und A.8.24 einbezogen werden.

Schritt 3: Durchsetzbare Klauseln verlangen

Verwenden Sie einen Sicherheitsanhang für Lieferanten, der eine erste Vorfallmeldung innerhalb von 24 Stunden, ein detailliertes Update innerhalb von 72 Stunden, Abschlussberichterstattung zu Vorfällen, MFA für privilegierten Zugriff, personenbezogene Benutzerkonten, Kontrollen für Unterauftragnehmer, sichere Übertragung, Verschlüsselung, Sicherheitsnachweise, regulatorische Zusammenarbeit, BCP- und DR-Nachweise, Exit-Unterstützung, Datenrückgabe oder -löschung und den Entzug von Zugriffsrechten verlangt.

Die Enterprise-Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten stellt die Kontinuitätsanforderung bereit:

„Soweit anwendbar, die Anforderung an den Lieferanten, eigene Business-Continuity-Pläne (BCP/DRP) und Pläne für das Vorfallmanagement zu unterhalten, diese zu testen und uns auf Anfrage Zusammenfassungen oder Testberichte bereitzustellen.“

Aus dem Abschnitt „Umsetzungsanforderungen“, Richtlinienklausel 6.8.4.

Schritt 4: Das Paket der Sicherheitsnachweise erstellen

Fordern Sie vor der Genehmigung die unterzeichnete Vereinbarung, das SLA, den Sicherheitsanhang, den Geltungsbereich der ISO/IEC 27001:2022-Zertifizierung oder gleichwertige Sicherheitsnachweise, einen SOC-Bericht, sofern verfügbar, eine Management-Zusammenfassung des Penetrationstests, eine Zusammenfassung des Schwachstellenmanagements, eine Zusammenfassung der Incident-Response-Verfahren, eine BCP- oder DR-Testzusammenfassung, eine Bestätigung zu Zugriffskontrolle und MFA, eine Liste der Unterauftragnehmer, Verfahren zu Datenlöschung und Exit sowie einen Auftragsverarbeitungsvertrag an, sofern personenbezogene Daten verarbeitet werden.

Die KMU-Richtlinie zur Lieferanten- und Drittparteiensicherheit für KMU macht grundlegende Vertragsnachweise messbar:

„Unterzeichnete Vereinbarungen und SLAs“

Aus dem Abschnitt „Durchsetzung und Einhaltung“, Richtlinienklausel 8.3.2.1.

Sie benennt außerdem wiederkehrende Lieferantennachweise:

„Gültige Sicherheitszertifizierungen oder aktualisierte Kontrollnachweise“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.1.2.

Für weiter gefasste Lieferanten-Due-Diligence erklärt die Richtlinie zur Audit- und Compliance-Überwachung:

„Lieferanten-Due-Diligence muss die Prüfung von Zertifizierungen (z. B. ISO 27001, SOC 2), Sicherheitsfragebögen und Vorfallsaufzeichnungen umfassen.“

Schritt 5: Nach Kritikalität überwachen

Die Enterprise-Richtlinie zum Management von Auftragsverarbeitern, Unterauftragsverarbeitern und Datenschutz bei Drittparteien verlangt für Hochrisiko-Beziehungen mit personenbezogenen Daten eine vierteljährliche Überwachung:

„[Alle] Der Lieferanten- / Beschaffungsverantwortliche MUSS aktive Hochrisiko-Beziehungen mit Auftragsverarbeitern und Unterauftragsverarbeitern vierteljährlich und andere aktive Beziehungen mit Auftragsverarbeitern und Unterauftragsverarbeitern personenbezogener Daten jährlich anhand der Bedingungen aus der gebotenen Sorgfalt, des Vertragsstatus, des Nachweisstatus, offener Punkte und Prüftermine in REG08 überwachen.“

Aus dem Abschnitt „Laufende Überwachung, Unterstützung, Offenlegungsschnittstelle und Exit“, Richtlinienklausel 4.5.1.

So wird A.5.22 praktisch wirksam. Die Überprüfung sollte feststellen, ob der Lieferant weiterhin innerhalb der Risikobereitschaft liegt, ob Nachweise aktuell sind, ob offene Punkte bestehen, ob Vorfälle aufgetreten sind und ob Leistungsänderungen eine Neubewertung erfordern.

Wie Auditoren NIS2-Lieferantenklauseln prüfen

Auditoren beginnen selten damit, Ihre Richtlinie isoliert zu lesen. Sie ziehen Stichproben von Lieferanten und folgen der Nachweiskette.

Ein ISO/IEC 27001:2022-Auditor wird das Lieferanteninventar, die Risikoklassifizierung, Lieferantenkriterien, Due-Diligence-Nachweise, Verträge, Nachweise, SoA-Zuordnung und Überwachungshistorie anfordern. Für Anhang A 5.20 wird der Auditor prüfen, ob die gezogenen Verträge durchsetzbare Klauseln enthalten. Für Anhang A 5.22 wird der Auditor testen, ob Berichte geprüft, Ausnahmen protokolliert und Maßnahmen nachverfolgt wurden.

Eine nach NIS2 zuständige Behörde kann darauf fokussieren, ob die Cybersicherheitspraktiken und sicheren Entwicklungsverfahren von Lieferanten nach Artikel 21(3) bewertet wurden. Ein DORA-orientierter Prüfer kann Einträge im IKT-Vertragsregister, Exit-Strategien, Analysen des Konzentrationsrisikos und die verpflichtenden Bestimmungen nach Artikel 30 anfordern. Ein Datenschutzauditor kann Auftragsverarbeiterverträge, weiterzugebende Verpflichtungen an Unterauftragsverarbeiter, Schnittstellen bei Verletzungen des Schutzes personenbezogener Daten und Nachweise hinreichender Garantien prüfen.

Die Enterprise-Richtlinie für Sicherheit und Zugriffskontrolle personenbezogener Daten zeigt, wie Zugriffskontrolle, Schwachstellen, Konfiguration, Überwachung und Kryptografie auf ISO/IEC 27001:2022 zurückverweisen:

„ISO/IEC 27001:2022 — Klausel 6.1.3; Klausel 8.1; Anhang-A-Kontrollen 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Behandelt durch Klauseln [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].“

Aus dem Abschnitt „Referenznormen und Rahmenwerke“, Richtlinienklausel 13.9.

Wenn ein Lieferant Zugriff auf personenbezogene Daten, privilegierte Systeme oder Überwachungsdaten hat, sind Nachweise zur Zugriffskontrolle nicht von der Sicherstellung von Lieferanten getrennt. Sie sind Teil desselben Prüfpfads.

Die Beschaffungsfalle: Unterzeichnete Verträge ohne Assurance-Betrieb

Der häufigste Fehler in der NIS2-Lieferanten-Governance ist nicht das Fehlen von Verträgen. Es ist die Lücke zwischen Vertragstext und täglichem Betrieb.

Ein Vertrag kann jährliche Zusammenfassungen von Penetrationstests verlangen, aber kein Verantwortlicher fordert sie an. Er kann eine Vorfallmeldung innerhalb von 24 Stunden verlangen, aber der Lieferant hat nur eine allgemeine Support-Adresse. Er kann eine Genehmigung von Unterauftragnehmern verlangen, aber die Beschaffung erhält nie Änderungsmitteilungen. Er kann Auditrechte enthalten, aber die Organisation hat keinen Prozess zur Bewertung von Ausnahmen in SOC-Berichten. Er kann Datenlöschung beim Exit verlangen, aber die IT validiert nie die Kontodeaktivierung.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 23, erklärt, wie Lieferantenkontrollen wirksam betrieben werden:

„In der Praxis wird diese Kontrolle umgesetzt durch:

✓ Risikobeurteilungen von Lieferanten, ✓ Fragebögen zur gebotenen Sorgfalt vor der Beauftragung, ✓ Vertragsvorlagen mit eingebetteten Sicherheitsbedingungen, ✓ Lieferanten-Onboarding-Checklisten, die Zugriffsbereitstellung und Einrichtung der Überwachung enthalten, ✓ laufende Neubewertungen, insbesondere wenn sich der Lieferantengeltungsbereich ändert, Vorfälle auftreten oder Verlängerungen anstehen.

Und diese Kontrolle endet nicht bei Tier-1-Lieferanten. Ihr Lieferant kann Leistungen an eigene Anbieter auslagern, und Sie tragen das Risiko möglicherweise weiterhin.“

Das ist die NIS2-Botschaft für das Leitungsorgan: Die Auslagerung der Leistungserbringung lagert die Rechenschaftspflicht nicht aus.

Checkliste zur Nachbesserung von NIS2-Lieferantenverträgen

Beginnen Sie mit Ihren 20 wichtigsten Lieferanten nach Kritikalität und führen Sie eine fokussierte Nachbesserung durch:

• Identifizieren Sie Lieferanten, die wesentliche oder wichtige Dienste unterstützen.
• Bestätigen Sie, ob der jeweilige Lieferant personenbezogene Daten verarbeitet, regulierte Services unterstützt oder privilegierten Zugriff hat.
• Weisen Sie einen Geschäftsverantwortlichen, einen Beschaffungsverantwortlichen und einen Sicherheitsprüfer zu.
• Verifizieren Sie, dass die Risikobeurteilung des Lieferanten aktuell ist und dem tatsächlichen Leistungsumfang entspricht.
• Bestätigen Sie, dass der Vertrag Sicherheitsbasis, Vorfallmeldung, Audit- oder Nachweisrechte, Kontrollen für Unterauftragnehmer, Kontinuität, sichere Übertragung, Zugriffskontrolle, Zusammenarbeit bei Schwachstellen und Exit-Klauseln enthält.
• Bestätigen Sie, dass die Fristen zur Meldung von Verstößen die 24- und 72-Stunden-Eskalationsanforderungen unterstützen, soweit relevant.
• Fordern Sie aktualisierte Sicherheitsnachweise an, einschließlich Zertifizierungen, SOC-Berichten, Zusammenfassungen von Penetrationstests, BCP- oder DR-Tests und Vorfallhistorie.
• Prüfen Sie Nachweise, legen Sie sie nicht nur ab.
• Protokollieren Sie Ausnahmen und weisen Sie Verantwortliche für die Mängelbehebung zu.
• Aktualisieren Sie die SoA und das Risikoregister, wenn Lieferantenkontrollen NIS2, GDPR, DORA oder Kundenzusagen unterstützen.
• Planen Sie die Überwachungsfrequenz anhand der Kritikalität des Lieferanten.
• Testen Sie einen Eskalationsweg für Lieferantenvorfälle.
• Testen Sie einen Beendigungspfad für Lieferanten, einschließlich Datenrückgabe, Löschung, Asset-Rückgabe und Entzug von Zugriffsrechten.

Wenn Sie diese Punkte für einen kritischen Lieferanten nicht nachweisen können, ist der Vertrag noch nicht auditbereit.

Lieferantenklauseln in aufsichtsfähige Nachweise überführen

NIS2-Lieferanten-Governance ist heute eine laufende operative Disziplin. Aufsichtsbehörden, Kunden, Zertifizierungsauditoren, Datenschutzteams, Partner aus dem Finanzsektor und Leitungsorgane werden nicht nur fragen, ob Lieferantenklauseln existieren. Sie werden fragen, ob die Klauseln risikobasiert, durchsetzbar, überwacht, nachgewiesen und mit Vorfallmeldung, Kontinuität, Zugriffskontrolle, Schwachstellenmanagement, weiterzugebenden Verpflichtungen an Unterauftragnehmer und Exit verknüpft sind.

Clarysec unterstützt Organisationen dabei, diese Lücke mit dem Zenith Blueprint zu schließen, indem Lieferantenkontrollen in ISMS-Phasen, Risikobehandlung, SoA-Einträge, Onboarding-Routinen und Auditnachweise überführt werden. Zenith Controls ordnet die ISO/IEC 27002:2022-Lieferantenkontrollen A.5.19, A.5.20 und A.5.22 NIS2, DORA, GDPR, NIST, COBIT 2019, unterstützenden ISO-Normen und Auditmethodiken zu. Die Lieferanten- und Datenschutzrichtlinien von Clarysec stellen die Klauselstruktur, Nachweiserwartungen und Überwachungsroutinen bereit, die die Sicherstellung von Lieferanten belastbar machen.

Ihre nächste Maßnahme ist einfach: Wählen Sie fünf kritische Lieferanten aus, ziehen Sie eine Stichprobe ihrer Verträge, ordnen Sie jede Klausel der ISO/IEC 27001:2022-Risikobehandlung und den Kontrollen aus Anhang A zu, fordern Sie aktuelle Sicherheitsnachweise an und führen Sie eine Tabletop-Übung zur 24-Stunden-Vorfallmeldung durch. Wenn die Nachweiskette bricht, geben Ihnen die Toolkits von Clarysec die Struktur, um sie zu reparieren, bevor ein Vorfall, eine Kundenprüfung oder eine aufsichtsbehördliche Anfrage dies für Sie übernimmt.