Swiss Room · Leitfaden 14 von 15

LIEFERKETTEN-

SICHERHEIT

20–25 Min Vertiefung Alle Branchen · Supply Chain

Was dieser Leitfaden Ihnen gibt

Third Party Risk Management für Schweizer KMU

Klassifizierung · Vertragsrealität · Fragebogen-Toolkit · Vorfallmanagement

Vorbemerkung

Diese Leitfadenreihe ist aus einer spezifischen Perspektive heraus geschrieben: der einer General Counsel / Senior Vice President, die über viele Jahre in leitender Inhouse-Funktion in regulierten Unternehmen gearbeitet hat – in der Schweiz und in der EU. Die Autorin verfügt über eine juristische und betriebswirtschaftliche Ausbildung in der Schweiz und in Deutschland sowie über langjährige operative Erfahrung als interne Rechts- und Compliance-Verantwortliche in internationalen Konzernen und KMU-Umfeldern.

Diese Kombination – juristische Tiefe, operatives Management-Know-how und direkte Erfahrung mit den Realitäten von Lieferketten, Vertragsverhandlungen und Aufsichtsbehörden – ist der Grund, warum die Texte so geschrieben sind, wie sie sind: nicht als formale Gesetzeskommentare, sondern als Arbeitsinstrumente. Sie richten sich gleichzeitig an Führungskräfte, die schnell einordnen müssen, was eine Regulierung für ihr Unternehmen bedeutet, und an Fachabteilungen, die wissen müssen, was operativ zu tun ist.

Der interdisziplinäre Ansatz ist bewusst: Digitale Regulierung berührt gleichzeitig IT, Recht, Procurement, Geschäftsführung, HR und Lieferkette. Eine Perspektive, die nur eine dieser Dimensionen kennt, liefert unvollständige Antworten. Die Leitfäden versuchen, alle relevanten Dimensionen gleichzeitig zu adressieren – mit dem Bewusstsein, dass in der Praxis selten ein Team allein zuständig ist und die wirklichen Herausforderungen meistens an den Schnittstellen entstehen.

Die Perspektive «Schweizer KMU im EU-Kontext» ist nicht zufällig. Sie spiegelt langjährige Arbeit an der Schnittstelle zwischen Schweizer Geschäftspraxis und europäischem Regulierungsrahmen: die Erfahrung, was es konkret bedeutet, wenn ein EU-Kundenvertrag plötzlich DORA-Klauseln enthält, wenn ein Procurement-Fragebogen AI-Act-Anforderungen stellt oder wenn ein Lieferant keine NIS2-konformen Sicherheitsnachweise liefern kann. Diese Leitfäden sind aus genau diesen Situationen heraus entstanden – nicht aus dem Lesen von Gesetzestexten, sondern aus der Erfahrung ihrer Auswirkungen.

Hinweis
Diese Leitfäden ersetzen keine Rechtsberatung. Sie sind Orientierungsinstrumente aus der Praxis und können keine auf den Einzelfall bezogene juristische, steuerliche oder technische Beratung ersetzen. Bei konkreten Fragen zu Ihrer Situation wenden Sie sich an qualifizierte Fachleute – gerne auch an das Team von NBK Legal: www.nbklegal.online

Vorwort: Warum Lieferkettensicherheit das blinde Fleck der KMU-Compliance ist

63% der Security-Incidents beginnen bei Drittanbietern. Das ist keine Statistik aus dem Lehrbuch – es ist die Realität der letzten Jahre: SolarWinds, Kaseya, MOVEit. Jedes dieser Ereignisse hat Tausende von Unternehmen getroffen, die selbst nichts falsch gemacht hatten. Ihr Anbieter hatte ein Problem – und sie trugen die Konsequenzen.

NIS2, DORA und der AI Act haben diese Realität in Regulierungsanforderungen übersetzt: Lieferkettensicherheit ist keine optionale Best Practice mehr, sondern eine gesetzliche Pflicht für regulierte Unternehmen – und damit indirekt eine Marktanforderung für alle ihre Lieferanten.

Das Kernproblem Sie können Ihre eigene Sicherheit kontrollieren. Sie können die Sicherheit Ihrer Lieferanten nicht direkt kontrollieren – aber Sie können sie durch Verträge, Fragebögen, Audits und Monitoring steuern. Dieser Leitfaden zeigt, wie.

1. Die regulatorischen Anforderungen im Überblick

RegulierungKernforderungWas Sie als Lieferant tun müssenWas Sie von Ihren Lieferanten verlangen müssen
NIS2Lieferkettensicherheit als Teil des RisikomanagementsSicherheitsnachweise, Incident-EskalationISO-27001-orientierte Sicherheit, Incident-Meldeprozess
DORADrittanbieter-Management für FinanzunternehmenBCM/DR-Nachweis, Auditfähigkeit, Exit-StrategienVertragsklauseln: Logging, Auditrechte, Exit
AI ActDokumentation von Modellen und TrainingsdatenData Cards, Model Cards, Bias-DokumentationDatenherkunftsnachweise, Modell-Dokumentation
CRASichere Software-LieferkettenSBOM, Vulnerability-DisclosureCVE-Monitoring, Patch-Fristen
ISO 27001Lieferantenmanagement als Pflicht-KontrollbereichSicherheitspolitik kommunizierenLieferanten-Risikobewertung und Vertragsanforderungen

2. Die Lieferanten-Klassifizierung – Fundament des TPRM

Nicht alle Lieferanten sind gleich riskant. Das ist der wichtigste Grundsatz des Third Party Risk Managements. Wer alle Lieferanten gleich behandelt, verschwendet Ressourcen bei unkritischen Anbietern und unterschätzt kritische.

2.1 Die drei Kritikalitätsstufen

StufeKriterienTypische BeispieleMaßnahmen
KRITISCHBetriebsausfall bei Ausfall des Lieferanten | Zugang zu kritischen Systemen oder Daten | Direkte Auswirkung auf Kunden oder RegulierungCore-Cloud-Provider, ISMS-Tools, Zahlungsinfrastruktur, Core-Business-SoftwareVollständiger Fragebogen, jährliches Audit/Review, Vertragsklauseln, Monitoring
WICHTIGBetriebsstörung (nicht -ausfall) bei Ausfall | Zugang zu nicht-kritischen Daten | Indirekte Kunden-AuswirkungSekundäre SaaS-Tools, Subunternehmer, professionelle DienstleisterVerkürzter Fragebogen, zweijährliches Review, Standard-Vertragsklauseln
UNKRITISCHKein Systemzugang | Kein Datenzugang | Kein direkter BetriebseinflussBüromaterial, Reinigung, Catering, allgemeine Software ohne DatenzugangStandardvertrag mit Datenschutzklausel; kein spezifisches TPRM
Die wichtigste Klassifizierungsfrage Nicht: 'Wie gross ist der Lieferant?' Sondern: 'Was passiert, wenn dieser Lieferant morgen ausfällt oder kompromittiert wird?' Ein kleiner, unbekannter Software-Anbieter, dessen Tool in alle Ihre Produktionsprozesse integriert ist, ist kritischer als ein großer, bekannter Anbieter, der nur Ihre Newsletter verschickt.

2.2 Die Lieferanten-Matrix – Ihr Arbeitsinstrument

Die Lieferanten-Matrix ist das zentrale Dokument Ihres TPRM. Sie existiert einmal, wird kontinuierlich aktualisiert, und ist die Grundlage für Kunden-Audits und regulatorische Prüfungen.

LieferantLeistungStufeDatenzugangLetztes ReviewStatus
[Cloud-Provider]InfrastrukturKritischAlle Daten2025-12Zertifikat vorhanden
[SaaS-CRM]KundendatenKritischKundendaten2025-10Fragebogen + MSA
[Buchhaltungs-SW]FinanzdatenWichtigFinanzdaten2025-09Standard-Klauseln
[Office-Tools]ProduktivitätWichtigKeine sensitiven2025-08Vertragsklausel
[Büromaterial]VerbrauchsmaterialUnkritischKeinerStandard-AGB

3. Der Lieferanten-Fragebogen – vollständig und einsatzbereit

Dies ist kein 'Auszug' – dies ist ein vollständiger, sofort verwendbarer Fragebogen für kritische Lieferanten. Er deckt die Anforderungen aus NIS2, DORA, ISO 27001 und AI Act ab.

3.1 Fragebogen für KRITISCHE Lieferanten

A. Informationssicherheits-Management

FrageAntwortNachweise
Verfügen Sie über ein dokumentiertes ISMS (z.B. ISO 27001)?Zertifikat / Policy
Ist die Geschäftsleitung explizit für Informationssicherheit verantwortlich?Policy-Unterschrift
Führen Sie ein Risikoregister und überprüfen es mindestens jährlich?Risikoregister-Auszug
Haben Sie eine unterzeichnete Informationssicherheits-Policy?Policy-Dokument

B. Technische Sicherheit

FrageAntwortNachweise
Ist MFA für alle Admin-Zugänge aktiviert?Technische Bestätigung
Werden kritische Patches innerhalb von 72h eingespielt?Patch-Policy
Sind alle sensitiven Daten at rest und in transit verschlüsselt?Technische Doku
Betreiben Sie ein Logging- und SIEM-System?Runbook / Log-Policy
Führen Sie regelmässige Penetrationstests durch? Letztes Datum?Pentest-Bericht
Sind Ihre Systeme netzwerksegmentiert?Architektur-Übersicht
Wo werden unsere Daten gespeichert (Land/Region)?Infrastruktur-Doku

C. Incident Response

FrageAntwortNachweise
Haben Sie einen dokumentierten Incident-Response-Prozess?IR-Plan / Playbook
Gibt es einen 24/7-Notfallkontakt für Sicherheitsvorfälle?Kontaktliste
Innerhalb welcher Frist informieren Sie uns bei einem Vorfall, der unsere Daten betrifft?SLA / Vertrag
Wurde Ihr IR-Prozess in den letzten 12 Monaten getestet?Testprotokoll

D. Business Continuity

FrageAntwortNachweise
Haben Sie einen dokumentierten Business Continuity Plan (BCP)?BCP-Dokument
Was ist Ihr Recovery Time Objective (RTO) für kritische Dienste?BCP / SLA
Was ist Ihr Recovery Point Objective (RPO)?BCP / SLA
Wurde der BCP in den letzten 12 Monaten getestet?Testprotokoll
Haben Sie einen dokumentierten Exit-Plan für die Beendigung unserer Zusammenarbeit?Exit-Konzept

E. Lieferkette des Lieferanten (Sub-Tier)

FrageAntwortNachweise
Welche kritischen Subdienstleister setzen Sie für unsere Leistungserbringung ein?Lieferantenmatrix
Informieren Sie uns über wesentliche Änderungen in Ihrer Sub-Lieferkette?Vertrag / Prozess
Haben Ihre Subdienstleister Zugang zu unseren Daten?Datenfluss-Doku
Werden Ihre Subdienstleister auf Sicherheitsanforderungen geprüft?Supplier Policy

F. Software-Lieferkette (relevant wenn Softwarelieferant)

FrageAntwortNachweise
Erstellen Sie eine SBOM (Software Bill of Materials) für Ihre Produkte?SBOM-Datei
Wie handhaben Sie bekannte Schwachstellen (CVEs) in integrierten Komponenten?Vulnerability Policy
Innerhalb welcher Frist patchen Sie kritische Schwachstellen?Patch-Policy
Gibt es einen Security-Review-Prozess in der Softwareentwicklung?SDLC-Doku

3.2 Fragebogen für WICHTIGE Lieferanten (Kurzversion)

Für wichtige (nicht kritische) Lieferanten genügt ein kürzerer Fragebogen. Diese fünf Fragen decken die Kernrisiken ab:

FrageAntwort / Nachweis
Haben Sie ein dokumentiertes Sicherheitsprogramm oder eine ISO-27001-Zertifizierung?
Wo werden unsere Daten gespeichert?
Wie schnell informieren Sie uns bei einem Sicherheitsvorfall, der unsere Daten betrifft?
Welche Subdienstleister haben Zugang zu unseren Daten?
Können wir bei Vertragsbeendigung alle unsere Daten vollständig exportieren?

4. Vertragsklauseln für Lieferkettensicherheit

4.1 Pflichtklauseln für kritische Lieferanten

Sicherheitsanforderungen

Klausel «Der Auftragnehmer verpflichtet sich, während der gesamten Vertragslaufzeit angemessene technische und organisatorische Sicherheitsmaßnahmen zu unterhalten, die mindestens den Anforderungen von ISO/IEC 27001 entsprechen oder gleichwertig sind. Auf Anfrage ist dem Auftraggeber ein aktueller Sicherheitsnachweis (Zertifikat, Fragebogen oder Security Master Document) bereitzustellen.»

Incident-Meldepflicht

Klausel «Der Auftragnehmer informiert den Auftraggeber unverzüglich, spätestens innerhalb von 4 Stunden nach Kenntnisnahme, über Sicherheitsvorfälle, die Daten oder Systeme des Auftraggebers betreffen oder betreffen könnten. Innerhalb von 72 Stunden ist ein detaillierter Bericht mit Ursache, Auswirkung und ergriffenen Maßnahmen zu liefern.»

Auditrechte

Klausel «Der Auftraggeber hat das Recht, einmal pro Kalenderjahr auf eigene Kosten mit 30 Tagen Vorlauf eine Überprüfung der sicherheitsrelevanten Dokumentation und Prozesse des Auftragnehmers durchzuführen oder durch einen gemeinsam vereinbarten Dritten durchführen zu lassen. Der Scope der Überprüfung wird gemeinsam definiert.»

Sub-Lieferkette

Klausel «Der Auftragnehmer informiert den Auftraggeber über alle Subdienstleister, die Zugang zu Daten des Auftraggebers haben, und informiert diesen über wesentliche Änderungen mindestens 30 Tage im Voraus. Subdienstleister mit Datenzugang verpflichtet sich der Auftragnehmer zu gleichwertigen Sicherheitsanforderungen.»

Exit und Datenrückgabe

Klausel «Bei Vertragsbeendigung stellt der Auftragnehmer alle Daten des Auftraggebers innerhalb von 30 Tagen in einem standardisierten Format bereit und löscht alle Kopien nachweislich innerhalb von 60 Tagen. Auf Anfrage wird ein Löschungsnachweis ausgestellt.»
Problematisch
Überzogene Klausel – so nicht «Der Auftragnehmer haftet vollständig für alle Schäden, die dem Auftraggeber durch Sicherheitsvorfälle entstehen, die ihren Ursprung beim Auftragnehmer haben.» – 'Vollständig' und 'Ursprung' sind beide rechtlich problematisch. Verlangen Sie stattdessen: Kausalitätsnachweis, Haftung auf direkten Schaden begrenzt, vereinbarte Obergrenze.

5. Monitoring: Lieferanten nach Onboarding steuern

Lieferantenbewertung ist kein einmaliger Prozess. Die gefährlichsten Vorfälle entstehen bei Lieferanten, die lange als sicher galten und deren Situation sich unbemerkt verändert hat.

5.1 Der Monitoring-Kalender

FrequenzMaßnahmeKritische LieferantenWichtige Lieferanten
LaufendCVE/Vulnerability-Monitoring für eingesetzte SoftwareAutomatisiertManuell bei Kenntnis
MonatlichSLA-Überprüfung (Verfügbarkeit, Incidents)JaBei Auffälligkeiten
HalbjährlichIncident-Statistik und Sicherheits-UpdateJaNein
JährlichVollständige Neubewertung; Fragebogen aktualisiertJaKurzversion
Bei EreignisNeu-Assessment bei: M&A, Datenpanne, wesentliche Änderung, KritikalitätsänderungSofortJe nach Auswirkung

5.2 Red Flags: Wann Sie sofort handeln müssen

Öffentlich bekannt gewordene Datenpanne beim Lieferanten: Sofort kontaktieren, Exposition prüfen, bei Bedarf Contingency-Plan aktivieren.

Lieferant wird übernommen oder fusioniert: Vertragliche Konditionen prüfen; Daten exportieren, bevor neue Eigentümer Zugang haben.

Lieferant ändert Datenspeicherort: Compliance-Auswirkung prüfen (GDPR, FINMA, revDSG). Schriftliche Bestätigung verlangen.

Lieferant kündigt Dienst an oder geht in Insolvenz: Exit-Plan sofort aktivieren. Datensicherung hat Priorität.

Lieferant verweigert Audit oder Fragebogen: Eskalation; bei kritischen Lieferanten: Vertragskündigung prüfen.

6. Incident-Management mit Drittanbieter-Bezug

Wenn ein Sicherheitsvorfall bei einem Lieferanten entsteht oder dort seinen Ursprung hat, brauchen Sie einen klaren Prozess. Ohne Vorbereitung verlieren Sie wertvolle Zeit.

6.1 Der Drittanbieter-Incident-Prozess

SchrittAktionVerantwortlichFrist
1Lieferanten-Incident identifizieren (eigene Systeme, Medien, Lieferantenmeldung)Alle Mitarbeitenden / ITSofort
2Kritikalität bewerten: Sind unsere Daten oder Systeme betroffen?SicherheitsverantwortlicherInnerhalb 1h
3Lieferanten kontaktieren: Was ist passiert? Sind unsere Daten betroffen?VertragsverantwortlicherInnerhalb 2h
4Interne Eskalation: Management informieren bei kritischen IncidentsSicherheitsverantwortlicherInnerhalb 4h
5Eigene Meldepflichten prüfen: NIS2? DORA? GDPR? BACS?Legal/ComplianceParallel zu Schritt 3–4
6Contingency-Maßnahmen aktivieren (Failover, Daten-Backup prüfen, etc.)ITJe nach Schwere
7Post-Incident: Lieferanten-Bewertung aktualisieren, Konsequenzen prüfenManagementInnerhalb 2 Wochen

7. Typische Fehler

Fehler 1: Kritische Lieferanten nicht kennen

Die häufigste Antwort auf 'Welche Lieferanten haben Zugang zu Ihren Kundendaten?' ist Schweigen oder Unsicherheit. Das ist ein Grundlagenproblem: Ohne Inventar ist kein TPRM möglich.

Was zu tun ist
Lieferanten-Inventarisierungs-Workshop: Alle Abteilungen listen ihre externen Dienste und Tools auf. IT konsolidiert. Ergebnis: Lieferanten-Matrix v1.0 – in einem halben Tag.

Fehler 2: Sicherheitsklauseln nur in Rahmenverträgen

Der Rahmenvertrag enthält Sicherheitsklauseln. Aber die Arbeitspakete, Einzelaufträge und Erweiterungen werden ohne diese Klauseln beauftragt. Im Schadensfall gilt der Einzelauftrag.

Was zu tun ist
Sicherheitsklauseln als Standardanlage definieren, die automatisch an jeden Auftrag angehängt wird. Nicht als optionales Anhängsel.

Fehler 3: SBOM als reine Compliance-Übung

Eine SBOM wird für einen Kunden erstellt, dann nie aktualisiert. Beim nächsten Release ist sie veraltet. Eine veraltete SBOM ist irreführend und kann Sicherheitslücken verbergen, die sie eigentlich aufdecken sollte.

Was zu tun ist
SBOM-Generierung automatisieren: Tools wie Syft oder Trivy können bei jedem Build eine aktuelle SBOM erzeugen. Das kostet nach Einrichtung fast keine Zeit.

Fehler 4: Keine Sub-Tier-Transparenz

Sie haben Ihren Cloud-Provider bewertet und ein Zertifikat erhalten. Aber dieser Cloud-Provider hostet Ihre Daten auf einer Drittinfrastruktur, die Sie nicht kennen. In einem Incident stellt sich heraus: das eigentliche Problem war beim Sub-Tier-Anbieter.

Was zu tun ist
Für kritische Lieferanten: Sub-Tier-Frage explizit in Fragebogen und Vertrag verankern. Sie haben ein Recht zu wissen, wer tatsächlich Ihre Daten verarbeitet.

8. Was Sie jetzt tun – priorisiert

PrioMaßnahmeWarum jetzt
1Lieferanten-Inventar erstellen: alle Dienste mit DatenzugangOhne Inventar kein TPRM. Halbtägiger Workshop.
2Lieferanten klassifizieren: kritisch / wichtig / unkritischBestimmt, wie viel Aufwand pro Lieferant gerechtfertigt ist.
3Kritische Lieferanten mit Fragebogen aus Abschnitt 3 befragenErste Sicherheitsbewertung. Identifiziert sofort Hochrisiko-Anbieter.
4Bestehende Verträge auf Sicherheitsklauseln prüfenViele Verträge enthalten keine oder unzureichende Klauseln.
5Incident-Response-Prozess für Drittanbieter-Incidents dokumentieren63% aller Incidents beginnen beim Drittanbieter. Kein Prozess = Chaos.
6Jährlichen TPRM-Review-Termin im Governance-Kalender verankernTPRM ist kein Projekt. Es ist ein kontinuierlicher Prozess.
Hinweis
Dieser Leitfaden ersetzt keine Rechtsberatung. Bei konkreten Fragen wenden Sie sich an nbklegal.online.

Kontakt & weitere Informationen

NBK Legal
Rechts- und Compliance-Beratung
EU-Digitalregulierung · Datenschutz · Cybersicherheit
Schweiz · EU
Website
www.nbklegal.online
Alle Leitfäden der Serie
www.nbklegal.online/leitfäden

Weiter vertiefen

← Alle Leitfäden