DORA Incident Reporting Requirements

Major Incident Reporting Timeline

Once an ICT-related incident is classified as major (per RTS 2024/1772), the financial entity must follow this three-stage reporting path with the competent authority. The clock starts at the moment of classification, not at detection.

The 7 Classification Criteria (RTS 2024/1772)

Commission Delegated Regulation (EU) 2024/1772 sets out the criteria, thresholds and approach for classifying ICT-related incidents and significant cyber threats. An incident is major if it meets at least 2 primary criteria or 1 primary criterion plus the economic-impact threshold.

Three Reporting Streams under DORA

Single channel: per Article 19(1), each Member State designates one competent authority as the entry point. Reports may be transmitted via national portals or the ESAs' joint platform once operational.

NCA Reporting Portals: Submission Channels

Under Article 19(1), each Member State designates a single competent authority as the entry point for major incident reports. The submission channel and specific portal vary by jurisdiction. The reporting entity submits to its home NCA, which forwards aggregated information to the relevant ESA, the ECB (where applicable for SSM-supervised banks) and ENISA per Article 19(6).

Major NCA portals across the EU

Practical recommendation: identify your home NCA portal during normal-operations preparation, not during an incident. Pre-register access credentials, conduct a dry-run submission with a test incident, and document the portal walkthrough in the incident response playbook. Many incidents are reported late simply because the submitter could not retrieve the portal credentials at 3 AM during the outage.

Worked Example: A Major Incident Walk-Through

To make the classification process tangible, here is a fictional but representative incident at a mid-size EU bank, followed by the application of the RTS criteria, the classification decision, and the reporting timeline.

Scenario

At 14:32 CET on a Wednesday, the online banking platform of Bank Alpha (€18bn total assets, 1.2 million retail clients in Germany and France) becomes unresponsive. By 15:00 the SOC confirms a denial-of-service attack against the load balancer fronting the customer portal. The mobile app and web banking are unavailable; bill payments queued during the outage are not processed; SMS authentication for high-value transfers is also affected (different downstream system). At 16:45 the load balancer is failed over to the DR region; service is restored by 17:30 with limited residual lag. Total downtime: 2h 58min during peak banking hours. No data confidentiality compromise.

Classification analysis

• Criterion 1 (Clients & transactions): ~310,000 active sessions interrupted; ~22,000 transactions delayed. Above primary threshold for "more than 10% of clients" affected: YES.
• Criterion 2 (Reputational impact): Social media spike during peak hours; 4 newspaper articles (3 regional, 1 national) by Thursday morning. Borderline — supervisory dialogue needed.
• Criterion 3 (Duration): 2h 58min downtime. Primary threshold "longer than 24h" not met: NO.
• Criterion 4 (Geographical spread): Clients affected in 2 Member States (DE + FR): YES.
• Criterion 5 (Data losses): No confidentiality breach: NO.
• Criterion 6 (Critical functions): Online banking platform supports a Critical or Important Function (retail payment services): YES.
• Criterion 7 (Economic impact): Direct cost (incident response, comms): €40K. Indirect cost (delayed transactions, fee waivers, customer compensation): €180K. Total: €220K — above €100K threshold: YES.

Decision: Multiple primary criteria triggered (1, 4, 6) plus economic threshold (7). Classification: major incident. The 4h clock starts at the classification decision (assume 16:00 same day after SOC confirmation).

Reporting timeline

• 20:00 same day (4h after classification): Initial notification submitted to BaFin via MVP portal. Basic facts. ACPR notified in parallel via OneGate as cross-border incident.
• Saturday 15:30 CET (72h after classification): Intermediate report submitted. Includes preliminary root cause (DDoS via botnet, peak 240 Gbps), containment timeline, customer impact data, third-party DDoS mitigation provider engaged.
• One month later: Final report. Full root cause analysis, control gap (load balancer capacity not aligned with peak demand assumption), corrective actions (DDoS scrubbing capacity upgrade, monitoring enhancement, run-book updates), lessons learned. Forward-looking actions: include DDoS scenario in next year's resilience testing programme.

Significant Cyber Threat Reporting (Article 19(2))

Article 19(2) introduces a voluntary notification mechanism for "significant cyber threats" — threats observed by the entity that have not yet materialised as incidents but are considered relevant to the financial system. The aim is sector-wide intelligence sharing: an early warning from one entity can help others harden defences.

What qualifies as a significant cyber threat

The RTS on classification (RTS 2024/1772) clarifies the criteria for "significant" status:

• Threat actors with capability and intent to cause major impact on the entity
• Tactics, techniques and procedures (TTPs) targeting Critical or Important Functions
• Indicators suggesting imminence (active reconnaissance, exposure of credentials, supply chain compromise upstream)
• Threats with potential cross-border or sector-wide spillover

Reporting mechanism

Notification is made via the same NCA portal as incident reports, using RTS 2025/301 Annex III (threat notification template). The template captures: threat description, TTPs observed, indicators of compromise (IOCs), affected functions/systems, mitigation actions taken, intelligence sharing recommendation. The NCA may forward the threat brief to ESAs and to other entities via trusted information sharing arrangements (Article 45).

Practical recommendation: establish a Threat Notification Decision Committee in the SOC governance — typically 3-5 people meeting weekly to review observed threats and decide whether to notify. Most banks find that 10-30 threats per year qualify for voluntary notification under Article 19(2).

Common Pitfalls to Avoid

• Confusing detection with classification. The 4h clock starts at classification, but classification itself must happen without undue delay. Internal SLAs of 24h are reasonable; 72h is too late.
• Ignoring third-party incidents. Under Article 17, a major incident at a critical ICT third-party that affects your CIFs must be reported even if you only learn about it indirectly.
• Underreporting cumulative impact. Recurring related incidents must be aggregated when assessing economic impact — not analysed in isolation.
• Missing the 30 April RoI deadline. The Register of Information is a separate annual filing — not bundled with incident reporting. xBRL-CSV format is mandatory.
• Forgetting client notification. Article 19(3): when a major incident affects financial interests of clients, the entity must inform clients without undue delay and indicate measures taken.
• No dual-language plan. Reports must be filed in the official language(s) of the host Member State; some authorities also accept English. Plan templates accordingly.

Related DORA References

• RTS on Incident Reporting — deep-dive guide — full text walk-through of RTS 2025/301
• Critical or Important Functions (CIF) — the materiality concept that drives "criticality of services affected"
• All DORA RTS & ITS — complete index of technical standards
• DORA Audit: Requirements & Checklist — how incident reporting is tested in supervisory inspections
• TLPT (Threat-Led Penetration Testing) — how testing findings inform incident-readiness
• DORA Compliance Software — SaaS to operationalise reporting
• Server Hardening Requirements — preventive controls that reduce incident likelihood