Art. 17: The incident management process Every in-scope financial entity must have a formal ICT-related incident management process that includes: Detection and logging: all ICT-related incidents must be detected promptly and recorded in a dedicated incident log Classification: each incident must be classified using the criteria in Art. 18 to determine whether it is "major" (triggering reporting) or not Escalation procedures: clear internal escalation paths from IT operations to the management body Root cause analysis: post-incident review with identification of root causes and corrective actions Communication protocols: internal and external communication (clients, counterparties, media) managed under predefined procedures Art. 18: Classifying incidents — what makes an incident "major"?

The EBA, ESMA and EIOPA have published Regulatory Technical Standards (RTS) under DORA that specify exactly how to classify incidents. An incident is classified as "major" if it meets materiality thresholds in at least one of these dimensions:

Art. 19: The three-stage reporting obligation When a major ICT-related incident is confirmed, three mandatory reports must be submitted to the competent authority: 4h Initial notification — within 4 hours From the moment the entity classifies the incident as major (or no later than 24 hours after first becoming aware if immediate classification is not possible). Minimal information: incident reference, date/time of detection, brief description, whether the incident is ongoing. 72h Intermediate report — within 72 hours From the initial notification. Updated classification, preliminary root cause analysis, containment measures taken, estimated impact on clients and counterparties, whether cross-border elements are involved. 1mo Final report — within 1 month of incident resolution Detailed root cause analysis, total financial impact, lessons learned, permanent remediation actions implemented or planned, updated risk assessment. This report forms the basis for supervisory review. Is your incident classification process DORA-ready? IgeraRegTech maps your ICT incidents to DORA Art. 18 thresholds and auto-generates the three reporting templates. Request a demo For financial entities in Spain, France, Germany, Italy and the Netherlands Art. 20–22: Harmonised reporting and the centralised EU Hub One of DORA's most operationally significant features is the move toward harmonised reporting templates across all financial sectors and member states. Art. 20: Implementing Technical Standards (ITS) for templates

The Joint Committee of EBA, ESMA and EIOPA has developed Implementing Technical Standards specifying the exact format, content and submission procedures for all three reporting stages. These ITS are binding — using your own format is not compliant.

Art. 21: Delegating incident reporting within a group Financial groups (parent + subsidiaries) may designate a single entity within the group to submit consolidated incident reports on behalf of all in-scope entities. This avoids duplication where a group-level IT incident triggers reporting obligations in multiple subsidiaries simultaneously. Critical point: the original entity remains legally responsible. Delegation does not transfer liability. The group-level reporting arrangement must be formally documented and the competent authority of each subsidiary's home member state must be informed of the arrangement. Art. 22: The centralised EU Hub The EBA operates a centralised EU Hub that receives incident reports from all in-scope entities across all sectors. For cross-border groups, this avoids submitting the same report to five different national competent authorities. The Hub distributes reports to the relevant national authorities automatically. The Hub is particularly relevant for: pan-European banks, cross-border payment institutions, and CASPs operating across multiple member states under MiCA. Art. 23: Significant cyber threats — voluntary notification Art. 23 creates a framework for voluntarily notifying competent authorities of significant cyber threats that have not yet materialised into incidents. This is distinct from the mandatory reporting of Art. 19 — it covers active threats that are being mitigated before they cause service disruption. Why notify voluntarily? Competent authorities can share anonymised threat intelligence with other financial entities in the sector Demonstrates a proactive compliance posture — relevant in supervisory reviews Where a cyber threat involves a critical third-party provider, notification can trigger oversight action against the CTPP No penalty risk for voluntary disclosure (unlike failing to report a major incident) The notification must include: description of the threat, systems targeted, mitigations applied, and an assessment of whether the threat could qualify as a major incident if it materialises. Third-party ICT risk: what Art. 28–44 demands from your vendor contracts DORA's third-party requirements are among the most complex to implement. Every ICT service contract with a provider that supports a critical or important function must include a mandatory set of provisions. Mandatory contractual clauses include: Full description of all services provided, including subcontracting chains Service levels (SLAs) with availability and performance metrics Incident response and notification obligations of the ICT provider Audit and inspection rights — both by the financial entity and by competent authorities Right to terminate on regulatory grounds without financial penalty Data portability and transition assistance requirements Business continuity provisions and testing cooperation obligations For contracts with cloud providers (AWS, Azure, Google Cloud), the standard terms of service are not sufficient for DORA compliance without a bespoke addendum. Most major cloud providers now offer DORA-specific addenda — ensure yours is signed and current. Additionally, every financial entity must maintain a register of all ICT third-party contracts, classified by criticality. This register must be made available to the competent authority on request. DORA testing requirements: basic vs advanced (TLPT) DORA mandates two levels of resilience testing: Basic testing applies to all in-scope entities and must be conducted annually (or more frequently if the risk profile warrants it). It includes vulnerability assessments, network security scanning, gap analyses, physical security reviews and scenario-based testing. Threat-Led Penetration Testing (TLPT) is required for significant financial entities — typically large banks, central counterparties and major payment institutions designated by competent authorities. TLPT must: Be conducted at least every 3 years Cover live production systems (not test environments) Use external testers who are independent of the entity Follow the TIBER-EU framework or national equivalents (CBEST in the UK, TIBER-NL in the Netherlands) Include critical ICT third-party providers in scope if they support critical functions TLPT results are shared with the competent authority. Significant findings must be remediated within defined timeframes. The TLPT certificate issued after successful completion provides a period of regulatory credit — the entity does not need to repeat testing within that window unless a major incident occurs. Penalties for non-compliance with DORA DORA itself does not set harmonised fines — penalties are implemented by each member state's national competent authority. However, the ESAs (EBA, ESMA, EIOPA) have supervisory powers over critical third-party providers that include fines of up to 1% of average daily worldwide turnover of the CTPP for each day of infringement, up to a maximum of 6 months. For financial entities, national penalties vary by jurisdiction but are aligned with existing sectoral frameworks. In practice, the most significant consequences of DORA non-compliance are: Formal supervisory action and remediation plans Suspension or restriction of the authorisation to provide services Public disclosure of the infringement (reputational damage) Personal liability for members of the management body Art. 19 failures (late or absent incident reporting) are treated with particular severity — supervisors expect near-real-time notification for major incidents and have made clear that reporting delays will be subject to enforcement action from 2025 onwards. How IgeraRegTech supports DORA Art. 17–23 Compliance team query: "We had a payment processing outage for 2.5 hours affecting 8% of our retail customers. Do we need to submit an initial notification under DORA Art. 19?" IgeraRegTech responds: "Yes. Based on the Art. 18 RTS classification criteria: duration exceeds the 2-hour threshold for critical services and 8% of retail customers affected meets the materiality threshold for client impact. This qualifies as a major ICT-related incident. You must submit the initial notification within 4 hours of classification. The Art. 19 ITS template fields required for the initial report are: [1] incident reference [2] detection timestamp [3] brief description [4] ongoing/resolved status. Shall I pre-populate the template with the information you provided?" ⏱ Instant classification 📋 Art. 18 RTS cited 📄 Template auto-populated 🔒 Audit trail maintained How to build your DORA Art. 17–23 compliance roadmap Most financial entities that are behind on DORA need to prioritise Art. 17–23 first because the reporting obligations are the most time-sensitive and the ones supervisors are actively checking. A practical six-week sprint to reach basic compliance with Art. 17–23: Week 1: Designate a DORA incident response owner (CISO or equivalent) and map current ICT incident log to DORA Art. 18 classification criteria Week 2: Gap analysis — which current incidents would have triggered major classification? Identify missed reports Week 3: Draft updated ICT incident response procedure with DORA-compliant classification tree and 4h/72h/1mo reporting triggers Week 4: Implement Art. 19 ITS-compliant reporting templates in your incident management system (ServiceNow, Jira, or purpose-built) Week 5: Train incident response team, first responders and the management body on the new classification and reporting procedures Week 6: Tabletop exercise simulating a major incident — test the 4-hour notification pathway end to end The tabletop exercise in week 6 consistently reveals procedural gaps that documents miss. Run it before your competent authority requests it in a supervisory review. See also our guide on DORA ICT compliance: complete guide for financial entities for the full five-pillar framework. Is your DORA incident reporting process ready for supervisory review? IgeraRegTech automates incident classification, pre-populates Art. 19 ITS templates and maintains the audit trail required by DORA. Schedule a DORA readiness review Available for banks, insurers, investment firms and CASPs In summary: DORA Art. 17–23 compliance essentials Art. 17: Every financial entity must have a documented ICT incident management process with detection, classification, escalation and root cause analysis Art. 18: Incidents are "major" when they meet materiality thresholds on client impact, duration, geographic spread, data loss or economic impact — per the EBA/ESMA/EIOPA RTS Art. 19: Three mandatory reports — initial (4h), intermediate (72h), final (1 month) — submitted via the Art. 20 ITS templates to competent authority and the centralised EU Hub Art. 21: Group-level reporting delegation is permitted but liability stays with the original entity Art. 23: Significant cyber threats can be voluntarily notified — doing so supports sector-wide intelligence sharing and demonstrates proactive compliance Does DORA apply to my company if we are headquartered outside the EU?

Yes, if you provide services to EU financial entities or operate within the EU financial system. DORA has explicit extraterritorial reach — the same logic as GDPR. If you are a non-EU CTPP providing cloud services to EU banks, you are directly subject to the DORA oversight framework under Art. 31–44.

What is the difference between a DORA major incident report and a GDPR breach notification?

They are separate and can be triggered simultaneously. A data breach involving personal data triggers GDPR Art. 33 (notification to data protection authority within 72 hours) and GDPR Art. 34 (notification to affected individuals if high risk). If the breach results from an ICT incident that meets DORA Art. 18 thresholds, it also triggers DORA Art. 19 reporting. The two reports go to different authorities and use different templates — do not conflate them or assume one report satisfies both obligations.

How do micro-enterprises apply DORA differently?

Micro-enterprises (under 10 employees, under €2M turnover/balance sheet) benefit from simplified requirements in several areas: they can adopt a simplified ICT risk management framework under Art. 16, are exempt from TLPT under Art. 26, and have lighter third-party contract requirements under Art. 28. However, they are still fully subject to Art. 17–23 incident reporting — there is no size-based exemption from major incident notification.

What counts as an "ICT third-party service provider" under DORA?

Any undertaking that provides digital and data services on an ongoing basis, including cloud computing, software (SaaS, PaaS), data analytics, data centres, and hardware provision that underpins critical or important functions. Payment card network operators, CLS, and interbank messaging providers are all in scope. Internal group entities providing ICT services to other group entities are also covered if they support critical or important functions.

Can a cyber incident qualify as both a major ICT incident and a reportable operational risk event under CRR?

Yes. A significant cyber attack on a credit institution may simultaneously trigger: DORA Art. 19 (ICT incident reporting), CRR/Basel III operational risk event recording, GDPR Art. 33/34 if personal data is affected, and national central bank reporting in some jurisdictions. Your incident response procedure should map each regulatory trigger and assign a clear owner for each reporting obligation.

How does DORA interact with NIS2?

DORA is lex specialis with respect to NIS2 for in-scope financial entities. Recital 16 of DORA clarifies that financial entities subject to DORA are exempt from the NIS2 incident reporting obligations when an ICT incident also qualifies as a significant cyber threat under NIS2. The DORA competent authority (EBA, ESMA or EIOPA, or national equivalent) coordinates with NIS2 authorities to avoid duplication. In practice, file under DORA and inform your DORA competent authority — they handle coordination with the NIS2 national authority.

regtech

Cumplimiento DORA para entidades financieras: Art. 17-23

Gerard Maymó

31 de mayo de 2026

14 min read

DORA compliance guide Art. 17-23 for financial entities EU 2025

#DORA compliance 2025#DORA Art 17 incident management#DORA incident reporting 4 hours#DORA Art 19 major incident report#DORA financial entities guide#digital operational resilience act#DORA EU 2022/2554#DORA classification major incident

Comparte el conocimiento con tu red

Productos relacionados

IgeraRegTech DORA

Explora esta solución relacionada con el contenido que acabas de leer

Cumplimiento DORA para entidades financieras: Art. 17-23

COMPARTIR

Productos relacionados

IgeraRegTech DORA

Artículos relacionados

Cumplimiento DORA para entidades financieras: guía completa ICT 2025

RAG vs ChatGPT para Contratación Pública: La Diferencia Clave

EU AI Act 2026: qué deben hacer las empresas antes del plazo de agosto