Delegated Regulation (EU) 2025/301: incident reporting RTS

What DORA incident reporting RTS 2025/301 asks you to send, and by when

Once a major ICT-related incident is classified, your compliance lead is working against three reporting stages under Delegated Regulation (EU) 2025/301: an initial notification, an intermediate report and a final report. The initial notification is due within 4 hours of classification as major and no later than 24 hours after the entity became aware of the incident, whichever the RTS's wording makes binding in your case. The 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. Confirm these deadlines against Article 5(1) of the RTS and against your competent authority's guidance, because the clock starts from dates your own incident log must prove.

The content is what makes the deadlines hard to meet. The initial notification must already carry the incident reference code, the date and time of detection and of classification, a description, the classification criteria met, the member states affected, how the incident was discovered, its origin where known, and whether a business continuity plan was activated. Every report also needs general information such as the entity's LEI, the submission type, contact persons, any parent undertaking and the currency used for amounts. Most teams find that the facts needed in the first hours, such as affected member states and origin, are the ones still under investigation. Decide before an incident who writes each field, who approves it, and how a field stays marked as unknown rather than blank.

Two other parts of the RTS need planning. If you cannot meet a deadline, you must tell the competent authority no later than that deadline and give your reasons, so the late-reporting procedure belongs in your runbook rather than in a legal memo written afterwards. Article 5(4) also moves deadlines that fall on weekends and bank holidays to noon on the next working day, with exceptions in Article 5(5) and (6) that you should read before relying on them. Separately, Article 6 sets the content of voluntary notifications of significant cyber threats, which covers detection time, potential impact, the classification criteria that would have been met and any indicators of compromise. A case tool that holds one record per incident with its timeline and evidence reduces the drafting work for all three stages.

Which incidents, entities and teams fall under the 2025/301 reporting content

Before any template is filled, the team has to settle who reports, which incidents reach major classification, and who holds the data. Each decision below changes how much evidence must be gathered, who gathers it, and how quickly it can move through the deadlines in Delegated Regulation (EU) 2025/301.

Financial entity type and reporting scope

The content rules apply to the financial entities DORA covers under Article 2(1), so the first check is whether your organization is one of them and which competent authority supervises it. Entity type does not change the report structure, but it decides who receives the submission and which supervisory relationship the incident team must maintain. Confirm the entity type with legal counsel before building the notification workflow, because a misclassified entity will route reports to the wrong authority.

Major classification triggers the full content

Only incidents classified as major start the initial notification, intermediate and final report cycle. Classification depends on the criteria and thresholds set in Delegated Regulation (EU) 2024/1772, so the team needs a documented method that scores each incident against them. Until classification is recorded, the clock in Article 5(1) of the 2025/301 RTS is not running, which means the classification timestamp must be captured as evidence in its own right.

Group and parent reporting

Where an entity belongs to a group, the report must identify the parent undertaking where applicable, and the group structure determines who submits and who must be informed. Group-level incidents can touch several subsidiaries in several member states, so the team must decide whether one submitting entity files for the group or each entity files separately. Map the legal entities, their LEI codes and their parent relationships in advance, because the general information block cannot be completed from memory during an incident.

Outsourced incidents and the provider's role

When an ICT third-party provider causes or runs the affected service, the financial entity still owns the report, but much of the technical content sits with the provider. The contract should require timely access to logs, timelines and impact data that the initial notification and intermediate report ask for. Ask each critical provider how quickly it can supply the detection time, the origin of the incident and the status of recovery, and test that answer in a tabletop exercise before an incident happens.

Incident response team ownership

The incident response team generates most of the facts the initial notification requires, including the incident reference code, the date and time of detection, how the incident was discovered and its origin where known. It should keep a running record from the first alert onward, because reconstructing detection times after the fact weakens the report and the evidence trail. Assign one owner for the case record and make sure alert sources from SIEM and EDR tooling are linked to it from the start.

Business continuity, legal and compliance inputs

Business continuity staff supply whether a continuity plan was activated, while legal and compliance decide the reporting path, the currency used for monetary amounts and the wording of any deadline extension request under Article 5(3). Operations owns the affected systems, member states impacted and the service status used in the intermediate report. Agree these handoffs in a written RACI before go-live, since each team holds a field that cannot be left blank.

How an assessor tests the reporting timeline and content

This table sets out how a competent authority or independent reviewer would test a major incident file against Delegated Regulation (EU) 2025/301, step by step, with the evidence each test expects. Read each row as one test: the question asked, the record needed to answer it, and the gap that most often causes a finding.

Test area	What the assessor checks	Evidence expected and common findings
Sampling and scope	Selects reported major incidents and checks them against the entity's own incident log and the classification record	Full case log for each sampled incident. Finding: incidents classified as major with no matching report, or reports with no underlying case
Timestamp reconciliation	Compares detection, classification and awareness times across the case record, the initial notification and the timeline	Timestamped case entries and classification decision record. Finding: classification time missing from the case record, or times that differ between systems
Deadline compliance	Tests the 4-hour window after classification, the 24-hour limit after awareness, and the 72-hour intermediate report window	Submission receipts with time stamps. Finding: clock start points that were not documented or were inconsistently applied
Weekend and bank holiday handling	Checks whether deadlines falling on weekends or bank holidays moved to noon on the next working day, and whether any exception was relied on	Calendar of applicable holidays for each member state and the reasoning behind any exception. Finding: deadlines calculated without the holiday rule
Content completeness	Reviews each report against the required fields for the initial notification, intermediate report and final report, plus general information	Field-by-field checklist per report with LEI, incident reference code, affected member states and BCP activation status. Finding: blank or inconsistent fields
Late report explanations	Tests whether a missed deadline was notified to the competent authority before it passed, with reasons given	Copy of the notice and its send time. Finding: explanation sent after the deadline or without reasons
Consistency across reports	Checks that the final report reconciles with earlier intermediate reports and that changes are explained	Version history and change rationale. Finding: final report figures or root cause that contradict the intermediate report
Voluntary threat notifications	Reviews significant cyber threat notifications for the Article 6 content and for timing against the entity's own decision	Threat record with detection time, potential impact and indicators where applicable. Finding: notifications with no status or preventive actions recorded

Implementing the reporting workflow step by step

This sequence turns the content requirements and deadlines of Delegated Regulation (EU) 2025/301 into a working reporting process that a team can rehearse before a real major incident. Each step ends with a named artifact that an assessor or competent authority could inspect.

Define the incident record fields
Compliance and incident response leads map every field the RTS asks for to a field in the incident record. This covers the general information in every report (submission type, entity name, LEI code and type, submitting entity, contact persons, parent undertaking where applicable, and reporting currency), plus the initial notification content such as the incident reference code, detection and classification times, description, classification criteria met, member states affected, discovery method, origin where known, and business continuity plan status. Output: a field dictionary that links each RTS content item to a system field, its owner and its source, reviewed and approved by the management body or its delegate.
Set up classification and timestamp capture
Engineering configures the incident platform so that detection, classification and awareness times are recorded automatically and cannot be overwritten without an audit entry. Classification decisions are captured with the criteria that drove them, because the initial notification must state those criteria. Output: a test incident showing an immutable timeline with detection, classification and awareness timestamps, and a change log entry for every edit to those fields.
Build report templates for each stage
Compliance drafts one template for each stage that Article 5 defines: the initial notification, the intermediate report and the final report. Each template pulls values from the incident record fields rather than from free text, and marks which fields are mandatory at that stage. Templates also carry a section for explaining any missed deadline, as Article 5(3) requires. Output: three versioned templates with a field mapping sheet, reviewed against the RTS annexes by someone outside the drafting team.
Assign owners and escalation paths
The organization names a single owner for each report stage, a deputy, and an escalation route to the management body and the competent authority contact. Deadline timers are set from the awareness and classification times, so that the 4-hour, 24-hour, 72-hour and one-month clocks are visible to the duty team. Output: a RACI table, an on-call roster and a deadline register showing which timer applies to which report, with the trigger time that starts it.
Rehearse weekend and holiday cases
Teams walk through incidents that start on a Friday evening, on a weekend and on a bank holiday, and check how Article 5(4) moves the relevant deadlines to noon on the next working day. The exercise also covers the exceptions in Article 5(5) and (6), so the team knows when those exceptions apply and who confirms them. Output: a written calendar of working days for the entity's jurisdictions, and a rehearsal log recording each deadline calculation and the person who checked it.
Run a tabletop exercise on a sample incident
The team runs a scenario-based tabletop exercise on an illustrative major incident, from detection through initial notification, intermediate report and final report. Participants produce each template from the incident record, practice the late-reporting explanation, and record gaps in fields, owners or timers. The sample incident should be labeled as illustrative and kept separate from production data. Output: an exercise report listing decisions taken, times achieved against each deadline, defects found, and corrective actions with owners.
Close gaps and approve the workflow
Owners fix the defects from the tabletop exercise, update templates, timers and the field dictionary, and re-test the changed steps. The management body or its delegate approves the final workflow and the record of approval is kept as evidence. Output: an approved version of the reporting procedure, a re-test record, and a review date set in the governance calendar so the workflow is revisited when the RTS or its templates change.

Evidence that shows each report was complete and on time

A competent authority judging a major incident report will test two things: whether each submission was complete and whether it was filed within the deadlines in Article 5. The cards below list the records that prove both, and they show how one incident record can hold much of the chain from detection to final report.

Timestamped incident records

Keep a record that fixes the time of detection, the time of classification as major and the time the entity became aware of the incident. The initial notification deadlines run from classification and from awareness, so these three timestamps decide whether the 4-hour and 24-hour tests were met. Confirm your system clock source and whether the record stores time zones and edits as separate events. An undated edit history is the weakest point in this evidence.

Classification decisions and criteria met

Record which classification criteria the incident met, who made the decision, and when. The initial notification must state those criteria, so the decision log has to match what was reported. Store the reasoning alongside the decision, including any reclassification, so an assessor can trace how the incident moved between categories.

Submitted reports and acknowledgments

Keep each submitted initial notification, intermediate report and final report as the exact version sent, together with the competent authority's acknowledgment. Pair each file with its submission time and submission type. Assessors compare these files against the internal record, so any later correction should appear as a new version, not an overwrite.

Late-report explanations

When a deadline cannot be met, Article 5(3) requires the entity to inform the competent authority no later than that deadline and to explain why. Keep the notice, its time of sending and the reasons given. Also record the internal decision to escalate, so the file shows the entity recognized the risk before the deadline passed.

Reporting procedures and approvals

Keep the written procedure for major incident reporting, the named roles for drafting and submitting, and the record of who approved each version. Include the weekend and bank holiday rules in Article 5(4), because an assessor will check that staff applied the noon-next-working-day rule correctly. Confirm that the procedure matches the templates and channels used by your competent authority.

Tabletop exercise records

Keep the scenario, participants, timings and findings from each tabletop exercise on the reporting process. Show how the exercise tested the deadlines, the drafting of the initial notification and the late-report path. Record the corrective actions and their owners, so the exercise results can be traced to changes in the procedure. Confirm the exercise cadence your supervisor expects.

What meeting the reporting content and deadlines costs

This table breaks down the main cost components of meeting the content and deadline rules in Delegated Regulation (EU) 2025/301, who is paid for each, and whether the cost is one-time or recurring. Use it to shape a quote request, since no figures are published here and each line should be priced from your written scope.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Engineering time to wire timestamps and case records	Internal platform or security engineers, or an implementation partner for integration work	One-time build, then recurring upkeep	Number of alert sources, how many systems must stamp detection and classification times, and whether logs already carry reliable clocks
Compliance time to build report templates and procedures	Internal compliance and incident response leads, with optional outside drafting support	One-time, then periodic review	Number of reporting entities, the number of templates needed for initial, intermediate and final reports, and how many competent authorities are involved
On-call and reporting duty rota	Internal staff; overtime or on-call allowances may apply	Recurring	Whether the deadlines can be met during weekends and bank holidays under the weekend rules, and how many people are trained to submit
Exercise and tabletop time	Internal teams, and external facilitators if bought in	Recurring, usually annual or after major changes	Size of the exercise scenario, number of entities participating, and whether group members run joint drills
Legal review of report wording	Internal legal counsel or external counsel billed by the hour or by fixed fee	Recurring per incident, plus one-time template review	Complexity of the incident, number of member states affected, and how much pre-approved wording exists
External review of procedures	Independent consultants or assessors, if purchased	Usually one-time, then periodic	Scope of the review, group structure and whether outsourced providers' reporting duties must be covered
Case management platform licensing	Commercial vendor if a proprietary case tool is chosen	Recurring subscription or licence	Seat count, number of entities, and integrations; a self-hosted open-source case platform can remove this licence line, while hosting and support remain
Hosting and operations of self-hosted tooling	Internal infrastructure team or implementation partner under a retainer	Recurring	Infrastructure location, backup and retention requirements, upgrade cadence and support level agreed in writing

Who owns the report, who prepares the evidence, and who checks it

The financial entity owns the major incident decision, the notifications and the reports. Its management body remains accountable under DORA for ICT risk, so the people who classify an incident and sign off a submission must be named in the internal procedures and must be able to act outside office hours. The in-house team also keeps the timeline of what was known and when, because the RTS ties every deadline to the moments of detection, classification and awareness.

Classification and notification decision: Staff with authority decide whether an incident is major and when the initial notification clock starts.
Submission and contacts: The entity names the submitting person and contact persons that Article 1 requires, and keeps those details current.
Procedures and runbooks: Internal documents describe who does what within the 4 hour and 24 hour initial notification window.
Final report content: The team supplies root cause, remediation and impact data, and confirms the figures before submission.
Record keeping: Logs of decisions, timestamps and approvals are retained as evidence.

Before relying on any tooling or outside support, confirm with your competent authority which submission channel and template version apply to your entity.

Where incident reporting usually falls short and how to close each gap

Most reporting failures under Delegated Regulation (EU) 2025/301 are not about missing knowledge of the deadlines. They come from gaps in the record: when the clock started, where the timers live, who covers weekends, how the final report ties back to earlier submissions, and what providers send and when. Each card below names one gap and the single action that closes it.

Classification time not recorded

The initial notification clock runs from classification as major, and the RTS also asks for the date and time of detection and classification in the notification itself. If the incident record only shows when someone opened a ticket, the entity cannot prove when the four-hour window began. Check that the case record stamps detection and classification as separate, timestamped events, and that the person who classifies the incident must log the time at the moment of decision.

Deadlines tracked in email

When the initial, intermediate and final report dates sit in individual inboxes or calendar invites, a single absence can cause a missed deadline. Under Article 5, a late report requires an explanation to the competent authority, so a missed date is also a supervisory event. Move every incident to a case management system that holds the timers, owners and submission status in one place, and review open timers at each shift handover.

Weekend and holiday rules missing

Article 5 moves deadlines that fall on weekends and bank holidays to noon on the next working day, but only if the entity's escalation plan reflects that rule. Plans written for office hours often name no one for Saturday night, and staff may assume the clock stops over the weekend. Write the rule into the escalation plan, name an on-call owner who can submit, and test the path with a tabletop exercise that starts on a Friday evening.

Final reports not reconciled

The final report is due no later than one month after the latest intermediate report, and it must be consistent with what the authority already received. If the incident timeline, root cause and impact figures were drafted separately in each submission, the final report often contradicts the earlier ones without anyone noticing. Keep one investigation timeline per incident that every submission draws from, and record each change to a figure with its reason and date.

Voluntary threat notifications ignored

Article 6 sets the content of voluntary notifications of significant cyber threats, including the classification criteria that would have been met, the status of the threat and any preventive actions taken. Teams that handle only confirmed incidents may never record threats that were stopped early, so the information is lost. Add a decision step to the threat triage process that asks whether a threat is significant enough to notify, and capture the Article 6 fields even when the entity decides not to submit.

Provider incident data arriving late

An outsourced provider may detect an incident that affects the entity, yet the contract may not require it to share the data within a set time. When the provider's logs and status updates arrive after the entity's clock has started, the entity must still meet the deadline with partial information. Review each ICT service contract for an incident notification clause with a defined sharing window, and test the handoff by asking the provider for a sample incident data set before an incident occurs.

How long, how much effort and what it takes to meet the 2025/301 requirements

How much effort does the first build of 2025/301 reporting take?

The effort depends mainly on how mature your incident management process already is, and no fixed duration is set by the Regulation or its supporting facts. The RTS requires specific content in the initial notification, intermediate report and final report, so the first build means mapping each required data field to a source in your systems: incident reference codes, detection and classification timestamps, affected member states, discovery method, origin and business continuity status. Teams that already log incidents with timestamps and a clear owner usually have less to build than teams that reconstruct this data after the fact. Ask any partner for a written scope listing the report templates, data sources, integrations and test cases before agreeing to a timeline.

Can a small financial entity handle 2025/301 reporting in-house?

A small entity can often run the reporting in-house if it has a named incident owner, a documented classification decision and staff who can gather the required fields quickly under time pressure. The hard part is not the form but the clock: the initial notification is due within 4 hours of classification as major and no later than 24 hours after awareness, and the intermediate report follows within 72 hours of the initial notification. Small teams should test the process with a tabletop exercise, confirm who can sign off a submission out of hours, and check how weekend and bank holiday deadlines apply to them. Whether in-house capacity is enough is a question your compliance lead and competent authority guidance should answer, not a vendor.

What do the compliance and engineering teams need to contribute?

The compliance team owns the classification decision, the content of each report and the contact details and legal entity information the RTS requires, including the LEI code, entity type and currency used for monetary amounts. The engineering and security teams own the evidence: accurate detection and classification timestamps, an incident record that shows how the incident was discovered, the origin where known, and the status of any preventive actions. Both teams should agree on who writes the description, who checks the figures and who approves the submission, and they should keep these roles in a written runbook. Engineering time is usually concentrated in building reliable timelines and records before an incident happens.

Could the Digital Omnibus proposal change single-entry-point reporting under DORA?

Yes, if adopted in its current form. The Commission's Digital Omnibus proposal COM(2025) 837, dated 19 November 2025, would amend DORA Article 19 so that major incident reports and voluntary threat notifications go through a single entry point under NIS2. As of October 2026, the European Parliament's Legislative Observatory lists the procedure 2025/0360(COD) as awaiting committee decision, so the current reporting route has not changed. Keep your existing 2025/301 process running and avoid redesigning it until the procedure moves. Ask your counsel to track the outcome and to confirm how any change would affect entities that are also subject to NIS2.

What happens if an entity misses a 2025/301 reporting deadline?

If you cannot meet a deadline, Article 5(3) requires you to inform the competent authority no later than that deadline and explain the reasons. Silence is the worst option, because a missed deadline with no explanation is harder to defend than a late report with a documented cause. Weekend and bank holiday rules in Article 5(4) move certain deadlines to noon on the next working day, with exceptions in Article 5(5) and (6), so confirm these carefully before relying on them. Penalties and remedial measures are set under Chapter VII of DORA and national law, so ask your supervisor how late reporting is treated in practice.

Can an outside partner take over 2025/301 reporting?

An outside partner can prepare the work, but it cannot take over the legal obligation. Under DORA, the financial entity owns its reports and decisions, and only the competent authority supervises compliance. A typical split is that the partner helps design the incident record, build the timeline and data capture in self-hosted tools, write the runbooks and test them, while your team makes the classification decision and submits the reports. DeployOpen plans, implements and supports self-hosted open-source platforms in your own infrastructure, including incident case management, and prepares the process and evidence. It does not issue reports or attestations. Agree the scope, deliverables and timeline in writing before work starts, and confirm which deadline-related tasks stay with your staff.

How DeployOpen prepares incident reporting for DORA

DeployOpen prepares the systems, case records and reporting workflow that an entity needs to produce the initial notification, intermediate report and final report described in Delegated Regulation (EU) 2025/301. The organization keeps ownership of its classification decisions, its reports and its regulator relationship, and DeployOpen works within the scope agreed in writing.

How we scope

Confirm which entities, ICT services and reporting channels the written scope covers under Delegated Regulation (EU) 2025/301
Map the data fields the initial notification requires, such as the incident reference code, detection and classification times and affected member states
Agree the deadline clock points with the client, including classification time, awareness time and weekend handling
Record which competent authority receives reports and which internal roles hold reporting responsibility

How we build

Configure a self-hosted DFIR-IRIS instance inside the client's own infrastructure to hold each incident as one case record
Set up alert triage from SIEM, EDR and REST sources into cases, with assets, indicators of compromise and tasks linked
Build a consolidated investigation timeline and evidence logging with SHA-256 verification and chain of custody
Create report templates that draw general information and incident details from case data, for client review before use

How we hand over

Deliver a written runbook covering the initial, intermediate and final report steps, owners and escalation paths
Document the audit trail, access controls and evidence handling procedures so an assessor can trace each reported figure
Run a walkthrough with the incident response and reporting teams using a tabletop scenario agreed in advance
Provide the configuration record, field mapping and open items list at handover for the client to keep

How we support

Offer ongoing support, upgrades and maintenance of the reporting platform as a retainer when the client wants continuity
Confirm with the client which regulatory updates, including any change to Article 19 under the Digital Omnibus proposal, require configuration changes
Keep the client's compliance and legal teams responsible for the content, classification and timing of every submission
Ask for a fixed-scope quote in writing before work starts, since DeployOpen does not publish a price list