Kantyra
Kantyra
Kantyra · 25-07-2026 · 11 min leestijd
Jahrelang war das Lieferantenmanagement in der Informationssicherheit (IS) das Register, das man für den Auditor ausfüllte und danach ein Jahr lang nicht anfasste. Die Zahlen zeigen, wie unklug das geworden ist. Als die Agentur der Europäischen Union für Cybersicherheit (ENISA) 2021 vierundzwanzig Lieferkettenangriffe zerlegte, missbrauchten 62 Prozent der Angriffe das Vertrauen, das der Kunde in seinen Lieferanten setzte. Der Angreifer kommt über genau die Partei herein, die Sie bewusst hereingelassen haben. Mit der NIS2-Richtlinie und dem Digital Operational Resilience Act (DORA) ist die Unverbindlichkeit zudem rechtlich vorbei, denn beide stellen Anforderungen an die Beherrschung Ihrer Kette. Zeit also, das Thema ernsthaft aufzusetzen. Doch genau da beginnt die Begriffsverwirrung, denn „Lieferantenmanagement" bedeutet in drei Teilen der Organisation drei verschiedene Dinge, und darüber schwebt noch ein vierter Begriff, das Third Party Risk Management (TPRM). Dieser Artikel stellt sie nebeneinander.
Nehmen Sie eine Organisation, die ihre Gehaltsabrechnung ausgelagert hat. Mit diesem einen Lieferanten laufen drei völlig verschiedene Gespräche, und jedes Gespräch hat einen eigenen Verantwortlichen, einen eigenen Rhythmus und ein eigenes Register.
Das erste Gespräch führt der Einkauf. Dort geht es um den Vertrag, den Preis, die Laufzeit, die Lieferbedingungen und die Frage, ob die Organisation bekommt, wofür sie bezahlt. Dieses Fach heißt Vertragsmanagement oder Vendormanagement, es lebt in einem Vertragsregister, und es kennt seine eigenen Momente, nämlich die Ausschreibung, die Verlängerung und die Verhandlung. Die Frage, die dieses Gespräch beantwortet, ist, ob die Vereinbarungen stimmen und eingehalten werden.
Das zweite Gespräch führt die IT-Abteilung. In der Information Technology Infrastructure Library (ITIL) und in ISO/IEC 20000 heißt das Supplier Management, und es geht um die tägliche Dienstleistung. Werden die vereinbarten Verfügbarkeiten erreicht, wie schnell werden Störungen aufgegriffen, wie laufen Änderungen, und wer eskaliert, wenn etwas schiefgeht. Dieses Gespräch lebt in der Servicemanagementumgebung, neben der Konfigurationsdatenbank (CMDB), und sein Rhythmus ist der des Betriebs, also wöchentlich oder monatlich. Die Frage lautet hier, ob der Dienst leistet, was die Nutzer brauchen.
Das dritte Gespräch ist das der Informationssicherheit, und es stellt eine grundlegend andere Frage. Welches Risiko läuft unsere Information, weil dieser Lieferant an sie herankommt, sie verarbeitet oder sie hostet? Was geschieht mit der Vertraulichkeit, Integrität und Verfügbarkeit unserer Daten, wenn diese Partei kompromittiert wird, ausfällt oder insolvent geht? ISO/IEC 27001 widmet dem vier Maßnahmen, 5.19 bis 5.22, von der Richtlinie und den vertraglichen Vereinbarungen bis zur Überwachung von Veränderungen beim Lieferanten. Dieses Gespräch gehört in Ihr Managementsystem für Informationssicherheit (ISMS), mit dem Chief Information Security Officer (CISO) als Prozessbegleiter und einem Verantwortlichen je Lieferant.
Die drei Gespräche ähneln einander, weil sie dieselbe Partei betreffen, aber sie unterscheiden sich in allem, was zählt. Wer sie in ein einziges Register presst, erhält eine Liste, die für alle fast passt und damit für niemanden. Wer sie völlig getrennt bestehen lässt, verpasst die Zusammenhänge, denn eine Vertragsverlängerung ist genau der Moment, um Sicherheitsanforderungen durchzusetzen, und eine Reihe betrieblicher Störungen ist oft das erste Signal, dass beim Lieferanten etwas Strukturelles nicht stimmt. Die Kunst besteht darin, drei Register ihre eigene Arbeit machen zu lassen und die Momente zu verbinden.
Viele CISOs ringen mit der Frage, ob Third Party Risk Management eine eigene Disziplin ist, die sie zusätzlich aufbauen müssen. Die kurze Antwort lautet nein. TPRM ist der angelsächsische Name für dasselbe Arbeitsfeld, mit zwei Akzentunterschieden, die man kennen sollte.
Der erste Unterschied steckt im Wort „third party". Das ist breiter als „Lieferant", denn darunter fallen auch Parteien, die nie eine Rechnung stellen, etwa Kettenpartner, Franchisenehmer, Vermittler und kostenlose Dienste, durch die Ihre Daten laufen. Für Ihr Risikobild ist dieser Unterschied real: Die Branchenplattform, mit der Sie Daten austauschen, ist kein Lieferant, verdient aber dieselbe Bewertung.
Der zweite Unterschied liegt in der Breite des Risikobegriffs. TPRM-Programme großer Organisationen betrachten neben der Informationssicherheit auch Kontinuität, Compliance, finanzielle Gesundheit und Reputation der dritten Partei. IS-Lieferantenmanagement ist in dieser Lesart der Informationssicherheitskern des TPRM, und dieser Kern ist, was ISO 27001 und NIS2 von Ihnen verlangen. DORA liegt etwas anders. Die Verordnung beschränkt sich auf IKT-Dienstleister, verlangt innerhalb dieser Gruppe aber gerade mehr als Informationssicherheit allein, denn Kontinuität, Konzentrationsrisiko und eine Ausstiegsstrategie gehören ausdrücklich dazu. Nur die Reputation bleibt auch unter DORA eine freiwillige Ergänzung.
Die praktische Schlussfolgerung ist dieselbe wie bei den Unternehmenswerten aus einem früheren Artikel dieser Reihe. Richten Sie keine zwei Prozesse ein. Führen Sie ein Lieferantenregister auf Risikoniveau, geben Sie jeder Partei einen Verantwortlichen und eine Kritikalität, und hängen Sie je Rahmenwerk die Merkmale an, die das jeweilige Rahmenwerk verlangt. Ob Sie das Ganze dann TPRM oder Lieferantenmanagement nennen, ist eine Frage des Sprachgebrauchs, nicht der Substanz.
Das Lieferantenrisiko ist eines der Gebiete, auf denen die Ökonomie der Informationssicherheit mehr erklärt als die Technik. Kunreuther und Heal zeigten 2003, was geschieht, wenn Ihre Sicherheit von den Investitionen anderer abhängt, eine Situation, die sie Interdependent Security nannten. Ihre spieltheoretische Analyse kennt Gleichgewichte, in denen niemand investiert, weil der Schutz, den Sie kaufen, wenig wert ist, solange Ihre Nachbarn nichts tun. Anderson und Moore arbeiteten in Science heraus, warum Informationssicherheit so oft ökonomisch scheitert statt technisch, denn wer absichert, trägt die Kosten, während ein Teil des Schadens bei anderen anfällt. Zusammen erklären diese beiden Einsichten, warum Lieferkettensicherheit jahrzehntelang ein Stiefkind bleiben konnte, und warum der Gesetzgeber mit NIS2 und DORA die Anreize verschiebt: Die Sorgfaltspflicht macht das Risiko Ihres Lieferanten zu Ihrer nachweisbaren Verantwortung.
Das Fachgebiet selbst ist jung. Boyson beschrieb 2014, auf Basis eines mehrjährigen Forschungsprogramms für das amerikanische National Institute of Standards and Technology (NIST), Cyber Supply Chain Risk Management als eine Disziplin im Aufbau, in der die meisten Organisationen noch ad hoc arbeiteten. Ghadge und Kollegen kamen in ihrer systematischen Literaturstudie zu einem ähnlichen Schluss, denn Forschung zu Cyberrisiken zwischen Organisationen erwies sich als rar im Vergleich zur Forschung innerhalb der eigenen Mauern, während gerade die Schnittstellen das Risiko tragen.
Die praxisnächste Forschung ist jüngeren Datums. Slapničar, Vidmar und Tsen bauten aus 33 Interviews und einer Befragung von 53 Sicherheitsexperten eine Prozesstheorie der Lieferantenbewertung. Zwei Befunde verdienen Aufmerksamkeit. Erstens funktioniert der Prozess, denn eine strukturierte Bewertung unterscheidet riskante von weniger riskanten Lieferanten. Zweitens funktioniert er nur, wenn die Tiefe der Bewertung mit der Kritikalität des Lieferanten mitgeht, weil niemand die Kapazität hat, jede Partei gleich schwer zu prüfen. Fragebögen ohne Differenzierung zu versenden liefert Stapel unbeantworteter Formulare und kein Risikobild.
Dazu gehört eine nüchterne Anmerkung zu Zertifikaten. Lins, Schneider und Sunyaev zeigten, dass ein Zertifikat eine Momentaufnahme ist, denn zwischen zwei Audits kann sich die Wirklichkeit bei einem Clouddienst erheblich verschieben. Ein ISO-27001-Zertifikat Ihres Lieferanten ist also eine sinnvolle Anforderung und ein guter Ausgangspunkt, ersetzt aber Ihre eigene Bewertung nicht, und bei Ihren kritischsten Lieferanten wollen Sie zusätzliche Nachweise sehen, etwa aktuelle Penetrationstestergebnisse oder einen Assurance-Bericht.
Die NIS2-Richtlinie nennt die Sicherheit der Lieferkette ausdrücklich als Pflichtbestandteil der Sorgfaltspflicht, einschließlich der sicherheitsbezogenen Aspekte der Beziehungen zu direkten Lieferanten und Dienstleistern. Die Maßnahmen müssen dem Risiko angemessen sein, und damit ist die Kritikalitätseinstufung Ihrer Lieferanten kein administrativer Luxus, sondern die Begründung Ihrer Verhältnismäßigkeit. Das Leitungsorgan billigt die Maßnahmen und ist dafür verantwortlich.
DORA geht für Finanzunternehmen erheblich weiter, allerdings ausschließlich für dritte Parteien, die IKT-Dienstleistungen erbringen; die Auslagerung außerhalb der IKT fällt unter die gesonderten Leitlinien der europäischen Aufsichtsbehörden. Kapitel V regelt das Management des IKT-Drittparteienrisikos bis auf Vertragsebene, mit vorgeschriebenen Vertragsklauseln, einem eigenen Artikel zum Konzentrationsrisiko, einer Ausstiegsstrategie, die auch den Ausfall oder das Absacken des Dienstleisters abdeckt, und dem Informationsregister über alle vertraglichen Vereinbarungen mit IKT-Dienstleistern, das auf Anfrage an die Aufsicht geht. Innerhalb seines Geltungsbereichs verlangt DORA damit ausdrücklich mehr als Informationssicherheit allein, denn Kontinuität und Ersetzbarkeit wiegen ebenso schwer. Die kritischsten IKT-Dienstleister kommen zudem unter direkte europäische Aufsicht. Wer unter DORA fällt, kann Lieferantenmanagement also nicht mehr auf eine jährliche Überprüfung beschränken, denn das Register selbst wird zum Aufsichtsprodukt.
In Kantyra ist IS-Lieferantenmanagement ein fortlaufender Zyklus aus sechs Schritten, und die Abbildung fasst ihn zusammen.
Die Reihenfolge ist bewusst risikogesteuert, genau wie es die Forschung von Slapničar und Kollegen empfiehlt: Die Kritikalität aus Schritt 1 und 2 bestimmt, wie schwer Schritt 3 und 4 ausfallen, damit Ihre Kapazität bei den Lieferanten landet, auf die es wirklich ankommt.
Die sechs Schritte durchlaufen damit alle vier Phasen des Modells hinter Kantyra. Registrieren und Verknüpfen sind Erkennen, denn dort halten Sie die Fakten fest. Messen, Abfragen und Bewerten bilden zusammen die Phase Bewerten, in der das Urteil über den Lieferanten entsteht. Der Überwachungsschritt gehört zu Lösen und Nachweisen: Die automatischen Aufgaben und Signale stellen sicher, dass Vereinbarungen eingehalten werden, und die festgehaltenen Umfragen, Bewertungen und die Überprüfungshistorie sind genau der Nachweis, den ein Auditor oder eine Aufsicht sehen will. Lieferantenmanagement ist also keine Registerpflege in der Erkennungsphase, sondern ein Zyklus durch das gesamte Modell.
Wer dies liest und noch keinen funktionierenden Prozess hat, muss nicht mit einem vollständigen Register von zweihundert Parteien beginnen. Beginnen Sie mit den zehn Lieferanten, deren Kompromittierung oder Ausfall Ihren Primärprozess unmittelbar trifft, und durchlaufen Sie für diese zehn die sechs Schritte. Danach wächst das Register von selbst mit jeder Beschaffung und jeder Datenschutz-Folgenabschätzung (DSFA), die einen neuen Auftragsverarbeiter ans Licht bringt. Der Unterschied zwischen einem Stiefkind und einem funktionierenden Prozess liegt nicht im Umfang der Liste, sondern in der Frage, ob sich jemand mit Namen für jede Zeile darauf verantwortlich fühlt.
Normative Quellen, direkt nachschlagbar:
Wissenschaftliche Literatur:
In een demo van 30 minuten lopen we het model door aan de hand van jouw situatie.
Plan een demo