For payment institutions and fintechs, DORA's incident-reporting pillar is the obligation most likely to bite first. Unlike a governance framework you can build over months, an incident happens on its own schedule, and DORA gives you hours, not weeks, to notify your competent authority. This guide explains how classification works, what the reporting timeline looks like, and how to be ready before the first major incident.
What DORA actually requires
DORA's incident-reporting pillar (Articles 17–23) requires every in-scope financial entity to detect, manage, classify, and report major ICT-related incidents to its competent authority using a harmonised process. For payment and e-money institutions, this largely replaces the overlapping operational and security incident reporting under PSD2, reducing duplicate channels.
Two things matter most: whether an incident is major (and therefore reportable), and how fast you must report it.
Classifying an incident
Under Article 18, you assess each incident against criteria including:
- the number of clients or financial counterparts affected,
- the duration and service downtime,
- the geographical spread,
- data losses (availability, integrity, confidentiality),
- the economic impact.
If an incident crosses the thresholds set in the regulatory technical standards, it is a major incident and the reporting clock starts. Our incident classifier walks through these criteria and estimates whether an incident is reportable.
The reporting timeline
Major incidents follow a three-stage flow:
- Initial notification, a short, fast alert to the competent authority.
- Intermediate report, once the situation stabilises or materially changes.
- Final report, root-cause analysis and remediation once the incident is closed.
The precise deadlines are set in the technical standards. The practical takeaway: you cannot improvise this during a live incident. The notification has to be pre-wired.
A readiness checklist for fintechs
- Know your competent authority and channel. Confirm exactly where and how you submit, before you need to.
- Pre-fill what you can. Entity identifiers, contact points, and system inventories should be ready to drop into the template.
- Rehearse classification. Run a tabletop against the Article 18 criteria so the "is this major?" decision is not made cold.
- Assign owners. Someone must own detection, someone must own the regulatory submission, and they must be reachable out of hours.
- Log everything. DORA also requires you to record all incidents and significant cyber threats, not only the reportable ones.
Where this fits in the bigger picture
Incident reporting does not stand alone. It depends on the detection capability built under the ICT risk-management framework and often involves your ICT third-party providers, whose contracts must require them to support your reporting obligations.
If you are unsure where your programme stands, the DORA Readiness Score scores your incident-reporting maturity alongside the other four pillars in about five minutes.