Third Party Risk Management für ausgelagerte Software
Third Party Risk Management statt Einmalprüfung
Hinter dem englischen Begriff steckt die Idee, Risiken aus der Arbeit von Dienstleistern so zu steuern wie eigene Risiken, dauerhaft und nicht nur beim Einkauf.
Third Party Risk Management (TPRM) bezeichnet die fortlaufende Steuerung der Risiken, die aus der Zusammenarbeit mit externen Anbietern entstehen. Dazu gehören die Einstufung jedes Anbieters nach Zugriff und Kritikalität, die Prüfung vor der Beauftragung, die Überwachung während der Laufzeit, die Kontrolle von Unterauftragnehmern und eine geplante Beendigung.
Nur bei 14,3 Prozent von 500 befragten IT-Verantwortlichen sind die neuen gesetzlichen Pflichten zu Risikomanagement und Cybersicherheit vollständig umgesetzt, so eine Umfrage von TÜV Rheinland vom Juni 2026. Die Steuerung der Dienstleister gehört zu diesen Pflichten.
Welche Dienstleister fallen unter § 30 BSIG?
Nach § 30 Abs. 2 Nr. 4 BSIG gehört zu den Risikomanagementmaßnahmen die Sicherheit der Lieferkette, einschließlich der sicherheitsbezogenen Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern. Das BSI nennt ausdrücklich Outsourcing-Partner, Dienstleister sowie Hard- und Softwarezulieferer. Anders als die Lieferketten-Souveränität für KRITIS, die Ersatzteile, Rechenzentren und Zweitlieferanten gemeinsam betrachtet, geht es beim Third Party Risk Management um den einzelnen Vertragspartner. Nr. 5 derselben Vorschrift ergänzt Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von IT-Systemen samt Umgang mit Schwachstellen. Beide Pflichten aus § 30 BSIG treffen sich beim Dienstleister, der eine Anwendung erst entwickelt und später wartet. Wie weit sie reichen, wenn dieser Dienstleister selbst wieder Aufträge vergibt, ist die schwierigste Frage des Themas und steht im Abschnitt über Unterauftragnehmer.
Prüftiefe nach Zugriff statt nach Einkaufsvolumen
Nicht jeder Anbieter braucht dieselbe Prüfung, und das Einkaufsvolumen ist dafür ein schlechter Maßstab. Im Third Party Risk Management zählt, was ein Dienstleister im Ernstfall anrichten kann, also welchen Zugriff er hat und wie kritisch der ausgelagerte Prozess ist. Der IT-Grundschutz des BSI verlangt deshalb im Baustein OPS.2.3 eine Risikoanalyse Auslagerung für Auslagerung, die regelmäßig und anlassbezogen wiederholt wird.
Produktivzugriff verlangt eine andere Prüfung
Ein Wartungsvertrag über eine Fachanwendung ist aus Sicht der Einrichtung ein Zugang zu den eigenen Systemen. Einen Lieferanten mit Systemzugriff absichern heißt deshalb zuerst, ihn richtig einzustufen. Der Dienstleister mit Produktivzugriff steht damit ganz oben in der Lieferanten-Risikobewertung, auch wenn sein Vertrag kleiner ist als der eines Hardwarelieferanten. Aus derselben Überlegung folgt die Nähe zur digitalen Souveränität, denn wer den Zugang hält, entscheidet mit über Wartung und Ersatz. Die folgende Übersicht zeigt eine mögliche Staffelung der Prüftiefe nach Art des Zugriffs.
| Zugriff | Beispiel | Prüftiefe |
|---|---|---|
| Produktivzugriff | Wartung, Betrieb, Hosting | laufende Nachweise |
| Entwicklung ohne Betrieb | Code, Schnittstellen | Prüfung vor Freigabe |
| Kein Systemzugriff | Beratung, Schulung | Selbstauskunft genügt |
Ein Anbieter ohne Systemzugriff, der aber einen kritischen Prozess allein trägt, rückt in der Lieferanten-Risikobewertung trotzdem eine Stufe höher.
Reicht das ISO-27001-Zertifikat des Dienstleisters?
Ein Zertifikat ist ein guter Anfang und selten der ganze Beleg. Eine ISO-27001-Zertifizierung bestätigt ein Managementsystem für Informationssicherheit, aber nur für den Bereich, den der Geltungsbereich beschreibt. Deckt dieser Bereich die ausgelagerte Leistung nicht ab, belegt das Zertifikat für diesen Vertrag nichts. Der Geltungsbereich hält fest, welche Tätigkeiten und Standorte geprüft wurden. Die Erklärung zur Anwendbarkeit listet dazu, welche Maßnahmen aus dem Anhang der Norm umgesetzt und welche begründet ausgeschlossen sind. Vor der Freigabe helfen vier Prüffragen.
❓ Nennt der Geltungsbereich Entwicklung, Hosting oder Wartung ausdrücklich?
❓ Welche Stelle hat zertifiziert, und bis wann gilt das Zertifikat?
❓ Welche Maßnahmen schließt die Erklärung zur Anwendbarkeit aus?
❓ Sind die Standorte erfasst, von denen aus gearbeitet wird?
Lieferantenselbstauskunft und Fragebogen gezielt nutzen
Eine Lieferantenselbstauskunft ergänzt das Zertifikat dort, wo es schweigt. Ein langer Lieferantenfragebogen erzeugt viele Antworten, doch nur die ausgewerteten senken ein Risiko. Für das Third Party Risk Management reichen deshalb wenige Fragen, die sich aus der Risikoeinstufung ergeben, etwa zu Patchzeiten, Protokollierung und Unterauftragnehmern. Eine belastbare Lieferantenqualifizierung für IT-Dienstleister benennt außerdem die Belege, die vor der Freigabe vorliegen müssen. Die Einrichtung muss diese Unterlagen vom Softwaredienstleister anfordern und festlegen, wer sie prüft. Welche Belege das im Einzelnen sind, folgt aus den Nachweis- und Dokumentationspflichten der eigenen IT-Compliance.
Supply Chain Risk Management hinter dem Dienstleister
Mit der Freigabe ist ein Dienstleister geprüft, aber noch nicht gesteuert. Supply Chain Risk Management bedeutet hier, zwischen zwei Prüfungen zu erkennen, ob sich die Lage bei einem Dienstleister verändert, und über ihn hinaus in die Kette zu sehen. OPS.2.3 verlangt dafür regelmäßige und anlassbezogene Prüfungen der Anbieter sowie ein zentrales Register aller Auslagerungen.
Nachweise, die zwischen zwei Prüfungen fließen
Ein jährlicher Fragebogen zeigt den Stand eines Tages. Einen Softwarelieferanten regelmäßig überprüfen heißt im Third Party Risk Management deshalb vor allem, laufende Nachweise zu bekommen, die beim Dienstleister in einem geordneten Betrieb ohnehin entstehen. Welche davon geliefert werden, regelt die Vereinbarung.
- Patch- und Updatezeiten gegen die vereinbarten Fristen
- Reaktionszeiten bei Störungen und Sicherheitsvorfällen
- Protokolle über Zugriffe auf Produktivsysteme
- Wechsel beim Personal mit Systemzugriff
- Ergebnisse eigener Sicherheitsprüfungen des Dienstleisters
- Änderungen an der Liste der Unterauftragnehmer
Reaktions- und Patchzeiten lassen sich nur prüfen, wenn sie messbar vereinbart sind. Die Grundlage dafür ist ein Service Level Agreement, das Zeiten, Messpunkte und Berichtsweg festlegt. So wird aus dem Third Party Risk Management eine Messung und keine Vertrauensfrage.
Unterauftragnehmer sichtbar halten
Rechenzentrum, Monitoring, Backup oder Spezialentwicklung können bei einem Softwaredienstleister von weiteren Firmen kommen, die im Vertrag der Einrichtung gar nicht auftauchen. OPS.2.3 verlangt in den Grundanforderungen an Outsourcing-Verträge deshalb einen Zustimmungsvorbehalt bei Weiterverlagerungen sowie ein Recht auf Prüfung, Revision und Audit. Ein Auditrecht im Vertrag vereinbaren und die Weitergabe von Aufträgen an eine Zustimmung binden, das sind die beiden Hebel, mit denen Supply Chain Risk Management über die erste Vertragsgrenze hinausreicht. Die Liste der Unterauftragnehmer mit Leistung und Verarbeitungsort gehört zu den Vertragsunterlagen, und jede Änderung löst eine neue Bewertung aus. Ohne diese Liste endet die Sicht beim ersten Vertragspartner.
Das Auslagerungsregister als Arbeitsinstrument
Das Auslagerungsregister ist der Ort, an dem Einstufung, Verträge und Prüfergebnisse zusammenlaufen. Geführt wird es von der zuständigen Person für das Auslagerungsmanagement. OPS.2.3 nennt dafür konkrete Inhalte.
- Angaben zu den Anbietern
- Leistungskennzahlen der ausgelagerten Leistung
- Kritikalität des ausgelagerten Prozesses
- abgeschlossene Verträge und Vereinbarungen
- nachgehaltene Änderungen
Im Einkauf trägt dieselbe Aufgabe auch den Namen Vendor Management, im Third Party Risk Management ist das Register zugleich Beleg. Aus dem Register entstehen außerdem die Auslagerungsberichte, die OPS.2.3 regelmäßig für die Leitung vorsieht. Für das Supply Chain Risk Management steht im Register auch, welche Unterauftragnehmer hinter jedem Eintrag arbeiten.
Third Party Risk Management braucht Verantwortung
Supply Chain Risk Management und die Steuerung einzelner Dienstleister funktionieren nur mit einer benannten Zuständigkeit und mit einem Plan für das Ende der Zusammenarbeit. Rechtslage und IT-Grundschutz legen die Verantwortung dabei auf die Leitungsebene und verlangen Handlungsalternativen für eine geplante oder ungeplante Beendigung.
Wer das Auslagerungsmanagement verantwortet
Nach § 38 BSIG setzt die Geschäftsleitung die Risikomanagementmaßnahmen aus § 30 um, überwacht ihre Umsetzung und haftet bei schuldhafter Verletzung dieser Pflichten. Das Auslagerungsmanagement selbst legt OPS.2.3 in die Hände einer zuständigen Person mit festgelegten Befugnissen. Sie ist Schnittstelle zum Dienstleister, wird bei der Vertragsgestaltung einbezogen und berichtet regelmäßig an die Leitung. Der Informationssicherheitsbeauftragte gehört in jede strategische Entscheidung, der Einkauf in die Qualifizierung. Das Management von Drittparteirisiken ist damit eine Führungsaufgabe mit operativer Zuständigkeit, keine reine Einkaufsfrage.
Auslagerungsmanagement plant die Beendigung mit
Für die geplante wie die ungeplante Beendigung einer Auslagerung verlangt OPS.2.3 Regelungen zur Rückgabe von Daten und zum Entzug von Zugriffsrechten, dazu Handlungsalternativen und geeignete Ersatzanbieter. Ob die Rückgabe gelingt, hängt an der Datenportabilität, also an Exportformaten und offenen Schnittstellen. Für das Third Party Risk Management ist ein Dienstleister, dessen Code, Dokumentation und Betriebswissen sich nicht übergeben lassen, ein Risiko, das keine Prüfung senkt. Bei Individualsoftware wiegt das schwerer, weil kein zweiter Anbieter dasselbe Produkt liefert. Die Maßnahmen dagegen, etwa Code-Eigentum und offene Standards, sind dieselben, mit denen sich ein Vendor Lock-in vermeiden lässt.
Übergabefähigkeit gehört in die Einstufung
Ob sich eine Leistung geordnet zurückholen oder an einen anderen Anbieter geben lässt, gehört deshalb schon in die Einstufung, nicht erst in die Kündigung. Dazu zählen ein aktueller Stand der Dokumentation, der Zugang zum Quellcode und ein Übergabeplan mit Zuständigkeiten und Fristen. Erst damit lässt sich ein Lieferant mit Systemzugriff absichern, auch über das Vertragsende hinaus.
TenMedia steht in dieser Kette selbst als Dienstleister und liefert die Nachweise, die ein Risikomanagement für Drittparteien braucht. Die Zertifizierung nach ISO/IEC 27001:2022 durch TÜV SÜD nennt im Geltungsbereich Entwicklung von Individualsoftware sowie Hosting und Maintenance von Cloud-Anwendungen. Zum Auftragsverarbeitungsvertrag gehört eine Liste der Subunternehmer, und Updates sowie Sicherheitspatches laufen im Betrieb für den gesamten Stack. Ein Beispiel ist die Übernahme und Betreuung einer hochverfügbaren Plattform, seit 2022 im laufenden Betrieb.
Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.
