Exit Option for Customer Engagement Workloads: Securing CDP, Personalization, and Campaigns in a DORA-Compliant Manner

Part 4 of 7 of our DORA series: This post describes a provider perspective from Acceleraid. It does not answer whether a bank needs to replace a specific platform. It shows how banks can evaluate a resilient exit and backup option for customer engagement workloads – and which features Acceleraid claims to offer for this purpose. The legal and risk classification remains the responsibility of the institution.

Author: acceleraid editorial team

Why Customer Engagement in particular needs an exit path

CDP, personalization, and campaign management are not minor marketing tools once they bundle customer data, consent, communication logic, and sales-relevant decisions. A bank should comprehensibly evaluate the potential consequences of a failure, the interchangeability, and the protection of personal data for every workload. For CRM, CDP, and marketing automation workloads, this does not automatically result in a "critical" label. However, they can become relevant evaluation objects if their disruption affects customer communication, data rights, or a significant business outcome. Part 7 of this series explains the classification from Core Banking to CDP. If the bank classifies the workload as critical or important, DORA requires comprehensive, documented, sufficiently tested, and regularly reviewed exit plans; alternative solutions and transition plans must enable the secure transfer of services and associated data. Article 28 Paragraph 8 DORA.

The goal is not to be able to switch providers for every campaign. The goal is to have a controlled path before the relationship comes under pressure: during a severe disruption, contract termination, strategic provider change, or a regulatory-mandated response.

An exit is a workload project, not a data export

A CSV file can be important, but it does not yet prove operational capability. A customer engagement workload consists of at least four levels: data and identities, decision and segmentation logic, integrations to channels, and operational and control artifacts. A resilient exit answers a different question for each level.

This structure separates portability from equivalence. Data can often be exported, while segment- or channel-specific logic must be reconfigured. A clean exit plan identifies this gap instead of hiding it behind the promise of a "seamless migration." Part 2 of our series shows why exit plans must not only be written but also validated through desktop review, walkthrough, and critical migration tests.

The Data Act sets important guidelines for cloud switching. The regular transition period may last a maximum of 30 calendar days, and the maximum notice period is two months. In case of technical impossibility, the provider must inform within 14 working days; the alternative transition period is limited to a maximum of seven months. From January 12, 2027, switching charges are prohibited. Articles 25 and 29 of the Data Act Regulation thus provide a contractual framework, but no guarantee for the functional migration of a campaign landscape.

Which portability rights already exist

For personal data, the GDPR complements the view of the individual concerned: Article 20 grants, under its conditions, the right to receive data in a structured, commonly used, and machine-readable format and, where technically feasible, to have it transmitted directly to another controller. Article 20 GDPR is not a general migration right for all CDP artifacts. However, it sharpens the expectation to understand data flows and formats before an exit occurs.

The Data Act goes further for the data processing services covered therein: it requires support with the exit strategy, a data retrieval period of at least 30 calendar days, data export in a structured, commonly used, and machine-readable format, and free open interfaces. Intellectual property and business secrets do not have to be disclosed. Articles 25 and 30 of the Data Act therefore mark a realistic limit: portability is a contractual and interface task, not an identical copy of every product.

The Acceleraid perspective: evaluating an option, not promising one

In this context, Acceleraid positions itself as a possible target or backup option for defined customer engagement workloads. This is a provider perspective, not an independent assessment of suitability for every use case. A bank should evaluate it against its own architecture, risk analysis, contracts, and tests.

For deployment, Acceleraid lists several operational options: Private Cloud at LeaseWeb in Frankfurt, On-Premise in the bank's data center, or operation in an existing AWS, Azure, or GCP environment. The "Why Acceleraid" page describes these options. This choice can be relevant for an exit path because the target environment, data residency, and responsibility model can be decided in advance. However, it does not replace the assessment of whether specific interfaces, data volumes, security requirements, and operational roles fit the institution.

Architectural and control questions before parallel operation

A parallel operation should not start with a large-scale copy of data. A limited scope with clear comparison logic makes more sense: one target group, one data model, one channel, and measurable acceptance criteria. Only when functional results, authorizations, and control evidence match can the bank decide on a phased cutover. The diagram below is intentionally a procedural model, not a commitment to duration or results.

According to Acceleraid, the CDP module aggregates data in real-time from CRM, core banking, and card processing, and includes consent management, complete data lineage, role-based access control, and PII protection. The platform page highlights these features. For an exit evaluation, such features are only helpful if they are concretely verified in the target state: What fields arrive, how are consents mapped, who is allowed to export, and how can discrepancies be traced?

The security page mentions PII filtering and redaction at the field level prior to model access, pseudonymization, data minimization, and separate encryption keys per customer; BYOK is said to be available for highly sensitive deployments. It also mentions SOC 2 Type I, third-party penetration testing, and annually tested BC/DR. Acceleraid's security specifications are self-disclosures by the provider. They replace neither a bank's own due diligence nor mandatory DORA contractual content such as data return, locations of performance, termination rights, and transition periods.

For GenAI, Acceleraid describes model-agnostic connectivity, the customer's Azure and Google Cloud contracts, and open-source models in their own infrastructure as options, using the term "no vendor lock-in" themselves. The GenAI product page is a relevant input for architectural review, not an absolute lock-in guarantee. Part 6 classifies this issue as model dependency under DORA.

A comprehensible decision package

For a resilient decision, the bank does not first need a product demonstration, but a testing mandate. It should define the source workload, permitted data, target environment, export and import formats, required controls, and clear exit criteria. This is followed by four proofs: data and consent reconciliation, functional validation of selected journeys, technical review of integrations, and an operational walkthrough with the responsible teams.

Only on this basis can it be evaluated whether Acceleraid is suitable as a target platform, as a partial alternative option, or not at all in the specific case. This openness is not a flaw in the exit plan. It is its core: DORA-compliant resilience requires comprehensible alternatives – not blanket guarantees.

Overview of the DORA series

• Part 1: DORA for banks: What the EU regulation governs and how it works

• Part 2: The DORA exit plan: What it must contain and why it must be tested

• Part 3: Cloud dependency of European banks: How to get away from AWS, Microsoft, and Google if necessary

• Part 4: Exit option for customer engagement workloads: Securing CDP, personalization, and campaigns in compliance with DORA (this post)

• Part 5: The DORA register of information: Why it is actually a data quality problem

• Part 6: AI providers as a new concentration risk: What DORA means for model dependencies

• Part 7: Critical or important? Risk levels from core banking to CRM, data lake, and CDP

Illustration: AI-generated. AI-supported content: In creating our posts, we utilize AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, technical direction, and final approval remain with our team.