Third-Party-Risk-Management (TPRM) galt lange als Pflichtfach: Fragebogen verschicken, Zertifikate einsammeln, Auditberichte abheften – fertig. Spätestens mit dem Digital Operational Resilience Act (DORA) ist dieses Verständnis Geschichte. TPRM wird vom statischen Kontrollpunkt zum dynamischen Kern der digitalen Widerstandsfähigkeit. Nicht mehr das „Ob“ einer Maßnahme zählt, sondern das „Hält es im Ernstfall?“. Governance rückt damit näher an den operativen Puls; Lieferantenbeziehungen werden zu gemeinsam verantworteten Resilienz-Systemen – gemessen, getestet, nachweisbar.

Dieser Beitrag zeigt, wie sich TPRM unter DORA grundlegend verschiebt: weg von Dokumentation, hin zu belastbarer Operations-Resilienz. Er ordnet die neuen Erwartungen, skizziert ein modernes Operating Model, gibt konkrete Leitplanken für Verträge, Technik und Monitoring – und benennt Anti-Patterns, die heute noch zu häufig zu sehen sind.

1. Die Verschiebung: Von der Checkliste zur Funktionssicherheit

Klassisches TPRM beantwortete drei Fragen: Hat der Anbieter Policies? Ist er zertifiziert? Gibt es ein Audit? DORA dreht die Perspektive: Kann der Anbieter störungsrobust liefern, wenn es darauf ankommt – und können Sie das auch belegen? Daraus leiten sich fünf Konsequenzen ab:

  1. Resilienz statt Formalismus: Nachweise ohne Funktionsbezug reichen nicht. Gefordert sind wirksame Notfallpläne, getestete Wiederanlaufzeiten, klare Kommunikationswege, geübte Eskalationen und belegbare Leistungswerte unter Stress.
  2. Kontinuität statt Stichtag: Einmalige Due-Diligence verliert ihren Wert nach Wochen. DORA denkt in laufendem Monitoring, regelmäßigen Reviews, Roll-ups über kritische Ketten und gelebten Lessons Learned.
  3. Systemische Sicht: Nicht nur Ihr direkter Anbieter zählt, sondern die Kette – Subdienstleister (Fourth Parties), vorgelagerte Plattformen, geteilte Infrastrukturen. Transparenz über diese Ebenen wird Pflicht.
  4. Eigenverantwortung: Auslagerung entbindet nicht. Verantwortung bleibt beim Institut. Verträge helfen, tragen aber nur, wenn Sie Ihre Rechte aktiv nutzen und technisch unterfüttern.
  5. Proportionalität mit Tiefgang: Ja, Maßnahmen müssen zum Risiko passen. Aber „proportional“ heißt nicht „weniger“, sondern gezielter: je kritischer die Funktion, desto dichter das Kontrollnetz – fachlich, technisch, organisatorisch.

2. Kritikalität verstehen: Funktionen statt Lieferanten etikettieren

DORA verlangt, dass Institute den Kritikalitätsgrad ausgelagerter IKT-Services bestimmen. Der Fehler passiert oft am Start: Man klassifiziert Anbieter, nicht Funktionen. Besser ist eine funktionsbasierte Taxonomie:

Diese Einstufung verknüpfen Sie mit Impact-Parametern (RTO/RPO-Ziele, regulatorische Zeitvorgaben, Kundenauswirkungsgrade) und Privilegienprofilen (Datenklassen, Systemzugriffe, Adminrechte). Ergebnis ist eine Kritikalitätsmatrix, die steuert, wie tief Sie prüfen, wie oft Sie testen und welche Vertragsklauseln obligatorisch sind.

Tipp: Klassifizieren Sie Services je Mandant/Use Case, nicht den „gesamten Anbieter“. Ein Cloud-Provider kann für Workload A Tier-1 und für Workload B Tier-3 sein.

3. Der Lebenszyklus: Vom Screening zur belegten Wiederanlauffähigkeit

Ein DORA-fähiges TPRM deckt den gesamten Service-Lifecycle ab – mit klaren Artefakten:

  1. Sourcing & Screening
    • Minimalanforderungen (Security, Resilienz, Rechtsraum, Subprozessoren, Exit-Fähigkeit).
    • Vorab-SBOM/DBOM-Verfügbarkeit (Software/Data Bill of Materials) für relevante Komponenten und Datenflüsse.
    • Architekturskizze mit Redundanzpfaden, Regionentopologie, Abhängigkeiten.
  2. Due Diligence
    • Prüfberichte (nicht nur Zertifikatslogos), Pentest-Zusammenfassungen, BC/DR-Konzepte inkl. Testprotokolle.
    • Ereignis-Historie (Incidents, Root-Cause, Remediation), Metriken (Verfügbarkeit, Mean Time to Detect/Recover).
    • Rechts-/Compliance-Klarheit: Datenstandorte, Subprozessoren, Lösch- und Meldepflichten.
  3. Vertrag & Onboarding
    • Resilienz-SLAs (RTO/RPO, DR-Fenster, Kommunikationsfristen) mit Sanktionslogik.
    • Rechte: Security-Logs, Audit-Feeds, Forensik-Support, vorab vereinbarte Templates für Meldungen.
    • Exit-/Portabilitäts-Paket: Formate, Fristen, Supportumfang, Migrationstests.
  4. Betrieb & Monitoring
    • Technische Feeds (Admin-Events, Security-Events, Verfügbarkeits-Streams), OAuth/Token-Telemetrie.
    • KPI/KRI-Dashboard je Tier, Eskalationsschwellen, Change-Notices (Sicherheitsprofiländerungen).
    • Rezertifizierung und Fourth-Party-Überblick (Kettenänderungen).
  5. Test & Validierung
    • Funktionsfähige Failover-Drills, Restore-Tests, Tabletop-Übungen gemeinsam mit dem Anbieter.
    • Threat-led-Tests (TLPT-Anleihen) für Tier-1-Services: realitätsnahe Angriffsszenarien mit Nachweis der Verteidigungs- und Wiederanlaufleistung.
  6. Exit & Migration
    • Geprobter Datenexport, Vollständigkeitscheck, Integritätsprüfungen, Abschaltungspfad inkl. Lösch-Nachweisen.
    • Rückfalloptionen oder Warm-Standby bei hochkritischen Pfaden.

4. Verträge, die im Ernstfall tragen

Papier schützt nicht vor Ausfällen – aber Papier entscheidet, ob Sie handlungsfähig sind. Vertragsklauseln, die unter DORA den Unterschied machen:

Achten Sie auf Durchgriffsfähigkeit: Klauseln, die an „Best Effort“ hängen, lassen Sie im Regen stehen. Wo messbar, numerisch; wo kritisch, Nachweise.

5. Transparenz über die Kette: SBOM, DBOM, Identitäten

DORA fordert Nachweisfähigkeit über Abhängigkeiten. Drei Objekte helfen, die Kette sichtbar zu machen:

Diese Artefakte verbinden Verträge mit Technik – und machen Drift erkennbar (z. B. neue Subprozessoren, neue Bibliotheken, geänderte Token-Scopes), bevor sie schaden.

6. Technische Leitplanken: Zero Trust für Dritte

Resilienz entsteht nicht allein aus Dokumenten. Ein DORA-festes TPRM braucht architektonische Leitplanken:

7. Monitoring, das zählt: Von Indikatoren zu Interventionen

Ein TPRM-Dashboard, das DORA-Prüfungen besteht, zeigt nicht nur Status, sondern Steuerung. Wichtige KPIs/KRIs:

Metriken ohne Schwellenwerte sind Folklore. Jede Kennzahl braucht Zielwert, Owner, Eskalationsweg, und sie muss in Maßnahmen münden (z. B. Rezertifizierung forcieren, Anbieter in „Enhanced Monitoring“, Wechsel vorbereiten).

8. Testen statt vermuten: Resilienzübungen mit und bei Dritten

DORA betont Resilienzübungen. Für TPRM gilt: Mit dem Anbieter testen, nicht nur über ihn reden.

Das Ergebnis ist nicht „bestanden/nicht bestanden“, sondern ein Verbesserungsplan mit Terminen, Verantwortlichen und Nachweisen.

9. Incident-Fähigkeit: Wenn der Dienstleister brennt, müssen Sie handeln

Vorfälle bei Dritten sind Ihre Vorfälle – in der Kommunikation, in den Meldepflichten, in der Kundenwirkung. Ein TPRM-fähiges Incident-Playbook enthält:

10. Operating Model: Wer führt, gewinnt

TPRM unter DORA ist quer: Einkauf, IT, Security, Compliance, Fachbereiche, Recht, Betriebsführung. Ohne eindeutige Verantwortung versickern Maßnahmen. Ein tragfähiges Operating Model:

11. Anti-Patterns: Wenn „proportional“ zur Ausrede wird

12. Praktische Szenarien – und was sie lehren

A) Manipuliertes Update in der Lieferkette
Ein Release enthält kompromittierte Bibliotheken. SBOM-Validierung erkennt die Divergenz, Pipeline stoppt Rollout. Resilienz-Muster: Signaturprüfung, Policy-Gates, SBOM-Check, Canary-Rollouts.

B) MSP-Konto kompromittiert
Angreifer nutzen RMM-Zugänge. PAM erzwingt JIT; außerhalb der Wartungsfenster schlägt SIEM Alarm; Zugriffe werden automatisiert entzogen; betroffene Segmente isoliert. Lehre: Identität, Zeit, Kontext.

C) SaaS-Ausfall 48 Stunden
CRM down. Notfall-Modus greift: Export-Cache wird schreibgeschützt bereitgestellt, Minimalprozesse auf CSV, manuelle Workarounds aktiviert, Kundenkommunikation klar. Wiederanlauf mit Delta-Sync. Lehre: Betrieb auf Sicht ist gestaltbar – aber nur, wenn geübt.

13. Kultur: Zusammenarbeit statt Gegenseite

TPRM wird oft als „wir gegen die Anbieter“ wahrgenommen. Erfolgreich ist das Gegenteil: kooperative Resilienz. Gute Anbieter begrüßen klare Leitplanken, definierte Meldewege, sauber vereinbarte Tests – es macht auch ihre Welt stabiler. Intern gilt: Governance muss benutzbar sein. Wer nur bremst, bekommt Schatten-Wege. Wer ermöglicht, bekommt Einhaltung.

Das bedeutet:

14. Zusammengeführt: Das Resilienz-Framework für TPRM

Am Ende lässt sich der DORA-Gedanke in ein kompaktes Rahmenwerk gießen:

  1. Erkennen: Kritische Funktionen, Abhängigkeiten, Datenflüsse, Identitäten – sichtbar, versioniert, überprüfbar.
  2. Begrenzen: Rechte, Reichweiten, Retention, Regionen – minimal und messbar.
  3. Absichern: Verträge + Technik + Prozesse – kohärent, durchsetzbar, testbar.
  4. Überwachen: Telemetrie, Metriken, Drifts – in Echtzeit, mit Eskalation.
  5. Erproben: Failover, Restore, Threat-Szenarien, Exit – dokumentiert, wiederholt, verbessert.
  6. Erholen: Klarer Betrieb auf Sicht, Kommunikations-Routinen, schnelle Rückführung.
  7. Lernen: Lessons Learned in Design, Vertrag, Technik und Kultur verankern.

Diese sieben Schritte sind kein Projektplan, sondern ein Dauerzustand – die Arbeitsweise reifer TPRM-Organisationen. Wer sie etabliert, erfüllt DORA nicht nur, sondern gewinnt: weniger Blindflug, schnellere Reaktion, messbare Handlungsfähigkeit. Das ist Resilienz – nicht versprochen, sondern bewiesen.

Fazit: TPRM wird zum Resilienz-Motor

DORA macht TPRM erwachsen. Weg vom Fragebogen-Theater, hin zum Lackmustest: Hält der Dienst – und halten wir – wenn es wirklich zählt? Die Antwort entscheidet über mehr als Compliance. Sie entscheidet über Vertrauen am Markt, über Reputation, über betriebliche Kontinuität und strategische Freiheit.

Wer TPRM als Resilienz-Motor begreift, führt nicht nur Lieferanten, sondern die eigene Organisation: mit Klarheit über Kritikalität, mit Verträgen, die tragen, mit Technik, die begrenzt und beobachtet, mit Tests, die überzeugen, und mit einer Kultur, die ermöglicht statt verhindert. So wird aus „Risiko managen“ Resilienz gestalten – genau der Schritt, den DORA verlangt und den starke Institute jetzt gehen.