The General Framework

The Digital Operational Resilience Act (DORA) represents a seismic shift in the European regulatory landscape, moving beyond the traditional focus on financial capital resilience to a comprehensive standard for operational capability. In a hyper-connected global economy, the financial sector is no longer defined solely by its assets, but by the integrity of the digital systems that manage them. The General Framework of DORA establishes a unified rulebook designed to harden the European financial infrastructure against Information and Communication Technology (ICT) disruptions.

How to use this DORA library

This interface allows for rapid correlation between operational tasks and regulatory texts. Execute the following query protocols:

• If auditing your incident response plan or defining reporting fields: RTS (EU) 2025/301.
• If calculating aggregated annual losses from cyber events: Joint Guidelines (JC/GL/2024/34).
• If preparing the scope and Rules of Engagement for a TLPT: RTS (EU) 2025/1190.
• If drafting the ICT Risk Management Policy or reviewing crypto safeguards: RTS (EU) 2024/1774.
• If determining whether a disruption qualifies as a 'Major Incident': RTS (EU) 2024/1772.
• If defining the multi-vendor strategy or exit plans for cloud services: RTS (EU) 2024/1773.
• If populating the Register of Information for third-party dependencies: ITS (EU) 2024/2956.
• If assessing risks associated with sub-contractors supporting critical functions: RTS (EU) 2025/532.
• If harmonizing supervisory procedures for a Critical Third-Party Provider: RTS (EU) 2025/295.

The Core Objective:

To prevent systemic failures by ensuring that all financial entities—ranging from banks and insurance companies to crypto-asset service providers—can withstand, respond to, and recover from ICT-related threats.

The Five Pillars of Resilience

DORA structures its requirements around five distinct pillars, creating a holistic approach to cybersecurity and operational continuity. This is not a fragmented directive but a Regulation, meaning it applies directly and uniformly across all EU Member States without the need for national transposition.

ICT Risk Management:

Financial entities must establish a robust governance framework. This requires the management body to bear ultimate responsibility for ICT risk. Entities must identify their critical functions, map their assets, and implement protection and prevention measures. It is a transition from reactive firefighting to proactive architectural defense.

Incident Reporting:

The Regulation harmonizes the classification and reporting of ICT-related incidents. By establishing a standard taxonomy, DORA ensures that major incidents are reported to competent authorities with speed and precision, allowing for a coordinated European response to systemic threats.

Digital Operational Resilience Testing:

Resilience must be proven, not just documented. DORA mandates a proportional testing program. For significant financial entities, this includes advanced Threat-Led Penetration Testing (TLPT), effectively simulating sophisticated cyber-attacks to expose vulnerabilities before malicious actors can exploit them.

Third-Party Risk Management:

Financial institutions increasingly rely on external cloud providers and software vendors. DORA brings these critical ICT third-party service providers (CTPPs) within the regulatory perimeter. Financial entities must monitor these risks throughout the contract lifecycle, ensuring that outsourcing does not equal an abdication of responsibility.

Information Sharing:

Cybersecurity is a collective defense effort. The framework creates a legal basis for financial entities to exchange cyber threat intelligence and indicators of compromise within trusted communities, fostering a "herd immunity" against emerging attack vectors.

Legislative Architecture

The DORA framework is supported by key legislative texts that define its scope and implementation. Understanding these documents is essential for full compliance alignment.

DORA Regulation – (EU) 2022/2554:

This is the primary legislative text, entering into full force on January 17, 2025. It details the obligations for financial entities regarding risk management, incident reporting, testing, and third-party oversight. Unlike a Directive, it is binding in its entirety and directly applicable in all Member States.
Access Regulation (EU) 2022/2554

DORA Amending Directive – (EU) 2022/2556:

This Directive modifies existing financial services directives (such as CRD IV, PSD2, and Solvency II) to align them with the new DORA framework. It ensures legal consistency across the diverse spectrum of the EU financial market, removing conflicting provisions and creating a seamless regulatory environment.
Access Directive (EU) 2022/2556

ESAs Q&A Tool on the DORA Regulation:

The European Supervisory Authorities (EBA, EIOPA, and ESMA) provide a dynamic tool for regulatory clarification. This resource allows market participants to submit questions and receive official interpretations, serving as a vital navigational aid for complex implementation scenarios.
Access ESAs Q&A Tool

Joint ESAs Report pursuant to Article 58(3):

Published in December 2025, this report evaluates the feasibility of the centralized EU Hub for major incident reporting, marking a critical step toward unified pan-European situational awareness.
Access Joint ESAs Report

ICT Risk Management

If the Regulation is the hull of our resilience vessel, ICT Risk Management is the engine that powers it. Under DORA, risk management is elevated from a technical support function to a core strategic imperative. It establishes a mandatory, documented, and comprehensive framework that financial entities must implement to protect their information assets. This is not merely about installing firewalls; it is about creating a continuous, self-improving cycle of defense that permeates every layer of the organization.

The Governance Mandate

The era of plausible deniability for board members regarding cyber risk is over. DORA explicitly places the ultimate responsibility for the ICT risk management framework on the management body. This includes defining the digital operational resilience strategy, approving the risk appetite, and ensuring that appropriate budget is allocated for ICT security.

The Three Lines of Defense:

Financial entities must implement a governance structure that clearly separates the functions of ICT operations, risk control, and internal audit. This segregation of duties ensures that those building the systems are not the only ones checking them, creating a robust system of internal checks and balances.

The Risk Management Cycle

DORA prescribes a dynamic process anchored in four key phases: Identification, Protection and Prevention, Detection, and Response and Recovery.

Identification:

Entities must maintain an up-to-date inventory of all ICT assets and map their dependencies on critical functions. You cannot protect what you cannot see; therefore, granular visibility into the digital estate is the prerequisite for all security measures.

Protection and Prevention:

This phase involves the implementation of technical controls—encryption, identity management, and network segmentation—to minimize the attack surface. It demands a "Zero Trust" mindset where trust is never granted implicitly but must be continually evaluated.

Detection:

Mechanisms must be in place to promptly detect anomalous activities. The speed of detection often determines the severity of the impact, making continuous monitoring capabilities non-negotiable.

Response and Recovery:

When defenses are breached, the focus shifts to containment and restoration. A comprehensive Business Continuity Policy (BCP) and Disaster Recovery Plan (DRP) ensure that critical services can be restored within recovery time objectives (RTO) that minimize market disruption.

Regulatory Technical Standards (RTS)

While the Regulation sets the high-level requirements, the Regulatory Technical Standards (RTS) provide the granular engineering blueprints necessary for compliance. These documents translate legal obligations into technical specifications.

ICT Risk Management – RTS (EU) 2024/1774:

This crucial legal act supplements DORA by specifying the detailed content of the policy on ICT services. It harmonizes the tools, methods, processes, and policies that financial entities must use. It covers everything from cryptographic management and patch management to the physical security of data centers. It distinguishes between the standard framework applicable to all and the simplified framework for smaller entities, ensuring proportionality.
Access RTS (EU) 2024/1774

Final Report on ICT Risk Management RTS (JC 2023 86):

This document is the foundational analysis provided by the European Supervisory Authorities (ESAs). It offers the rationale behind the technical standards, explaining the "why" and "how" of the requirements. For compliance officers and risk architects, this report provides invaluable context for interpreting the strict letter of the law, offering insight into the supervisors' expectations regarding network security, data integrity, and system availability.
Access Final Report (JC 2023 86)

Incident Management & Reporting

In the landscape of digital finance, silence is no longer an option. Historically, financial institutions have been hesitant to disclose cyber incidents due to fear of reputational damage. DORA fundamentally alters this dynamic by mandating a paradigm of transparency and speed. Incident Management & Reporting is not just about logging errors; it is about the rapid identification, classification, and communication of threats to prevent localized contagion from becoming a systemic crisis.

Classification of Major Incidents

DORA introduces a standardized methodology for classifying ICT-related incidents. Financial entities must no longer rely on subjective judgment but must apply rigorous quantitative and qualitative criteria to determine if an incident is "Major".

The Classification Criteria:

An incident is classified based on the number of clients affected, the duration of the downtime, the geographical spread, the data loss involved, and the criticality of the services impacted. This ensures that the European Supervisory Authorities receive consistent data, enabling them to distinguish between minor technical glitches and significant threats to financial stability.

Incident Classification – RTS (EU) 2024/1772:

This Delegated Regulation specifies the exact thresholds for classification. It defines what constitutes a "significant" impact, providing the mathematical formulas and definitions necessary for compliance officers to accurately categorize events.
Access RTS (EU) 2024/1772

Final Report on Incident Classification RTS (JC 2023 83):

This report provides the background and reasoning for the classification thresholds. It clarifies the ESAs' approach to "Materiality" and "Significance," offering essential guidance for entities struggling to define the boundary between a standard operational incident and a reportable major event.
Access Final Report (JC 2023 83)

The Reporting Lifecycle

Once an incident is classified as Major, the clock starts ticking. DORA establishes a streamlined, three-stage reporting obligation designed to provide authorities with immediate awareness followed by detailed analysis.

The Initial Report:

Due within hours of classification, this report alerts the authorities that a major incident is underway. It is a "heads-up" notification, focusing on the basic nature of the event without requiring exhaustive technical detail.

The Intermediate Report:

As the situation evolves, entities must provide updates regarding the impact on operations and clients. This acts as a status check, ensuring authorities are informed of any escalation or containment progress.

The Final Report:

After the dust has settled, a comprehensive root cause analysis is required. This report details the actual impact, the mitigation measures taken, and the lessons learned to prevent recurrence.

Incident Reporting Content – RTS (EU) 2025/301:

This Regulation dictates strictly what information must be included in each report. It harmonizes the data fields, ensuring that every financial entity in the EU speaks the same language when describing cyber threats.
Access RTS (EU) 2025/301

Incident Reporting Templates – ITS (EU) 2025/302:

While the RTS defines what to report, the Implementing Technical Standards (ITS) define how. This document provides the standard templates and forms, eliminating ambiguity and ensuring digital compatibility with regulatory systems.
Access ITS (EU) 2025/302

Final Report on Incident Reporting RTS/ITS (JC 2024 33):

A comprehensive analysis by the ESAs that supports the new reporting standards. It discusses the feedback from public consultations and explains the rationale for the specific timelines and data fields chosen.
Access Final Report (JC 2024 33)

2024 Dry Run Exercise Key Findings:

Published in December 2024, this report analyzes the results of the voluntary dry run. It provides critical insights into common reporting pitfalls and data quality issues that entities must avoid in mandatory reporting.
Access Dry Run Key Findings

Impact Assessment and Centralization

Reporting is not just about the technical fix; it is about understanding the financial fallout. DORA requires entities to estimate the aggregated annual costs and losses caused by major ICT-related incidents.

Cost and Loss Estimation – Joint Guidelines (JC/GL/2024/34):

These guidelines provide a methodology for calculating the financial impact of cyber incidents. They help entities move beyond vague estimates to concrete figures, covering direct costs, reputational damage, and lost business opportunities.
Access Joint Guidelines (JC/GL/2024/34)

ESAs Report on a Single EU Hub (JC 2024 108):

This forward-looking report explores the feasibility of centralizing all incident reporting into a single EU Hub. Such a centralization would drastically improve the speed of information sharing and allow for real-time analysis of cross-border threats, truly unifying the European cyber defense posture.
Access ESAs Report (JC 2024 108)

Operational Resilience Testing

In the realm of cybersecurity, assumption is the mother of failure. It is not enough to build defenses; one must attack them to prove they hold. Operational Resilience Testing under DORA marks a decisive shift from passive compliance "on paper" to active verification in the field. This framework mandates that financial entities subject their ICT systems to rigorous stress tests, vulnerability assessments, and live-fire cyber exercises to validate their actual capability to withstand disruption.

The Testing Hierarchy

DORA establishes a proportional testing program, meaning the intensity of the test depends on the size and systemic importance of the entity. There is no one-size-fits-all; the testing regime must match the risk profile.

Standard Testing Program:

All financial entities are required to conduct a comprehensive set of routine tests. This includes annual vulnerability assessments, network security scans, gap analyses, and physical security reviews. These are the hygiene factors of resilience—constant, iterative checks that ensure basic doors and windows are locked.

Threat-Led Penetration Testing (TLPT):

For financial entities deemed significant, DORA introduces the elite tier of testing: TLPT. This is not a simple tick-box exercise. It is a controlled, intelligence-led Red Team operation that mimics the tactics, techniques, and procedures (TTPs) of real-world threat actors. The goal is to compromise the entity’s critical functions on live production systems, providing the ultimate proof of resilience.

The TIBER-EU Standard

To ensure consistency across the Union, DORA draws heavily on the TIBER-EU framework (Threat Intelligence-based Ethical Red Teaming). This framework ensures that tests are not random assaults but are carefully planned scenarios based on specific threat intelligence relevant to the entity.

The Process:

A TLPT involves three distinct phases: Preparation (scoping and intelligence gathering), Testing (the active Red Teaming phase), and Closure (remediation and root cause analysis). Crucially, the test must cover "live" production systems to be valid, requiring extreme care to avoid accidental service disruption during the exercise.

Mutual Recognition:

A key innovation of DORA is the principle of mutual recognition. A TLPT conducted in one Member State covers the entity’s operations across the entire EU, eliminating the burden of duplicate testing for cross-border financial groups.

Technical Standards and Frameworks

The execution of these tests is governed by precise technical standards that define the rules of engagement, ensuring safety, privacy, and effectiveness.

Threat-Led Penetration Testing (TLPT) – RTS (EU) 2025/1190:

This Regulation serves as the operational handbook for advanced testing. It defines the criteria for identifying entities required to perform TLPT, the methodology for scope inclusion, and the requirements for external testers. It provides the legal certainty needed to conduct attacks on one's own infrastructure.
Access RTS (EU) 2025/1190

Final Report on TLPT RTS (JC 2024 29):

This report offers the ESAs' detailed rationale for the TLPT standards. It addresses industry concerns regarding the risks of testing on live systems and clarifies the interaction between internal Red Teams and external testers. It is an essential companion for CISOs planning their testing roadmap.
Access Final Report (JC 2024 29)

TIBER-EU Framework (Updated):

Developed by the European Central Bank, TIBER-EU is the gold standard for intelligence-led testing. While DORA makes TLPT mandatory, TIBER-EU provides the "how-to" methodology. It connects the dots between threat intelligence providers, the Red Team (attackers), and the Blue Team (defenders).
Access TIBER-EU Framework

ICT Third-Party Risk Management

In the modern financial ecosystem, no entity is an island. Reliance on external ICT services—from cloud platforms to data analytics—has created a complex web of dependencies. ICT Third-Party Risk Management (TPRM) is DORA’s answer to the supply chain challenge. It mandates that financial entities extend their risk management perimeter beyond their own walls, treating third-party vendors not as external black boxes, but as integral components of their own operational body.

The Register of Information

You cannot manage what you do not know. DORA imposes a strict obligation to map the entire ICT supply chain. Financial entities must maintain a comprehensive Register of Information that details every contractual arrangement with third-party providers. This is not a static list; it is a dynamic database that links vendors to the critical functions they support, identifying concentration risks and potential single points of failure.

Register of Information Templates – ITS (EU) 2024/2956:

This Implementing Regulation provides the standardized templates for the Register. It ensures that every financial entity across the EU captures data in a uniform format, facilitating the supervisory analysis of systemic risks posed by Critical Third-Party Providers (CTPPs).
Access ITS (EU) 2024/2956

Final Report on Register of Information ITS (JC 2023 85):

The ESAs' report clarifying the structure of the Register. It addresses the practical challenges of gathering data, defining the "Legal Entity Identifier" (LEI) usage, and structuring the data fields to capture the entire outsourcing chain.
Access Final Report (JC 2023 85)

ESAs Opinion on RoI ITS (JC 2024 75):

This opinion highlights the dialogue between the European Commission and the ESAs regarding the finalization of the templates. It sheds light on the rejection of certain complex identifiers, streamlining the requirements to make compliance more feasible for entities while retaining supervisory value.
Access ESAs Opinion (JC 2024 75)

Sub-contracting and Cloud Risks

The risk does not stop at the primary vendor. DORA explicitly addresses the "Nth party" risk found in complex sub-contracting chains. Financial entities must monitor the entire chain of outsourcing, ensuring that a failure deep in the supply chain does not cascade upward to disrupt critical financial services.

ICT Third-Party Policy – RTS (EU) 2024/1773:

This Regulation outlines the content of the policy that entities must adopt regarding the use of ICT services. It mandates a multi-vendor strategy to avoid lock-in, requires pre-contractual risk assessments, and defines the exit strategies necessary to migrate data safely if a provider fails.
Access RTS (EU) 2024/1773

Sub-contracting – RTS (EU) 2025/532:

This legal act specifies the conditions under which ICT services supporting critical functions can be sub-contracted. It requires financial entities to retain control and oversight, ensuring that sub-contractors meet the same high standards of resilience as the primary provider.
Access RTS (EU) 2025/532

Joint Final Report on Subcontracting RTS:

This report details the technical advice from the ESAs regarding the depth of the subcontracting chain that must be monitored, addressing the complexities of multi-layered cloud dependencies.
Access Joint Final Report

ESAs Opinion on Rejection of Subcontracting RTS:

This opinion provides context on the regulatory debate concerning the granularity of subcontracting oversight, explaining modifications requested by the Commission to ensure proportionality.
Access ESAs Opinion

Supervisory Guidance

Beyond the strict text of the Regulation, supervisory guides provide the practical expectations for managing these risks, particularly regarding cloud computing.

ECB Guide on Outsourcing Cloud Services:

While not a DORA text per se, this guide from the European Central Bank is vital for significant institutions. It details the supervisor's expectations for cloud outsourcing, emphasizing the need for robust exit plans, data localization understanding, and the ability to audit cloud providers effectively.
Access ECB Guide

The Oversight Framework

The Oversight Framework marks the end of the "black box" era for critical technology providers. For the first time, the regulatory perimeter expands to include the tech giants themselves. Financial regulators are no longer limited to supervising financial institutions; they now have the direct authority to look "under the hood" of Critical ICT Third-Party Providers (CTPPs) such as cloud hyperscalers, ensuring that the digital bedrock of the European financial system is structurally sound.

Designation of Critical Providers

Not every vendor is critical. The European Supervisory Authorities (ESAs) apply a rigorous set of criteria to designate which providers are "Critical" (CTPPs). This designation triggers direct oversight, subjecting the provider to inspections, penalties, and operational recommendations.

Critical ICT Providers Designation Criteria – (EU) 2024/1502:

This Delegated Regulation sets the specific qualitative and quantitative thresholds for designation. It considers the systemic impact of a provider's failure, the number of financial entities relying on them, and the degree of substitutability. If a provider is "too big to fail" or "too hard to replace," they fall under this scope.
Access Delegated Regulation (EU) 2024/1502

List of Designated Critical ICT Providers (CTPPs):

Transparency is key. The ESAs publish the official list of designated CTPPs. This list serves as a signal to the market, indicating which providers are subject to the highest standards of operational resilience supervision.
Access Designated CTPPs List

Decision on Information Reporting for CTPP Designation:

This decision formalizes the data flow required from financial entities to the regulators, enabling the ESAs to accurately identify and designate critical providers based on actual market dependency data.
Access Designation Decision

The Oversight Mechanics

Once designated, a CTPP is assigned a Lead Overseer (one of the three ESAs: EBA, EIOPA, or ESMA). This Lead Overseer coordinates the supervision, assisted by Joint Examination Teams (JETs) composed of experts from across the EU.

Oversight Harmonisation – RTS (EU) 2025/295:

To prevent regulatory arbitrage, this Regulation harmonizes the oversight activities. It establishes the rules of engagement for the Lead Overseer, detailing the procedures for requesting information, conducting general investigations, and performing on-site inspections.
Access RTS (EU) 2025/295

Joint Examination Teams – RTS (EU) 2025/420:

This Regulation defines the composition and functioning of the JETs. These multi-disciplinary teams are the "boots on the ground" for oversight, conducting the technical deep-dives into the CTPP's operations to verify their resilience claims.
Access RTS (EU) 2025/420

Preparing for the DORA Oversight Framework Guidance:

Released in May 2025, this practical guidance outlines how CTPPs should prepare for direct EU supervision, detailing the expected documentation standards and interaction protocols with the Lead Overseer.
Access Oversight Guidance

ESAs Statement on DORA Application:

Issued in December 2024, this statement clarified the supervisory expectations for the "Day 1" application of DORA, addressing common implementation questions regarding the transitional period.
Access ESAs Statement

Financial and Cooperative Structures

Supervision requires resources. DORA establishes a funding model where the CTPPs themselves bear the cost of their oversight, ensuring that the taxpayer does not foot the bill for monitoring profitable tech giants.

Oversight Fees – (EU) 2024/1505:

This Regulation determines the amount of fees to be levied on CTPPs to cover the ESAs' oversight costs. It details the methodology for calculating these fees, ensuring they are proportionate to the provider's turnover and the complexity of the supervision required.
Access Delegated Regulation (EU) 2024/1505

Oversight Cooperation – Joint Guidelines (JC/GL/2024/36):

Cyber risk knows no borders. These guidelines foster cooperation and information exchange between the Lead Overseer and other competent authorities. They ensure that if a risk is identified in one corner of the EU, the intelligence is shared rapidly across the entire supervisory network.
Access Joint Guidelines (JC/GL/2024/36)

Non-Cyber ICT Risks & Business Continuity

DORA is often mistakenly viewed solely through the lens of cybersecurity. However, Article 28 and the broader risk management requirements place heavy emphasis on the availability and continuity of services, regardless of the cause of disruption. A supplier going bankrupt is just as dangerous to financial stability as a supplier getting hacked. These topics are not "optional" add-ons; they are core mandates.

Supplier Failure and Service Deterioration

The financial health of a third-party provider is a direct operational risk to the financial entity. If a Critical ICT Provider enters liquidation, services may cease abruptly. DORA mandates that entities consider the insolvency risk of their vendors.

Level 1 (The Law):

Article 28(8) requires you to have exit strategies to ensure you can switch to another provider or bring the service in-house without disruption. This is your primary defense against "supplier failure."

Level 2 (The Detail):

Commission Delegated Regulation (EU) 2024/1773 (RTS on the policy on ICT services). This document explicitly details the mandatory contractual clauses you must have regarding service levels (SLAs), termination rights, and transfer of data in case of service deterioration or insolvency.
Access RTS (EU) 2024/1773

Level 2 (Subcontracting):

Commission Delegated Regulation (EU) 2025/532 (RTS on Subcontracting). This deals with the risk of service deterioration further down the chain (the "4th party" risk).
Access RTS (EU) 2025/532

Service Deterioration Monitoring

Operational resilience is not binary (up or down). It is a spectrum. DORA requires the monitoring of service performance to detect "silent failures" or gradual deterioration.

SLA Integrity:

Service Level Agreements (SLAs) must quantify performance targets. High latency, data throughput bottlenecks, or degradation in support responsiveness can cripple a high-frequency trading platform or a real-time payment system just as effectively as a total outage.

Concentration Risk

The "All eggs in one basket" problem is a central theme of DORA's macro-prudential oversight. Concentration risk occurs on two levels: at the entity level (single institution relying on one provider) and the systemic level (market-wide reliance).

Level 1 (The Law):

Article 29 is titled "Preliminary assessment of ICT concentration risk at entity level." It explicitly forbids you from entering into a contract if it creates a dependency that is hard to substitute.

Level 2 (The Data):

Commission Implementing Regulation (EU) 2024/2956 (ITS on the Register of Information). This standard forces you to map out exactly which vendors support which critical functions using specific templates, specifically to expose concentration risk to the regulators.
Access Commission Implementing Regulation (EU) 2024/2956

Future Outlook & Interoperability

DORA is not an isolated island. It exists within a dynamic ecosystem of evolving EU digital regulation. As technology accelerates, the legislative framework must adapt to ensure continued resilience. This section outlines the roadmap for future developments and how DORA intersects with other critical EU laws.

The 2026 Review

Article 58 of DORA mandates a comprehensive review by the European Commission. While the official Commission report (originally due by January 17, 2026) is currently pending publication, the Joint ESAs' input report from December 2025 has laid the groundwork. This forthcoming review will assess the effectiveness of the regulation after its first year of full application. Key areas of focus will likely include the functioning of the Oversight Framework for critical providers and the potential need for amendments to address emerging threats such as quantum computing risks.

Cross-Framework Alignment

Financial entities often operate across multiple sectors, requiring them to navigate a complex web of overlapping regulations. Understanding how DORA interacts with these frameworks is essential for a unified compliance strategy.

NIS2 Directive:

The NIS2 Directive (Network and Information Security) sets the baseline cybersecurity requirements for essential sectors across the EU. DORA is considered a lex specialis (special law) for the financial sector, meaning its specific provisions take precedence over the general rules of NIS2. However, for entities with mixed activities (e.g., a bank that also provides general cloud services), alignment between the two regimes is crucial to avoid regulatory gaps.
Access NIS2 Directive (EU) 2022/2555

EU AI Act:

The EU AI Act classifies Artificial Intelligence systems based on risk. Financial AI models used for credit scoring or risk assessment are often categorized as "High-Risk AI Systems." This creates a dual-compliance landscape: entities must ensure these systems are resilient under DORA (ICT risk perspective) while simultaneously meeting the fundamental rights and safety requirements of the AI Act.
Access AI Act Regulation (EU) 2024/1689