What CADA assurance level should a bank target for core banking workloads?

Under the proposed Cloud and AI Development Act (CADA), banks do not face a single, fixed mandate for a specific assurance level for all core banking workl

Summary Under the proposed Cloud and AI Development Act (CADA), banks do not face a single, fixed mandate for a specific assurance level for all core banking workloads. Instead, the regulation establishes a risk-based framework where the appropriate level is determined by the sensitivity, criticality, and magnitude of the data processed. While Union Assurance Level 1 serves as the baseline for non-critical activities, core banking operations—characterized by systemic importance and sensitive personal data—will typically require Union Assurance Levels 2, 3, or 4 to safeguard public order and ensure operational autonomy. The specific target level depends on the outcome of a mandatory risk assessment under Article 29 (for public sector) or Article 31 (for private sector entities in critical sectors), which evaluates the risk of unlawful third-country access or service disruption.

Detail

The proposed Cloud and AI Development Act (CADA), COM(2026) 502 final, introduces a sophisticated, risk-based sovereignty framework rather than a blanket prohibition on non-EU providers. For financial institutions, particularly banks managing core banking workloads, the critical task is mapping their specific data profiles to the four Union assurance levels defined in Article 16 and detailed in Annex II. This mapping is not arbitrary; it is driven by the necessity to preserve public order and financial stability.

The Four Union Assurance Levels: A Hierarchy of Sovereignty

Article 16 establishes a Union cloud computing sovereignty framework comprising four distinct assurance levels. These levels represent a gradient of legal, operational, and physical sovereignty, with criteria escalating in strictness as defined in Annex II.

Union Assurance Level 1 (Baseline): This level serves as the minimum threshold for cloud services procured by public sector bodies whose activities do not contribute to the preservation of public order. Under Annex II (1.1), providers must be established in the Union, and infrastructure and assets (including subcontractors) must be located in the Union unless explicitly required otherwise by the public sector body. Customer data, including metadata and telemetry, must remain exclusively within the Union. Crucially, if a provider is subject to third-country control, they must guarantee that no laws in that third country require the reporting of software vulnerabilities to foreign authorities prior to exploitation. While this offers a baseline of data residency, it does not mandate Union citizenship for personnel or prohibit third-country control over the provider itself, provided specific transparency measures are met.
Union Assurance Level 2 (Operational Autonomy): Level 2 introduces stricter requirements for operational autonomy and supply chain integrity. Annex II (2.1) mandates that the audited provider and its subcontractors be established in the Union, with infrastructure, assets, and personnel located within the Union. A critical differentiator is the prohibition on using data generated by the service to train or fine-tune any AI system operated by a third country. Providers must obtain a European cybersecurity certificate of at least assurance level 'substantial' (as per the Cybersecurity Act) or demonstrate compliance with the highest cybersecurity standards. Furthermore, strict software supply chain measures are required, including a complete Software Bill of Materials (SBOM) and controls to block remote tampering features in third-country software components.
Union Assurance Level 3 (High Sensitivity & Personnel Control): Designed for higher sensitivity, Level 3 adds rigorous personnel and control constraints. Annex II (3.1) requires that all personnel involved in the provision of the service, including subcontractors, be Union citizens. Where appropriate, personnel handling classified information must possess necessary national security clearances. The provider and subcontractors must not be subject to the control of a third country. However, a specific derogation exists: a provider subject to third-country control may still qualify for Level 3 if the Commission has adopted an implementing act under Article 18 identifying that third country as providing sufficient assurances. (Note: The text of Annex II 3.1(g) contains a drafting slip referencing "Article 19" for this derogation; however, Article 18 is the correct legal basis for "Associated third countries" and the mechanism for such implementing acts). Technical and operational support must be performed exclusively within the Union by Union residents and third parties not subject to third-country control.
Union Assurance Level 4 (Maximum Sovereignty): This is the highest tier, intended for the most critical workloads involving classified or highly sensitive data. Annex II (4.1) requires that sensitive data, as identified by a risk assessment, remain exclusively within the Union. Personnel must be Union citizens with necessary security clearances. The service must obtain a European cybersecurity certificate of at least assurance level 'high'. Crucially, the provider and subcontractors must not be subject to the control of a third country under any circumstances. The provider must demonstrate effective control over software components, ensuring that no third country holds effective control over the design, development, maintenance, or evolution of those components.

Mapping Data Sensitivity to Assurance Levels

The CADA proposal explicitly frames the selection of an assurance level as a risk-based choice, not a fixed mandate for all sectors. Recital 63 highlights that in their risk assessments, Union entities and Member States shall assess the "sensitivity, criticality and magnitude of personal and non-personal data processed in cloud environment." This processing may include ordinary business information, commercially sensitive information, operationally critical data, and personal data within the meaning of the GDPR.

For banks, core banking workloads typically involve a confluence of these data types:

Personal Data: Extensive customer data subject to GDPR, including financial histories and identities.
Operationally Critical Data: Transaction records, account balances, and payment systems essential for the functioning of the financial sector.
Commercially Sensitive Information: Proprietary algorithms, risk models, and client portfolios.

Recital 63 further notes that the Commission will provide centrally coordinated guidance on the mapping between Union assurance levels and categories of information. This mapping will consider the systematic importance of the activities and applicable obligations arising from Union law. Consequently, a bank cannot arbitrarily select Level 1 for core banking if the data sensitivity and systemic importance dictate a higher level of protection. The risk assessment acts as the bridge between the nature of the data and the required assurance level.

The Role of Risk Assessments: Public vs. Private Sector

Article 29 of the CADA proposal obliges Member States and Union entities to carry out risk assessments to determine which Union assurance level (2, 3, or 4) is appropriate for identified public sector activities that contribute to the preservation of public order. While Article 29 primarily targets public sector bodies, Article 31 extends this logic to the private sector. It allows entities referred to in Annex I of the NIS2 Directive (which includes financial sector entities) to carry out similar impact assessments.

Recital 66 explains that public procurement requirements tend to be mirrored by private-sector entities in regulated industries. Consequently, banks are expected to perform similar risk assessments to determine the appropriate assurance level for their cloud workloads. The assessment must consider:

The sensitivity and criticality of the data.
The risk of unlawful access by a third country.
The risk of service disruption.

If a bank's core banking workload is deemed to have "public order relevance" due to its systemic importance to the financial sector, it may be required to procure services recognized as offering Union Assurance Levels 2, 3, or 4, as per Article 30(3). Even if not strictly mandated by public procurement rules, the risk of regulatory scrutiny and the need to ensure operational resilience under the Digital Operational Resilience Act (DORA) and CADA will push banks toward higher assurance levels.

Implications for Core Banking Workloads

Core banking systems are the backbone of financial institutions. They process real-time transactions, manage customer accounts, and interact with payment systems. The failure or unauthorized access to these systems could have severe consequences for financial stability and consumer trust.

Given the high sensitivity of financial data and the critical nature of these operations, Union Assurance Level 1 is likely insufficient for most core banking workloads. Level 1 allows for some flexibility in subcontractor locations and does not mandate Union citizenship for personnel or strict prohibitions on third-country control over software supply chains to the same extent as Levels 2-4.

Union Assurance Level 2 offers a stronger baseline with requirements for Union-based infrastructure and personnel, and prohibitions on using customer data for third-country AI training. However, for highly sensitive core banking data, Levels 3 or 4 may be necessary. Level 3 adds the requirement for Union citizen personnel and stricter controls on third-country influence. Level 4 provides the highest level of sovereignty, ensuring no third-country control over software components and requiring high-level cybersecurity certification.

The choice between Levels 2, 3, and 4 will depend on the specific risk assessment outcomes. For example, if a bank uses AI models for credit scoring or fraud detection, the requirements in Annex II regarding the non-use of customer data for third-country AI training (Level 2 and above) become particularly relevant. If the bank's systems are considered critical infrastructure under NIS2, the pressure to adopt Level 3 or 4 increases.

What this means for you

For CTOs, compliance officers, and architects in the banking sector, the CADA proposal necessitates a fundamental shift in cloud strategy. You can no longer rely solely on GDPR compliance and standard cybersecurity certifications. You must now evaluate your cloud providers against the four Union assurance levels.

Conduct a Comprehensive Risk Assessment: Begin by mapping your core banking workloads. Identify which systems process sensitive personal data, commercially sensitive information, or operationally critical data. Assess the potential impact of third-country access or service disruption. This assessment will guide your choice of assurance level.
Evaluate Current Providers: Check if your current cloud providers can meet the requirements of Union Assurance Levels 2, 3, or 4. Many major hyperscalers may not currently meet the strictest requirements, particularly regarding third-country control and personnel citizenship. You may need to engage with European sovereign cloud providers or demand significant changes from existing vendors.
Plan for Migration: If your current providers do not meet the required assurance level, start planning a migration strategy. This may involve multi-cloud strategies, as suggested in Recital 65, to distribute risk and ensure resilience. Ensure that any migration maintains data integrity and operational continuity.
Engage with Regulators: Stay informed about the guidance the Commission will provide on mapping data sensitivity to assurance levels. Engage with national competent authorities to understand how they interpret the risk assessment requirements for the financial sector.
Consider DORA Compliance: Align your CADA compliance efforts with your Digital Operational Resilience Act (DORA) obligations. DORA requires financial entities to manage ICT risks, and CADA's assurance levels provide a framework for mitigating sovereignty-related ICT risks.

Common misconceptions

"All banking workloads must be at Level 4." This is incorrect. CADA is risk-based. Not all banking data is equally sensitive. While core banking systems may require Level 3 or 4, less sensitive workloads, such as internal HR systems or public-facing informational websites, may only require Level 1 or 2. The risk assessment determines the appropriate level.
"GDPR compliance is enough for cloud sovereignty." GDPR focuses on data protection and privacy. CADA focuses on sovereignty, operational autonomy, and protection against third-country interference. A provider can be GDPR-compliant but still subject to third-country laws that allow data access or service disruption, which CADA aims to prevent.
"Level 1 is sufficient for most financial data." Level 1 allows for some third-country involvement in subcontracting and does not prohibit third-country control over the provider in the same strict manner as Levels 2-4. Given the systemic importance of financial data, Level 1 is likely too weak for core banking workloads.
"Only public sector bodies are affected." While Article 29 targets public sector bodies, Article 31 and Recital 66 indicate that private sector entities in critical sectors, like finance, will be expected to conduct similar assessments. Market pressure and regulatory expectations will drive private sector adoption of higher assurance levels.

Official sources

This is general information about a draft EU regulation, not legal advice.