DORA ICT Incident Reporting – How to Classify, Escalate, and Report Major Incidents

ByOfficer

Last updated: March 2026

Your payment processing system goes down at 2:15 PM on a Tuesday. Client-facing services are unavailable. Internal teams are scrambling. At some point in the next few hours, someone needs to answer a question that has nothing to do with fixing the problem: does this incident meet the classification criteria for a “major ICT-related incident” under DORA? Because if it does, you have four hours from the moment you classify it to submit an initial notification to the CSSF. Not four hours from when you fix it. Four hours from when you determine it is major. The clock starts at classification, and most teams are not ready for that.

DORA (Regulation (EU) 2022/2554) introduced a harmonized ICT incident reporting framework for all EU financial entities, effective 17 January 2025. Article 19 sets out the obligation: financial entities must report major ICT-related incidents to their competent authority. The classification criteria and materiality thresholds are specified in Commission Delegated Regulation (EU) 2024/1772 (the RTS on classification). The reporting timelines are in Commission Delegated Regulation (EU) 2025/301 (the RTS on timelines). The content, format, templates, and procedures are in Commission Implementing Regulation (EU) 2025/302 (the ITS on templates, based on ESA final report JC 2024/33). Together, these create a three-stage reporting process with tight deadlines and detailed data requirements.

This article covers the classification framework, the reporting timeline, the data fields, and the practical challenges that trip teams up during their first real incident.

Related reading: DORA Register of Information

Who Must Report

All financial entities within the scope of DORA Article 2 are subject to the incident reporting obligation. This includes credit institutions, investment firms, payment institutions, electronic money institutions, investment fund managers, insurance and reinsurance undertakings, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, and other regulated entities listed in Article 2(1).

The obligation applies to the financial entity itself, not to its ICT third-party service providers. If your cloud provider suffers an outage that causes a major incident at your institution, you are the one who reports. The provider is not a financial entity under DORA (unless it is separately regulated). Your contractual arrangements should ensure you receive timely information from providers to support your classification and reporting obligations, but the regulatory duty sits with you.

For groups, DORA Article 19(4)(c) allows the competent authority to determine whether individual entities report or whether a single entity reports on behalf of the group. In practice, this depends on the group structure and the competent authority’s preference. In Luxembourg, the CSSF is the competent authority for entities it supervises. Check with the CSSF if your group structure raises questions about who reports.

The Classification Framework

Not every ICT incident triggers a reporting obligation. Only “major” ICT-related incidents require notification to the competent authority. The classification criteria determine whether an incident crosses that threshold.

The Mandatory Condition: Critical Services Affected

The first test is mandatory. The incident must have had an impact on critical services. This means the incident has affected:

  • ICT services or network and information systems that support critical or important functions of the financial entity, or
  • Financial services that require authorization, registration, or are otherwise supervised by competent authorities, or
  • A successful, malicious, and unauthorized access to the network and information systems of the financial entity

If the incident does not meet this mandatory condition, it is not major under DORA regardless of its other characteristics. An outage affecting a non-critical internal tool (say, a staff training portal) does not qualify even if it lasts a week.

The definition of “critical or important functions” comes from your own assessment under DORA Article 3(22). This is the same classification you use for the Register of Information. If you have not properly identified your critical or important functions, you cannot properly classify incidents. The two obligations are linked.

The Trigger: Two Additional Criteria or Malicious Access

Once the mandatory condition is met, the incident is classified as major if either:

  • The thresholds of at least two additional classification criteria (from the six listed below) are met, or
  • The incident involves a successful, malicious, and unauthorized access to network and information systems that may result in data losses

The second path (malicious access with potential data loss) is an automatic trigger. If someone breaches your systems and data may have been compromised, the incident is major regardless of how many other criteria are met. This reflects the severity regulators assign to cybersecurity breaches.

The Six Classification Criteria and Their Materiality Thresholds

The Commission Delegated Regulation (EU) 2024/1772 specifies six classification criteria, each with a defined materiality threshold. An incident must meet the threshold of at least two of these (in addition to the mandatory condition) to qualify as major:

1. Clients, financial counterparts, and transactions affected. The threshold is met if any of the following apply: more than 10% of all clients using the affected service are impacted; more than 100,000 clients are affected; more than 30% of all financial counterparts used by the entity are affected; more than 10% of the daily average number of transactions is affected; more than 10% of the daily average amount of transactions is affected; or any impact on clients or counterparts that the entity identifies as relevant to its business objectives.

2. Data losses. Any impact on the availability, authenticity, integrity, or confidentiality of data that has or will have an adverse impact on the implementation of business objectives or on meeting regulatory requirements.

3. Reputational impact. This is met if the incident is reflected in the media, if the entity receives repetitive complaints, if the entity cannot meet regulatory requirements because of the incident, or if there is a likely loss of clients or financial counterparts with a material impact on the entity’s business.

4. Duration and service downtime. The incident duration exceeds 24 hours, or the service downtime exceeds 2 hours for ICT services that support critical or important functions.

5. Geographical spread. The impact of the incident is identified in the territories of at least two Member States.

6. Economic impact. The costs and losses incurred by the financial entity exceed or are likely to exceed EUR 100,000. This includes direct costs (expropriated funds, replacement costs, staff costs, contract non-compliance fees, customer compensation, forgone revenues, communication costs, advisory costs) and can be based on estimates where actual figures are not yet available.

In practice, the “critical services affected plus two additional criteria” test is where most classification decisions happen. The two most commonly triggered criteria are duration/downtime and clients affected, because any significant outage affecting client-facing services will usually meet both.

The Three-Stage Reporting Timeline

Once you classify an incident as major, DORA requires three sequential reports. The timeline is tight and the clock starts at different moments for each stage.

Stage 1: Initial Notification

Deadline: within 24 hours of becoming aware of the incident, and within 4 hours of classifying it as major (whichever comes later, but the 4-hour deadline from classification is typically the binding constraint).

The initial notification is a concise alert. It tells the competent authority that a major incident has occurred, provides basic identification information (entity name, LEI, contact person), a preliminary description, the date and time of occurrence, the date and time of classification, and which classification criteria triggered the report. It also requires an indication of whether the incident is ongoing or resolved.

This is not a full analysis. It is a notification. The competent authority needs to know the incident exists and roughly what it involves. Do not wait until you have a complete picture. Submit what you know.

If the incident is not classified as major within the initial 24 hours but is reclassified as major later (as the impact becomes clearer), the 4-hour clock starts from the moment of reclassification.

Stage 2: Intermediate Report

Deadline: no later than 72 hours from the submission of the initial notification.

The intermediate report is substantially more detailed. It requires: the incident reference code (if provided by the competent authority), date and time of occurrence, date and time of restoration (if applicable), the classification criteria that triggered the report, the type of incident, the threats and techniques used by the threat actor (if applicable), the affected functional areas and business processes, the affected infrastructure components, the impact on financial counterparts and clients, a description of the response and recovery actions taken, and the root cause (if identified).

Even if the status or handling of the incident has not changed since the initial notification, you must still submit the intermediate report within 72 hours. The RTS is explicit on this point. And if regular activities are restored before the 72-hour deadline, you must submit an updated intermediate report without undue delay.

Stage 3: Final Report

Deadline: no later than one month from the submission of the latest updated intermediate report.

The final report is the full post-incident analysis. It includes everything from the intermediate report plus: the root cause analysis, the timeline of events from detection to resolution, the total impact assessment (quantified where possible), the remediation measures taken, and the lessons learned.

The one-month timeline from the latest intermediate report (not from the incident itself) means that if you submit multiple updated intermediate reports, the final report deadline shifts accordingly. This gives entities time for a proper root cause analysis rather than rushing a superficial conclusion.

Weekend and Bank Holiday Rules

If a submission deadline for an initial notification or intermediate report falls on a weekend or bank holiday in the Member State of the reporting entity, the entity may submit by noon of the next working day. This relaxation also applies to the final report, which can always be deferred to the next working day if the deadline falls on a weekend or holiday.

However, the weekend exemption for initial notifications and intermediate reports does not apply to significant or systemic institutions at EU and national level (e.g., significant credit institutions under SSM, central counterparties, operators of trading venues), or to entities identified as essential or important under the NIS2 Directive. Those entities must meet the original deadlines regardless of weekends or holidays. Check CDR (EU) 2025/301 for the full list of excluded entity types. If you are a significant bank, you report on Saturday if the deadline falls on Saturday.

What Goes in Each Report

The ITS (CIR (EU) 2025/302) specifies the data fields for each stage. The template is structured in sections:

Section 1: General Information

Entity identification (name, LEI, entity type), contact person details, supervisory identification codes. These fields are mandatory across all three reports. Most of this information should be pre-populated in your incident reporting template.

Section 2: Incident Information

This section expands across the three stages. In the initial notification, you provide: date and time of detection, date and time of occurrence, date and time of classification as major, a preliminary description, which classification criteria triggered the notification, how the incident was discovered (IT security, staff, internal audit, external audit, or clients), and the EEA Member States impacted (if geographical spread is a factor).

In the intermediate and final reports, this section adds: the incident type, threats and techniques used, affected functional areas and business processes, the impact on clients and financial counterparts (with quantification), the impact on transactions, and the economic impact assessment.

Section 3: Impact Assessment and Recovery

This section is primarily for the intermediate and final reports. It covers: the ICT services affected, the duration and service downtime metrics, the data losses identified, the response actions taken, the recovery timeline, and the third-party ICT providers involved (if the incident originated at or was exacerbated by a provider).

In the final report, this section also includes root cause analysis, lessons learned, and remediation measures implemented or planned.

How the Incident Was Discovered

The reporting template requires you to indicate how the incident was discovered. The options are a closed list in Annex I of CIR (EU) 2025/302 (field 2.7). The categories include: IT Security (automated monitoring, SIEM alerts), Staff member, Internal audit, Consumer or payment service user, External auditor, Third-party provider, Attacker or warning, and Other. This matters because it gives the competent authority insight into your detection capabilities. An incident discovered by your IT security team suggests functioning monitoring. An incident discovered by clients or a third-party provider suggests your monitoring missed it.

I have seen teams default to “IT Security” even when the incident was actually flagged by a client complaint. Be accurate. The competent authority will review this field in the context of your broader ICT risk management framework. If clients are consistently discovering your incidents before your monitoring tools do, that is a finding in itself.

Significant Cyber Threats: Voluntary Reporting

In addition to mandatory major incident reporting, DORA Article 19(2) allows financial entities to voluntarily notify the competent authority of significant cyber threats that they deem relevant, even if the threat has not materialized into an incident. This is voluntary, not mandatory.

The ITS provides a separate template for cyber threat notifications (Annex III of CIR (EU) 2025/302). The data fields are lighter than the incident reporting template: entity identification, a description of the threat, the threat type (e.g., malware, phishing, DDoS, supply chain), the potential impact assessment, and whether any countermeasures have been implemented.

In practice, voluntary threat notification is about information sharing. The competent authority can use the information to alert other entities in the sector. If you detect a targeted phishing campaign against Luxembourg financial entities, notifying the CSSF helps the broader ecosystem even if the threat did not breach your defenses.

NIS2 Alignment and Double Reporting

Financial entities that fall within the scope of both DORA and the NIS2 Directive (Directive (EU) 2022/2555) may face overlapping incident reporting obligations. DORA is lex specialis for the financial sector, meaning DORA’s incident reporting requirements take precedence over NIS2 for financial entities.

The ESAs designed the DORA reporting timelines to align with NIS2 to the extent possible, while being more stringent in certain areas. The key differences:

  • NIS2 requires an “early warning” within 24 hours of becoming aware of a significant incident. DORA requires an initial notification within 24 hours of awareness and within 4 hours of classification. The 4-hour classification deadline makes DORA more demanding.
  • NIS2 requires an “incident notification” within 72 hours of awareness. DORA requires an intermediate report within 72 hours of the initial notification submission (not awareness), giving slightly more time in practice.
  • NIS2 requires a final report within one month of the incident notification. DORA requires a final report within one month of the latest intermediate report, which may shift the deadline later if multiple intermediate reports are submitted.

For entities subject to both frameworks, DORA reporting to the CSSF satisfies the financial sector reporting obligation. Separate NIS2 reporting to a national CSIRT is a matter of national implementation. In Luxembourg, the CSSF acts as the single point of entry for DORA incident reports from the entities it supervises. Check with the CSSF and the national CSIRT (CIRCL or ILR, depending on the entity type) for any additional NIS2 obligations that may apply.

Luxembourg Specifics: Reporting to the CSSF

CSSF Circular 25/893 (dated 27 May 2025) is the key Luxembourg-specific document. It sets out the practical modalities for DORA incident reporting to the CSSF. The circular applies to all financial entities defined in DORA Article 2(1)(a) to (i), (k) to (m), (p), (r) and (s), and also extends the DORA incident reporting framework to Payment Service Providers not in DORA scope, requiring them to follow the same classification and reporting procedures to fulfil their obligations under Article 105-2 of the Law of 10 November 2009 on payment services (LPS).

The submission channel is specific: major ICT-related incident notifications and significant cyber threats must be submitted via the dedicated procedure “DORA Major ICT-related Incident Notification” on the CSSF eDesk Portal, or via the API interface (S3) provided by the CSSF. Financial entities must follow the time limits laid down in Article 5 of the RTS on incident reporting (CDR (EU) 2025/301).

The CSSF has existing incident reporting experience from pre-DORA frameworks (including PSD2 major incident reporting for payment institutions and the previous CSSF cyber incident notification process). DORA harmonizes and replaces these with a single framework. If you were previously reporting ICT incidents to the CSSF under a different framework, the DORA process supersedes it. Note that Circular 25/893 explicitly requires non-DORA PSPs to follow the DORA framework for all ICT-related incidents (including those unrelated to payment services), to avoid running a dual reporting scheme.

One practical point: make sure your incident response team knows who has the credentials and access to submit reports via eDesk or the S3 API. This should not be one person. If that person is on vacation when the incident occurs, you have a process gap that adds unnecessary stress to an already stressful situation.

Common Errors in the First Live Incident

Based on how incident reporting works in practice across regulatory frameworks, here are the mistakes that teams make most often during their first major ICT incident under DORA:

Confusing Detection with Classification

Detection is when you become aware something is wrong. Classification is when you determine the incident meets the criteria for “major.” These are two different events with different timestamps. The 24-hour clock starts at detection (awareness). The 4-hour clock starts at classification. Teams that conflate the two either report too late (missing the 4-hour window because they treated detection as classification) or too early (submitting before properly assessing whether the incident is truly major).

Waiting for Complete Information Before Submitting

The initial notification is intentionally lightweight. It does not require root cause analysis, complete impact quantification, or a recovery plan. Teams accustomed to internal incident management processes (where you gather all facts before escalating) tend to hold the initial notification while they investigate. Do not do this. Submit what you know within the 4-hour window. The intermediate and final reports exist precisely to provide the complete picture later.

Not Pre-Populating the Template

Section 1 (general information) is identical for every incident. Entity name, LEI, entity type, contact details, supervisory codes. Pre-populate these fields in your incident reporting template now, during business-as-usual, so that during a live incident you only need to complete the incident-specific fields. Filling in boilerplate identification data under pressure is a waste of scarce time.

Unclear Ownership of the Classification Decision

Who decides whether an incident is “major”? The head of IT operations? The CISO? The MLRO? The management board? DORA does not prescribe this, but your internal policies should. If the classification decision requires a committee meeting, and the committee cannot convene within two hours of detection, you will not meet the 4-hour deadline. Designate a classification authority (and a deputy) who can make the call without waiting for a full meeting.

Miscounting the Materiality Thresholds

The classification requires the mandatory condition (critical services affected) plus two additional criteria. Teams sometimes count the mandatory condition as one of the two. It is not. Critical services affected is the gateway. You still need two more. Conversely, teams sometimes dismiss an incident because only one additional criterion is met, without checking whether the malicious access path applies independently.

Forgetting the 72-Hour Intermediate Report When Nothing Has Changed

The RTS on timelines requires the intermediate report within 72 hours of the initial notification “even where the status or the handling of the incident have not changed.” Teams assume that if there is nothing new to report, they can skip the intermediate report. They cannot. Submit the report with the current status, even if it is unchanged. The obligation is time-based, not event-based.

Building Your Incident Reporting Playbook

A practical playbook should cover at least these elements:

  • Pre-populated reporting template with Section 1 (entity identification) already completed
  • Classification decision tree: mandatory condition check, then additional criteria assessment, with clear thresholds documented for your entity (what does “10% of clients” mean for your specific client base?)
  • Named classification authority and deputy, with mobile contact details and delegated authority to classify without a formal meeting
  • CSSF eDesk portal access (or S3 API credentials): credentials, URL, backup access, tested at least quarterly
  • Internal escalation path: who is notified at detection, who makes the classification call, who drafts the notification, who submits it
  • Communication templates for internal stakeholders, management board, and (if required) clients
  • Clock management: a simple checklist tracking the 24-hour awareness clock and 4-hour classification clock separately
  • Third-party provider notification clauses: contractual provisions requiring your ICT providers to alert you within a defined timeframe if an incident at their end affects your services

I recommend running a tabletop exercise at least once a year. Simulate a realistic incident scenario (a provider outage, a ransomware event, a data breach) and walk through the classification criteria, the 4-hour initial notification, and the 72-hour intermediate report. Time the exercise. If your team cannot complete the initial notification within 4 hours in a simulation with no actual pressure, they will not do it during a real incident when the systems are down and everyone is stressed.

Frequently Asked Questions

What if we are not sure whether the incident is major?

You have 24 hours from when you become aware of the incident to classify it. Use that time to assess against the criteria. If it is borderline, err on the side of reporting. Submitting an initial notification for an incident that later turns out to be non-major is far less problematic than failing to report a major incident within the deadline. You can update the classification in the intermediate report.

Does a third-party provider outage trigger our reporting obligation?

Yes, if the outage causes a major ICT-related incident at your entity. The reporting obligation sits with the financial entity, not the provider. Your contracts should include provisions requiring the provider to notify you promptly when incidents occur at their end. Without timely provider notification, you may not become aware of the incident until clients report it, which shortens your effective response time.

Do we report to the CSSF or to the ESAs?

Financial entities report to their competent authority. For Luxembourg-supervised entities, this is the CSSF. The CSSF may then share relevant information with the ESAs, the ECB, or other authorities as required under DORA Article 19(6) and (7). You report once, to the CSSF.

How does the economic impact threshold work if we do not have exact figures?

The RTS explicitly allows estimates where actual figures are not yet available. For the initial notification and intermediate report, you can use reasonable estimates of costs and losses. The final report should include more accurate figures. The EUR 100,000 threshold includes both direct costs (replacement, staff, compensation) and indirect costs (forgone revenues, reputational damage). When in doubt, estimate conservatively and flag that the figure is an estimate.

What counts as “service downtime” for the duration criterion?

Service downtime is measured from the moment the service is fully or partially unavailable or delayed to clients, financial counterparts, or internal/external users, until activities are restored to the same level as before the incident. Partial degradation counts. If your online banking works but is significantly slower than normal, that is service downtime. The 2-hour threshold applies specifically to ICT services supporting critical or important functions.

Can we submit a single report for recurring incidents?

The ITS (CIR (EU) 2025/302, Article 7) provides for aggregated reporting, but the conditions are strict. All of the following must be met: the incident originates at a third-party ICT provider; the provider serves more than one financial entity (or a group) in the same Member State; the affected entities are all supervised by the same competent authority; each entity has individually classified the incident as major; each entity has outsourced its reporting obligation to the provider under Article 19(5) of DORA; and the aggregated report contains the impact assessment for each covered entity. Significant credit institutions, central counterparties, and operators of trading venues are excluded from aggregated reporting. It does not apply to recurring but separate incidents (e.g., repeated outages from different causes).

What is the penalty for late or missing reports?

DORA Chapter VII (Articles 50-52) empowers Member States to lay down rules on administrative penalties and remedial measures for infringements of the Regulation. The specific penalties depend on national implementation. In Luxembourg, the CSSF has broad sanctioning powers. In practice, a late report for a genuine incident handled in good faith is treated differently from a pattern of non-reporting or a deliberate failure to classify incidents as major. The regulatory relationship matters. Communicate proactively with the CSSF if you anticipate a delay.

Related Articles

  • DORA Register of Information – The other major DORA deliverable: building and submitting the register of ICT third-party arrangements. The register and incident reporting share the “critical or important functions” classification.
  • PSD2 Reporting Requirements – Payment institutions previously reported major operational or security incidents under PSD2. DORA supersedes this for ICT-related incidents.
  • MiCAR Reporting Obligations – CASPs are within DORA scope. MiCAR establishes additional reporting, but ICT incident reporting falls under DORA.
  • COREP Reporting Explained – Operational risk capital (C 17.00/C 17.01) captures ICT losses. DORA incidents may also surface in COREP operational risk templates.
  • EMIR Reporting Explained – CCPs and trade repositories are in DORA scope. A major ICT incident affecting trade reporting or clearing has both DORA and EMIR implications.

Key Takeaways

  • DORA ICT incident reporting applies to all financial entities in scope of Article 2. The obligation sits with the entity, not its ICT providers.
  • An incident is “major” if it affects critical services AND either triggers two of six additional classification criteria or involves malicious unauthorized access with potential data loss.
  • The six classification criteria are: clients/counterparts/transactions affected, data losses, reputational impact, duration/service downtime, geographical spread, and economic impact (EUR 100,000 threshold).
  • Three-stage reporting: initial notification (24 hours from awareness, 4 hours from classification), intermediate report (72 hours from initial notification), final report (one month from the latest intermediate report).
  • The 4-hour classification deadline is the binding constraint for most incidents. Designate a classification authority who can decide without convening a committee.
  • Pre-populate Section 1 of the reporting template now. Do not fill in entity identification data under pressure during a live incident.
  • The intermediate report must be submitted within 72 hours even if nothing has changed since the initial notification.
  • Significant cyber threats can be reported voluntarily under a separate, lighter template (Annex III). This supports sector-wide information sharing.
  • In Luxembourg, CSSF Circular 25/893 sets the practical modalities: submit via eDesk (“DORA Major ICT-related Incident Notification”) or the S3 API. Non-DORA PSPs must also follow the DORA framework.

Sources and References

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts