DORA ICT incident reporting deadlines and process

How DORA ICT incident reporting works and who owns each step

A major ICT-related incident triggers an initial notification within 4 hours of classifying the incident as major, and no later than 24 hours after the entity became aware of it. An intermediate report follows within 72 hours of the initial notification, and the final report is due no later than one month after the latest intermediate report. These clocks run in parallel with containment work, so the reporting process has to be designed before an incident happens. The financial entity, or the ICT provider acting for it, owns every deadline. The entity remains responsible even when a third party files the reports, and it must inform its competent authority before the first report if it outsources reporting.

Ownership is split across three roles. The entity's management and incident response team own the classification decision, the timing and the content of each report. A partner can prepare the systems and evidence that make those deadlines achievable, such as incident logs with stable identifiers, a documented classification workflow, report drafting templates based on the Annex I template in Implementing Regulation (EU) 2025/302, and tested escalation paths. The partner does not decide whether an incident is major and does not submit reports to the authority. The DORA Regulation on EUR-Lex sets the framework, but the operational detail sits in the delegated and implementing acts.

Only the competent authority receives these reports, through the secure channels it provides. No independent auditor, assessor or certification body issues a report, attestation or certificate for incident reporting, so a clean audit history does not show that reporting works. The evidence an authority can request is the incident record, the classification rationale, timestamps of awareness and submission, and any notice of a missed deadline with its explanation. Before you engage a partner, confirm with your competent authority which channel and template version it currently accepts, and ask the partner to show how each piece of evidence is produced during a tabletop exercise.

How an incident becomes a major incident under DORA

This sequence turns a raw operational event into a documented classification decision that either triggers the three-report reporting cycle or records why it does not. Each step produces a record that an assessor or supervisor can trace back to the criteria.

Record every ICT-related incident
Under Article 17, the financial entity records all ICT-related incidents in its incident management process, not only those that look serious at first. The owner is the incident response function, working with the ICT operations teams that detect the event. The step is complete when each incident has a unique identifier, a timestamp for when it was detected, a short description of the affected ICT systems and services, and an initial severity assigned. That identifier should stay the same through every later report, so confirm with your competent authority how it expects the identifier to be carried forward.
Classify the incident against the criteria
The entity assesses the recorded incident against the classification criteria in Delegated Regulation (EU) 2024/1772, including whether it affects critical services. The compliance or risk function reviews the assessment, usually with the service owner who can state which clients, counterparts and transactions were touched. The output is a classification record that shows each criterion, the evidence used for it, and the person who approved the result. Where data is incomplete, the record should say what is still unknown and when it will be updated.
Test the client and counterpart thresholds
Article 9 of Delegated Regulation (EU) 2024/1772 sets quantitative thresholds for clients, including more than 10 % or more than 100 000 clients using the affected service, and for financial counterparts, including more than 30 %. The entity measures each share against its own client and counterpart data for the affected service. The output is a threshold table with the measured value, the threshold and the data source for each line. Retain the query or report used so the figures can be reproduced during supervision.
Test the transaction, duration and downtime thresholds
The same article sets thresholds for transaction volume or value (more than 10 % of the daily average), for duration (over 24 hours), and for downtime over 2 hours for services that support critical or important functions. Operations and finance teams usually provide the transaction baselines and the incident timeline from monitoring and ticketing systems. The output is the timeline and calculation sheet, with clock sources recorded so that durations can be defended. Ask your system owners to confirm how downtime is measured for each service, since the measurement method changes the result.
Test the geographic and financial thresholds
The remaining thresholds cover impact in two or more member states and costs and losses over EUR 100 000. For the geographic test, the entity records which member states' clients or operations were affected. For the financial test, finance and the incident team estimate direct and indirect costs and losses, separating what has been incurred from what is expected. The output is a documented cost and location assessment. Include the assumptions behind any estimate, because the same figures may later feed the annual cost and loss estimate requested under Article 11(10).
Decide major status under Article 8
Under Article 8 of Delegated Regulation (EU) 2024/1772, an incident is major if it affected critical services and either involved malicious unauthorised access that may cause data losses, or met two or more of the other thresholds. The incident response lead and the compliance function make the decision and the accountable manager signs it off. The output is a dated decision record that cites the criteria met, the criteria not met and the rationale. This record is what the competent authority will ask for first, so it should be written for an outside reader.
Start the reporting clock or record the decision
If the incident is major, the entity moves to the reporting cycle, where the initial notification falls due within 4 hours of classification and no later than 24 hours after awareness, as set by Delegated Regulation (EU) 2025/301. If the incident is not major, the decision record is retained and the incident stays in the register of ICT incidents. Either way, the entity should confirm the time it became aware and the time it classified, since both dates control the deadlines. Reassess the classification whenever new facts emerge, and record each reassessment as its own dated entry.

What the three DORA incident reports must contain and when they are due

DORA requires a major ICT-related incident to move through three reports on fixed clocks, each with its own deadline rules. The cards below cover the timing rules, the exceptions that change weekend handling, the duty to warn the authority early, and the operational expectations supervisors have set for the reporting lifecycle.

Initial notification clock

The initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after the entity becomes aware of it. The two clocks run separately, so a late classification does not extend the 24-hour outer limit. Teams should record the time of awareness and the time of classification in the incident log from the first alert, because the authority will test both against the timestamps in the report.

Intermediate report timing

The intermediate report is due within 72 hours of the initial notification and must update the authority on the incident's status and development. Entities should plan for it to be filed while the incident is still open, since the ESA operational instructions of 16 September 2026 expect at least one intermediate report per month until the final report. Ask whether your reporting tool can reissue a status update without restarting the incident record.

Final report deadline

The final report is due no later than one month after the latest intermediate report. Its timing depends on the last intermediate report, so a series of short updates can move the final date. Teams should confirm that root cause analysis, impact figures and remediation status are complete before the final report is due, because late corrections are harder to explain once the report is filed.

Weekend and bank holiday rule

A deadline that falls on a weekend or bank holiday moves to noon on the next working day. The exception matters: initial notifications and intermediate reports from credit institutions, central counterparties, trading venue operators and NIS2 essential or important entities do not get this extension. Compliance teams should build their on-call rota and reporting calendar around that difference, and confirm with their competent authority which public holidays it observes.

Warning the authority before a missed deadline

If an entity cannot meet a deadline, it must tell its competent authority no later than that deadline and explain why. A missed deadline without prior notice is a separate compliance failure from a late report, so the warning should be sent as soon as the delay is foreseeable. The message should state the cause, the expected new date and the steps being taken, and it should be stored with the incident file as evidence.

Stable identifiers and thousands

The ESA operational instructions of 16 September 2026 expect the incident identifier to stay unchanged through the whole reporting lifecycle, so the same reference must appear in the initial, intermediate and final reports. Monetary fields are reported in thousands of units. Systems that generate reports should lock these two conventions in the template mapping, not leave them to each analyst, and test them before the first live incident.

Templates, submission channels and outsourcing the reporting

The incident team produces the facts that fill the reporting template. Each report asks for structured data about the incident, its impact on clients, services, transactions and costs, and the measures taken, so the team needs to record these items from the first hour rather than reconstruct them later. Incident identifiers matter here because supervisors expect the same identifier to stay unchanged through every report in the lifecycle.

Log the detection time early: Record when the incident was detected and when it was classified as major, since the initial notification clock starts from those points.
Track impact figures as they change: Keep running counts of affected clients, transactions, downtime and estimated costs and losses, so each intermediate and final report reflects the latest position.
Assign one incident identifier: Issue it at the start and use it in every communication, log entry and submission.
Record the mitigation steps: Note the measures taken, because clients must be informed of them and the reports ask for them.
Keep monetary values consistent: Agree internally how costs and losses are calculated, since the ESA operational instructions expect monetary fields in thousands of units.

Before closing the incident, confirm with the reporting lead which template fields the team can complete from its records and which require input from business owners or providers.

When clients must be told about a major incident

Article 19(3) of DORA requires a financial entity to inform its clients without undue delay when a major ICT-related incident affects their financial interests, and to explain the measures taken to mitigate the effects. The duty is triggered by the classification of the incident as major, not by the first report to the competent authority, and it runs alongside the regulatory clock rather than replacing it. Client notice is a separate obligation with its own owner, so it should appear as a named step in the incident runbook with a decision point after classification. The Regulation sets no fixed hour for client notice, so any internal target must be a policy choice that the entity can defend to its supervisor, and the reporting deadlines in Delegated Regulation (EU) 2025/301 do not stand in for it.

The hardest part is deciding which clients are affected. Start from the service impact record that the incident team already holds: which ICT services were degraded or unavailable, which client groups consume them, and whether any client's money, positions, payments, claims or data-driven financial decisions were disrupted. A client can be affected even when the entity's own systems look restored, for example when a delayed settlement or a corrupted balance is still being reconciled. Record the reasoning for each client group, including the groups judged unaffected, because a supervisor may ask why a particular group was not told. Legal and client-facing teams should agree the criteria before an incident occurs, so the decision is not made under pressure in the first hours of a major incident.

A client notice should stay factual and general. It should state what happened in plain terms, the period during which the service was affected, what the client may observe or need to check, and the measures the entity has taken or is taking to limit the effect. It should not speculate about root cause before analysis is complete, and it should not disclose details that would expose other clients or weaken security. Each notice should be consistent with the information later filed in the initial, intermediate and final reports, so the entity should keep one fact base that both the regulator reports and client messages draw from. Confirm with counsel how the notice interacts with existing contract terms, service level commitments and any national rules that apply to the entity.

Payment incidents and significant credit institutions: who else receives the report

Not every major incident goes only to one supervisor. Payment-related incidents fall under the same reporting regime for several kinds of payment provider, and significant credit institutions route reports through the ECB. Each card below covers a receiving party or a routing rule that changes who sees the report and what the reporting entity must check.

Payment-related incidents under Article 23

Article 23 extends the DORA reporting regime to operational or security payment-related incidents at credit institutions, payment institutions, account information service providers and electronic money institutions. Payment teams often assume their incidents already sit under a separate scheme, so the first check is whether each payment incident is recorded and classified under the same DORA process as other ICT incidents. Confirm this with your competent authority for each entity in the group.

PSD2 reporting switched off

Directive (EU) 2022/2556 switched off PSD2 incident reporting for payment service providers covered by DORA. Teams that still file PSD2 incident reports out of habit risk duplicate or misdirected submissions. Update procedures, runbooks and templates so that a payment incident follows the DORA classification and the three-report sequence, and confirm with the supervisor which channel now applies.

Significant credit institutions and the ECB

A significant credit institution reports a major incident to its national competent authority, which then forwards the report immediately to the ECB. The entity still files once, but it must know which authority receives its submission and that the ECB will see the same content. Build the routing into the incident workflow so that the report reaches the national authority within the deadlines in Article 5 of Delegated Regulation (EU) 2025/301.

Copies to NIS2 authorities and CSIRTs

Member states may require copies of DORA incident reports to be sent to NIS2 authorities or CSIRTs. The obligation depends on national implementation, so the same report can reach more than one authority in some countries. Ask your competent authority which additional recipients apply in each member state where you operate, and whether they expect the copy from you or from the authority.

Mapping recipients to each entity

A group with several licensed entities may hold a credit institution, a payment institution and an electronic money institution, each with its own authority and routing. Keep a table that lists, for every entity, the payment incidents in scope, the receiving authority, any ECB forwarding and any national copy requirement. Review it whenever a licence, a classification or a member state changes.

Consistent identifiers across recipients

Whoever receives a copy of the report, the incident identifier must stay the same through the reporting lifecycle, according to the ESA operational instructions of 16 September 2026. A mismatch between the national authority, the ECB and a CSIRT copy creates avoidable queries. Assign the identifier at detection, record it in the incident tool and reuse it in every submission and follow-up.

What must be in place before the first incident hits the clock

The reporting clock under DORA starts when an entity classifies an incident as major, so the classification logic, the people, the channels and the data have to exist before anything goes wrong. Each card below is a piece the organization must own, and each one can be checked with a tabletop exercise run against a realistic scenario.

Classification procedure tied to thresholds

Write a procedure that walks an incident through the major criteria in Delegated Regulation (EU) 2024/1772, including the critical services test and the materiality thresholds on clients, counterparts, transactions, duration, geography and costs. The procedure should say who decides, how fast, and what evidence is recorded for the decision. In a tabletop, give the team a scenario with partial data and check whether they reach a classification decision within the time the procedure allows, and whether the record would satisfy a supervisor.

Named reporting roles and deputies

Assign named people to classify, approve, draft and submit each report, and name a deputy for every role. Decide who can sign off on an initial notification at night or over a weekend, since deadlines that fall on those days can move, but not for every type of entity. In a tabletop, remove the primary owner of one role and time how long it takes to reach a submittable draft.

Tested contact route to the authority

Confirm with your competent authority which secure electronic channel it expects for each of the three reports, who holds the credentials, and what happens when the channel is down. Keep a documented fallback and a way to tell the authority why a deadline cannot be met, which must be done no later than the deadline itself. In a tabletop, test log-in, submission of a dummy draft and the fallback contact, and record the results.

Incident identifiers that persist

Set an incident identifier scheme that is assigned at logging and never changes through the initial, intermediate and final reports. Link it to internal ticket numbers, affected services and register of information entries so that every later report refers to the same record. In a tabletop, ask the team to reopen an incident three weeks later and confirm that the identifier, timeline and monetary figures still match across systems.

Data to estimate client and cost impact

Keep current data on the number of clients per affected service, daily transaction counts and values, counterpart numbers, and the member states where services are used. Maintain a cost and loss register that captures direct and indirect costs as they accrue, since the authority may request an estimate of aggregated annual costs and losses. In a tabletop, have the team fill in the threshold fields from the scenario and flag any figure they could not source within the hour.

Agreed outsourcing notice for third-party reporting

If a provider or an external firm will file reports for you, you must inform your competent authority before the first report is filed, and you remain responsible for the content and the deadlines. Agree the scope, the authority notice and the escalation path in writing with that party, and confirm whether an aggregated report for a provider-caused incident is permitted. In a tabletop, have the outsourced party and your own team run one scenario end to end, including who approves the final submission.

Who owns reporting, who prepares evidence and who receives the reports

This table compares the four parties that touch a DORA major incident report: the financial entity, an implementation partner, an outsourced reporting third party and the competent authority. Read each row to see who signs off on what, which work can be handed off, and where independence is required. The main takeaway is that the entity stays accountable for every report even when others prepare or file it.

Party	Responsibilities	What is usually outsourced	Independence boundary
Financial entity	Classifies incidents as major, meets the Article 19 deadlines, approves each report, informs clients under Article 19(3) and remains responsible for every submission	Often nothing in full. Entities may keep reporting in-house or appoint a third party under Article 19(5)	Accountable for all reports. Must inform the competent authority before the first report if a third party files
Implementation partner (for example DeployOpen)	Prepares incident logging, detection and escalation procedures, log retention, classification workflows, report drafting support and runbooks for the entity's own systems	Build of logging, monitoring and runbook tooling inside the entity's infrastructure, plus tabletop exercises and documentation	Prepares systems, logs and procedures only. Does not submit reports on the entity's behalf unless engaged under Article 19(5) with notice to the authority
Outsourced reporting third party	Files initial, intermediate and final reports under a written engagement, using the Annex I template and the authority's secure channels	Report preparation and submission, and where the authority allows it, one aggregated report for an incident caused by a shared ICT provider	Acts for the entity, which keeps responsibility. Must be named to the authority before the first report
Competent authority	Receives initial, intermediate and final reports, assesses them, may forward them to other bodies and supervises the entity's incident management process	Nothing. Authorities do not outsource their receipt or supervisory decisions	Independent supervisor. Issues no certificate or attestation for incident reporting
Independent auditor or assessor	Tests the entity's incident management controls if the entity or its supervisor requests an assessment	Not applicable to filing. Assessment scope is agreed with the entity	Issues its own report only. Does not prepare or file incident reports
Client or ICT provider	Receives notice of major incidents affecting its financial interests (clients) or supplies incident data and assistance (providers)	Notification content may be drafted with the entity's compliance team	Receives information from the entity. Cannot file reports for it

The proposed single entry point and what it would change

The European Commission's Digital Omnibus proposal, COM(2025) 837 of 19 November 2025, would change where DORA incident reports go. It would amend Article 19 so that major ICT-related incident reports and voluntary significant cyber threat notifications pass through a single entry point under NIS2 instead of being filed separately with each competent authority. The proposal would apply 18 months after its entry into force. As of October 2026, the European Parliament's Legislative Observatory lists the procedure (2025/0360(COD)) as awaiting committee decision. Until it is adopted and applies, the current Article 19 obligations, the deadlines in Delegated Regulation (EU) 2025/301 and the channels set by your competent authority remain in force, and an incident today must be reported on that basis.

The practical question for incident response teams is what would move and what would stay put. The classification criteria, the three report types and their timings, and the content of the templates are not the focus of the proposal as summarized here, so the reporting logic you build now is unlikely to be wasted. What may change is the recipient of the report, the routing between authorities, and possibly the channels and identifiers used. Review your incident playbooks, your contacts list and any outsourced reporting arrangements, and note which steps depend on a named national authority. Keep the proposal's text itself under review on the Commission's EUR-Lex page for COM(2025) 837 and track the procedure's status on the Legislative Observatory.

Ask your competent authority three questions now: whether it expects to continue accepting reports through its current secure channel during any transition, how it will share reports with NIS2 authorities or CSIRTs in your member state, and what notice it will give before any change applies. If you use a third party to file reports under Article 19(5), confirm with that provider how it would adapt to a single entry point and who carries the cost of any change to tooling. Record the answers in your incident management documentation, and assign an owner to review them each time the procedure moves forward in Parliament or Council.

Questions buyers ask about DORA incident reporting cost, time and scope

Can we outsource DORA incident reporting to a third party?

Yes, reporting may be outsourced under Article 19(5), but the financial entity stays responsible for every report filed on its behalf. Before the first report, the entity must inform its competent authority that it uses a third party. The entity still owns the classification decision, the content of each report and the deadlines. Internally, it must keep the people who can confirm facts, approve submissions and answer follow-up questions from the authority. A third party can also file one aggregated report for an incident caused by a shared ICT provider affecting several entities in one member state, but only if the authority allows it under Implementing Regulation (EU) 2025/302. Confirm with your authority how it expects notifications to be channelled before you sign any service agreement.

What drives the effort of a DORA incident reporting programme?

The effort depends mainly on how many services are in scope, how well incidents are already logged and how quickly data can be pulled from monitoring and ticketing systems. Entities with many critical or important functions, several ICT providers and several member states usually have more classification decisions and more facts to collect for each report. The materiality thresholds in Delegated Regulation (EU) 2024/1772 require client counts, transaction volumes, downtime and cost figures, so measurement capability matters as much as the report itself. Other drivers include the number of legal entities that report, the maturity of the incident management process, the clarity of internal escalation paths and how many reports a single incident triggers. Ask any partner to size the work against a written list of services, systems and data sources rather than a generic headcount.

How much time do we have to send the initial DORA incident notice?

The initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after the entity becomes aware of it, under Delegated Regulation (EU) 2025/301, Article 5. In practice, the 24-hour outer limit runs from awareness, while the 4-hour clock starts only once classification is made, so a slow classification decision can consume the time available for drafting. Pre-approved templates, named decision-makers and a standing list of facts to capture help meet both limits. If the entity cannot meet a deadline, it must tell its competent authority no later than that deadline and explain why. Weekend and bank holiday rules can move some deadlines, but the exceptions for initial notifications and intermediate reports by credit institutions, central counterparties, trading venue operators and NIS2 essential or important entities mean those deadlines do not move.

Can an auditor certify that our incident reporting is DORA ready?

No. DORA sets no certification scheme, and no auditor or certification body can issue a DORA certificate for reporting readiness. Competent authorities supervise compliance using their powers under Article 50, and they judge reporting by reviewing actual incident records, report quality and timeliness. An independent assessor may still test your procedures and produce findings for your own management, and that work can be useful evidence. Any provider that offers a DORA reporting certificate is making a claim that the regulation does not provide for. Ask what the deliverable is, who signs it and what the competent authority has said about it.

What does the reporting work need from our internal staff?

Internal staff must own the decisions and the facts, even when an outside team drafts the reports. Typical roles include an incident coordinator who runs classification, a technical lead who confirms affected services and root cause, a business owner who assesses client and financial impact, and a senior approver who signs off each submission. Finance or data staff may need to supply monetary values, which the ESA operational instructions of 16 September 2026 expect in thousands of units, and risk or compliance staff must keep the incident identifier stable across the lifecycle. Each role needs a named backup, because deadlines run around the clock. Plan for training and tabletop exercises so these people can work under time pressure.

Can we run DORA incident reporting ourselves without a partner?

Yes, a financial entity can run its own reporting if it has the skills, tooling and staffing to meet the deadlines and templates. Whether to do it in-house depends on your current incident maturity, the number of systems you must monitor, how often you expect major incidents and how much internal capacity you can commit to on-call duty. An implementation partner can help build detection and logging, define classification workflows, prepare templates and run exercises, but the entity keeps the accountability and the authority relationship. Before deciding, compare your readiness against the Implementing Regulation (EU) 2025/302 template and the classification criteria, then ask any potential partner to scope the work in writing.

What should we ask a partner to confirm before starting?

Ask for a written scope that names the entities, services, systems and reporting channels covered. Confirm which deliverables the partner prepares, such as detection and logging changes, classification procedures, report drafts or exercise material, and which remain with your team. Ask how the partner documents its work, how it handles confidential incident data and how it hands over ownership at the end. Confirm that your competent authority accepts the proposed model, including any outsourcing notice and aggregated reporting. Finally, ask what is one-time setup and what recurs, such as retainer support, exercises or updates after regulatory changes, so you can compare quotes on the same basis.

How DeployOpen prepares incident reporting readiness

DeployOpen prepares the systems, workflows and records an entity needs to report major incidents, but it does not submit reports, classify incidents on the entity's behalf or certify anything. Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. The scope usually names the in-scope entities, ICT systems and logging sources, the classification criteria the entity has adopted, the reporting roles, and the evidence records to be produced. The organization keeps ownership of its controls, its classification decisions and its reports, and the competent authority or an independent assessor decides on compliance.

Inside the client's own cloud accounts, data centers or air-gapped networks, DeployOpen can implement or harden the parts of the process that produce evidence. That includes centralized logging for in-scope services, an incident register with fields for the classification thresholds in Delegated Regulation (EU) 2024/1772, a classification workflow with named approvers, and runbooks that map each step to the 4-hour, 24-hour, 72-hour and one-month clocks. Records should keep a stable incident identifier from first detection through the final report, since that is what the authority will trace. Confirm with your competent authority which secure channel and template version it expects, because these details change and should not be built from memory.

DeployOpen can also run tabletop exercises that walk the reporting roles through a simulated major incident, including a scenario where an ICT provider is the cause and the entity relies on an outsourced reporter. The exercise output is a dated after-action list with owners, which becomes part of the evidence trail. Before engaging, ask for a written scope that names who approves the classification, who is authorized to contact the authority, how missed deadlines will be explained, and which tests will be repeated each year. Keep in mind that a readiness exercise shows preparation, not compliance; the assessment outcome rests with the independent reviewer.

DORA ICT incident reporting