Third-Party Risk Management: Aufgaben, Prozess und technische Datenquellen
Dieser Text wurde mit künstlicher Intelligenz (KI) erstellt.
Unternehmen beziehen Software, Cloud-Dienste, IT-Betrieb, Beratung und viele weitere Leistungen von externen Organisationen. Jede dieser Beziehungen kann Abhängigkeiten, Zugriffsrechte und Datenflüsse schaffen. Third-Party Risk Management ordnet diese Risiken über den gesamten Lebenszyklus einer Geschäftsbeziehung. Es verbindet Einkauf, Informationssicherheit, Datenschutz, Recht, Fachbereiche und Unternehmensleitung in einem nachvollziehbaren Prozess.
Die Begriffe Third-Party Risk Management (TPRM) und Vendor Risk Management werden in der Praxis häufig für ähnliche Programme verwendet. Vendor Risk Management richtet den Blick oft auf Lieferanten. TPRM kann zusätzlich Dienstleister, Vertriebspartner, Berater und andere externe Parteien einschließen. ICT Third-Party Risk Management bezeichnet den auf Informations- und Kommunikationstechnologie bezogenen Teil. Entscheidend ist nicht das Etikett, sondern ein klar definierter Geltungsbereich.
Das Wichtigste in Kürze
Ein belastbarer TPRM-Prozess beginnt mit einem gepflegten Inventar und einer risikobasierten Kritikalitätseinstufung.
Due Diligence kombiniert Selbstauskünfte, Nachweise, Vertragsinformationen, interne Erkenntnisse und technische Außensicht.
Prüftiefe, Freigabe, Vertragsmaßnahmen und Überwachung richten sich nach dem möglichen Schaden und der Abhängigkeit.
Ein Security Rating oder eine externe Analyse ergänzt die organisatorische Bewertung, ersetzt sie aber nicht.
Offboarding gehört zum Prozess: Zugänge, Daten, Unterauftragnehmer, Nachweise und Restpflichten müssen kontrolliert beendet werden.
Was Third-Party Risk Management leisten soll
TPRM schafft einen einheitlichen Entscheidungsrahmen für Risiken aus Geschäftsbeziehungen mit externen Parteien. Das Programm beantwortet fünf praktische Fragen: Mit wem arbeitet das Unternehmen zusammen? Welche Leistung wird bezogen? Welche Systeme, Daten oder Geschäftsprozesse sind betroffen? Welcher Schaden kann bei Ausfall, Angriff oder Pflichtverletzung entstehen? Welche Behandlung ist vor Beginn und während der Zusammenarbeit erforderlich?
Der NIST Cybersecurity Framework 2.0 ordnet Cybersecurity Supply Chain Risk Management der Funktion „Govern“ zu. Die Kategorie GV.SC verlangt unter anderem bekannte und nach Kritikalität priorisierte Lieferanten, vereinbarte Rollen sowie Anforderungen in Verträgen. NIST SP 800-161 Rev. 1 beschreibt dazu einen organisationsweiten, risikobasierten Ansatz für die Identifikation, Bewertung, Behandlung und fortlaufende Beobachtung von Cyberrisiken in der Lieferkette. Diese Veröffentlichungen sind keine deutschen Gesetze, bieten aber eine tragfähige Struktur für interne Programme.
TPRM ist breiter als eine Sicherheitsabfrage beim Einkauf. Es begleitet Auswahl, Onboarding, Betrieb, wesentliche Änderungen, Vorfälle, Vertragsverlängerung und Beendigung. Regulatorische Anforderungen können zusätzliche Kontrollen auslösen. Für nach DORA erfasste Finanzunternehmen ist die Steuerung des IKT-Drittparteirisikos bei bezogenen IKT-Dienstleistungen relevant. Unternehmen im Anwendungsbereich von NIS2 sollten auch die Sicherheit ihrer Lieferkette in das Risikomanagement einbinden.
Der TPRM-Prozess vom Inventar bis zum Offboarding
Am Anfang steht ein zentrales Verzeichnis der Drittparteien. Es sollte Vertragspartner, erbrachte Leistung, internen Eigentümer, Laufzeit, Unterauftragnehmer, Datenarten, Zugriffswege und betroffene Prozesse enthalten. Beschaffungssysteme, Vertragsablagen, Finanzdaten und Identity-Systeme liefern dafür Hinweise. Kein einzelnes System enthält zwangsläufig die benötigten Angaben. Deshalb braucht das Inventar eine verantwortliche Stelle und definierte Aktualisierungsanlässe.
Die Kritikalität bestimmt anschließend die Prüftiefe. Kriterien sind etwa die Bedeutung der unterstützten Leistung, Zugriff auf produktive Systeme, Verarbeitung schutzbedürftiger Daten, Austauschbarkeit, Konzentrationsrisiken und mögliche Auswirkungen eines Ausfalls. Eine kleine Agentur ohne Systemzugriff benötigt meist eine andere Prüfung als ein Cloud-Anbieter, auf dem ein Kernprozess läuft. Die Einstufung sollte vor der Auswahl erfolgen und bei erheblichen Änderungen erneut geprüft werden.
Phase
Kernaufgabe
Typisches Ergebnis
Inventarisierung
Drittpartei, Leistung, Daten und Zugriffe erfassen
Geprüfter Stammdatensatz
Kritikalität
Auswirkung und Abhängigkeit einordnen
Risikoklasse und Prüftiefe
Due Diligence
Kontrollen, Nachweise und Exponierung bewerten
Befunde und Restrisiko
Behandlung
Maßnahmen, Freigaben und Vertragsklauseln festlegen
Akzeptierter Maßnahmenplan
Monitoring
Änderungen, Vorfälle und Fristen beobachten
Aktualisierte Risikobewertung
Offboarding
Zugänge, Daten und Pflichten beenden
Dokumentierter Abschluss
Ein Stage-Gate-Modell verhindert, dass ein kritischer Dienstleister vor Abschluss der vorgesehenen Prüfung produktiv eingesetzt wird. Ausnahmen bleiben möglich, benötigen aber einen benannten Risikoeigentümer, eine Begründung, kompensierende Maßnahmen und ein Ablaufdatum.
Die Risikobehandlung folgt der Bewertung. Vermeidbare Risiken lassen sich durch einen anderen Leistungszuschnitt oder Anbieter reduzieren. Technische und organisatorische Maßnahmen senken Eintrittswahrscheinlichkeit oder Auswirkung. Versicherungen und Vertragsregelungen können bestimmte finanzielle Folgen übertragen, beseitigen aber nicht die operative Abhängigkeit. Ein verbleibendes Restrisiko darf nur die dafür befugte Rolle annehmen. Entscheidung, Annahmezeitraum und Annahmekriterien gehören in die Dokumentation. Wird eine Maßnahme vereinbart, braucht sie einen Eigentümer, eine Frist und einen Nachweis der Umsetzung. Diese Regeln verhindern, dass offene Punkte nach der Beschaffung ohne Steuerung bestehen bleiben.
Due Diligence und technische Datenquellen kombinieren
Due Diligence untersucht verfügbare, für die Entscheidung relevante Informationen über eine Drittpartei und ihre Leistungen. Der NIST Quick-Start Guide SP 1326 nennt für IKT-Lieferanten unter anderem Herkunft und Kontrolle, Resilienz, grundlegende Cyberpraktiken und Ebenen der Lieferkette als Untersuchungsfelder. Für Unternehmen folgt daraus kein starres Standardformular. Die Fragen sollten zur Leistung, Kritikalität und tatsächlichen Zugriffssituation passen.
Selbstauskünfte erklären Prozesse, interne Kontrollen, Wiederanlaufplanung und Zuständigkeiten. Zertifikate und Prüfberichte liefern Nachweise für einen definierten Geltungsbereich und Zeitraum. Verträge zeigen zugesagte Leistungen, Meldewege, Prüfungsrechte und Beendigungsregeln. Interne Daten dokumentieren Vorfälle, Servicequalität und offene Maßnahmen. Öffentliche Quellen können Unternehmensverflechtungen, Sicherheitsmeldungen oder technische Veränderungen sichtbar machen.
Eine externe technische Analyse betrachtet die aus dem Internet erkennbare Angriffsfläche. Sie kann erreichbare Systeme, eingesetzte Software, Konfigurationshinweise und Veränderungen aufzeigen. Ein Security Rating verdichtet ausgewählte Beobachtungen zu nachvollziehbaren Kennzahlen. Diese Außensicht belegt jedoch weder alle internen Kontrollen noch die Wirksamkeit jedes Prozesses. Sie erkennt auch nicht zwangsläufig die konkret verwundbare Version einer Software. Umgekehrt kann ein Fragebogen technische Exponierungen übersehen, die dem Lieferanten selbst nicht bekannt sind.
Eine belastbare Bewertung führt die Quellen zusammen und kennzeichnet Reichweite, Aktualität und Evidenz. Widersprüche lösen eine Klärung aus. Fehlt beispielsweise ein Subdomain-Eintrag im Fragebogen, obwohl er technisch dem Lieferanten zugeordnet werden kann, sollte der Prüfer die Attribuierung bestätigen und den Befund mit der Drittpartei besprechen. Automatische Bewertungen dürfen keine endgültige Freigabeentscheidung vortäuschen.
Rollen und RACI im Third-Party Risk Management
TPRM scheitert häufig nicht an fehlenden Daten, sondern an unklarer Verantwortung. Der Fachbereich kennt Nutzen, Abhängigkeit und operative Auswirkungen. Der Einkauf steuert Auswahl und kommerzielle Vereinbarungen. Informationssicherheit bewertet Cyberrisiken und technische Nachweise. Datenschutz und Recht prüfen ihre jeweiligen Anforderungen. Das Vendor- oder TPRM-Team betreibt Methodik, Plattform, Fristen und Berichterstattung. Die Unternehmensleitung entscheidet über Risiken oberhalb definierter Schwellen.
Eine RACI-Matrix unterscheidet Ausführung, Ergebnisverantwortung, Beratung und Information. Pro Entscheidung sollte nur eine Rolle rechenschaftspflichtig sein. Für die Kritikalität kann der Fachbereich die Angaben liefern, während der Prozesseigentümer des TPRM-Modells die methodische Freigabe verantwortet. Bei einem hohen technischen Risiko führt die Informationssicherheit die Analyse aus; der zuständige Risikoeigentümer entscheidet über Behandlung oder Annahme.
Auch die Drittpartei braucht benannte Ansprechpartner für Sicherheit, Vorfälle und Vertragsfragen. NIST CSF 2.0 empfiehlt, Rollen für Lieferanten, Kunden und Partner intern wie extern zu etablieren und zu koordinieren. Praktisch gehören Eskalationswege, Reaktionszeiten und Informationspflichten in den Vertrag oder eine verbindliche Anlage. Ein gemeinsames Begriffsmodell verhindert, dass „kritisch“ in Einkauf, IT und Risikomanagement verschiedene Bedeutungen hat.
Die RACI-Matrix sollte nicht jede Einzelfrage abbilden. Sie muss die Übergaben sichtbar machen: Wer eröffnet die Prüfung? Wer darf Unterlagen anfordern? Wer bewertet Ausnahmen? Wer verfolgt Maßnahmen? Wer sperrt einen produktiven Zugang beim Offboarding? Wenige klare Entscheidungsrechte sind im Betrieb hilfreicher als eine sehr große Zuständigkeitstabelle.
Vertragsmaßnahmen, Monitoring und Eskalation
Die Due-Diligence-Ergebnisse fließen in risikogerechte Vertragsmaßnahmen ein. Mögliche Themen sind Mindestkontrollen, Meldefristen für Sicherheitsvorfälle, Mitwirkung bei Untersuchungen, Umgang mit Unterauftragnehmern, Nachweise, Prüfungsrechte, Datenrückgabe und Exit-Unterstützung. Welche Klauseln erforderlich und rechtlich geeignet sind, muss die zuständige Rechtsfunktion für den konkreten Vertrag entscheiden.
Nach dem Onboarding verändert sich das Risiko. Neue Domains, Cloud-Dienste, Zertifikate, Softwarekomponenten oder Fehlkonfigurationen können die technische Außensicht verändern. Daneben laufen Nachweise ab, Ansprechpartner wechseln, Leistungen werden erweitert oder Unterauftragnehmer kommen hinzu. Monitoring verbindet deshalb technische Signale mit organisatorischen Ereignissen. Der Rhythmus richtet sich nach Kritikalität und Dynamik: Ein kritischer IKT-Dienstleister verlangt engere Kontrollen als eine Drittpartei ohne Zugriff auf schutzbedürftige Informationen.
Für technische Hinweise sollte der Prozess Schwellen und Eskalationen definieren. Ein neuer Befund wird zunächst attribuiert und auf Relevanz geprüft. Danach folgen Validierung, Rückfrage an die Drittpartei, Maßnahmenfrist und gegebenenfalls die Eskalation an den Risikoeigentümer. Der Third-Party-Risk-Management-Ansatz von LocateRisk unterstützt die fortlaufende externe Beobachtung und KPI-basierte Einordnung. Er ersetzt keine Vertragsprüfung, keine interne Auditierung und keine rechtliche Bewertung.
Geeignete Steuerungskennzahlen messen den Prozess und das Risiko getrennt. Prozesskennzahlen sind etwa der Anteil fristgerecht abgeschlossener Bewertungen, überfällige Maßnahmen oder Drittparteien ohne Eigentümer. Risikokennzahlen zeigen offene hohe Befunde, Konzentrationen oder Trends nach Lieferantengruppe. Ein Durchschnittswert allein kann einzelne kritische Abhängigkeiten verdecken.
Offboarding und kontinuierliche Verbesserung
Die Beendigung einer Geschäftsbeziehung reduziert Risiken nur, wenn operative Verbindungen tatsächlich entfernt werden. Das Offboarding umfasst Konten, API-Schlüssel, VPN-Zugänge, Zertifikate, Datenkopien, Geräte, Weiterleitungen und Einträge in Support- oder Monitoring-Systemen. Der Fachbereich bestätigt das Leistungsende. IT und Identity Management entziehen Zugänge. Datenschutz und Recht prüfen Aufbewahrung, Löschung und fortwirkende Pflichten. Der Einkauf dokumentiert Vertragsende und offene Ansprüche.
Bei kritischen Leistungen sollte eine Exit-Planung bereits vor Vertragsabschluss bestehen. Sie berücksichtigt Datenexport, Übergabe an einen Nachfolger, technische Abhängigkeiten und eine kontrollierte Übergangsphase. Das erleichtert auch die Reaktion, wenn ein Risiko nicht innerhalb der vereinbarten Frist behandelt wird.
Nach Vorfällen, größeren Ausnahmen und wiederkehrenden Verzögerungen folgt eine kurze Ursachenanalyse. Sie prüft, ob Kriterien, Datenquellen, Verträge oder Zuständigkeiten angepasst werden müssen. Ebenso wichtig ist die regelmäßige Bereinigung des Inventars. Dubletten, abgelaufene Verträge und Drittparteien ohne internen Eigentümer verfälschen Kennzahlen und binden Prüfkapazität.
Ein skalierbarer Prozess standardisiert Risikoklassen, Evidenzanforderungen und Entscheidungswege, ohne jeden Lieferanten gleich zu behandeln. Automatisierung kann Daten sammeln, Fristen überwachen und Veränderungen melden. Die risikobezogene Entscheidung bleibt nachvollziehbar bei den zuständigen Rollen. So wird TPRM zu einem Steuerungsprozess, der Beschaffung ermöglicht und Risiken transparent behandelt.
Third-Party Risk Management ist der strukturierte Umgang mit Risiken aus Beziehungen zu Lieferanten, Dienstleistern und anderen externen Parteien. Es umfasst Inventarisierung, Kritikalität, Due Diligence, Risikobehandlung, Monitoring und Offboarding.
Die Begriffe werden häufig ähnlich verwendet. Vendor Risk Management konzentriert sich meist auf Lieferanten. TPRM kann zusätzlich weitere externe Parteien wie Berater, Vertriebspartner oder Betreiber gemeinsamer Prozesse einschließen. Der konkrete Geltungsbereich sollte intern definiert sein.
Geeignet ist eine Kombination aus Stammdaten, Selbstauskunft, Zertifikaten und Prüfberichten, Vertragsinformationen, internen Erfahrungen, Vorfällen sowie externer technischer Beobachtung. Jede Quelle hat eine begrenzte Reichweite und sollte mit Datum und Evidenz dokumentiert werden.
Nein. Ein Security Rating liefert eine skalierbare Außensicht auf ausgewählte technische Signale. Es kann interne Prozesse, Zugriffsmodelle, Vertragsrisiken oder die Wirksamkeit sämtlicher Kontrollen nicht abschließend beurteilen.
Neben einem risikobasierten Regeltermin eignen sich konkrete Auslöser: wesentliche Leistungsänderungen, neue Daten oder Zugriffe, ein Sicherheitsvorfall, neue Unterauftragnehmer, auffällige technische Veränderungen oder eine anstehende Vertragsverlängerung.
Sie möchten die externe Sicherheitslage Ihrer Drittparteien systematisch beobachten und in Ihren bestehenden TPRM-Prozess einbinden? Erfahren Sie mehr über Vendor Risk Management mit LocateRisk.
We use cookies to optimize our website and our service.
Functional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistics
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
Deutsch 
English 
Français