Digital operational resilience, product security, AI governance and data protection in the financial sector

How DORA, the Cyber Resilience Act, the EU AI Act, the GDPR and NIS2 interact for financial entities

Financial entities operating in the European Union are subject to a set of interlocking instruments that address different layers of digital risk. The Digital Operational Resilience Act (DORA) is the specialised framework for the financial sector. The Cyber Resilience Act (CRA) regulates products with digital elements that financial entities use or place on the market. The EU Artificial Intelligence Act regulates the development and deployment of AI systems. The General Data Protection Regulation (GDPR) continues to govern the processing of personal data. The Network and Information Security Directive (NIS2) has only limited residual application to financial entities because DORA takes precedence as lex specialis.

DORA applies to a defined range of financial entities, including credit institutions, payment institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, and central securities depositories. It also brings certain critical ICT third-party service providers within a direct oversight regime. Its five pillars require a documented ICT risk management framework under board-level responsibility, formal incident classification and reporting with tight timelines, regular digital operational resilience testing (including threat-led penetration testing for systemically important entities), rigorous third-party ICT risk management with registers and contractual rights, and voluntary information-sharing arrangements. The objective is continuity and recovery rather than absolute prevention.

Because DORA is a regulation tailored to financial entities and is more detailed on ICT operational resilience, it overrides NIS2 where the two overlap. Financial entities do not maintain a parallel NIS2 compliance programme. ICT risk management, incident reporting, testing and third-party oversight are performed under DORA. NIS2 may still touch residual non-ICT supply-chain relationships (for example physical facility management or non-digital logistics) and will apply directly to ICT vendors that supply the financial sector. Critical ICT third-party providers may themselves become subject to direct DORA oversight.

The Cyber Resilience Act applies to financial entities in two ways. Where a financial entity places products with digital elements on the EU market-mobile banking applications, customer portals, proprietary trading applications, ATM software or payment devices-it is a manufacturer under the CRA. It must implement security-by-design, maintain a software bill of materials, manage vulnerabilities and provide security updates for the support period, and meet conformity assessment requirements. Where the entity merely uses third-party software and hardware, it is an end-user. In that case the CRA obligations fall on the manufacturers, but the financial entity's DORA third-party risk management is facilitated by the CRA's requirements for transparency, patching and documentation. Vulnerability management under DORA Articles 6-10 is supported by the patches and disclosures that CRA-compliant vendors must provide. Software bills of materials required by the CRA improve the transparency that DORA expects in vendor assessments.

High-risk AI systems used by financial entities-credit scoring, insurance pricing, certain automated underwriting or fraud systems-engage the EU AI Act. Providers of such systems must implement a risk management system, data governance, technical documentation, human oversight and cybersecurity measures. Deployers have obligations relating to use, monitoring and fundamental-rights impact assessment where Article 27 applies. DORA's ICT risk framework can incorporate the AI-specific risk management required by the AI Act rather than running two separate systems. Technical documentation and transparency obligations under the AI Act, together with software bills of materials under the CRA, give financial entities the information they need for DORA third-party registers and due diligence when AI components are supplied by third parties. Incident reporting paths can converge: a single event may require reporting under DORA to financial supervisors, under the CRA to CSIRTs/ENISA for exploited product vulnerabilities, and under the AI Act to market surveillance authorities for serious incidents affecting health, safety or fundamental rights. Coordinated reporting channels are intended to reduce duplication.

GDPR remains fully applicable. Personal data processed in ICT systems, in AI training or inference, or in incident response must still meet the GDPR's conditions for lawful processing, data minimisation, purpose limitation, security (Article 32), and data-subject rights. A major ICT incident under DORA that involves personal data will normally also trigger GDPR breach-notification obligations (Articles 33 and 34). AI systems that make decisions producing legal or similarly significant effects on individuals engage GDPR Article 22 in addition to AI Act requirements. Data protection impact assessments under GDPR can be aligned with, but are not replaced by, fundamental-rights impact assessments under the AI Act or ICT risk assessments under DORA. Contracts with processors and sub-processors must satisfy both GDPR Article 28 and the third-party provisions of DORA.

In practice a financial entity treats DORA as the central operational architecture for ICT resilience. It uses the CRA as a procurement and product-development standard: demanding CRA-compliant products and software bills of materials from vendors, and meeting CRA obligations itself for any digital products it places on the market. It overlays the EU AI Act's risk-management, data-governance and human-oversight requirements on any high-risk AI systems it provides or deploys, integrating those requirements into the DORA framework where possible. GDPR continues to govern all personal-data processing and supplies additional notification and rights obligations that run alongside the other instruments. NIS2 does not require a separate management system.