Lieferkettenrisiko ist ein Programm, keine Audit-Liste

6 Min. Lesezeit

Die Lieferantenliste war vor dem Audit grün. Dann tauchte der Admin-Zugang eines Subunternehmers des ERP-Hosters in einem Ticket-System auf, das weder im Vertrag noch im Register stand. NIS2 und DORA verlangen kein abgehaktes Fragebogen-Archiv, sondern einen Prozess, der Verträge, Daten und Zugriffe laufend synchron hält.

Verwandt:TrapDoor: Supply-Chain-Angriff auf npm, PyPI und Crates  /  DORA und NIS2: Warum Banken-Audits kollidieren

Was Paragraf 30 zur Lieferkette wirklich verlangt

Was ist Third-Party-Risk-Management? Third-Party-Risk-Management ist der laufende Prozess, mit dem eine Organisation die Sicherheitsrisiken ihrer Dienstleister, Software-Anbieter und deren Subunternehmer erfasst, bewertet, vertraglich absichert und überwacht. Es reicht vom Onboarding über die kontinuierliche Kontrolle bis zum Offboarding.

Paragraf 30 Absatz 2 Nummer 4 BSIG nennt die Sicherheit der Lieferkette ausdrücklich als Pflichtmassnahme. Der Fokus liegt auf den Beziehungen zu den unmittelbaren Anbietern. Die gesamte Kette bis zum Rohstoff ist nicht gemeint. Das ist die gute Nachricht für den Mittelstand: Es geht um die direkten Vertragspartner, die Zugriff auf Systeme oder Daten haben.

Die weniger bequeme Nachricht steht in Absatz 1 und in der europäischen Vorlage. Die Maßnahmen müssen geeignet, verhältnismäßig und wirksam sein, dazu kommt eine Dokumentationspflicht. NIS2 Artikel 21 verlangt eine laufende Risikosteuerung für alle Netz- und Informationssysteme, die der Betrieb nutzt. Erwägungsgrund 85 der Richtlinie nennt Cloud, Managed Security und Software beim Namen. Ein Verzeichnis, das einmal im Jahr entsteht, bildet diese Pflicht nicht ab.

DORA macht aus dem Register eine Dauerpflicht

Wer im Finanzsektor arbeitet, kennt den schärferen Maßstab. DORA gilt seit dem 17. Januar 2025 verbindlich. Für Finanzunternehmen greift es als spezielleres Recht an Stelle der NIS2-Lieferkettenpflichten. Beide Regime gelten für dasselbe Unternehmen nicht parallel. Artikel 28 lässt die Verantwortung vollständig beim Finanzunternehmen, auch wenn die Leistung ausgelagert ist.

Das Register der Informationen ist kein Excel, das man einmal befüllt. Es wird auf Instituts- und Konzernebene geführt, jährlich an die Aufsicht gemeldet und muss auf Anfrage vollständig vorliegen. Vor jedem Vertrag für eine kritische Funktion steht eine Due Diligence, dazu kommen Konzentrationsrisiko-Analyse und Exit-Strategien. Artikel 30 schreibt konkrete Vertragsinhalte vor: Subunternehmer-Regelungen, Standort der Datenverarbeitung, Audit-Rechte und Meldepflichten bei wesentlichen Änderungen.

Wie ernst die Aufsicht das nimmt, zeigt der 18. November 2025. Die europäischen Aufsichtsbehörden EBA, EIOPA und ESMA haben die erste Liste kritischer IKT-Drittdienstleister veröffentlicht, 19 Anbieter, darunter mehrere große Cloud-Anbieter und SAP. Diese Anbieter stehen jetzt unter direkter EU-Aufsicht. Das Lieferkettenrisiko wird auf Systemebene reguliert, längst über den Einzelvertrag hinaus.

Warum der Jahresfragebogen die Lücke nicht schließt

Ich habe einmal einen Lieferanten-Fragebogen mit einem grünen Haken bei ISO 27001 abgelegt und den Fall für erledigt gehalten. Vier Monate später wechselte der Anbieter seinen Hosting-Subunternehmer. Der Fragebogen war noch grün, die Realität nicht mehr. Genau diese zeitliche Diskrepanz ist das Problem.

Der regulatorische Text meint einen Zyklus. Eine Einmalprüfung genügt ihm nicht. Paragraf 30 Nummer 6 verlangt eine Bewertung der Wirksamkeit, DORA Artikel 30 verlangt laufende Überwachung bei kritischen Verträgen. Nicht jeder Lieferant braucht dieselbe Tiefe. Ein Tiering nach Zugang zu Systemen, Sensibilität der Daten und Verfügbarkeitsabhängigkeit trennt die Tier-A-Partner von der langen Liste unkritischer Dienstleister.

Dazu kommt ein Datenproblem. Eine Branchenerhebung zum Third-Party-Risk-Management aus dem Jahr 2026 legt nahe, dass nur eine Minderheit der Programme voll ins Enterprise-Risk-Management integriert ist und noch weniger Organisationen ihre Datenqualität als hoch einstufen. Die genauen Werte sind je nach Methodik zu lesen. Der Befund bleibt: Ohne sauberes Register gibt es keine belastbare Tiering-Entscheidung. Ohne ERM-Anbindung bleibt das Risiko im Beschaffungs-Ticket hängen statt im Quartalsbericht der Geschäftsleitung.

Die folgende Übersicht stellt die beiden Denkweisen gegenüber.

Fünf Bausteine, die aus Kontrolle ein Programm machen

Ein tragfähiges Programm braucht keine große Plattform, es braucht klare Eigentümer je Prozessschritt. Fünf Bausteine reichen für den Anfang.

Policy und Tiering. Eine Kritikalitätsmatrix nach Zugang, Daten und Verfügbarkeit legt fest, wer Tier A ist und wie oft er geprüft wird. Eigentümer ist der Bereich Risk oder der CISO, umgesetzt durch einen TPRM-Verantwortlichen.

Onboarding-Assessment. Die Due Diligence steht vor dem Vertrag. Danach ist der Zugang oft schon aktiv. Sicherheitsnachweise, Standortfragen und Konfliktprüfung gehören geklärt, bevor der Zugang aktiv wird. DORA Artikel 28 macht das für kritische Funktionen zur Pflicht.

Laufende Überwachung. Register-Pflege, Re-Zertifizierung nach Risiko und ein Kanal für Incident-Meldungen des Lieferanten. Hier lebt oder stirbt das Programm. Ein Vertragswechsel beim Anbieter muss ein Signal auslösen. Eine stille Notiz reicht nicht.

Offboarding. Zugangsentzug, Datenrückgabe oder Löschung und ein dokumentiertes Vertragsende. Der häufigste blinde Fleck sind Zugänge, die nach Projektende aktiv bleiben.

Vierte Partei und Software-Transparenz. Subunternehmer gehören in die Register-Felder, kritische Software braucht eine Stückliste nach dem SBOM-Prinzip. Eine solche Stückliste ist keine ausdrückliche Normpflicht, sie hilft aber, das Schwachstellen-Management aus Paragraf 30 Nummer 5 BSIG bis in die Lieferkette zu tragen.

Über allem steht die Geschäftsleitung. Paragraf 38 BSIG verpflichtet sie zur Umsetzung und Überwachung. Ein TPRM-Programm ohne sichtbares Management-Review ist ein CISO-Deckblatt ohne Governance-Wert. Der Facility-Dienstleister mit Zutritt zum Serverraum ist Tier A, auch wenn ihn die Beschaffung nur unter Gebäudedienste führt. Genau solche Einordnungen entscheiden über das Risiko.

Der Einstieg: Wo Sie diese Woche anfangen

Der Weg vom Fragebogen zum Programm braucht keinen großen Wurf. Fünf Schritte bringen Struktur, ohne den Betrieb zu blockieren. Erstens: die Tier-A-Lieferanten identifizieren, also alle mit Systemzugang oder kritischen Daten. Zweitens: das Register gegen die Realität abgleichen und fehlende Subunternehmer nachtragen. Drittens: für jeden Tier-A-Partner einen Eigentümer und einen Überwachungsrhythmus festlegen. Viertens: die Vertragsklauseln zu Audit-Rechten, Subunternehmern und Meldepflichten prüfen. Fünftens: die Lieferantenrisiken als Einträge ins Enterprise-Risk-Register heben, mit Quartalsbericht an die Leitung.

Das ist kein Projekt mit Enddatum. Es ist ein Betriebsmodus. Wer ihn einmal etabliert hat, besteht das nächste Audit nebenbei, weil der Nachweis ein Nebenprodukt des laufenden Betriebs ist.

Häufige Fragen

Reicht ein Lieferantenverzeichnis für die NIS2-Compliance?

Nein. Paragraf 30 BSIG und NIS2 Artikel 21 verlangen geeignete, wirksame und laufend gesteuerte Maßnahmen. Ein Verzeichnis allein genügt nicht. Ein statisches Register ohne Tiering, Überwachung und Wirksamkeitsbewertung deckt die Pflicht zur Risikosteuerung nicht ab.

Was unterscheidet DORA von den NIS2-Lieferkettenpflichten?

DORA gilt seit dem 17. Januar 2025 im Finanzsektor und hat dort Vorrang. Es verlangt ein formales IKT-Drittparteienregister mit jährlicher Meldung, Exit-Strategien und detaillierten Vertragsinhalten nach Artikel 30. NIS2 setzt den Rahmen breiter, aber weniger formalisiert.

Müssen wir Subunternehmer unserer Dienstleister erfassen?

Im Finanzsektor ja, sobald sie kritische oder wichtige Funktionen berühren. DORA Artikel 30 und die technischen Vorgaben zum Register verlangen Kaskadierungsklauseln und die Erfassung relevanter Subunternehmer. Unter NIS2 adressiert Paragraf 30 Nummer 4 vor allem die unmittelbaren Anbieter, die ausdrückliche Pflicht zur Subunternehmer-Erfassung ist eine DORA-Besonderheit.

Wie oft müssen wir Lieferanten neu bewerten?

Es gibt keine feste Frequenz für alle. Der Rhythmus richtet sich nach dem Tier: kritische Anbieter mit Systemzugang engmaschig und ereignisgesteuert, unkritische Dienstleister seltener. Auslöser sind Vertragsänderungen, Subunternehmer-Wechsel und Sicherheitsvorfälle.

Was ist ein SBOM und warum gehört es ins TPRM?

Ein SBOM ist eine Stückliste der Softwarebestandteile eines Produkts, oft im Format CycloneDX oder SPDX. Es zeigt, welche Bibliotheken aus der Lieferkette stammen und unterstützt so das Schwachstellen-Management aus Paragraf 30 Nummer 5. Vorgeschrieben ist ein SBOM nicht, es hat sich aber als Praxis etabliert. Ohne diese Transparenz bleibt Software-Herkunft ein blinder Fleck.

Lesetipps der Redaktion

• TrapDoor: Koordinierter Supply-Chain-Angriff auf npm, PyPI und Crates
• DORA und NIS2: Warum Banken-Audits jetzt kollidieren
• Wo der Mittelstand bei NIS2 technisch noch hinterherhinkt

Mehr aus dem MBF Media Netzwerk

Bildquelle: KI-generiert (Juni 2026)