Lieferanten unter der Lupe – Third-Party-Risiken smart managen

Lieferanten unter der Lupe – Third-Party-Risiken smart managen

Die Digitalisierung der Finanzwelt hat in den letzten Jahren einen klaren Trend hervorgebracht: Immer mehr Leistungen werden an externe Partner ausgelagert. Cloud-Computing, spezialisierte IT-Dienstleister, externe Rechenzentren, Software-as-a-Service-Lösungen oder Managed Security Services – kaum ein Finanzunternehmen betreibt heute noch seine gesamte IT selbst. Diese Entwicklung hat enorme Vorteile: schnellere Innovation, flexiblere Skalierung, Zugang zu Spezialwissen und oft auch Kostenvorteile. Doch sie hat eine Schattenseite, die spätestens mit dem Inkrafttreten von DORA in den Mittelpunkt rückt: Die Abhängigkeit von Drittanbietern kann zur Achillesferse werden, wenn Risiken nicht konsequent gemanagt werden. DORA macht deshalb das Management von IKT-Drittparteien zu einer eigenen Säule der digitalen Resilienz – mit klaren Vorgaben, die deutlich über das hinausgehen, was bisher viele Unternehmen praktiziert haben.

Der Grundsatz: Auslagerung hebt Verantwortung nicht auf

Der Kern der DORA-Vorgaben ist einfach: Unternehmen bleiben auch dann vollständig verantwortlich, wenn sie kritische Funktionen an externe Partner auslagern. Es gibt kein „Das macht unser Dienstleister, darum kümmern wir uns nicht“ mehr. Vielmehr muss jedes Unternehmen sicherstellen, dass auch ausgelagerte Services den gleichen Resilienz- und Sicherheitsstandards entsprechen wie interne Leistungen. Das bedeutet, dass die Auswahl, Überwachung und vertragliche Absicherung von Drittanbietern einen zentralen Platz im Risikomanagement bekommt. Schon vor Vertragsabschluss muss geprüft werden, ob ein Anbieter die technischen, organisatorischen und finanziellen Voraussetzungen erfüllt, um die ausgelagerten Leistungen sicher und stabil zu erbringen. Diese Prüfung ist keine reine Formalität, sondern muss dokumentiert, nachvollziehbar und auf die kritischen Funktionen des Unternehmens zugeschnitten sein.

Begriffsklärung: Drittparteien, Viertparteien, Konzentrations- und Systemrisiko

Unter „Drittpartei“ (Third Party) versteht DORA IKT-Dienstleister, die Funktionen, Prozesse oder Systeme unterstützen oder betreiben. „Viertparteien“ (Fourth Parties) sind die Sub-Dienstleister Ihrer Dienstleister – häufig Cloud-Infrastrukturen, Identitäts-Provider, Rechenzentrumsanbieter, CDN-Netze oder spezialisierte Nischenservices. Ein zentrales Thema sind Konzentrationsrisiken: Wenn viele kritische Prozesse an wenige große Anbieter gebunden sind, entsteht ein systemisches Risiko – fällt der Anbieter aus oder ändert Bedingungen, betrifft das gleichzeitig eine Vielzahl von Finanzunternehmen. DORA adressiert das doppelt: Unternehmen müssen ihre eigene Abhängigkeit managen, und besonders bedeutende IKT-Drittparteien kommen zusätzlich unter direkte Aufsicht europäischer Behörden.

Operating Model: Interdisziplinär statt Silodenken

Third-Party-Risikomanagement (TPRM) unter DORA ist ein Teamsport: Einkauf (kommerziell), IT/Architektur (Technik), Informationssicherheit/ISMS (Kontrollen), Risikomanagement (Bewertung, Limits), Compliance/Legal (Regeln, Verträge), Fachbereiche (Use-Cases, Kritikalität), BCM (Wiederanlauf), Finanzen (Bonität) und bei Bedarf Datenschutz (Datenflüsse). Bewährt hat sich die Logik der drei Verteidigungslinien: 1) Fachbereiche „besitzen“ das Risiko und betreiben Kontrollen; 2) Risiko/Compliance setzen Rahmen, beraten und überwachen; 3) Interne Revision prüft unabhängig. Ein Sourcing-Komitee oder „Third-Party Risk Council“ priorisiert, genehmigt und eskaliert Entscheidungen entlang definierter Schwellen.

Der Lebenszyklus: Vom Bedarf bis zum Exit

Ein wirksames DORA-konformes TPRM folgt einem Lifecycle, der jede Auslagerung durchgängig steuert:

1) Strategie & Risk Appetite

Zu Beginn steht ein Risk Appetite Statement speziell für Auslagerungen: Welche Risikokategorien werden akzeptiert, welche Risikotoleranzen gelten (z. B. maximale Downtime, maximale Datenmigrationzeit, maximale Single-Vendor-Quote), welche Konzentrationsgrenzen sind zulässig? Hierzu gehören auch Designprinzipien wie „Portabilität und Exit-Fähigkeit“ oder „Kundenschlüssel über Anbieter-Schlüssel“.

2) Discovery & Inventar

Ohne Inventar kein Schutz: Legen Sie ein Third-Party-Register an, das Service, Datenklassen, Schnittstellen, Standorte/Regionen, Sub-Prozessoren, kritische Abhängigkeiten, Verträge, SLA/SLO, Sicherheitsnachweise (ISO, SOC, Pen-Tests), BCM/DR-Fähigkeiten und Owner erfasst. Ergänzen Sie ein Shadow-SaaS-Programm gegen unautorisierte Eigenbeschaffungen.

3) Due Diligence (Vorvertrag)

Die Vorauswahl klärt, ob ein Anbieter grundsätzlich geeignet ist. Das umfasst:

• Sicherheits-Evidenz (z. B. Auditberichte, Zertifikate, Policies, Pentest-Zusammenfassungen, Schwachstellen-Management, Sicher-Entwickeln, Incident-Prozesse).
• Technische Architektur (Mandantentrennung, Verschlüsselung in Ruhe/Transit/bei Verarbeitung, Schlüsselverwaltung BYOK/BYOKMS/HYOK, Härtung, Logging/Monitoring, Identity & Access, Admin-Zugänge, Kundensegregation).
• BCM/DR-Fähigkeit (RTO/RPO, Tests, Geo-Redundanz, Lieferketten-Fallbacks).
• Betriebsprozesse (Change-/Release-Management, Patch-Zyklen, Notfallprozesse, 24/7-Support).
• Datenschutz (Datenkategorien, -standorte, -flüsse, Betroffenenrechte-Support, Löschkonzepte).
• Recht/Regulierung (Aufsichts-Fit, Meldeprozesse, Audit-/Informationsrechte, Datenlokalität).
• Finanzielle Stabilität (Bonität, Liquidität, Versicherungsschutz).
• Geopolitische Faktoren (Sanktionsrisiken, Rechtszugriff, politische Stabilität von Standorten).

4) Risikoanalyse: Inherent vs. Residual

Bewerten Sie inherente Risiken (ohne Kontrollen) entlang von Vertraulichkeit, Integrität, Verfügbarkeit, ergänzt um Authentizität, Revisionssicherheit, Resilienz, Privatsphäre, Portabilität. Leiten Sie daraus erforderliche Kontrollen ab und bestimmen Sie das Residualrisiko nach den zugesicherten Maßnahmen. Kritische Services verlangen ggf. zusätzliche Kompensationen (z. B. externe Backups, zusätzliche Monitoring-Sensoren, alternatives Fallback).

5) Vertragsgestaltung (Security by Contract)

DORA erwartet präzise Auslagerungsverträge. Unverzichtbare Klauseln:

• Sicherheitsanforderungen (Mindestkontrollen, Härtungsstandards, Kryptovorgaben, Schlüsselmodelle, Admin-Zugriff, Logging).
• SLA/SLO und Resilienzmetriken (RTO/RPO, Testpflicht, Kapazitätsplanung, DDoS-Vorsorge).
• Vorfallmeldungen (Fristen, Inhalte, 24/7-SPOC, Koordination mit DORA/DSGVO/NIS-Meldepflichten).
• Audit- und Inspektionsrechte (regelmäßig/aus besonderem Anlass, Remote/Onsite, Dritt-Audit-Anerkennung, Rechte auch gegenüber Sub-Prozessoren).
• Sub-Outsourcing (Genehmigungspflicht, Liste, Vorab-Info-Fristen, gleiche Standards „flow-down“).
• Änderungsmanagement (Standortwechsel, Architekturwechsel, Eigentümerwechsel, wesentliche Prozessänderungen = zustimmungspflichtig).
• Portabilität & Exit (Exportformate, Migrations-Support, Betriebs- und Daten-Escrow, Übergabe von Konfigurationen/Schlüsseln/Logs, Lösch-/Vernichtungsnachweise, Exit-Timelines, „Assisted Exit“).
• Verfügbarkeit von Beweismitteln (Forensic-Kooperation, Log-Retention, Chain of Custody).
• Haftung & Versicherung (Mindestdeckung, Sublimits, Ausschlüsse, Mitwirkungspflichten).
• Rechtswahl/Erfüllungsort/Schiedsverfahren (Durchsetzbarkeit in Krisen).

6) Onboarding & Integration

Vor Go-Live werden Kontrollen verifiziert: Identity-Anbindung, Rollenprofile, Netzpfade, TLS-Profile, Logging-Routen (SIEM/XDR), CSPM/CNAPP-Policies für Cloud-Ressourcen, Secrets-Management, Backup-Ziele, Alarme, Notfallkontakte, Out-of-Band-Kanäle, „Break-Glass“-Zugänge, Tamper-Protection der Logs. Ein Shared-Responsibility-Matrix verdeutlicht Aufgaben: Wer patcht, wer überwacht, wer reagiert, wer meldet?

7) Kontinuierliches Monitoring

DORA fordert regelmäßige Überwachung – mehr als KPI-Reports. Bausteine:

• Technische Telemetrie (Synthetik-Checks, API-Health, Latenz/Fehler, Kapazität, QoS).
• Sicherheits-Signale (Use-Cases im SIEM, Anbieter-Advisories, Threat-Intel-Feeds, Schwachstellen).
• Kontroll-Nachweise (Zertifikate, Auditberichte, DR-Testprotokolle, Patch-Status, Pen-Test-Ergebnisse).
• Qualitative Indikatoren (Transparenz, Reaktionsqualität, Ursachenanalysen, Stabilität des Managements, Personalfluktuation in Schlüsselrollen).
• KRIs/KPIs (siehe weiter unten) je Provider in Scorecards – mit Ampel, Schwellen, Eskalation.

8) Vorfälle & Meldungen

Bei Incidents greifen gemeinsame Playbooks: Erstmeldung, Informationsaustausch, forensische Kooperation, Kundenkommunikation, Synchronisierung von DORA-, DSGVO- und NIS-Meldungen, Nachweisführung. Verträge müssen Vorfallfristen (z. B. „unverzüglich“, konkrete Stundenkorridore), Inhalte (Fakten, Scope, IoCs, Maßnahmen, nächste Updates) und Zugänge (SPOC, War-Room) festlegen.

9) Änderungen, Trigger & Reviews

Definieren Sie Trigger für Neubewertungen: SLA-Verfehlungen, Major-Incidents, Standort-/Architekturwechsel, M&A, neue Sub-Prozessoren, regulatorische Änderungen. Planen Sie jährliche oder risikobasierte Reviews mit erneuter Due Diligence.

10) Exit & Nachsorge

Der Exit ist kein Dokument, sondern ein geübter Prozess: Datenexporte testen (Vollständigkeit/Integrität), Konfigurationen/Policies/Automationen sichern, Abhängigkeiten entfernen, Zugänge entziehen, gemeinsame Systeme abklemmen, Lösch- und Vernichtungszertifikate einholen, Lessons Learned dokumentieren. Für SaaS empfiehlt sich Daten- oder Betriebs-Escrow (Treuhand), damit im Fall der Insolvenz der Service oder die Daten verfügbar bleiben.

Kritikalitätsklassifizierung: Nicht jeder Dienst ist gleich

Nicht alle Auslagerungen sind gleich kritisch. Eine Klassifizierung hilft, Aufwand zu fokussieren:

• Kernkritisch: Ausfall bedroht Geschäftsfortführung oder Finanzsystemstabilität (z. B. Kernbank, Zahlungsverkehr, zentrale Identität).
• Geschäftskritisch: Erheblicher Prozess-/Kundeneinfluss, Compliance-Risiko.
• Unterstützend: Begrenzte Auswirkung, ggf. nur Komfort oder interne Effizienz.
  Pro Klasse definieren Sie Mindestkontrollen, Review-Frequenzen, Exit-Fristen, Meldepflichten und Testdichten (z. B. DR-Übung halbjährlich bei Kernkritisch).

Konzentrations-Management: Portfolio statt Einzelbeziehung

Sicht auf das Ganze: Wie stark hängt Ihr Unternehmen an einem Provider/Region/Technologiestack? Nutzen Sie Konzentrationsmetriken (z. B. Herfindahl-Index) und Szenario-Stresstests („Region X fällt 24 h aus“). Gegenmaßnahmen: Multi-Region-Architektur, ausgewählte Multi-Provider für besonders kritische Funktionen, Abstraktionsschichten (z. B. Standard-Schnittstellen), Daten-Portabilität und Exit-Proben. Ziel ist begrenzte Kopplung statt „blindem Multi-Cloud-Dogma“.

Sicherheitstechnische Designprinzipien mit Drittanbietern

• Verschlüsselungslayering: Eigene Schlüssel (BYOK/HYOK), Schlüsseldrehs, geteilte Verantwortung, Dual Control.
• Mandantentrennung: Technische Isolation (VPCs/Projekte/Tenants), harte Grenzen für Admin-Zugriffe.
• Identität vor Netzwerk: Zero-Trust-Prinzip, kontextbasierte Zugriffe, starke Authentisierung (phishing-resistent).
• Logging & Unveränderlichkeit: WORM/Append-Only, Zeitstempel-Synchronität, zentrale Korrelation.
• Backups außerhalb des Anbieters: Immutability (z. B. Objekt-Locks), Cross-Account/-Region, regelmäßige Restore-Tests inkl. Integritätscheck.
• Secure Development & Supply Chain: SBOMs, signierte Artefakte, Abhängigkeitsprüfung, reproduzierbare Builds, Secrets-Hygiene, VDP/Coordinated Disclosure.
• Least Privilege & PAM: Kurzlebige Privilegien, Approval-Workflows, Sitzungsaufzeichnung.
• Segmentierung & Blast-Radius-Minimierung: Mikro-Segmente, circuit breaker, Bulkheads.

Vertrags-Checkliste (Auszug)

1. Definitionen & Scope: Klare Abgrenzung der Services, Daten, Standorte.
2. Sicherheitsanhang: Mindestmaßnahmen, Standards, Testpflichten, Kryptomodelle.
3. Vorfallmeldung: Fristen, Inhalte, Koordination mit Behördenpflichten.
4. Auditrechte: Frequenz, Umfang, Sub-Prozessor-Einbezug, Remediation-Fristen.
5. BCM/DR: RTO/RPO, Testpläne, Berichtspflichten, Abhängigkeiten.
6. Leistungsmetriken: SLOs, Service-Credits plus verpflichtende RCA bei Grenzwertverstoß.
7. Sub-Outsourcing: Genehmigung, Liste, Fristen, Flow-down.
8. Daten & IP: Eigentum, Nutzungsrechte, Export, Format, Fristen.
9. Portabilität/Exit: Migrations-Support, Escrow, Löschung/Nachweise, Cut-over-Plan.
10. Rechtliches: Haftung, Versicherung, Compliance, Rechtswahl, Streitbeilegung.

KRIs & KPIs: Messbar machen, was zählt

Risikokennzahlen (KRIs)

• Anteil kritischer Anbieter ohne aktuellen Sicherheitsnachweis.
• Anzahl/Trend der SLA-Major-Breaches.
• Zeit bis Vorfallmeldung (Erkennung → Erstinfo).
• Patch-/Vulnerability-Backlog auf Shared-Systemen.
• Sub-Prozessor-Anteil mit unbekannter Lage oder ohne Zustimmung.
• Konzentrationsquote der Top-3-Provider je kritischem Prozess.

Leistungskennzahlen (KPIs)

• Time-to-Restore je Vorfallklasse vs. RTO.
• Erfolgsquote DR-Tests (inkl. Datenintegrität).
• Ticket-Abarbeitung bei Findings innerhalb Fristen.
• Transparenz-Score (Vollständigkeit/Tempo der Berichte).
• Audit-Non-Conformities pro Jahr und deren Schließzeit.

Praktische Szenarien – und was DORA impliziert

SaaS-Ausfall während Stichtag: Vertrag muss Notbetrieb/Export-Pfad sichern; DR-Test belegt Wiederanlauf. Ransomware beim Provider: Sofortige Koordination, forensische Kooperation, schnelle DORA-Erstmeldung, sauberer Kommunikationsfaden, getrennte Backups entscheidend. Cloud-Region gestört: Multi-AZ/Region-Design, Traffic-Umschaltung, Kommunikationsplan; nachgelagert Ursachenanalyse und Portfolio-Anpassung. Supply-Chain-Exploit: Signaturketten, SBOM-Abgleich, Rollback-Plan, Kundensignale; DORA-Meldung inklusive Impact auf Ihre Kunden.

Datenschutz und Auslagerung: Privatsphäre als harte Anforderung

Datenklassifizierung bestimmt zulässige Standorte, Schlüsselmodelle, Zugriffsregeln und Lösch-/Aufbewahrungsfristen. Dienstleister müssen Betroffenenrechte unterstützen (Auskunft, Löschung, Korrektur), Datenminimierung und Zweckbindung respektieren sowie Transparenz über Sub-Prozessoren liefern. Vereinbaren Sie Löschläufe, Anonymisierung/Pseudonymisierung, Privacy by Design und Privacy-Logs für Nachweise.

Integration in ISMS, BCM und Risikomanagement

TPRM ist kein Solo:

• ISMS: Lieferantenbeziehungen als eigener Control-Bereich; Findings in Risikoregister, SoA und Maßnahmenplan.
• BCM/DR: Externe Abhängigkeiten fest in BIA, RTO/RPO, Notbetrieb und Übungsprogramm verankern.
• Risikomanagement: Portfolio-Sicht, Konzentrationsgrenzen, regelmäßige Management-Reviews mit Scorecards.

Reifegradmodell: Wo stehen Sie?

Level 1 – Ad-hoc: Unvollständiges Register, Verträge ohne Sicherheitsanhang, Reaktion reaktiv.
Level 2 – Definiert: Basis-Prozess, Due-Diligence-Checklisten, sporadisches Monitoring.
Level 3 – Gemanagt: Scorecards, regelmäßige Audits, geübte DR-/Exit-Szenarien, klare Eskalation.
Level 4 – Integriert: Vollverzahnt mit ISMS/BCM/Risk, Portfolio-Konzentrationssteuerung, automatisiertes Telemetrie-Monitoring.
Level 5 – Adaptiv: Threat-intel-gestützt, kontinuierliche Verbesserung, „Design for Exit“, automatisierte Kontrollen, gemeinsame Übungen mit Providern.

Typische Fallstricke – und Gegenmittel

• „Service-Credits reichen.“ Nein: Service-Credits kompensieren nur finanziell, nicht systemisches Risiko. Fordern Sie RCAs, Abstellmaßnahmen, Testnachweise.
• „Unser Anbieter ist zertifiziert, also sicher.“ Zertifikate sind Startpunkt, nicht Endpunkt. Verifizieren, stichproben, technische Sensorik.
• „Multi-Cloud löst alles.“ Nur, wenn Portabilität und Betriebsprozesse mitziehen. Sonst doppelte Komplexität, wenig Resilienzgewinn.
• „Exit planen wir später.“ Zu spät ist teuer. Exit früh planen und jährlich minimal testen (Datenexport, Re-Import, Mapping).
• „Schatten-SaaS ist harmlos.“ Ohne Verträge keine Rechte – schaffen Sie schnelle, sichere Beschaffungspfade statt Verbote ohne Alternative.
• „Incident? Der Anbieter meldet schon.“ Verlangen Sie konkrete Fristen/Inhalte, War-Room-Zugang und forensische Kooperation vertraglich.

Quick-Start in 90 Tagen

0–30 Tage: Register vervollständigen, Kritikalität zuordnen, Risk Appetite/Schwellen definieren, Melde-/Kontaktliste aufbauen.
31–60 Tage: Top-10-kritische Anbieter re-bewerten, Vertrags-Gaps identifizieren, Incident/Comms-Playbooks entwerfen, erste DR-/Exit-Probe klein aufsetzen.
61–90 Tage: Sicherheitsanhänge nachschärfen, Scorecards live schalten, Tabletop mit Lieferanten durchführen, Management-Review mit klaren Maßnahmen.

Lieferantenkultur: Transparenz, Fairness, Konsequenz

Starke Beziehungen beruhen auf klaren Erwartungen, planbaren Anforderungen, sachlicher Zusammenarbeit – und Konsequenzen bei wiederholter Nichteinhaltung. Fördern Sie Transparenz (regelmäßige Jour-fixes, offene RCA-Diskussionen), Fairness (keine „Überraschungs-Audits“ ohne Grund, realistische Fristen), aber auch Konsequenz (Vertragsstrafen, Eskalation bis Exit), wenn Risiken nicht beherrscht werden.

Finanzperspektive: Kosten, Nutzen, Resilienz-ROI

DORA-konformes TPRM kostet – Prozesse, Menschen, Tools, Tests. Der Nutzen: geringere Vorfallschäden, schnellere Wiederanläufe, bessere Auditfähigkeit, niedrigere Versicherungsprämien, Ausschreibungsfähigkeit und – besonders wichtig – geringerer Tail-Risk durch Konzentration. Quantifizieren Sie mit Szenarioverlusten, vergleichen Sie gegen Maßnahmenkosten, priorisieren Sie investitionswirksam.

Architektur für Portabilität: Technik, die Verträge einlöst

Portabilität ist nicht nur Vertragstext, sondern Architekturarbeit: Standardisierte Schnittstellen, Infrastructure as Code, containerisierte Workloads, Datenmodelle mit dokumentierten Mappings, Konfigurations-Export als Pflicht, Entkopplung vom Anbieter-spezifischen IAM, Schlüsselverwaltung in Kundendomäne, Event-/Log-Exports in eigene Data-Lakes. So wird Exit machbar – nicht nur „theoretisch“.

Security-Scorecards: Sicht für Management und Board

Verdichten Sie pro kritischem Anbieter: Kritikalitätsstufe, SLA/SLO-Trend, Vorfalllage, Auditstatus, BCM-Tests, KRIs, Konzentrationsbeitrag, Maßnahmen-Backlog. Ampellogik plus kurzer Kommentar („Top-Risiko: fehlende Sub-Prozessor-Transparenz; Gegenmaßnahme: Vertragsnachtrag bis Q3“) schafft Entscheidbarkeit.

Zusammenarbeit im Vorfall: Gemeinsame War-Rooms

Definieren Sie im Vertrag War-Room-Mechanik: Tools, Kanäle, Rollen, Datenräume, Informationsfrequenz, Freigabeprozesse. Legen Sie fest, wie Beweise gesichert und geteilt werden und wie öffentliche Kommunikation abgestimmt wird. Üben Sie das mindestens jährlich; im Ernstfall entscheidet Tempo + Klarheit über Schadenhöhe – und über die Qualität Ihrer DORA-Meldungen.

Ausblick: DORA als Hebel für professionelles Sourcing

Am Ende geht es nicht darum, Auslagerungen zu verhindern. DORA will Innovation und Effizienzgewinne nicht ausbremsen, sondern sicherstellen, dass sie nicht zur Schwachstelle werden. Wer seine Lieferanten unter der Lupe hat, Risiken realistisch einschätzt, klare Verträge schließt, laufend überwacht und Exit-Strategien parat hat, kann die Vorteile von Drittanbietern nutzen, ohne die eigene Resilienz zu gefährden. In einer vernetzten Finanzwelt ist das nicht nur eine regulatorische Pflicht, sondern eine Überlebensstrategie – denn die Kette ist immer nur so stark wie ihr schwächstes Glied. Und genau hier setzt DORA an: Es macht aus Auslagerung eine beherrschte Fähigkeit – mit klaren Rollen, messbaren Zielen, geübten Szenarien und der Gewissheit, dass Verantwortung nicht delegierbar ist. Wer diese Haltung verinnerlicht, wird nicht nur Prüfungen bestehen, sondern im Ernstfall handlungsfähig bleiben – schnell, transparent und belastbar.