Third-Party Risk: Lieferanten audit-ready machen

Die Quote ist verdoppelt worden. Aktuelle Analysen zeigen, dass nahezu 30% aller gemeldeten Datenpannen Drittanbieter betreffen, ein Anstieg von 15% im Jahr davor. Im ersten Halbjahr 2025 allein waren 79 Supply-Chain-Attacken für Sicherheitsvorfälle bei 690 Organisationen verantwortlich. Und dieser Trend wird sich 2026 nicht entspannen.

Das Ergebnis: Lieferantenrisikomanagement ist vom Nebenschauplatz zur Pflichtdisziplin aufgestiegen. NIS2, DORA, ISO 27001 zwingen Organisationen, ihre Third-Party-Abhängigkeiten nicht nur zu kennen, sondern zu dokumentieren, zu bewerten und kontinuierlich zu überwachen.

Dieser Artikel zeigt dir, wie du ein strukturiertes Lieferantenrisikomanagement aufbaust und deine gesamte Vendor-Landschaft audit-ready dokumentierst.

Warum Third-Party Risk 2026 eskaliert

Die Gründe liegen auf zwei Ebenen: technisch und regulatorisch.

Auf der technischen Seite: Third Parties sind keine isolierten Inseln. Sie sind integriert in deine Systeme, haben Zugriff auf deine Daten, steuern kritische Funktionen. Ein Sicherheitsverstoß bei einem Zulieferer ist schnell auch dein Verstoß. Der durchschnittliche Schaden bei einer Third-Party-Breache liegt bei etwa 4,91 Millionen Dollar global. Das ist 40% höher als der Schaden bei internen Sicherheitsvorfällen.

Besonders tückisch: Breaches mit Supply-Chain-Kompromittierung dauern 267 Tage, bis sie erkannt und behoben werden. Das ist länger als bei jedem anderen Angriffsvektor. Wenn dein Lieferant gehackt wurde, merkst du es unter Umständen erst viel zu spät.

Auf der regulatorischen Seite: NIS2, DORA und ISO 27001 (in der 2022er-Revision) haben Supply Chain Risk Management zu einer pflichtgegenständigen Prüfmaterie gemacht. Es reicht nicht mehr, ein vages Vertrauen in deine Zulieferer zu haben. Du musst nachweisen können, dass du weißt, wer diese sind, welche Risiken sie mit sich bringen, und wie du diese Risiken minderst.

Für 98% aller Organisationen gilt: Mindestens einer ihrer Zulieferer ist bereits von einer Datenpanne betroffen gewesen. Die Statistik ist ein Weckruf. Du brauchst ein System, das du selbst kontrollierst.

Was NIS2 und DORA konkret von dir fordern

NIS2: Die zehn Mindestmaßnahmen

Die NIS2-Direktive nennt "Sicherheit rund um Supply Chains" explizit als eine ihrer zehn Mindestmaßnahmen. Das bedeutet: Du musst dokumentieren, dass du deine Zulieferer und Dienstleister identifiziert hast, deren Risiken bewertet hast und dass deine Verträge mit ihnen angemessene Sicherheitsanforderungen enthalten.

NIS2 ist technologieoffen. Es schreibt dir nicht vor, wie genau du das tun musst. Das gibt dir Flexibilität, macht dich aber auch verantwortlich für die Umsetzung. Ein Auditor wird fragen:

• Habt ihr ein Verfahren, um Zulieferer zu klassifizieren?
• Sind kritische Zulieferer (jene, die kritische Funktionen steuern) dokumentiert?
• Welche Sicherheitsanforderungen sind vertraglich festgehalten?
• Wie wird die Einhaltung überwacht?

DORA: Detailliert und sektoral

DORA richtet sich primär an den Finanzsektor, ist aber ein Präzedenzfall. Unter DORA ist Third-Party-Risk-Management nicht nur ein Thema, sondern eine der Säulen des ganzen Governance-Modells.

Konkrete Forderungen:

• Supplier-Register. Du musst nicht nur deine direkten Zulieferer dokumentieren, sondern auch deren Subunternehmer offenlegen. Dies muss in ein dediziertes Informationsregister eingetragen werden, das der Finanzaufsicht zur Verfügung steht.
• Kritikalitätsschwellen. Wenn ein Zulieferer oder Subunternehmer "kritisch" ist (weil mindestens 10% aller beaufsichtigten Finanzinstitutionen ihn nutzen), unterliegt er zusätzlicher Aufsicht.
• Vertragsklauseln. Sicherheitsverpflichtungen müssen in jedem Vertrag mit Third Parties festgeschrieben sein. Das ist nicht optional.

DORA fordert von Finanzinstitutionen explizit, die Risiken ausgelagerter kritischer Funktionen und von Third-Party-Anbietern zu managen und die Resilienz der Supply Chain sicherzustellen.

Aufbau eines Vendor Risk Management Programms

Ein strukturiertes VRMP hat vier Phasen.

Phase 1: Inventarisierung und Klassifizierung

Zunächst musst du wissen, wen du brauchst. Das klingt trivial, ist aber oft das Nadelöhr.

Inventarisierung: Erstelle eine Gesamtliste aller Third-Party-Dienstleister. Dazu gehören Softwareanbieter, Hosting-Provider, Beratungen, Service-Provider, ja sogar der Cleaning-Service, wenn dieser Zugang zu sensiblen Bereichen hat. Ein häufiger Fehler ist, nur die "IT-relevanten" Anbieter zu erfassen und den Rest zu vergessen.

Klassifizierung: Nicht alle Zulieferer sind gleich kritisch. Entwickle ein Klassifizierungsschema basierend auf:

• Datenzugriff: Zugriff auf sensible oder personenbezogene Daten?
• Systemkritikalität: Sind kritische Geschäftsprozesse abhängig von diesem Zulieferer?
• Substituierbarkeit: Wie leicht kannst du den Zulieferer wechseln?
• Regulatorische Kritikalität: Ist der Zulieferer für Compliance-Anforderungen essenziell?

Eine simple Klassifizierung könnte sein: Kritisch, Mittel, Niedrig. Später im Monitoring und bei der Due Diligence richten sich deine Anforderungen nach dieser Klasse.

Dokumentation: Speichert diese Inventarisierung in einer zentralen Datenbank oder Tabelle. Sie ist die Grundlage für alles Folgende.

Phase 2: Due Diligence und Risk Assessment

Vor Vertragsschluss oder bei regelmäßigen Überprüfungen musst du die Sicherheitsposition des Zulieferers bewerten.

Sicherheitsfragebogen: Ein strukturiertes Fragebogensystem (oft CAIQ, also Consensus Assessments Initiative Questionnaire, oder ein firmeneigenes Format) hilft dir, standardisiert abzufragen:

• Zertifizierungen vorhanden (ISO 27001, SOC 2, etc.)?
• Incident Management Prozess dokumentiert?
• Encryption Standards implementiert?
• Backup- und Disaster-Recovery-Pläne vorhanden?

Der Vorteil eines standardisierten Fragenkatalogs: Er ist reproduzierbar und vergleichbar. Der Nachteil: Zulieferer können das Formular ausfüllen, ohne dass es der Wahrheit entspricht. Daher ist der nächste Punkt wichtig.

Zertifizierungen und Audits: Fordere Nachweise an. Ein ISO 27001-Zertifikat ist kein Garant, aber ein starkes Indiz. Ist der Zulieferer nicht zertifiziert, frag nach SOC 2 Type II Audit Reports (für Cloud Services besonders relevant). Für Cloud-Services spielt ISO 27001 Control A.5.23 eine zentrale Rolle; Zulieferer sollten das Shared-Responsibility-Modell verstehen und transparent kommunizieren, welche Kontrollen sie übernehmen.

Kontraktuelle Anforderungen: Schreib die Sicherheitsanforderungen in den Vertrag rein. Verlass dich nicht auf Zusicherungen, die später nicht einklagbar sind. Unter ISO 27001 Control A.5.20 ist dies ausdrücklich gefordert. Der Vertrag sollte abdecken:

• Datenschutz und Compliance (GDPR, lokale Gesetze)
• Sicherheitsstandards (Verschlüsselung, Zugriffskontrolle)
• Incident Notification Verpflichtungen (innerhalb welcher Zeit muss eine Breache gemeldet werden?)
• Audit- und Prüfungsrechte (darf dein Unternehmen Sicherheitschecks durchführen?)
• Subcontracting Policy (darf der Zulieferer seinerseits weitere Subunternehmer beauftragen? Unter welchen Bedingungen?)

Phase 3: Kontinuierliches Monitoring und Review

ISO 27001 Control A.5.22 verpflichtet dich zu laufendem Monitoring, Review und Change Management bei Zulieferer-Services. Das ist kein einmaliger Prozess.

Risk Dashboards: Etabliere Metriken, mit denen du die Sicherheitshaltung deiner Zulieferer laufend überwachst. Das können sein:

• Sicherheitsbewertungen (z.B. auf Basis von Schwachstellen-Scanning, wenn der Zulieferer ein SaaS-Produkt anbietet)
• Incident History: Hat der Zulieferer öffentliche Sicherheitsvorfälle gehabt?
• Zertifizierungsstatus: Ist die ISO 27001-Zertifizierung aktuell?

Periodische Reassessments: Basierend auf der Klassifizierung solltest du Zulieferer in regelmäßigen Abständen neu bewerten. Kritische Zulieferer mindestens jährlich, mittel-kritische alle zwei bis drei Jahre, niedrig-kritische alle drei bis fünf Jahre. Eine simple Tracking-Tabelle mit Reassessment-Daten ist dein Freund.

Incident Monitoring: Abonniere Sicherheits-Feeds, die dich warnen, wenn einer deiner Zulieferer von einer öffentlich bekannten Sicherheitslücke oder Breache betroffen ist. Tools wie Google Alerts, Patch-Management-Services oder spezialisierte Third-Party-Risk-Plattformen helfen hier.

Fourth-Party Risk: Das oft vergessene Risiko

Hier wird es knifflig. Dein direkter Zulieferer (Third Party) nutzt seinerseits einen Zulieferer (Fourth Party). Diesen kennst du wahrscheinlich nicht. Aber er könnte dich treffen.

Das klassische Beispiel: CrowdStrike im Jahr 2024. Ein fehlerhaftes Software-Update betraf nicht nur die direkten Kunden von CrowdStrike, sondern auch deren Kunden und deren Kunden. Das Ausmaß war global.

Nur 13% der Organisationen überprüfen ihre direkten Zulieferer, und nur 7% untersuchen Risiken bei Fourth Parties. Das ist eine erhebliche Lücke.

Was kannst du tun?

Subunternehmer-Anforderungen in Verträgen: Fordere deine direkten Zulieferer auf, ihre eigenen Subunternehmer offenzulegen und selbst ein Third-Party-Risk-Management zu betreiben. Das ist der Ansatz von DORA: Cascade-Anforderungen.

Sichtbarkeit schaffen: Du kannst nicht alle Fourth Parties direct kontrollieren, aber du kannst fragen:

• Welche kritischen Subunternehmer nutzt der Zulieferer?
• Wie überwacht der Zulieferer diese selbst?
• Welche Sicherheitsverpflichtungen sind vertraglich mit ihnen vereinbart?

Resilienz durch Diversifizierung: Wo möglich, vermeide eine zu starke Abhängigkeit von einzelnen kritischen Zulieferern oder deren Zulieferern. Single Points of Failure sind ein Sicherheitsrisiko.

ISO 27001 Integration: Fünf Controls für Third-Party Risk

ISO 27001 in der 2022-Revision fasst Supplier Management unter fünf Kontrollen zusammen: A.5.19 bis A.5.23. Das ist dein Referenzrahmen für viele Audits.

A.5.19: Information Security in Supplier Relationships Dies ist die Kernkontrolle. Sie verlangt von dir:

• Ein dokumentiertes Supplier-Management-Verfahren, das den gesamten Lifecycle abdeckt: Identifizierung, Bewertung, Mitigation von Risiken vor, während und nach Beendigung der Beziehung.
• Supplier Vetting und Due Diligence vor Vertragsschluss (Sicherheitsfragebögen, Zertifizierungsverifizierung).
• Supplier Segmentierung. Nicht alle Zulieferer sind gleich kritisch. Deine Controls sollten dem Risiko entsprechen.

A.5.20: Addressing Information Security within Supplier Agreements Sicherheitsanforderungen müssen vertraglich verankert sein. Das ist nicht verhandelbar.

A.5.21: Managing Information Security in the ICT Supply Chain Dies ist spezifisch auf ICT-Zulieferer gerichtet. Es fordert die Verwaltung von Sicherheitsrisiken in der gesamten ICT-Supply-Chain, inklusive der Governance und der Compliance-Anforderungen.

A.5.22: Monitoring, Review and Change Management of Supplier Services Du musst die Sicherheit deiner Zulieferer laufend überwachen und regelmäßig überprüfen. Änderungen in der Konfiguration, den Services oder Richtlinien des Zulieferers müssen dir bekannt sein.

A.5.23: Information Security for use of Cloud Services Ein separater Control, weil Cloud Services eigene Tücken haben. Shared Responsibility Model, Data Residency, Service Level Agreements, Exit-Strategien. Das alles muss klar sein.

Ein ISO 27001 Auditor wird dir zeigen wollen:

• Den Supplier-Katalog.
• Due-Diligence-Dokumentation für jeden Zulieferer.
• Beispiele von Verträgen mit Sicherheitsklauseln.
• Monitoring- und Review-Logs (wer hat wann was überprüft?).
• Incident-Log: Hat es Sicherheitsvorfälle gegeben und wie wurden sie gehandhabt?

Ohne diese Unterlagen wirst du bei einer ISO 27001 Zertifizierung oder einem Re-Assessment nicht bestehen.

Bußgelder und Haftung: Die finanziellen Konsequenzen

Die Regulierungen sind nicht nur ein Compliance-Thema. Es geht um Geld.

NIS2: Verstöße können mit Bußgeldern von bis zu 10 Millionen Euro oder 2% des globalen Jahresumsatzes (je nachdem, was höher ist) geahndet werden. Für größere Unternehmen ist das erheblich.

DORA: Ähnliche Skalen. Verstöße gegen die Anforderungen an Third-Party-Risk-Management können zu Bußgeldern führen.

Haftung: Zusätzlich zu Bußgeldern können geschädigte Parteien (z.B. wenn dein Zulieferer gehackt wurde und der Hack dein System kompromittiert hat) Schadensersatz fordern. Wenn du fahrlässig warst in der Auswahl oder Überwachung des Zulieferers, haftest du unter Umständen selbst.

Beispiel: Dein Hosting-Provider wird gehackt. Deine Kundendaten lecken aus. Der Kunde verklagt dich. Deine Verteidigung könnte sein: "Ich habe alles getan, um diesen Anbieter zu überprüfen. Ich hätte diese Lücke nicht vorhersehen können." Das funktioniert aber nur, wenn du dokumentieren kannst, dass du ein strukturiertes Risk Management betrieben hast. Andernfalls ist deine Haftung schwer zu begrenzen.

Praktische Dokumentationsvorlage: Audit-Ready Setup

Hier ist ein minimales Set von Dokumenten, das du brauchst:

1. Supplier Register (Spreadsheet oder Datenbank)

Lieferanten-ID	Name	Kategorie	Klassifizierung	Due Date Reassessment	Zertifizierungen	Status
SUP001	CloudProvider XYZ	Cloud Services	Kritisch	Q2 2026	ISO 27001, SOC 2 Type II	Approved
SUP002	Office Cleaning Service	Facility Services	Niedrig	Q4 2026	Keine	Approved

2. Supplier Risk Assessment Template

Lieferanten-ID: SUP001
Name: CloudProvider XYZ
Bewertungsdatum: 2026-01-15
Evaluator: IT-Sicherheitsteam

Due Diligence Checklist:
[ ] Sicherheitsfragebogen ausgefüllt
[ ] ISO 27001-Zertifikat verifiziert
[ ] SOC 2 Audit Report angefordert
[ ] Datenschutzerklärung überprüft
[ ] Sicherheitsrichtlinien dokumentiert
[ ] Subunternehmer offengelegt

Gesamtrisikonote: Mittel
Begründung: ISO 27001 zertifiziert, aber begrenzte Sichtbarkeit in Subunternehmer-Struktur.

Mitigationsmaßnahmen:
1. Jährliche Reassessments durchführen.
2. Audit-Rechte im Vertrag verankern.
3. Incident Notification verpflichtend machen (48 Stunden).

Genehmigt durch: Chief Information Security Officer

3. Supplier Agreement Security Addendum

SICHERHEITSANLAGE ZUM LIEFERANTENVERTRAG

3.1 Sicherheitsstandards
Der Lieferant verpflichtet sich, mindestens die Kontrollen aus ISO 27001 Annex A
(aktuelle Version) zu implementieren und zu erhalten, soweit auf seine Services anwendbar.

3.2 Incident Notification
Der Lieferant verpflichtet sich, jeden Sicherheitsincident, der sich auf die bereitgestellten
Services auswirkt, dem Kunden innerhalb von 48 Stunden schriftlich zu melden.

3.3 Audit und Prüfungsrechte
Der Kunde hat das Recht, Sicherheits-Audits durchzuführen oder durch Dritte durchführen
zu lassen, mindestens einmal pro Jahr, mit angemessener Vorankündigung.

3.4 Subunternehmer
Der Lieferant darf Subunternehmer nur mit schriftlicher Zustimmung des Kunden einsetzen.
Eine Liste aller Subunternehmer ist verfügbar zu halten und dem Kunden auf Anfrage zugänglich.

3.5 Datenschutz
Der Lieferant verpflichtet sich zur Einhaltung aller geltenden Datenschutzgesetze,
insbesondere GDPR und lokale Datenschutzregelungen.

3.6 Beendigung und Datenrückgabe
Bei Beendigung des Vertrags wird der Lieferant alle Kundendaten in einem sicheren Format
zurückgeben oder sicher vernichten, nachweislich, innerhalb von 30 Tagen nach Vertragsende.

4. Monitoring und Review Log

Lieferanten-ID: SUP001
Monitoring-Zeitraum: 2026 Q1

Datum | Aktivität | Ergebnis | Durchführung durch
2026-01-10 | Vulnerability Scan der Cloud Platform durchgeführt | 3 niedrig-kritische Schwachstellen identifiziert, Vendor bestätigt Patch-Plan | Security Team
2026-02-15 | Jährliche Reassessment gestartet | Fragebogen versendet | Compliance Officer
2026-03-05 | Reassessment-Antwort erhalten | Positiv, keine wesentlichen Änderungen | Compliance Officer
2026-03-20 | Zertifizierungsstatus überprüft | ISO 27001 noch gültig bis 2027-01 | GRC System

Fazit: Kein erhöhtes Risiko erkannt. Weiterhin genehmigt.

Häufige Fehler beim Aufbau von VRMP

Fehler 1: Nur IT-Zulieferer inventarisieren Nicht-IT-Zulieferer (Facility Services, Personalvermittlung, Consulting) können genauso Risiken mit sich bringen. Eine Reinigungskraft mit Zugang zu Serverräumen ist ein Third-Party-Risiko.

Fehler 2: Fragebogens als finale Wahrheit nehmen Fragebogen sind ein Anfang, keine Endsicherheit. Ein Zulieferer kann ein Formular ausfüllen und trotzdem Sicherheitslücken haben. Zertifizierungen und externe Audits sind stärker.

Fehler 3: Due Diligence ist einmalig Sicherheit ist keine Einmalveranstaltung. Ein Zulieferer kann heute zertifiziert sein und morgen gehackt werden. Regelmäßige Reassessments sind notwendig.

Fehler 4: Keine Risikohierarchie Wenn du alle Zulieferer mit gleicher Strenge behandelst, verschwendest du Ressourcen. Ein Büromöbel-Lieferant braucht nicht die gleiche Überprüfung wie ein Security-Dienstleister.

Fehler 5: Fourth-Party-Risiko ignorieren Du kannst es nicht ignorieren. Die Frage ist nicht, ob deine Third Parties auch Fourth Parties nutzen, sondern wie du dich dagegen absicherst.

Implementierungs-Roadmap: 6 Monate bis zur vollständigen Abdeckung

Monat 1-2: Inventarisierung und Klassifizierung

• Alle Third-Party-Beziehungen erfassen.
• Klassifizierungsschema definieren.
• Initial Risk Assessment durchführen.

Monat 3: Due Diligence

• Sicherheitsfragebogen an kritische und mittel-kritische Zulieferer versenden.
• Zertifizierungen anfordern.
• Verträge auf Sicherheitsklauseln überprüfen.

Monat 4: Vertragsanpassung

• Sicherheitsaddenden zu bestehenden Verträgen entwickeln.
• Mit kritischen Zulieferern Nachverhandlungen führen.
• Neue Zulieferer automatisch mit Security Addendum aufnehmen.

Monat 5: Monitoring-Setup

• Monitoring-Tools oder Prozesse etablieren.
• Monitoring-Verantwortlichkeiten zuweisen.
• Erstes Quarterly Review durchführen.

Monat 6: Dokumentation und Audit-Readiness

• Alle Dokumente zentralisieren (GRC-System oder Dateiablage).
• Interne Audit durchführen.
• Governance-Meetings einrichten (mindestens quartalsweise).

Diese Roadmap ist komprimiert. Größere Organisationen mit hunderten von Zulieferern werden länger brauchen.

Fazit: Dokumentation als Schutzmauern

Third-Party-Risiken sind nicht weg. Sie wachsen. Mit 30% aller Datenpannen, die auf Zulieferer zurückgehen, ist klar: Du brauchst ein System. Nicht, um alle Risiken zu eliminieren (das ist unmöglich). Sondern um zu zeigen, dass du die Risiken kennst, sie bewertst und sie aktiv managst.

Genau das ist es, was NIS2, DORA und ISO 27001 von dir fordern. Ein strukturiertes, dokumentiertes Vendor Risk Management Programm.

Die gute Nachricht: Das ist alles machbar. Es erfordert keine exotischen Tools (spreadsheets reichen zum Anfangen), sondern Systematik. Eine Inventory, ein Assessment-Prozess, Monitoring, regelmäßige Reviews. Und Dokumentation. Immer Dokumentation.

Wer diese vier Dinge hat, ist audit-ready. Und das ist das Ziel.