DORA Article 17 in practice: major ICT-related incident reporting for EU banks and EMIs

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) became applicable on 17 January 2025. Article 17 is the piece that most visibly changes the day-to-day of incident management for banks, payment institutions, e-money firms, investment firms, and their critical ICT providers. This is a walk-through of what Article 17 actually requires, what the surrounding level-2 and level-3 measures add, and how to build a signed evidence trail that survives inspection by BaFin, ACPR, Banca d'Italia, DNB, CSSF, or any other competent authority.

Everything below is cross-referenced against the published text on EUR-Lex and the EBA / ESMA / EIOPA joint guidelines issued under Article 19. If your reading of a paragraph differs from ours, the text on EUR-Lex wins.

What Article 17 requires, in three clauses

Article 17 sits inside Chapter III (“ICT-related incident management, classification and reporting”). The three operational clauses are:

1. Article 17(1) — ICT-related incident management process.A financial entity must have “an ICT-related incident management process to detect, manage and notify ICT-related incidents” that records every incident and identifies its root causes. The process is defined in writing, approved by the management body, and tested.
2. Article 17(2) — classification. Incidents are classified using the criteria set in Article 18 (number of users affected, data loss, economic impact, duration, geographical spread, reputational impact, criticality of services). The RTS on classification of major ICT-related incidents (Commission Delegated Regulation (EU) 2024/1772) translates these criteria into thresholds.
3. Article 17(3) — major-incident notification. A major ICT-related incident must be notified to the competent authority. The RTS and the implementing technical standards (Commission Implementing Regulation (EU) 2024/2956) set the content and the cadence.

In practice, compliance teams spend their weeks inside Article 17(2) and (3) — the classification judgement and the notification cascade. Article 17(1) is where the governance sits, and it is the piece inspection will interrogate first because it ties the incident management process back to the overall ICT risk framework of Article 6.

The three reporting windows

The joint ESAs technical standards fix the reporting cascade at three deadlines. Memorise them:

A few details matter more than they look. First, the 4-hour clock starts from classification as major, not from detection. That means the classification step is itself time-bounded: the ITS expect entities to reach a classification decision within 24 hours of detection. Entities that cannot demonstrate a repeatable classification process will find their inspection comments harsh.

Second, “initial” is not a pre-filled form — it is a qualified notification. If you send the initial at t+3h with “details to follow”, you have satisfied the deadline but not the content requirement, and the intermediate notification will be asked for earlier.

Third, significant cyber threats (as distinct from incidents) are notified under Article 19 with a separate, voluntary-but-expected cadence.

What counts as “major”

Commission Delegated Regulation (EU) 2024/1772 defines two levels of thresholds that act jointly: primary criteria (Annex I) and secondary indicators (Annex II). To be classified major, an incident must meet the primary criteria for at least two of: clients affected, data-loss relevance, reputational impact, or service downtime. The primary thresholds are graduated; the published thresholds as of Q1 2026 are summarised below. Always re-check the RTS text before using these for a real classification — they are subject to EBA interpretive updates.

The inspection-ready evidence pack

A supervisor asked about a specific Article 17 notification will want the sequence. In a RegRadar-running tenant, that sequence is:

1. The original regulatory release (e.g. the RTS 2024/1772 when it was published), captured in Sources with its SHA-256 content hash and polling history.
2. The structured impact the AI produced against the tenant perimeter when 2024/1772 was captured, with its confidence score and factor breakdown.
3. The 1LoD signoff that confirmed DORA Art. 17 applies to the tenant's in-scope services, with rationale (e.g. “payment processing and card authorisation are critical functions; event notification process in place”) and evidence pack (link to the incident process doc version 3, approved by the board on 2025-11-04).
4. The 2LoD countersignature by independent Compliance or Risk, confirming the 1LoD reading.
5. Live incident records, each with its own 1LoD / 2LoD chain once classified major, plus the three successive notifications sent to the competent authority within the window.

Common gaps we see in DORA pilots

• No written classification criteria. The RTS gives thresholds; the entity still has to produce its own criteria document that the thresholds map into. Missing that document is an immediate inspection finding.
• Incident management process owned by IT only.Article 17 requires the financial entity's management body to approve the process. A process owned and approved by the CIO only is not Article 17-compliant, however technically competent it is.
• No link to third-party incident reporting.When a critical ICT provider has a major incident, the financial entity's clock may start at its notification. The third-party contracts must ensure that notification arrives in time for the entity to fulfil its own 24-hour classification window.
• No exercise of the process. Article 17 expects the process to be tested. An annual tabletop against one scenario (e.g. card-authorisation outage + customer data integrity question) plus an operational dry run of the notification flow is the minimum rehearsal we see working pilots adopt.
• No link from incidents back to Article 18 classification evidence.The thresholds crossed must be recorded per incident, not just asserted. A chain of four incidents with “not major” verdicts and no recorded criterion reading is a systemic finding waiting to happen.

Level-2 and level-3 measures to have on the radar

Article 17 does not live alone. The useful radar list, as of 2026-04-22:

• Commission Delegated Regulation (EU) 2024/1772 — RTS on classification of major ICT-related incidents and significant cyber threats.
• Commission Implementing Regulation (EU) 2024/2956 — ITS on reporting of major ICT-related incidents and significant cyber threats.
• EBA / ESMA / EIOPA Joint Guidelines on reporting major ICT-related incidents (GL on Article 20) — expected final text Q3 2026.
• Commission Delegated Regulation (EU) 2024/1773 — RTS on ICT third-party risk management.
• Article 23 register of information on contractual arrangements on the use of ICT services — ITS reporting template.
• Oversight framework for critical ICT third-party service providers (Articles 31–44) — relevant for counterparty diligence even if your firm is not designated critical.

The operating-model changes we see working

In pilots that pass their first DORA-themed internal audit cleanly, three operating-model moves are consistent:

1. A single incident queue with two owners. One for incident management (CISO / head of operational resilience) and one for regulatory change (head of compliance or regulatory affairs). Both sign every major-incident notification before it leaves the building. This is a deliberate friction point — it slows the notification by hours, not days, and it catches misclassification.
2. Criterion-by-criterion decision.When an incident hits the edge of the classification thresholds, the decision record captures each criterion reading separately (“clients affected: 8% of relevant base, below threshold; duration: 3h against critical function, above threshold; …”) rather than a single opinion. This maps one-to-one to Article 18 and supports any later appeal or supervisor challenge.
3. Third-party-linked clock.The firm's notification clock is started either by internal detection or by a notification from a critical ICT provider, whichever is earlier. The provider contract and the register of information under Article 23 are the anchor.

How RegRadar handles Article 17 specifically

The French Banking Group preset and the German Universal Bank preset both include DORA in scope with Article 17 as a dedicated obligation. New level-2 or level-3 measures published against DORA create an impact in the Operational Risk queue (SLA 48h); changes are diff-surfaced against the previous version so the 1LoD can see exactly what moved. The obligation register links to the internal incident management process document version, so inspection can trace from the paragraph of the RTS to the paragraph of the internal process. For the signoff chain itself see the three-lines-of-defence methodology.