Exit-Option für Customer-Engagement-Workloads: CDP, Personalisierung und Kampagnen DORA-konform absichern

Teil 4 von 7 unserer DORA-Serie: Dieser Beitrag beschreibt eine Anbieterperspektive von Acceleraid. Er beantwortet nicht, ob eine Bank eine konkrete Plattform ersetzen muss. Er zeigt, wie Banken für Customer-Engagement-Workloads eine belastbare Exit- und Backup-Option bewerten können – und welche Eigenschaften Acceleraid nach eigenen Angaben dafür anbietet. Die Rechts- und Risikoeinstufung bleibt Aufgabe des Instituts.

Autor: acceleraid Redaktion

Warum gerade Customer Engagement einen Exit-Pfad braucht

CDP, Personalisierung und Kampagnensteuerung sind keine nebensächlichen Marketingwerkzeuge, sobald sie Kundendaten, Einwilligungen, Kommunikationslogik und vertriebsrelevante Entscheidungen bündeln. Eine Bank sollte für jeden Workload die potenziellen Folgen eines Ausfalls, die Austauschbarkeit und den Schutz personenbezogener Daten nachvollziehbar bewerten. Für CRM-, CDP- und Marketing-Automation-Workloads folgt daraus kein automatisches Etikett „kritisch“. Sie können jedoch zu relevanten Bewertungsobjekten werden, wenn ihre Unterbrechung Kundenkommunikation, Datenrechte oder ein wesentliches Geschäftsergebnis beeinträchtigt. Teil 7 dieser Serie erläutert die Einstufung von Core Banking bis CDP. Wenn die Bank den Workload als kritisch oder wichtig einstuft, verlangt DORA umfassende, dokumentierte, ausreichend getestete und regelmäßig überprüfte Ausstiegspläne; alternative Lösungen und Übergangspläne müssen die sichere Übertragung der Dienste und zugehörigen Daten ermöglichen. Artikel 28 Absatz 8 DORA.

Das Ziel ist nicht, bei jeder Kampagne den Anbieter wechseln zu können. Das Ziel ist, einen kontrollierten Pfad zu besitzen, bevor die Beziehung unter Druck gerät: bei schwerer Störung, Vertragsbeendigung, strategischem Anbieterwechsel oder einer aufsichtsrechtlich verlangten Reaktion.

Ein Exit ist ein Workload-Projekt, kein Datenexport

Eine CSV-Datei kann wichtig sein, beweist aber noch keine Betriebsfähigkeit. Ein Customer-Engagement-Workload besteht mindestens aus vier Ebenen: Daten und Identitäten, Entscheidungs- und Segmentierungslogik, Integrationen zu Kanälen sowie Betriebs- und Kontrollartefakte. Ein belastbarer Exit beantwortet für jede Ebene eine andere Frage.

Diese Struktur trennt Portabilität von Gleichwertigkeit. Daten lassen sich häufig exportieren, während segment- oder kanalspezifische Logik neu konfiguriert werden muss. Ein sauberer Exit-Plan benennt diese Lücke, statt sie hinter dem Versprechen einer „nahtlosen Migration“ zu verstecken. Teil 2 unserer Serie zeigt, warum Exit-Pläne nicht nur geschrieben, sondern durch Desktop-Review, Walkthrough und kritische Migrationstests validiert werden müssen.

Der Data Act setzt für Cloud-Switching wichtige Leitplanken. Der reguläre Übergangszeitraum darf höchstens 30 Kalendertage dauern, die maximale Kündigungsfrist beträgt zwei Monate. Bei technischer Unmöglichkeit muss der Anbieter innerhalb von 14 Arbeitstagen informieren; der alternative Übergangszeitraum ist auf höchstens sieben Monate begrenzt. Ab 12. Januar 2027 sind Wechselentgelte untersagt. Artikel 25 und 29 der Data-Act-Verordnung geben damit einen Vertragsrahmen, aber keine Garantie für die fachliche Migration einer Kampagnenlandschaft.

Welche Portabilitätsrechte bereits bestehen

Für personenbezogene Daten ergänzt die DSGVO den Blick auf den einzelnen Betroffenen: Artikel 20 gibt unter seinen Voraussetzungen das Recht auf Erhalt in einem strukturierten, gängigen und maschinenlesbaren Format und, soweit technisch machbar, auf direkte Übermittlung an einen anderen Verantwortlichen. Artikel 20 DSGVO ist kein allgemeines Migrationsrecht für alle CDP-Artefakte. Er schärft aber die Erwartung, Datenflüsse und Formate nicht erst beim Exit zu verstehen.

Der Data Act geht für die dort erfassten Datenverarbeitungsdienste weiter: Er verlangt Unterstützung bei der Exit-Strategie, eine Datenabruffrist von mindestens 30 Kalendertagen, Datenexport in strukturiertem, gängigem und maschinenlesbarem Format sowie kostenlose offene Schnittstellen. Geistiges Eigentum und Geschäftsgeheimnisse müssen dabei nicht offengelegt werden. Artikel 25 und 30 Data Act markieren deshalb eine realistische Grenze: Portabilität ist eine Vertrags- und Schnittstellenaufgabe, keine identische Kopie jedes Produkts.

Die Acceleraid-Perspektive: eine Option bewerten, nicht versprechen

Acceleraid positioniert sich in diesem Kontext als mögliche Ziel- oder Backup-Option für abgegrenzte Customer-Engagement-Workloads. Das ist eine Anbieterperspektive, keine unabhängige Feststellung zur Eignung für jeden Anwendungsfall. Eine Bank sollte sie gegen eigene Architektur, Risikoanalyse, Verträge und Tests halten.

Für die Bereitstellung nennt Acceleraid mehrere Betriebsoptionen: Private Cloud bei LeaseWeb in Frankfurt, On-Premise im Rechenzentrum der Bank oder Betrieb in einer bestehenden AWS-, Azure- oder GCP-Umgebung. Die Seite „Why Acceleraid“ beschreibt diese Optionen. Diese Wahlmöglichkeit kann für einen Exit-Pfad relevant sein, weil Zielumgebung, Datenresidenz und Verantwortungsmodell vorab entschieden werden können. Sie ersetzt jedoch nicht die Prüfung, ob konkrete Schnittstellen, Datenvolumen, Sicherheitsvorgaben und Betriebsrollen im Institut passen.

Architektur- und Kontrollfragen vor einem Parallelbetrieb

Ein Parallelbetrieb sollte nicht mit einer großflächigen Datenkopie starten. Sinnvoller ist ein begrenzter Scope mit klarer Vergleichslogik: eine Zielgruppe, ein Datenmodell, ein Kanal und messbare Abnahmekriterien. Erst wenn fachliche Ergebnisse, Berechtigungen und Kontrollnachweise übereinstimmen, kann die Bank über einen gestuften Cutover entscheiden. Das nachstehende Schaubild ist bewusst ein Vorgehensmodell, keine Zusage zu Dauer oder Ergebnis.

Nach Angaben von Acceleraid aggregiert das CDP-Modul Daten in Echtzeit aus CRM, Core Banking und Kartenverarbeitung und umfasst Consent Management, vollständige Data Lineage, rollenbasierte Zugriffskontrolle und PII-Schutz. Die Plattformseite nennt diese Merkmale. Für eine Exit-Bewertung sind solche Funktionen nur dann hilfreich, wenn sie im Zielbild konkret nachgewiesen werden: Welche Felder kommen an, wie werden Einwilligungen abgebildet, wer darf exportieren, und wie lassen sich Abweichungen nachvollziehen?

Die Security-Seite nennt PII-Filterung und Schwärzung auf Feldebene vor dem Modellzugriff, Pseudonymisierung und Datensparsamkeit sowie getrennte Verschlüsselungsschlüssel je Kunde; BYOK sei für besonders sensible Bereitstellungen verfügbar. Sie nennt zudem SOC 2 Type I, Drittanbieter-Penetrationstests und jährlich getestetes BC/DR. Die Sicherheitsangaben von Acceleraid sind Selbstauskünfte des Anbieters. Sie ersetzen weder eine bankeigene Due Diligence noch vertragliche DORA-Mindestinhalte wie Datenrückgabe, Leistungsorte, Kündigungsrechte und Übergangszeit.

Für GenAI beschreibt Acceleraid eine modellagnostische Anbindung, Azure- und Google-Cloud-Verträge des Kunden sowie Open-Source-Modelle in eigener Infrastruktur als Optionen und verwendet selbst den Begriff „No vendor lock-in“. Die GenAI-Produktseite ist ein relevanter Input für die Architekturprüfung, keine absolute Lock-in-Garantie. Teil 6 ordnet diese Frage als Modell-Abhängigkeit unter DORA ein.

Ein nachvollziehbares Entscheidungspaket

Für einen belastbaren Beschluss braucht die Bank nicht zuerst eine Produktdemonstration, sondern ein Testmandat. Es sollte den Ausgangsworkload, die zulässigen Daten, die Zielumgebung, die Export- und Importformate, die erforderlichen Kontrollen und eindeutige Abbruchkriterien festlegen. Danach folgen vier Nachweise: Daten- und Consent-Abgleich, fachliche Validierung ausgewählter Journeys, technische Prüfung der Integrationen und ein Betriebs-Walkthrough mit den zuständigen Teams.

Erst auf dieser Basis lässt sich bewerten, ob Acceleraid im konkreten Fall als Zielplattform, als teilweise Ausweichoption oder gar nicht in Betracht kommt. Diese Offenheit ist kein Mangel des Exit-Plans. Sie ist sein Kern: DORA-konforme Resilienz verlangt nachvollziehbare Alternativen – nicht pauschale Garantien.

Die DORA-Serie im Überblick

• Teil 1: DORA für Banken: Was die EU-Verordnung regelt und wie sie funktioniert

• Teil 2: Der Exit-Plan nach DORA: Was er enthalten muss und warum er getestet werden muss

• Teil 3: Cloud-Abhängigkeit europäischer Banken: Wie man von AWS, Microsoft und Google notfalls loskommt

• Teil 4: Exit-Option für Customer-Engagement-Workloads: CDP, Personalisierung und Kampagnen DORA-konform absichern (dieser Beitrag)

• Teil 5: Das DORA-Informationsregister: Warum es in Wahrheit ein Datenqualitätsproblem ist

• Teil 6: KI-Anbieter als neues Konzentrationsrisiko: Was DORA für Modell-Abhängigkeiten bedeutet

• Teil 7: Kritisch oder wichtig? Risiko-Level von Core Banking bis CRM, Data Lake und CDP

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.