DORA and NIS2 incident reporting timelines: what your SOC must produce.

Who is in scope

Two European regimes put a reporting clock on serious cyber incidents. The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has applied since 17 January 2025 to financial entities such as banks, insurers, investment firms and payment institutions, and it reaches their ICT third-party providers through contracts and oversight (S01). The NIS2 Directive (Directive (EU) 2022/2555) covers essential and important entities across a wide set of sectors, from energy and transport to digital infrastructure and managed security services, and applies through each member state's national law (S04).

Where both could apply to a financial entity, DORA is the specific regime for ICT risk and incident reporting and takes precedence over the matching NIS2 obligations (S07). Many organizations outside finance sit under NIS2 only; many technology suppliers feel DORA through their financial customers' contracts.

This guide explains the reporting timelines and the evidence behind them. It is not legal advice; confirm your scope and national rules with your legal or compliance team.

The DORA clock

DORA requires financial entities to detect, manage, classify and record ICT-related incidents, and to report major ones to their competent authority (Articles 17 to 19, S01). The time limits are set by Commission Delegated Regulation (EU) 2025/301, Article 5 (S02, S03):

• Initial notification: within 4 hours of classifying the incident as major, and no later than 24 hours after the financial entity became aware of the incident.
• Intermediate report: within 72 hours of the initial notification, and updated when the status changes significantly.
• Final report: within one month of the latest intermediate report.

Two details matter for the SOC. First, the 24-hour outer limit runs from awareness, not from classification, so a slow classification does not buy time. Second, the 4-hour limit runs from the moment of classification, so the classification decision itself needs a timestamp that will stand up later. National supervisors publish their own explanations; the Austrian FMA's page is one clear example (S06).

DORA also lets a financial entity outsource the reporting task to a third party, but the entity stays responsible for it (S08). If your SOC provider will draft or submit reports, the contract needs to say how fast they detect, escalate and hand over the facts.

The NIS2 clock

NIS2 Article 23 sets staged reporting for significant incidents to the national CSIRT or competent authority (S04). An incident is significant when it has caused or can cause severe operational disruption or financial loss for the entity, or considerable material or non-material damage to others. The stages:

• Early warning: without undue delay and within 24 hours of becoming aware of the significant incident, saying whether it is suspected to be caused by unlawful or malicious acts and whether it could have a cross-border impact.
• Incident notification: within 72 hours of becoming aware, updating the early warning with an initial assessment of severity and impact and, where available, indicators of compromise.
• Intermediate report: on request of the CSIRT or competent authority, with relevant status updates.
• Final report: no later than one month after the incident notification, with a detailed description, the type of threat or root cause, the mitigation applied and ongoing, and any cross-border impact. If the incident is still ongoing, a progress report is due instead, with the final report within one month of handling the incident.

Side by side

The clocks differ in where they start, but they share one dependency: each one starts from facts the SOC records, the moment of awareness, the moment of classification and the timeline of what was found.

What your SOC must produce

Reports are written by compliance and legal teams, but almost every fact in them comes from security operations. If those facts are scattered across a SIEM, a ticketing system and chat threads, the 4-hour and 24-hour limits are spent reconstructing them. Have these ready as a matter of routine, for every incident that could become reportable:

1. The detection record. Which alert or report started the incident, from which source, and the exact time it fired.
2. The awareness timestamp. When a person or an approved process recognized it as an incident. Both regimes count from awareness, so this needs to be explicit, not inferred later.
3. The classification decision. Who classified it, against which criteria, at what time, and with what evidence. For DORA this starts the 4-hour limit.
4. The investigation timeline. What was checked, what was found, affected systems, users and data, and indicators of compromise, each with a time.
5. The action log. Every containment or response step, who approved it and when, and its effect.
6. Impact facts. Services affected and for how long, so the severity and impact sections can be filled in from records rather than estimates.
7. Root cause and remediation. The material the final report needs, captured as the investigation goes, not rebuilt a month later.

A useful test: pick a past incident and time how long it takes to answer the first three items from records alone. If the answer is longer than the time limits above, the gap is in record keeping, not in the reporting template.

Logging requirements behind the reports

The reports are only as good as the logs underneath them. DORA's technical standard on ICT risk management (Delegated Regulation (EU) 2024/1774, Article 12) asks for logging procedures, a retention period the entity defines and justifies, protection of logs against tampering, and clock synchronization (S09). For certain digital service providers under NIS2, Implementing Regulation (EU) 2024/2690 sets comparable monitoring and logging expectations in its annex, section 3.2 (S05). Neither fixes one retention number for everyone; both expect you to define and defend your own.

That links reporting back to detection quality. A silent log source or a dead rule does not only miss the attack; it removes the timeline you would need to report it. Our SIEM health check guidecovers how to find those failures.

SOCGenX is built to support this evidence. The agents work in your environment and theEvidence Ledger records when each alert fired, what the agents found and who approved each action and when, so the incident timeline is already written when the clock starts. Your team still classifies the incident and files the report; SOCGenX does not file reports, and it does not replace your compliance program. See how the evidence maps to DORA, NIS2 and other frameworks on the compliance evidence page.