Critical or important? Risk levels from Core Banking to CRM, Data Lake, and CDP

Part 7 of 7 of our DORA series: The question "critical or important?" is not a technical label, but a governance decision for outsourcing, contracts, and resilience. It builds upon the exit plan under DORA and the analysis of the cloud dependency of European banks. This article shows why core banking and payment transactions are usually assessed differently than CRM, Data Lake, CDP, or marketing automation.

Author: acceleraid Editorial Team

The classification determines the depth of the obligations

DORA defines a "critical or important function" as a function whose failure would materially impair the financial performance, soundness, or continuity of business operations. The same applies if disrupted, faulty, or omitted execution materially impairs continuous compliance with licensing conditions and other obligations. The standard therefore does not first ask for the name of a system, but for the consequences of its failure. (DORA, Art. 3 No. 22 and Art. 28 and 30)

This distinction is the switch for the stricter requirements. For ICT services supporting critical or important functions, additional contract contents, exit strategies, structured recording in the information register, and resilience testing particularly come into focus. Therefore, "important" is not the milder, consequence-free alternative to "critical". Both terms form a common regulatory threshold under DORA.

For governance, this leads to a simple rule: applications are not classified globally by a central IT list. The business department describes the function and its failure impact; risk, compliance, data protection, procurement, and IT assess these traceably together. The result must speak the same language for contracts, registers, and the exit plan.

From system designation to business consequence

The EBA outsourcing guidelines specify the assessment. According to their criteria, a function is critical or important if a failure would materially impair licensing conditions, financial performance, or soundness and continuity. This also applies to outsourced operational tasks of internal control functions and to activities subject to authorization. The guidelines also identify core business areas, data protection, substitutability, alternatives, and time-criticality as relevant assessment and documentation points. (EBA/GL/2019/02, paras. 29–31 and 55)

For banks, deposit business, lending, and payment transactions are core business categories. Core banking and payment systems therefore typically fall into the critical category: a prolonged outage can impact service delivery, regulatory compliance, and customer trust all at once. The final assignment, however, remains an institution-specific assessment of the concrete function and its dependencies.

The practical question is therefore not: "Is this a cloud or SaaS application?" But rather: "What business capability fails if this service is unavailable?" A data lake, for example, might merely delay analytics. However, it can also aggregate data for risk management, regulatory reporting, or customer decisions. The same technology designation then leads to different risk profiles.

Customer systems: regularly relevant, never automatically identical

CRM, Data Lake, CDP, and marketing automation are not globally uncritical systems. They frequently process personal data, shape customer communication, and can be integrated into multiple journeys at once. Precisely for this reason, an individual assessment is required: failure impact, reputational and loss risk, transferability, reintegration, and the protection of personal data must be considered together.

For these customer-facing workloads, "important" is often the appropriate starting point of the assessment: not because marketing is automatically far removed from regulation, but because the bank must assess the combination of customer data, communication capability, business interruption, and switching options. A CRM, for instance, might be replaceable for a small-scale sales campaign. If it is also the leading system for advisory contacts, complaints, or required customer communication, this increases the failure impact. A CDP can deliver isolated target group lists; however, it can also connect identities, consents, and real-time activation for core journeys. The critical factor is the actual function performed, not the product label.

Similarly, a data lake cannot be classified solely by its technical role. Those who use it for historical evaluations assess different consequences than an institution that provides current risk data or decision-relevant customer information on it. Marketing automation is likewise not just a delivery channel: the assessment also factors in frequency rules, dependency on consent, consequences of errors, and the question of whether alternative communication channels will work in time.

The individual assessment therefore needs robust answers to five questions:

• What material business, control, or authorized activity is supported by the service?

• What happens during an outage to customers, payment or decision processes, reports, and deadlines?

• What personal data is stored there, and what would be the data protection consequences of an outage, unauthorized access, or faulty operation?

• Is an alternative provider or internal operation realistically available – with data, interfaces, know-how, and time?

• Can teams restore the function or hand it over in an orderly manner without creating new operational risks?

The questions connect business and technology. They also prevent the common misconception that an externally operated system must automatically be difficult to substitute. Substituability must be proven, not assumed.

Substituability is not a gut feeling

For the outsourcing register, the EBA requires an assessment of substitutability as "easy, difficult or impossible", the identification of alternative providers, details on time-criticality, and the annual budget. This turns the abstract switching risk into auditable documentation.

The DORA ITS anchor this logic in the register of information. B_06.01 serves to identify functions; B_07.01 captures assessments, including substitutability and the last audit. The same register logic distinguishes between IaaS, PaaS, and SaaS, as well as infrastructure/hosting and on-premise software. Recording a CDP as SaaS therefore does not replace the assessment of the customer function running on it. (DORA ITS, Regulation (EU) 2024/2956)

What specifically changes after classification

If an outsourced ICT service is classified as supporting a critical or important function, a general SaaS contract is not sufficient. It requires complete service level descriptions with qualitative and quantitative performance targets, contingency plans, ongoing monitoring, participation in TLPT, and an exit strategy with a binding transition period. Service and data processing locations must be transparent, and planned changes must be notified in advance.

The exit topic is not an appendix for the crisis folder. DORA demands comprehensive, documented, sufficiently tested, and regularly reviewed exit plans. The previous part of the series on the exit plan explains the test logic in detail. The ECB mentions at least an in-depth desktop review by expert staff, walkthroughs, periodic tests of critical migration steps, and an independent feasibility study as good practice. (ECB Cloud Guide)

With classification, the supply chain also becomes relevant. For critical or important functions, the relevant Delegated Regulation requires an eligibility decision before contract conclusion, audit rights down to the subcontractor chain, and recurring assessments, including geopolitical risks. (Delegated Regulation (EU) 2025/532) Anyone who assesses a CDP or marketing automation as important must therefore not only understand the function and data flow, but also bring together the contract, data locations, subcontractors, and handover path.

A brief look at Switzerland and the United Kingdom

Classification is not a purely European specialty topic. In Switzerland, FINMA Circular 2023/1 defines critical functions on an institution-specific basis and requires a disruption tolerance for each critical function. Business impact analyses are intended to determine recovery time objectives and recovery point objectives, secured via SLAs. (FINMA Circ. 2023/1)

In the UK CTP regime, a designated critical third party must establish a maximum tolerable level of disruption for each service and communicate it to the affected financial entities. The perspective there is focused on provider duties, but pursues the same operational question: Which service may fail and for how long? (Bank of England, PS16/24)

Conclusion: justify "important" cleanly, secure "critical" robustly

Core banking and payment transactions are typically critical because they connect directly to core banking functions and licensing requirements. Customer systems such as CRM, Data Lake, CDP, and marketing automation, on the other hand, are not a category with a predetermined outcome. They belong in a documented individual assessment and will frequently have to be treated as important functions depending on the failure impact, data context, and substitutability.

The correct working mode is therefore repeatable: define the function, assess the failure impact, check the data and dependency profile, prove substitutability, document the classification in the register, and manage the resulting contract and exit measures. In this way, DORA does not become a list of system names, but a robust decision on which banking capability must be protected in the event of a disruption.

The DORA series at a glance

• Part 1: DORA for Banks: What the EU Regulation covers and how it works

• Part 2: The Exit Plan under DORA: 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

• 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 (this article)

Illustration: AI-generated. AI-supported content: We use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers, in the creation of our articles. Topics, professional direction, and final approval remain with our team.