When did DORA become enforceable?

DORA (Regulation EU 2022/2554) became applicable across the European Union on 17 January 2025. The Regulation is directly applicable in all Member States without national transposition.

What is the DORA major incident reporting timeline?

Article 19 requires major ICT-related incidents to be reported to the competent authority via an initial notification, an intermediate report and a final report on harmonised templates. The reporting clock starts at the moment an incident is classified as major under the Article 18 criteria; the precise hours are set by the regulatory technical standards adopted under Article 20.

How does DORA interact with NIS2 for financial entities?

DORA is lex specialis under Article 1(2): for financial entities in scope, DORA's ICT risk management and incident reporting provisions take precedence over the equivalent NIS2 (Directive EU 2022/2555) provisions. NIS2 still applies for non-ICT cybersecurity obligations and for sector-specific notifications outside DORA's scope.

DORA Compliance in 2026: ICT Risk, Incident Reporting, and…

The Digital Operational Resilience Act became enforceable in January 2025. Eighteen months in, what compliance officers are actually being asked to evidence.

What DORA Replaces and Why It Exists

The Digital Operational Resilience Act became applicable across the European Union on 17 January 2025. Before DORA, ICT risk for EU banks, insurers, investment firms, central counterparties, payment institutions and crypto-asset service providers was governed by a patchwork: EBA Guidelines on ICT and Security Risk Management, EIOPA guidance, the PSD2 incident-reporting regime, and the various supervisory expectations under MiFID II and Solvency II. DORA consolidates these into a single, directly applicable Regulation that binds twenty categories of financial entity plus their critical ICT third-party providers.

Who Falls Under DORA

Article 2 sets the scope. The Regulation applies to credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers (cross-referenced to MiCA), central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, UCITS management companies, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories, and account information service providers. The single carve-out is micro-enterprises and certain small-scale institutions, which receive a simplified framework under Article 16.

The Five DORA Pillars

1. ICT Risk Management (Articles 5-16)

Article 5 places ultimate accountability on the management body for the entity's ICT risk management framework. The framework must include strategies, policies, procedures, protocols and tools necessary to duly and adequately protect all information assets and ICT assets. Articles 6 through 16 expand this: identification and classification of ICT assets (Article 8), protection and prevention measures (Article 9), detection of anomalous activities (Article 10), response and recovery (Article 11), backup policies (Article 12), learning and evolving from incidents (Article 13), communication (Article 14), and an ICT business continuity policy (Article 15).

2. ICT-Related Incident Management (Articles 17-23)

Article 17 requires every financial entity to define, establish and implement an ICT-related incident management process. Article 18 sets the criteria for classifying an incident as major - duration, geographical spread, number of clients affected, data losses, criticality of services affected, economic impact and reputational impact. Article 19 then requires major ICT-related incidents to be reported to the competent authority via an initial notification, an intermediate report and a final report on standardised templates harmonised by Article 20. The reporting clock starts when the incident is classified as major.

3. Digital Operational Resilience Testing (Articles 24-27)

Article 24 establishes the testing programme; Article 25 sets out the basic testing tools (vulnerability assessments, scenario-based testing, source code reviews, end-to-end testing). Article 26 introduces threat-led penetration testing (TLPT) for significant financial entities, modelled on the TIBER-EU framework. TLPT must be carried out at least every three years on critical or important functions, with the test plan validated by the competent authority and the test report shared with the supervisor.

4. ICT Third-Party Risk Management (Articles 28-44)

Article 28 is the cornerstone: financial entities must manage ICT third-party risk as an integral component of their ICT risk management framework, and the management body must approve and review the strategy. Article 29 introduces preliminary assessment of ICT concentration risk before entering into a contractual arrangement. Article 30 prescribes the key contractual provisions that any contract for ICT services supporting critical or important functions must contain - including service level agreements, locations of data processing, audit rights, and exit strategies. Articles 31-44 set up the oversight framework for critical ICT third-party service providers, designated by the Joint Committee of the ESAs and subject to direct supervision by a Lead Overseer.

5. Information Sharing (Article 45)

DORA permits and encourages - but does not mandate - financial entities to exchange cyber threat information and intelligence among themselves within trusted communities, subject to GDPR.

Penalties and Supervisory Powers

DORA does not set Regulation-level fines; instead, it requires Member States to lay down rules on administrative penalties and remedial measures that are effective, proportionate and dissuasive. Most Member States have transposed substantial fining powers (in several jurisdictions reaching €1-5M plus turnover-based maxima). Critical ICT third-party providers are subject to periodic penalty payments under Article 35 set by the Lead Overseer.

How DORA Interacts with NIS2 and MiCA

Article 1(2) of DORA establishes lex specialis: for the financial entities in scope, DORA's ICT risk and incident provisions take precedence over NIS2 (Directive EU 2022/2555). For crypto-asset service providers, DORA applies alongside MiCA (Regulation EU 2023/1114). The Bidda registry crosswalks each DORA Article to the corresponding NIS2 obligation so a multi-jurisdiction entity can see at a glance which framework is controlling.

How Bidda Maps DORA

Bidda represents every operative DORA Article as a separate compliance node with a deterministic workflow, an actionable schema for agent-executable checking, the primary citation to the Official Journal text, and crosswalks to NIST 800-53 (especially the IR, SI and SC families), ISO/IEC 27001:2022 Annex A, APRA CPS 234, and the relevant EBA Guidelines. Compliance officers use the registry to map their internal control matrix to DORA; AI agents query the same nodes via the discovery API or MCP server to verify, at the moment of decision, that a proposed ICT change satisfies the controlling provision.

DORA Compliance in 2026: ICT Risk, Incident Reporting, and Third-Party Concentration for…