DORA incident reporting: deadlines, major incidents and the three reports

Under DORA, a major ICT-related incident starts a clock: the first notification to the authority is due within hours. Whether you make it depends on two things you have to have ready before anything happens: a quick way to decide whether an incident is major, and a reliable record of what happened on your systems and when.

This page is a general overview, not legal advice. The authentic texts are Regulation (EU) 2022/2554, Delegated Regulation (EU) 2024/1772 (classification), Delegated Regulation (EU) 2025/301 (content and time limits) and Implementing Regulation (EU) 2025/302 (templates). Your competent authority may publish its own instructions. Check with your legal or compliance team.

1. Step one: is the incident major?

DORA's technical standards on classification (Delegated Regulation (EU) 2024/1772) give a fixed test. An ICT-related incident is major when it affects critical services and at least one of these is true:

• there was a successful, malicious and unauthorised access to network and information systems that may result in data losses, or
• two or more of the other thresholds below are met.

Criterion	Threshold met when, for example...
Clients, financial counterparts and transactions	more than 10% of the clients using the affected service, or more than 100,000 clients, are affected; or more than 30% of the financial counterparts; or more than 10% of the daily average number or value of transactions
Reputational impact	for example media coverage, client complaints, or the entity can no longer meet regulatory requirements
Duration and service downtime	the incident lasts longer than 24 hours, or services supporting critical or important functions are down for more than 2 hours
Geographical spread	an impact in two or more EU Member States
Data losses	the availability, authenticity, integrity or confidentiality of data is affected in a way that harms the business or compliance
Economic impact	costs and losses exceed, or are likely to exceed, EUR 100,000

Recurring incidents: incidents that are not major on their own count as one major incident when they happened at least twice within 6 months, have the same apparent root cause and together meet the test above. Entities check for this monthly (microenterprises are exempt).

For a Windows Server, the first route matters most: an attacker who got in - a successful RDP logon after a password attack, a new administrator account, a firewall switched off from inside - can make an incident major on its own, as soon as critical services are affected. That is why the evidence of what happened on the Server has to be there from the first minute.

2. The three reports and their deadlines

Delegated Regulation (EU) 2025/301, Article 5, sets the time limits:

Report	Deadline	What it is for
Initial notification	as early as possible, within 4 hours of classifying the incident as major, and no later than 24 hours after you became aware of it	the authority learns that a major incident is happening: what, since when, which services, first assessment
Intermediate report	within 72 hours of submitting the initial notification - even if nothing has changed; an updated one without undue delay as things change, and in any case when regular activities have been recovered	more detail: impact on clients and transactions, the classification criteria that were met, what you are doing
Final report	within one month of the intermediate report, or of the latest updated one	the root cause, the full impact, the measures taken and what changes to prevent it again

• Classified late? If an incident is only classified as major more than 24 hours after you became aware of it, the initial notification is due within 4 hours of that classification.
• Weekends and bank holidays: if a deadline falls on one, a report may be submitted by noon of the next working day - but not the initial notification or intermediate report of credit institutions, central counterparties, trading venue operators and entities that are essential or important under NIS2. Your authority can also remove this relief for other significant entities.
• Can't make a deadline? Tell the competent authority without undue delay, at the latest when the report is due, and explain why.

An example

Tuesday 02:10 UTC: password guessing against RDP turns into a successful logon on a Server that runs the payment interface. 07:45: the IT team notices. 09:30: the incident is classified as major (critical service, malicious unauthorised access).

• Initial notification: by Tuesday 13:30 (4 hours after the classification - and within 24 hours of becoming aware). Submitted Tuesday 12:00.
• Intermediate report: by Friday 12:00 (72 hours after the initial notification). An updated one when the service is back to normal.
• Final report: one month after the last intermediate report.

Note which times the deadlines run from: becoming aware, classification and submission. Write each of them down, in UTC, when it happens - reconstructing them afterwards is exactly what goes wrong under pressure.

3. The forms

The content of each report is laid down in Delegated Regulation (EU) 2025/301, and Implementing Regulation (EU) 2025/302 provides the standard templates and data glossary. You submit them through your competent authority's own channel (portal or format) - check its current instructions. The fields fill much faster when the technical facts are already collected in one place.

4. What your Windows Servers have to deliver

Most of the template is about the business: clients, transactions, costs. But the first questions are technical, and they come from the Servers:

• When did it start, and when was it detected? The first failed logons, the first successful one, the first alert - with exact times in UTC.
• Was there unauthorised access? Successful logons from unknown addresses (event 4624 after a run of 4625), new accounts or group changes, firewall rules changed or the firewall switched off by someone other than you.
• Where did it come from? The attacking addresses, their owners and countries.
• What was affected? Which Servers, which services and ports were reachable, how long they were down.
• What did you do, and when? Addresses banned, ports closed, Servers isolated, passwords reset - each step with its time.
• Can you prove the record wasn't changed later? Auditors and supervisors will ask.

The Windows logs hold part of this, but they are small by default, overwrite themselves, can be switched off, and nobody writes the timeline for you. See DORA and NIS2 on Windows Servers: logging and incidents for the settings to check, and Event ID 4625 for reading failed logons.

5. How Coinetic helps with the reporting

Coinetic works on each Windows Server and PC through the Windows Firewall, with a protection service that runs in the background. It does not make you DORA compliant, and it does not submit anything to an authority. It makes sure the Server side of the reporting is ready:

• The incident opens itself (Pro): a password attack from many addresses (Under Attack mode), the firewall changed or switched off outside Coinetic, the protection service stopped unexpectedly, or security logging switched off goes into the Server's Incidents register with the time it was detected. Anything else you add with New incident.
• The classification test, built in: Coinetic asks the questions of the test above and suggests major or not major. You decide.
• The clock, running for you: for a major incident Coinetic counts the initial notification, the intermediate report and the final report from the times you recorded, in UTC, shows when each is due, warns when one is close and turns the incident red when it is overdue. It always shows the strict deadline, without the weekend relief.
• A timeline that can't be changed quietly: every entry - detection, bans, firewall changes, your notes, each report marked as sent - is part of a hash chain, so a later change to an entry is shown.
• The information for the notification: Report (DORA) puts together the facts for the selected incident, ready to print or save as PDF, to copy into your authority's template. Select several incidents for one document.
• Everything in your central register: new and changed incidents can be forwarded to a REST API (SIEM, ServiceNow, Jira...), a database (SQL Server or ODBC) or by e-mail to your compliance officer - so the incidents of all Servers land in one place.
• Evidence for later: the security history (bans, failed logins, port scans, firewall changes, incidents) is kept on the Server for 13 months by default and up to 10 years; the security report for a period lists its incidents and whether each report was on time.
• A first draft (Pro + AI): Ask AI on an incident checks the classification against what Coinetic recorded and writes a first version of the report text for you to review.

What stays with you: deciding whether an incident is major, the business figures (clients, transactions, costs), the submission to the authority and your legal assessment. Coinetic runs on Windows Server 2008 R2 to 2025 and on Windows 7 to 11, in any Windows language.

More guides: all Coinetic guides.

Frequently asked

Does every ICT incident have to be reported under DORA?

No. Every ICT-related incident has to be recorded and classified; only major ones have to be reported to the authority. Significant cyber threats can be reported voluntarily. That is why the classification has to be quick: the 4-hour clock starts when you classify.

When does the clock start?

Two clocks run: the initial notification is due 4 hours after the classification as major, but in any case no later than 24 hours after you became aware of the incident. The intermediate report runs from the submission of the initial notification, the final report from the last intermediate report.

Does Coinetic send the report to the authority?

No. It prepares the information and tracks the deadlines; you submit the report through your authority's own channel. Nothing from the incident register leaves the Server unless you set up forwarding or e-mail.

We are in the US. Does this apply to us?

DORA applies to financial entities in the EU. US rules have their own clocks - for example 36 hours for banks under the federal banking agencies' incident notification rule, 72 hours under the New York DFS cybersecurity regulation, and four business days for a material incident in an SEC Form 8-K. Coinetic's register, timeline, reports and forwarding work for any of them; its classification and deadlines follow DORA, so set the US deadlines with your counsel.

We fall under NIS2, not DORA.

NIS2 has its own steps for significant incidents: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month, under your country's law. The register and its evidence are the same; check the deadlines yourself.