Von Risiko zu Resilienz: Wie TPRM unter DORA neu gedacht wird

Von Risiko zu Resilienz: Wie TPRM unter DORA neu gedacht wird

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:

• Geschäftskritisch (Tier 1): Ausfall gefährdet unmittelbar Kernprozesse, Kundenzugang, Markt-/Stabilitätsfunktionen oder regulatorische Pflichten (z. B. Zahlungsverkehr, Kernbank, Marktinfrastruktur-Konnektoren, E-Geld-Ledger).
• Prozesskritisch (Tier 2): Ausfall führt zu massiven Beeinträchtigungen, aber nicht zum sofortigen Stillstand (z. B. Scoring-Engines, Kundenkommunikationsplattformen, Kartenprozessoren, Identity-Provider).
• Unterstützend (Tier 3): Ausfall beeinträchtigt Effizienz, Reporting, Komfort (z. B. HR-Suite, interne Wissensdatenbank).

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:

• Meldepflichten: Erstmeldung binnen Stunden; Mindestinhalte (IoCs, betroffene Services/Kundenregionen, Erstursache, erste Maßnahmen); Intervall für Updates; dedizierte Kontakte 24/7.
• Security- & Audit-Zugriff: Maschinelles Audit-Log-Interface, Admin-Event-Feeds, forensische Zusammenarbeit, Penetrationstest-Zusammenfassungen, SBOM-Bereitstellung bei Releases.
• Resilienz-Kennzahlen: Verfügbarkeitsziel und DoS-Robustheit, RTO/RPO je Funktion/Region; commitete Testfenster und Begrenzungen geplanter Downtime.
• Fourth-Party-Transparenz: Vorab-Info über Subprozessoren/Regionen; Widerspruchsrecht oder Kompensationsmaßnahmen; gleichwertige Pflichten in der Kette.
• Exit/Portabilität: Exportformate (maschinenlesbar, dokumentiert), maximale Lieferzeiten, kostenfreie Löschbestätigung, technische Unterstützung bei Migration; Probetest als Voraussetzung für Go-Live in Tier-1.
• KI-/Datenklauseln: Verbot der Trainingsnutzung sensibler Daten; Retention-Grenzen, Support-Zugriffskontrolle, Protokollierung, Löschpfad inklusive Subprozessoren.

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:

• SBOM (Software Bill of Materials): Welche Bibliotheken/Versionen stecken im Produkt? Welche bekannten Schwachstellen existieren? Gibt es Signaturen/Attestierungen (z. B. SLSA, Sigstore)?
• DBOM (Data Bill of Materials): Welche Datenklassen fließen wohin? Welche Retention/Regionen? Welche Zwecke? Welche Kopien entstehen?
• Identity Map: Welche externen Identitäten (Personen, Service-Accounts) besitzen welche Rechte in Ihren Systemen? Gibt es Just-in-Time (JIT), Just-Enough-Access (JEA), Ablaufdaten, Geräte- und Standortauflagen?

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:

• Identität vor Netzwerk: Externe Zugriffe stets über SSO, starke MFA, Conditional Access (Geräte-Compliance, Geolokation, Risiko).
• JIT/JEA & PAM: Privilegierte Aktionen über Privileged Access Management, zeitlich eng befristet, aufgezeichnet, approbiert. Dauerhafte Admin-Konten: nein.
• Segmentierung: Integrations-/Partner-Zonen isolieren; Ost-West-Traffic minimieren; Egress-Kontrolle auf Modell-/API-Ziele (bei KI/Externen).
• API-/KI-Gateways: Zentraler Ausleitpunkt mit PII-Maskierung, Prompt-/Payload-Policies, Ratenbegrenzung, Schlüsselverwaltung pro Team, Observability.
• Signierte Lieferkette: Reproduzierbare Builds, Cosign/Sigstore, SLSA-Level, Release-Policies; Verifikation in der Pipeline.
• Telemetry by Design: Admin-Events, Konfig-Drift, OAuth-App-Zulassungen, Token-Nutzung – alles maschinell auswertbar.
• Backups providerunabhängig: Exporte in kontrollierte Speicher, regelmäßige Restore-Tests, kryptografische Integritätschecks.

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:

• Verfügbarkeits-Ist vs. SLA je kritischem Service, inkl. Mean Time to Detect/Recover (externer und eigener Anteil).
• Third-Party Admin-Events: # privilegierter Aktionen, Zeitpunkte außerhalb Wartungsfenster, JIT-Quote (vs. Dauerkonten = 0).
• OAuth-Hygiene: # Apps mit breiten Scopes, nicht genehmigte Apps, Token-Lebensdauern, Rotationsquote.
• SBOM-Gesundheit: Anteil kritischer Komponenten mit offenen CVEs, Mean Time to Mitigate, Attestierungsgrad.
• Fourth-Party-Drift: Abweichungen zwischen vertraglich zugesagten und tatsächlich genutzten Regionen/Subprozessoren.
• Incident-Metriken: Time-to-Inform (Anbieter→Sie), Time-to-Contain (Sie intern), Konsistenz der Root-Cause-Berichte, implementierte Maßnahmen.
• Exit-Fähigkeit: Zeit bis vollständiger Export, Testhäufigkeit, „Readiness-Score“ für Alternativpfade.
• Datenfluss-Compliance: Treffer von Maskierung/Policy am Gateway, Anteil blockierter vs. umgeleiteter Anfragen.

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.

• Failover-Drills: Nachweis, dass Umschalten in die Sekundärregion klappt – mit Zeitstempel, Datenkonsistenz, Geschäftsprozess-Validierung.
• Restore-Proben: Stichprobenhaftes Wiederherstellen von Datensätzen/Systemzuständen aus Off-Provider-Backups.
• Tabletop-Szenarien: „Provider down 48h“, „bösartiges Update rollt aus“, „OAuth-App kompromittiert“ – mit klaren Rollen, Kommunikationslinien, Entscheidungspunkten.
• Threat-led Exercises (TLPT-Anleihen): Realistische Kill-Chains gegen Integrationspfade (Phishing MSP, Token-Theft, Supply-Chain-Injection) – abgestimmt, kontrolliert, dokumentiert.
• Exit-Proben: Echte Teilmigration inkl. Format/Mapping, Daten-Integrität, Deadlines, Rückfallebene.

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:

• Trigger & Klassifikation: Wann wird ein Anbieter-Ereignis für Sie meldepflichtig/öffentlichkeitsrelevant?
• Informationskanäle: Direkte 24/7-Kontakte, maschinelle Feeds, Fallback-Kanäle, Eskalationsmatrix.
• Sofortmaßnahmen: Zugriff entziehen, Token widerrufen, Gateways restriktiver, Segment isolieren, Kundenzugänge temporär begrenzen – vordefiniert je Risikotyp.
• Forensik & Evidenz: Welche Logs, Snapshots, Artefakte sichern Sie – und welche muss der Anbieter liefern?
• Kommunikation: Vorlagen für Kunden, Presse, Aufsicht; Fakten vor Spekulation; Zeitfenster für Updates.
• Lessons Learned: Fixes, Vertragsnachschärfung, Monitoring-Erweiterung, zusätzliche Tests – nachweisbar abgeschlossen.

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:

• Rollen & Gremien
  • Service Owner (fachlich): Kritikalität, Anforderungen, Abnahme von Tests, Exit-Plan.
  • Supplier Owner / Vendor Manager: Vertrag, Performance, Eskalation, Kosten/Nutzen.
  • TPRM/Resilience Office: Methodik, Metriken, Konsolidierung, DORA-Schnittstelle.
  • Security/IT-Risk: Technische Leitplanken, Monitoring, Tests, Incidents, Architektur.
  • Compliance/Legal: Klauseln, Meldepflichten, Datenschutz, Aufsichts-Interaktion.
  • Krisenstab: Übt, entscheidet, kommuniziert.
• Artefakte & Taktungen
  • Quartalsweiser Resilienz-Report der kritischen Services.
  • Halbjährliche Rezertifizierung der Tier-1-Anbieter.
  • Jährliche Exit-Probe je Top-Pfad (auch Teilmengen).
  • Kontinuierliche Metriken ins Management-Dashboard.
• Tooling
  • Lieferanten-Register mit Subprozessoren/Regionen.
  • Vertrags-/Klauselbiblio­thek (Standard-Addenda).
  • Integrations-CMDB (Flows, OAuths, Webhooks, Secrets).
  • SIEM-/SOAR-Use-Cases speziell für Drittanbieter-Signale.
  • AI/API-Gateway für Egress-Kontrolle und Observability.

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

• Zertifikats-Glaube: ISO-Logo ersetzt keine Resilienz-Nachweise, keine Logs, keine Proben.
• Einmal-Fragebogen: 200 Fragen, 0 Wirkung – ohne Validierung und Folgemaßnahmen wertlos.
• Dauerhafte Vollrechte: „Weil es sonst nicht geht“ – doch, es geht: JIT, JEA, PAM.
• Schatten-Integrationen: OAuth-Apps mit Full-Access, unkontrollierte Webhooks, „Test-Keys“ in Produktion.
• Exit nur auf Papier: Kein Export getestet, keine Schnittstelle dokumentiert, keine Fristen – Ausfall garantiert teuer.
• Multi-Alles ohne Governance: Multi-Cloud, Multi-CDN, Multi-MSP – und Null Konsistenz. Komplexität frisst Resilienz, wenn Führung fehlt.
• „No-Log“-Marketing: Ohne Audit-Zugriff und verifizierbare Zusagen irrelevant.

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:

• Ja, so statt „Nein“ – freigegebene Pfade, die funktionieren.
• Transparenz: Warum fragen wir was? Was tun wir mit den Daten? Wie messen wir Nutzen?
• Anerkennung: Teams, die Schwachstellen melden, Integrationen anmelden, Proben meistern, gehören gelobt – nicht verwarnt.

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.