Zum Inhalt springen
DORA Art. 28 · DORA Art. 29/30 · MaRisk AT 9 · FINMA-RS 2018/3 · EBA GL/2019/02 · DSGVO Art. 28

Drittdienstleistungen und Dienstleister steuern — von Intake bis Betrieb

Ein kritischer Prozess öffnet den passenden Prüfpfad — der CIF-Kontext wird aus dem gestützten Prozess übernommen, die konkrete Einstufung bleibt prüf- und bestätigbar.

Im Kern

Drei Gründe für Avalon TPRM

01

Eigener TPRM-Fachprozess: Dienstleister, Dienstleistung, Vertrag, Datenzugriff, IKT-Bezug und unterstützte Prozesse werden im Modul bewertet — Risiken werden in DRA und BPDD erhoben, nicht aus einem vorgelagerten Register übernommen.

02

Gezielt übernommener Kontext: CIF-Status, BIA/RTO/RPO, Schutzbedarf, Process Owner und Asset-Bezüge kommen aus den zuständigen Modulen und werden im TPRM nicht doppelt gepflegt.

03

KI-Vorbereitung mit Kontrolle: Quellen werden verarbeitet, Felder vorbefüllt, Plausibilität und Konfidenz sichtbar gemacht; Fachrollen prüfen, übernehmen, korrigieren oder lehnen ab. Methodik, Assessment-Templates, Checklisten, Schwellenwerte und Reviewer-Routing bleiben kundenspezifisch konfigurierbar.

KI-Arbeitsmodell

KI bereitet vor. Menschen führen.

Jedes Modul bleibt klassisch bedienbar. Wenn KI aktiviert ist, übernimmt sie operative Vorbereitung und Verdichtung: Vorbefüllungen, Zuordnungen, Zusammenfassungen und Review-Queues. Verantwortliche Rollen prüfen Qualität, treffen die Entscheidung und geben den Nachweis frei.

Was sich im Arbeitsalltag ändert

  • Weniger manuelle Vorbefüllung, Kopieren und Konsolidieren.
  • Schnellere Durchläufe, weil Fachrollen vorbefüllte Arbeitsentwürfe statt leere Masken sehen.
  • Mehr Ressourcen für Steuerung, Qualitätssicherung und prüffähige Entscheidung.
01

Operative Vorarbeit

KI befüllt definierte Assessment- und Workflow-Felder vor, entwirft Zuordnungen, Texte oder Report-Bausteine und legt Quellen, Begründung und Konfidenz offen.

02

Menschliche Qualitätssicherung

Fachrollen prüfen, korrigieren, bündeln oder verwerfen. Freigaben, Overrides und rechtlich relevante Entscheidungen bleiben menschlich.

03

Auditierbarer Nachweis

Input, Vorbefüllung oder Entwurf, Entscheidung, Begründung und Version werden protokolliert. Der Effizienzgewinn kommt ohne Kontrollverlust.

Interessentenperspektive

Für wen dieses Modul gebaut ist

Primär: TPRM-, Drittdienstleistungs- und Risk-Manager in regulierten Häusern, die DORA Art. 28 und – soweit einschlägig – MaRisk AT 9 belastbar und prüffähig bedienen müssen. Sekundär: Auslagerungsbeauftragte, CRO und Compliance-Officer, die konsolidierte Drittparteien-Sicht und aufsichtliche Berichterstattung verantworten, sowie CISO als Second-Line-Reviewer.

DORA · Art. 28
Was heute bremst
mehrfach

Kritikalität der Drittdienstleistung in Vertrag, Risiko und Prozessliste getrennt gepflegt

unklar

Welcher Prozess am Dienstleister hängt, steht nirgends abrufbar

verspätet

Konzentration je Dienstleister erst nach Handarbeit über alle Verträge sichtbar

Avalon-Kern

Ein kritischer Prozess öffnet den passenden Prüfpfad — der CIF-Kontext wird aus dem gestützten Prozess übernommen, die konkrete Einstufung bleibt prüf- und bestätigbar.

CIF-Kontext · Prüfpfad bestätigt

Ein kritischer Prozess öffnet den passenden Prüfpfad

Jedes Drittdienstleistungs-Arrangement übernimmt den Kontext der gestützten Prozesse — etwa CIF, RTO/RPO und Schutzbedarf — und nutzt ihn für Register, Reviews, Exit-Pflichten und Managementsicht. Der Kontext klassifiziert nicht automatisch: Ob daraus eine MaRisk-Auslagerung, eine DORA-relevante IKT-Drittdienstleistung oder ein sonstiger Leistungsbezug wird, bleibt im Quick Check prüf- und bestätigbar.

Belegt: DORA Art. 28–30 (IKT-Drittdienstleister-Risikomanagement, Register, Vertragsinhalte), Art. 29 (Konzentrationsrisiko), Art. 28(8) (Exit-Strategie, Exit-Plan und Testnachweise), MaRisk AT 9.1–9.6 (Auslagerungen als engerer Prüfpfad). Avalon unterstützt die Erfüllung; die regulatorische Verantwortung verbleibt beim Kunden.

Was dieses Modul für Sie leistet

Ein kritischer Prozess öffnet den passenden Prüfpfad — der CIF-Kontext wird aus dem gestützten Prozess übernommen, die konkrete Einstufung bleibt prüf- und bestätigbar.

Avalon-Kern

CIF-Kontext · Prüfpfad bestätigt

01

Drittdienstleistung vollständig erfassen

Dienstleister, Dienstleistung, Vertrag, Datenzugriff, IKT-Bezug, Subdienstleister, Ersetzbarkeit und unterstützte Prozesse bilden den Intake.

02

Kontext gezielt übernehmen

CIF, BIA/RTO/RPO, Schutzbedarf, Process Owner und Asset-Bezüge kommen aus den zuständigen Modulen und bleiben dort führend.

03

Risiken im TPRM-Prozess erheben

Quick Check klassifiziert; DRA bewertet die Dienstleistung; BPDD bewertet den Dienstleister; Vertragsprüfung, Exit und KPI steuern den Betrieb.

Vom Leistungsbezug zum aktiven Arrangement

So steuern Sie eine Drittdienstleistung in Avalon TPRM

Prozesslogik

Jeder Schritt zeigt, welche Vorarbeit entsteht, wer prüft und welcher Nachweis daraus wird.

VorarbeitQualitätsprüfungNachweis
  1. 01Schritt

    1. Drittdienstleistung anlegen

    Was passiert in diesem Schritt

    Der Fachbereich oder Sachverhaltsverantwortliche eröffnet den Leistungsbezug als Arrangement. Er erfasst Dienstleister, konkrete Dienstleistung, Vertrag oder Vertragsentwurf, Laufzeit, Kündigungsfristen, Kosten, Dokumente, verantwortliche Personen, Datenarten, IKT-Bezug, Cloud-/Standortinformationen, Subdienstleister und Ersetzbarkeit. Wenn KI aktiviert ist, kann sie diese Felder aus bereitgestellten Quellen wie Briefing, Datenblatt, öffentlicher Anbieterinformation, Vertrag, Vertragsentwurf, Präsentation, Angebot oder E-Mail vorbefüllen. Das ist der fachliche Intake; eine Risikobewertung wird dadurch noch nicht vorausgesetzt.

  2. 02Schritt

    2. Unterstützte Prozesse und Kontext übernehmen

    Was passiert in diesem Schritt

    Anschließend wird festgelegt, welche Geschäftsprozesse oder kritischen Funktionen durch die Dienstleistung unterstützt werden. Avalon übernimmt die dort gepflegten Kontextdaten gezielt: CIF-Status, BIA-Werte wie RTO/RPO, Business Impact, Schutzbedarf, Process Owner und Asset-Bezüge. Diese Werte beeinflussen Prüftiefe, DORA-Register, Review-Turnus und Exit-Pflichten, ersetzen aber nicht die fachliche TPRM-Klassifizierung.

  3. 03Schritt

    3. Quick Check: Einordnung und Prüfpfad bestimmen

    Was passiert in diesem Schritt

    Der Quick Check klärt die regulatorische Einordnung in geführten Fragen. Zuerst wird geprüft, ob der Leistungsbezug zulässig ist und welcher Vertragstyp vorliegt. Danach bewertet Avalon Eigenleistungsfähigkeit, bankspezifischen Charakter und operative Integration, um Auslagerung, Grenzfall oder sonstigen Fremdbezug zu unterscheiden. Anschließend werden Ausfallauswirkung, Zeitdruck, regulatorische Einbindung, aufsichtliche Bedeutung, IKT-Bezug, personenbezogene Daten, Datenstandort, Kosten, Ersetzbarkeit, Cloud- und Gruppenbezug einbezogen. Das Ergebnis wird in Klartext angezeigt und steuert Pflichten, Review-Turnus, Exit und Nachweise.

  4. 04Schritt

    4. DRA, BPDD und Vertragsprüfung durchführen

    Was passiert in diesem Schritt

    Erst jetzt werden die Risiken strukturiert erhoben. Die DRA bewertet die konkrete Dienstleistung, etwa Leistungsausfall, Datenschutz, IKT-Sicherheit, Compliance, Konzentration, Weiterverlagerung, Standort und Reputation. Die BPDD bewertet den Dienstleister, etwa finanzielle Stabilität, Kompetenz, Compliance, Organisation, Interessenkonflikte und Negative News. Die Vertragsprüfung prüft relevante Pflichtklauseln gegen DORA Art. 30, MaRisk AT 9, soweit einschlägig, und Datenschutzanforderungen. KI kann DRA-/BPDD-Antworten, Providerinformationen und Vertragsklauseln aus Quellen vorbereiten; Reviewer entscheiden, welche Vorbefüllungen übernommen, editiert oder abgelehnt werden.

  5. 05Schritt

    5. Kenntnisnahmen und Fachvoten einholen

    Was passiert in diesem Schritt

    Avalon ermittelt aus Klassifizierung, Datenzugriff, IKT-Bezug, Datenschutzrelevanz und Kritikalität, welche Fachrollen eingebunden werden müssen. Informationssicherheit, Datenschutz, Compliance, IKT, Interne Revision oder BCM erhalten gezielte Prüfaufgaben statt allgemeiner E-Mail-Abstimmungen. Jede Rolle votiert innerhalb ihrer Domäne mit Zustimmung, Zustimmung unter Auflagen, Ablehnung mit Begründung oder Delegation. Auflagen, Konflikte und Befangenheiten bleiben am Arrangement nachvollziehbar dokumentiert.

  6. 06Schritt

    6. Final Review und Aktivierung durch TPRM-Koordination

    Was passiert in diesem Schritt

    Wenn Pflichtangaben, DRA, BPDD, Vertragsprüfung, Fachvoten und gegebenenfalls Exit-Strategie vollständig sind, wird der Final Review freigegeben. TPRM-Koordination oder TPRM-Admin prüfen nicht inhaltlich anstelle der Fachrollen, sondern kontrollieren Vollständigkeit, offene Auflagen, Statuslogik, Aktivierungsbedingungen und Dokumentationsstand. Das Sign-off aktiviert das Arrangement für den laufenden Betrieb; es ist keine pauschale Geschäftsleitungsfreigabe.

  7. 07Schritt

    7. Exit-Strategie festlegen und Exit-Plan entwickeln

    Was passiert in diesem Schritt

    Die Exit-Strategie ist die institutsseitige Entscheidung: Wann muss ausgestiegen werden, welche Ausstiegsoption ist realistisch, welche Nachfolge- oder Interimsanbieter kommen in Betracht, wie werden Daten zurückgeführt oder gelöscht und wer trägt intern die Verantwortung. KI kann aus Vertrag, Risikodaten, Providerinformationen und vorhandenen Quellen einen begründeten Strategieentwurf vorbereiten. Erst danach wird mit dem Dienstleister der konkrete Exit-Plan entwickelt. Dieser Plan beschreibt Transition-Schritte, Termine, Mitwirkungspflichten, technische Übergaben, Datenrückgabe, Lösch- und Nachweispflichten sowie Abnahmekriterien. Strategie und Plan bleiben getrennte Objekte, weil sie unterschiedlichen Verantwortungen folgen.

  8. 08Schritt

    8. Aktiv überwachen, Exit testen und geordnet beenden

    Was passiert in diesem Schritt

    Nach Aktivierung läuft das Arrangement in die operative Steuerung. Providersteuerung und TPRM überwachen Reviews, Re-Checks, KPI-Ampeln, SLA-Verletzungen, Vertragsänderungen, Dokumentenaktualität, Konzentrationsrisiken, Findings und Eskalationen. Für kritische oder wichtige IKT-Drittdienstleistungen und für wesentliche Auslagerungen werden Exit-Plan-Tests terminiert, durchgeführt und mit Ergebnis, Abweichungen, Maßnahmen und getesteter Planversion dokumentiert. Wird das Arrangement beendet, führt der getestete Plan durch Transition, Datenrückgabe oder Löschung, Alternativlösung, Abschlussprüfung und revisionssichere Archivierung.

Funktionsumfang

Was das TPRM-Modul im Detail leistet

01

Saubere Terminologie: Drittdienstleistung ist der Oberbegriff

Avalon behandelt nicht jeden externen Leistungsbezug pauschal als Auslagerung. Drittdienstleistung ist der operative Oberbegriff; DORA fokussiert vertragliche Vereinbarungen mit IKT-Drittdienstleistern; MaRisk AT 9 greift nur, wenn der Auslagerungsbegriff erfüllt ist. Der Quick Check hält diese Einordnung fest, bevor Prüfpfade, Registerdaten, Vertragsanforderungen, Review-Zyklen und Exit-Pflichten ausgelöst werden.

02

Intake aus Dienstleister, Dienstleistung und unterstützten Prozessen

Der Datensatz beginnt mit dem Dienstleister, der konkreten bezogenen Leistung, Vertrags- und Laufzeitinformationen, Datenzugriff, IKT-Bezug, Subdienstleistern, Ersetzbarkeit und den unterstützten Geschäftsprozessen. Risiken werden daraus nicht vorausgesetzt, sondern im TPRM-Workflow strukturiert erhoben und bewertet.

03

KI-Multi-Source-Prefill über den gesamten TPRM-Prozess

Aktivierte KI-Funktionen können bereitgestellte Quellen lesen: Textbriefings, Sprachmemos, Datenblätter, Whitepaper, Verträge, Vertragsentwürfe, Web-Recherche, Begleitdokumente, Präsentationen, Angebote und E-Mails. Daraus entstehen Vorbefüllungen für Stammdaten, Quick-Check-Antworten, DRA-/BPDD-Felder, Vertragsklauseln, Informationsregister und Exit-Inhalte — jeweils mit Quellenausschnitt, Confidence, Plausibility-Status und Auditspur. Der Nutzer bleibt Manager des Prozesses und qualitätssichert jedes Feld.

04

Gezielt übernommener Prozess- und Schutzbedarfskontext

Verknüpfte Prozesse stellen den Kontext bereit, der fachlich in anderen Modulen gepflegt wird: CIF-Status aus der Kritikalitätslogik, BIA-Werte wie RTO/RPO aus BCM, Schutzbedarf aus dem ISMS, Process Owner und Asset-Bezüge aus Prozessmanagement/CMDB. TPRM nutzt diese Werte für Prüftiefe, DORA-Register, Reviews und Exit-Pflichten, ohne die MaRisk-Auslagerungseinstufung zu automatisieren.

05

ICT Services nach DORA und Auslagerungen nach MaRisk in einem Modul

Avalon TPRM deckt beide regulatorischen Steuerungspfade ab: vertragliche ICT Services bzw. IKT-Dienstleistungen mit IKT-Drittdienstleistern nach DORA und Auslagerungen nach MaRisk AT 9, soweit der Auslagerungstatbestand erfüllt ist. Beide Pfade nutzen dieselben Stammdaten, Dokumente, Rollen und Nachweise, bleiben in der Klassifizierung aber sauber getrennt.

06

Quick Check mit klarer regulatorischer Einordnung

Der Quick Check erklärt den Leistungsbezug in Klartext: wesentliche Auslagerung, nicht wesentliche Auslagerung oder sonstiger Fremdbezug; jeweils mit IKT-Bezug, CIF-Kontext und den daraus folgenden Pflichten. Die technische Codierung wird nur für Nachweis und Auswertung gespeichert. Anwender sehen, welche Prüfungen, Reviews, Vertragsanforderungen, Exit-Pflichten und Nachweise ausgelöst werden. Bei einer nicht wesentlichen Auslagerung mit CIF-Kontext markiert Avalon den Widerspruch und fordert die fachliche Prüfung einer Höherstufung.

07

Konfigurierbare Assessment-Templates und Methodik

Kunden können die TPRM-Methodik individuell konfigurieren: Quick-Check-Fragen, DRA-/BPDD-Assessment-Templates, Vertragsprüfungs-Checklisten, Pflichtdokumente, Review-Zyklen, KPI-Schwellenwerte, Eskalationen und Reviewer-Routing werden kundenspezifisch ausgerichtet. So bleibt der Standard regulatorisch vorstrukturiert, ohne Ihre interne Methodik zu erzwingen.

08

DRA: Dienstleistungsrisikoanalyse des konkreten Arrangements

Die DRA bewertet die Risiken der bezogenen Dienstleistung selbst, typischerweise Leistungsausfall, Datenschutz, IKT-Sicherheit, Compliance, Konzentration, Weiterverlagerung, Länder-/Standortrisiken und Reputation. Je nach regulatorischer Einordnung werden nur die relevanten Kategorien verpflichtend geöffnet.

09

BPDD: Business Partner Due Diligence des Dienstleisters

Die BPDD bewertet den Dienstleister als Geschäftspartner: finanzielle Stabilität, fachliche Kompetenz, regulatorische Compliance, organisatorische Stabilität, Interessenkonflikte, Negative News und — bei entsprechendem Scope — Nachhaltigkeit/ESG. Damit werden Provider-Risiken getrennt von der Dienstleistungsrisikoanalyse sichtbar.

10

Kenntnisnahme und Second-Line-Votierung

Je nach Klassifizierung werden die erforderlichen Reviewer eingebunden: Informationssicherheit, Datenschutz, Compliance, IKT, Interne Revision und BCM. Jeder votiert in seiner Domäne — Zustimmung, Zustimmung mit Auflagen, Ablehnung mit Begründungspflicht oder Delegation. Befangenheitsregeln, Auflagen und Findings halten die Entscheidungskette nachvollziehbar; der Final Review liegt bei TPRM-Koordinator oder TPRM-Admin.

11

Geführter Lebenszyklus Entwurf → In Prüfung → Aktiv → Beendet

Jedes Arrangement durchläuft einen kontrollierten Lebenszyklus: Entwurf (Basisdaten, Provider, Dokumente), Prüfung (Quick Check, DRA, BPDD, Vertragsprüfung, Exit-Strategie, Kenntnisnahme), Aktiv (periodische Reviews, KPIs, Re-Checks, Exit-Plan-Tests) und Beendet (ausgeführter Exit-Plan mit Transition-Timeline, Datenrückgabe und Alternative). Statusübergänge, Vollständigkeitsprüfung und Final Review werden durch Koordinator/Admin geführt.

12

Regulierungsabhängige Vertragsprüfung nach DORA Art. 30

Die Pflichtklausel-Checkliste stellt sich nach der Klassifizierung zusammen. Für DORA-relevante IKT-Drittdienstleistungen prüft Avalon u. a. uneingeschränktes Audit-Recht, quantitative SLAs, getestetes BCP des Providers, Weiterverlagerungsklauseln, Standortangaben und Exit-Unterstützung — geprüft gegen DORA Art. 30(2)/(3), MaRisk AT 9.3, soweit Auslagerung, und DSGVO Art. 28(3). Vertragslücken werden als Befund, Auflage oder Finding sichtbar.

13

Exit-Strategie, Exit-Plan und Exit-Tests getrennt geführt

Die Exit-Strategie ist die institutsseitige Entscheidung, wie Abhängigkeiten beendet oder ersetzt werden können: Trigger, strategische Option, Nachfolge-Provider, Datenrückgabe und Verantwortlichkeit. Daraus entsteht der konkrete Exit-Plan mit dem Dienstleister — inklusive Transition-Schritten, Terminen, Datenrückgabe/-löschung, Mitwirkungspflichten und Nachweisen. Für kritische oder wichtige IKT-Drittdienstleistungen sowie wesentliche Auslagerungen werden Exit-Plan-Tests geplant, durchgeführt, mit Findings dokumentiert und am getesteten Planstand vermerkt.

14

Konzentrationsrisiko nach DORA Art. 29

Avalon misst das Konzentrationsrisiko je Dienstleister aus mehreren regulatorisch hergeleiteten Faktoren nach DORA Art. 29 und Del. VO (EU) 2024/1502 — u. a. Abhängigkeit kritischer Funktionen, Kosten-, Prozess- und Standort-Konzentration, Substituierbarkeit und Weiterverlagerungs-Tiefe. Eine Ausfallsimulation zeigt, welche Prozesse und Wiederanlaufziele der Ausfall eines Dienstleisters gefährden würde.

15

Drei-Linien-Modell über spezialisierte Fachrollen

Drei-Linien-Modell über spezialisierte Fachrollen: operativ (Sachverhaltsverantwortliche, Providersteuerer, Evaluatoren), Second Line (sechs Fachdomänen ISM/Datenschutz/Compliance/IKT/Revision/BCM), Steuerung (Koordinator, Admin) und Lesezugriff für Reporting, Management und Prüfung. Ein Nutzer kann mehrere Rollen gleichzeitig tragen; Berechtigungen werden ausschließlich manuell vergeben.

16

KPI-Monitoring mit Ampel und Eskalationspfad

Pro Arrangement werden Dienstleistungs-KPIs erfasst — SLA-Verfügbarkeit, Reaktions- und Lösungszeit, Incident-Häufigkeit, Berichtsqualität — mit Ampellogik (Grün/Gelb/Rot) je Kennzahl. Verletzungen erzeugen Vorgänge, Fristen werden sichtbar und der KPI-Verlauf stützt Reviews, Eskalationen und Management-Reporting.

Typische Szenarien

Wann TPRM im Avalon-Einsatz ist

Cloud-Hosting des Kernbanksystems wird kritischkeitsrelevant

Am Prozess „Online-Banking“ ist der CIF-Kontext aus der Kritikalitätslogik gepflegt. Avalon macht sichtbar, welche Arrangements diesen Prozess unterstützen; das Cloud-Hosting wird dadurch in den passenden Prüfpfad geführt. Quick Check, DRA, BPDD, DORA-Art.-30-Vertragsprüfung, Second-Line-Votierung und Final Review durch die TPRM-Koordination laufen im gleichen Nachweisraum — ohne dass TPRM-Verantwortliche Kritikalität in mehreren Listen nachpflegen müssen.

Ein Provider häuft kritische Abhängigkeiten an

Ein Dienstleister erhält ein drittes CIF-Arrangement. Das Konzentrationsrisiko des Dienstleisters springt sichtbar auf Rot. Die Ausfallsimulation legt offen, welche Prozesse, welche kritischen Funktionen und welche Wiederanlaufziele ein Ausfall gefährden würde — Grundlage für Dual-Sourcing, Management-Entscheidungen und Aufsichtsvorbereitung.

Der Vertrag läuft aus, bevor jemand hinsieht

Ein aktives Arrangement nähert sich dem Vertragsende. Fristen, SLA-Signale, offene Findings, institutsseitige Exit-Strategie, mit dem Dienstleister abgestimmter Exit-Plan und der letzte Exit-Test liegen im selben Vorgang. Die Beendigung bleibt kontrolliert statt überstürzt.

Verbindungen

Wie dieses Modul mit Avalon zusammenspielt

TPRM liefert nach der fachlichen Bewertung steuerbare Risikosignale in das GRC-Modell – ohne dass ein vorgelagertes Register oder eine externe Vorbewertung die TPRM-Einstufung ersetzt.

Prozessmanagement

Die Prozesswelt liefert Kritikalitätskontext: Schutzbedarf, Wiederanlaufzeiten und Kritikalitätsstatus eines Prozesses beeinflussen die Prüftiefe der zugehörigen Drittdienstleistung. Die konkrete TPRM-Klassifizierung bleibt im Quick Check prüf- und bestätigbar; Prozessänderungen werden als Bewertungsanlass sichtbar.

IT Risk Management

DRA- und BPDD-Ergebnisse können nach Abschluss als Quellrisiken in das zentrale IT-Risk-Register gespiegelt werden. Dort starten sie im Entwurfsstatus, erhalten Vier-Augen-Freigabe und Reporting-Fähigkeit; die fachliche Detailbewertung und Aktualisierung bleiben im TPRM.

ISMS

Soweit Dienstleister, Services oder zugehörige technische Komponenten im Informationsverbund bzw. in der CMDB geführt werden, kann TPRM deren Schutzbedarfs- und Asset-Kontext nutzen. Die Bewertung der konkreten Dienstleistung bleibt dennoch DRA/BPDD im TPRM – Schutzbedarf ist Kontext, nicht Ersatz für die Drittparteienprüfung.

Regulatorik im Detail

Welche Rahmenwerke das TPRM-Modul abbildet

  • DORA Art. 28
  • DORA Art. 29/30
  • MaRisk AT 9
  • FINMA-RS 2018/3
  • EBA GL/2019/02
  • DSGVO Art. 28
Ein Modul, zwei Pfade — DORA ICT Services und MaRisk-Auslagerungen
Avalon TPRM führt ICT Services bzw. IKT-Dienstleistungen nach DORA und Auslagerungen nach MaRisk AT 9 in einem Datenmodell. Die Einordnung bleibt getrennt: DORA-Pflichten knüpfen an IKT-Dienstleistungen, IKT-Drittdienstleister und kritische oder wichtige Funktionen an; MaRisk-Pflichten knüpfen an den Auslagerungstatbestand und die Wesentlichkeit an.
DORA (EU) 2022/2554 — Art. 28
Avalon adressiert Art. 28 über die Kritikalitätsableitung kritischer/wichtiger Funktionen (CIF), eine geführte Einordnung von IKT-Drittdienstleistungen und eine belastbare Datenbasis für Register, Reviews und Prüfungen. DORA bezieht sich auf vertragliche Vereinbarungen über IKT-Dienstleistungen mit IKT-Drittdienstleistern; Avalon behandelt diese deshalb nicht pauschal als MaRisk-Auslagerung, sondern führt die regulatorische Einordnung im Quick Check.
DORA Art. 29 / Del-VO (EU) 2024/1502 — Konzentrationsrisiko
Das Konzentrationsrisiko wird je Dienstleister aus mehreren regulatorisch hergeleiteten Faktoren ermittelt (u. a. Abhängigkeit kritischer Funktionen, Kosten-, Prozess- und Standort-Konzentration, Substituierbarkeit, Weiterverlagerungs-Tiefe), als Ampel ausgewiesen und durch eine Ausfallsimulation untermauert.
DORA Art. 30 — Vertragsanforderungen
Die Vertragsprüfung stellt die Pflichtklauseln regulierungsabhängig zusammen und prüft DORA-relevante IKT-Drittdienstleistungen gegen Art. 30(2)/(3): uneingeschränktes Audit-Recht, quantitative SLAs, getestetes Provider-BCP, Weiterverlagerung, Standortangaben, Exit-Unterstützung. Lücken werden als Findings, Auflagen oder Nachbesserungsbedarf sichtbar.
DORA Art. 28(8) / RTS 2024/1773 — Exit-Strategie, Exit-Plan und Tests
Avalon trennt drei Ebenen: Die Exit-Strategie ist die institutsseitige Ausstiegsentscheidung mit Triggern, Alternativen und Verantwortlichkeiten. Der Exit-Plan ist der konkrete, mit dem Dienstleister entwickelte Umsetzungsplan inklusive Datenrückgabe/-löschung, Transition-Schritten und Mitwirkungspflichten. Exit-Plan-Tests werden terminiert, dokumentiert, mit Findings versehen und als getesteter Planstand nachweisbar gemacht.
MaRisk AT 9 / AT 4.4.2
MaRisk AT 9 ist der Auslagerungspfad innerhalb des TPRM-Spektrums: Erst wenn der Leistungsbezug als Auslagerung einzuordnen ist, greifen die AT-9-Anforderungen und die Wesentlichkeitsprüfung. Der Quick Check unterscheidet wesentliche und nicht wesentliche Auslagerungen, berücksichtigt IKT-/CIF-Kontext, §25b KWG und liefert die Datenbasis für anzeigepflichtige Sachverhalte nach MaRisk AT 9.6. Meldungen und Anzeigen bleiben organisatorische Entscheidungen Ihrer Institution.
FINMA-RS 2018/3 – Outsourcing (Banken und Versicherer)
Für Schweizer Banken und Versicherer kann der TPRM-Prozess als strukturierter Nachweisraum für Outsourcing-Sachverhalte genutzt werden: Auslagerungsinventar, Risikoanalyse, Dienstleisterprüfung, Vertrags-/Kontrollnachweise, Weiterverlagerung, laufende Überwachung und Exit-/Rückführungslogik. Die Einordnung bleibt vom DORA- und MaRisk-Pfad getrennt und wird im kundenspezifischen FINMA-Perimeter bestätigt.
EBA GL/2019/02 · BaFin MaGo §12 · DSGVO Art. 28
Laufendes Monitoring und Risikoanalyse bei Änderungen folgen EBA GL/2019/02; für Versicherer greifen die MaGo-§12-Überwachungspflichten; die Datenschutz-Votierung prüft Auftragsverarbeitung und Drittlandtransfer nach DSGVO Art. 28/44-49.

Avalon unterstützt die Umsetzung dieser Rahmenwerke. Die Konformität bleibt in der Verantwortung Ihrer Organisation.

KI-PlattformEntscheidungshoheit: Mensch entscheidetStatus: Live mit Rollout-Scope

KI als Prozess-Co-Pilot — Vorarbeit automatisch, Entscheidung beim Menschen

Die KI-Mechanik im TPRM-Modul ist auf breite Prozessvorbereitung ausgelegt: Sie kann Informationen über Dienstleister und Dienstleistung aus bereitgestellten Quellen lesen — öffentliche Anbieterinformationen, Verträge, Vertragsentwürfe, Präsentationen, Angebote, Briefings, Datenblätter, Whitepaper, E-Mails oder Sprachmemos — und daraus Stammdaten, Quick-Check-Antworten, DRA-/BPDD-Felder, Vertragsprüfungen, Informationsregister-Hinweise sowie institutsseitige Exit-Strategie-Entwürfe vorbereiten. Jede Ausgabe bleibt eine prüfbare Vorbefüllung mit Quelle, Quellenausschnitt, Begründung, Plausibility-Status und Konfidenz. Der Mensch nimmt die managende Rolle ein: prüfen, qualitätssichern, korrigieren, übernehmen oder ablehnen. Der Exit-Plan wird anschließend mit dem Dienstleister entwickelt und getestet. Der TPRM-Lebenszyklus bleibt vollständig manuell bedienbar; finale Entscheidungen, Workflow-Status, Klassifizierungen und Freigaben setzt immer der Mensch.

Optionaler KI-Baustein

TPRM wird durchgängig vorbereitet – vom Intake bis Exit

KI kann bereitgestellte Quellen über den gesamten Drittdienstleistungsprozess auswerten. Sie befüllt Felder vor, setzt aber keine finale Einordnung als ICT Service, Auslagerung oder sonstiger Fremdbezug.

Wo KI im Prozess eingreift
  • Intake und Stammdaten werden aus Multi-Source-Unterlagen feldweise vorbereitet.
  • Quick-Check-, DRA-/BPDD- und Vertragsprüfungsfelder erhalten Quelle, Ausschnitt und Konfidenz.
  • Exit-Strategie wird institutsseitig vorbereitet; der Exit-Plan bleibt mit dem Dienstleister entwickelt und getestet.
Assessment-VorbefüllungVORSCHLAG
Schutzbedarfs-Assessment
Vorbefüllt
Methode: CIA · Maximumprinzip · VVT-0091
IHRE ENTSCHEIDUNG
On-Premise · kein Datenabfluss · EU-AI-Act-konform
Ohne KI
  • Fachbereich und TPRM erfassen Dienstleistung, Vertrag, Quick Check, DRA, BPDD und Exit manuell.
  • DORA- und MaRisk-Pfade bleiben getrennt und folgen kundenspezifischer Methodik.
  • Second-Line-Voten, Final Review, Aktivierung und Exit-Tests sind vollständig nutzbar.
Mit KI
  • KI liest Briefings, Verträge, Angebote, Datenblätter, Mails und Sprachmemos zur Feldvorbefüllung.
  • Quick Check, DRA, BPDD, Vertragsprüfung, Registerdaten und Exit-Strategie starten mit Quellenbezug.
  • TPRM-Teams steuern Qualität, Plausibilität und Review statt Informationen aus Dokumenten zu extrahieren.
  • Multi-Source-Prefill: Die KI liest die vom Nutzer bereitgestellten Quellen und bereitet den gesamten TPRM-Prozess feldweise vor — vom Intake über Quick Check, DRA, BPDD und Vertragsprüfung bis zur Exit-Strategie.
  • Qualitätssicherung statt Blindübernahme: Jedes Feld zeigt Quelle, Quellenausschnitt, Plausibility, Konfidenz und Review-Status; Nutzer übernehmen, bearbeiten oder lehnen gezielt ab.
  • Audit-Trail & klare Grenze: jeder KI-Lauf, jede Übernahme, Korrektur und Ablehnung landet im Audit-Trail; die KI setzt keine Freigaben, keinen Workflow-Status und keine finale regulatorische Klassifizierung.
Wie KI mit Kontrolle bei Avalon funktioniert

Häufige Fragen zum TPRM-Modul

Avalon TPRM deckt beide Steuerungspfade ab: ICT Services bzw. IKT-Dienstleistungen nach DORA sowie Auslagerungen nach MaRisk AT 9. DORA wird insbesondere über Art. 28 (Governance, Register- und Vorabprüfungslogik), Art. 29 (Konzentrationsrisiko) und Art. 30 (Vertragsanforderungen) adressiert; MaRisk AT 9 greift als eigener Auslagerungspfad, wenn der Auslagerungsbegriff erfüllt ist. Die aufsichtliche Verantwortung bleibt bei Ihrer Organisation.

Über mehrdimensionale Bewertungslogik – Substituierbarkeit, Datenzugriff, Konzentrationsrisiko – mit transparentem Score und Begründung pro Dimension.

Der Quick Check liefert eine fachlich lesbare Einordnung des Leistungsbezugs: wesentliche Auslagerung, nicht wesentliche Auslagerung oder sonstiger Fremdbezug; jeweils ergänzt um IKT-Bezug, Unterstützung einer kritischen oder wichtigen Funktion (CIF) und die daraus folgenden Pflichten. Geprüft werden Leistungsart, Wesentlichkeit bei Auslagerungen, IKT-Bezug, CIF-Kontext, Ausfallauswirkung, Datenzugriff, Ersetzbarkeit, Konzentration, Datenstandort und weitere kundenindividuell konfigurierbare Kriterien. Bei Widersprüchen – etwa CIF-Kontext bei einer zunächst nicht wesentlichen Auslagerung – setzt Avalon einen Warnhinweis und fordert eine fachliche Prüfung. Unzulässige Auslagerungskonstellationen können den Prozess stoppen.

Ja, inkl. Metadaten, Laufzeiten, kritischen Klauseln und Verknüpfung zu betroffenen Prozessen und Assets. Erinnerungen für Reviews sind automatisiert.

Über regelmäßige Reviews, KPI-Tracking und Eventualfall-Workflows – alles in der gleichen Plattform wie Risiken, Compliance und ISMS.

Ja. Assessment-Templates, Quick-Check-Fragen, DRA-/BPDD-Fragenkataloge, Vertragsprüfungs-Checklisten, Pflichtdokumente, Review-Zyklen, KPI-Schwellenwerte, Eskalationen und Reviewer-Routing können kundenspezifisch an die eigene Methodik angepasst werden.

Module

Welches Modul passt zu Ihrem nächsten Schritt?

Wir zeigen Ihnen Avalon entlang Ihrer aktuellen Fragestellung – konkret, in Ihrem Kontext, ohne Standard-Sales-Demo.

  • On-Premise
  • Human-in-the-Loop
  • EU-AI-Act-Governance

On-Premise · KI-Inferenz auf Ihrer Appliance