DORA Notification Timelines (2026 Guide)
You discover a serious ICT incident on a Friday afternoon. Operations wants containment. Legal wants facts. Compliance wants to know whether the clock has already started. Senior management asks the question almost every institution has faced by now: do we need to notify under DORA, and by when? This is where things get stressful fast, not because the rules are impossible to understand, but because the timelines are short and the classification decision affects everything that follows.
For many financial entities, the hardest part of dora notification is not the form itself. It is knowing when the initial deadline begins, what belongs in the follow-up stage, and how to prepare the final report without losing control of the incident response. If you are still getting oriented, it helps to start with what is dora and then map incident obligations from there.
DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, turning complex regulatory requirements into structured, manageable workflows with a focus on auditable, technically compliant reporting outputs.
Why these deadlines matter more than they seem
DORA is not only about whether an incident happened. It is also about whether your institution can detect, assess, classify, escalate, and communicate it within a controlled timeframe. That is a key part of operational resilience, not just regulatory administration.
From a regulatory standpoint, 2026 is already less about first-time compliance and more about proof of compliance. Supervisors increasingly expect institutions to show that reporting timelines are embedded in day-to-day operations, supported by governance, evidence, and repeatable decision-making. That broader context is tied closely to digital operational resilience act dora requirements and the wider shift toward defensible operational practices.
Think of it this way: the notification timeline is a visible test of how well your incident management process works under pressure. If your team cannot establish awareness time, classify impact, and route approvals quickly, the problem is usually bigger than reporting alone.
What DORA actually expects from incident notifications
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies from 17 January 2025 and includes ICT-related incident reporting as one of its five main pillars. Financial entities that fall within scope may need to report major ICT-related incidents to their competent authority based on the reporting framework as currently defined in the applicable technical standards and supervisory guidance.
That means two things. First, not every incident becomes reportable. Second, once an incident is classified as major, the reporting sequence becomes time-sensitive. If you need the bigger legal context, dora regulation explained is a useful companion read.
Classification comes before reporting
One common misconception is that every operational issue triggers immediate external notification. In practice, the first question is whether the incident meets the threshold for a major ICT-related incident under your classification framework. That is why dora incident classification matters so much.
Under DORA, this means your institution needs a way to assess impact consistently. Typical factors may include service disruption, affected clients, transaction impact, data impact, duration, geographic spread, and whether critical services or important business functions were affected.
The reporting lifecycle is staged
DORA incident notification is generally structured as a staged process rather than a single filing. In many implementations, teams work through:
That staged design reflects the reality of incident response. You rarely know everything in the first few hours, but regulators still expect timely notice and later refinement.
Reportable vs. not reportable: what regulators typically expect you to decide fast
A lot of stress around DORA reporting comes from one practical question: what is actually reportable, and how fast do you need to decide? In most institutions, you will not have perfect information early on. Regulators usually understand that. What they typically do expect is that you can make a timely, defensible decision using your documented classification framework, then update it as facts evolve.
Here is the key framing that helps teams stay calm under pressure. “Reportable under DORA” usually means the incident meets the major ICT-related incident criteria as implemented through the applicable technical standards and supervisory expectations. The thresholds and interpretation details can vary by institution type and local supervisory setup, so your legal and compliance teams should confirm what applies to you. Operationally, your job is to apply the framework you have, record the decision point, and show your reasoning.
Three buckets teams should be able to separate quickly
In real incident response, you will often be sorting events into one of these buckets:
Think of it this way: “major” is a classification outcome, not a feeling. A noisy outage can feel catastrophic in the moment, but still fall below the reporting threshold once impact is assessed. At the same time, a contained security event can be reportable if it hits the right impact criteria, even if customer disruption is limited. Your framework is what keeps those calls consistent.
Decision inputs checklist (not a template, just the reality of what you will be asked)
When you are trying to reach a defensible reportability decision quickly, teams typically pull from a short list of inputs. You do not need every detail to start, but you do need enough to justify why you did or did not classify as major at that point in time:
What many people overlook is that documenting uncertainty is part of good reporting discipline. If you classify as major early and later downgrade, or you initially hold off and later upgrade, the question will usually be: was your decision reasonable based on what you knew at the time, and can you show the evidence trail?
Understanding the 24h and 72h stages
This is where many readers search for exact timing, especially around dora 24h reporting. The practical issue is that teams often talk about the 24-hour and 72-hour deadlines as shorthand, but the reporting clock depends on the legal trigger and the stage of the process.
The initial report: fast, focused, and often incomplete
Based on current operational interpretations and implementation workflows, the initial stage is designed to alert the authority quickly once a major incident has been identified. In practice, institutions should be prepared to submit an initial report within very short timelines after major classification, while also respecting any outer deadline linked to awareness of the incident.
That is why your internal process needs to capture two timestamps clearly:
The initial report usually contains high-level, structured facts, not a perfect narrative. You may not have a confirmed root cause yet. You may still be estimating customer impact. That is normal. What matters is that the information is accurate enough to be defensible at that stage.
The intermediate report: what changes by 72 hours
The follow-up stage, often discussed as the 72-hour update, is where the authority expects a more developed picture. By then, your team should typically know more about scope, current containment status, third-party involvement, and likely business consequences.
Consider this: the intermediate report is not just a copy of the initial report with a few extra lines. It should show that your investigation progressed. If nothing changed, that itself may need explanation. For teams that want a dedicated walkthrough of the wider process, dora incident reporting goes deeper into the reporting workflow.
Platforms like DORApp streamline the creation and maintenance of the Register of Information process and related reporting workflows through import, structured record management, auto-enrichment from public sources, validation logic, and generation of compliant outputs from controlled data.
A timeline view: what “without undue delay,” 24h, 72h, and final reporting often looks like in real teams
Deadlines are easier to meet when you stop thinking of them as three separate reports and start thinking of them as one continuous operational timeline. In most real incidents, the “reporting work” begins at detection, not at the moment someone opens a regulator form.
A realistic incident reporting timeline, step by step
While the exact deadlines and triggers depend on the applicable standards and competent authority expectations, many teams experience a flow that looks roughly like this:
The difference often comes down to discipline. If your team treats the incident record as the single source of truth from the first hour, the later reports become an output of your process, not a scramble to reconstruct history.
The “clock start” problem: awareness can be messy
One of the most common internal disputes is whether the reporting clock started when the first alert fired, when the service desk escalated, when the on-call engineer acknowledged, or when a formal incident ticket was created. Competent authorities typically care less about which team saw it first and more about whether your institution has a clear, consistently applied definition of awareness, supported by evidence.
If internal awareness can precede formal logging, your best defense is documentation. Record why you chose a specific awareness time, what signals you had, and who made the call. In later reviews, that rationale is often as important as the timestamp itself, especially when early indicators were ambiguous.
Weekends, holidays, and handoffs: where good plans get tested
Most major incidents do not wait for office hours. From a practical standpoint, you should assume the first 24 hours could include a weekend, a holiday, or a handoff between shifts. That is where reporting readiness becomes operational resilience, not policy.
Teams that handle this well often prepare three things in advance:
Consider this: if your initial report requires ten approvals, it may work on a Tuesday morning and fail on a Friday night. Most institutions eventually simplify approvals for the initial stage and rely on governance controls and audit trails to show how decisions were made.
What goes into the final report
The final report is where your institution closes the loop. By this point, supervisors generally expect a stable account of what happened, what the impact was, what was done to contain and recover, and what remediation or preventive actions follow.
The final report is about closure and accountability
In practice, this means the final submission often includes:
What many people overlook is that the final report is not just for the regulator. It is also evidence of internal governance maturity. If the timeline, decisions, and approvals are inconsistent, the final report may expose control weaknesses that were hidden during the incident itself.
With features such as workflow-driven processing, validation support, audit trail records, and a data model that converts reporting data into XBRL outputs, DORApp is one example of a platform that may help teams move from ad hoc incident handling toward repeatable reporting operations.
Where teams usually struggle in practice
The reality is that deadline breaches usually start long before the deadline itself. They tend to begin with unclear ownership, inconsistent data, or delayed escalation.
Unclear awareness time
If your team cannot agree on when the institution became aware of the incident, every subsequent timing decision becomes harder. This happens often when different functions see the same event at different moments, for example operations first, then cyber, then compliance.
Classification delays
Teams may hesitate because they want perfect facts before making a major incident decision. But waiting too long can create its own regulatory risk. A defensible preliminary classification, updated as facts develop, is usually more practical than indecision.
Third-party dependencies
Many ICT incidents involve outsourced providers, cloud services, software vendors, or other external dependencies. That means your ability to notify on time may depend partly on data you do not fully control. This is one reason DORA links incident response with broader supplier governance, Register of Information quality, and what is digital resilience as an operating discipline, not just a reporting task.
If you want to explore topic hubs related to this area, the Incident Reporting and DORA Fundamentals categories are useful starting points.
Third-party outages and supply-chain incidents: what to prepare before the next major disruption
Third-party dependencies deserve more than a single line in an incident postmortem. The reality is that small supplier issues can create broad disruption when they sit in the middle of critical services, for example authentication, payments routing, messaging, hosting, or endpoint tooling. In those moments, your reporting timeline can be constrained by what your provider knows, what they are willing to confirm, and how quickly you can translate their update into your classification and notification process.
For most small business owners and entrepreneurs, an outage is frustrating. For regulated financial entities, it can become a time-sensitive governance and reporting event. That is why DORA reporting readiness often overlaps with business continuity and disaster recovery planning, even if the incident starts with someone else’s platform.
Prepare your supplier escalation path before you need it
If your incident response plan assumes that “the vendor will tell us,” you are likely to lose time. In practice, teams that handle supplier incidents well usually have a pre-built escalation path that includes named contacts, escalation tiers, and an internal owner who can chase updates while the technical team focuses on containment.
From a process standpoint, you also need a clear evidence collection path. Save provider status updates, incident tickets, emails, and timeline statements in a way that can later support your awareness time and classification rationale. If your provider later revises their root cause or impact window, you want to show what you knew at each decision point.
What you typically need from providers within the first day
Even when providers cannot share every detail early, there is usually a minimum set of information that helps you classify and report without guessing:
Now, when it comes to making this reliable, contracts and supplier governance matter. Exact requirements vary, and you should confirm specifics with your legal, procurement, and compliance teams. Still, it is often worth ensuring that incident notification clauses, update cadence expectations, and escalation rights are defined clearly enough that you are not negotiating basics during an outage.
Connect reporting readiness to BC/DR testing
What many people overlook is that large-scale supply-chain incidents are not only a reporting challenge, they are a continuity test. If a critical provider fails, your institution may need to activate workarounds, shift traffic, pause certain services, or communicate with customers under pressure. That operational reality should be tested, not just documented.
In most institutions, tabletop exercises and BC/DR tests are where you find out whether your service mapping is accurate, whether escalation works on weekends, and whether your minimum data set for the first report is realistic. If you can run an exercise that produces a defensible awareness time, a preliminary classification decision, and a draft initial notification using partial facts, you are much closer to meeting real deadlines when the next disruption hits.
How to build a workable internal process
Here's the thing: good dora incident notification practice usually looks operational, not theoretical. The institutions that handle deadlines well tend to build a simple, disciplined workflow that can function even during a high-pressure event.
A practical reporting setup
From a practical standpoint, the best process is the one your team can actually execute at 2 a.m. with partial facts and competing priorities.
Where tools can help without replacing judgment
No platform replaces legal interpretation, internal governance, or experienced incident leadership. Still, systems can reduce friction. DORApp, for example, offers DORA-focused modules, including Register of Information reporting support, an audit trail, Help Center resources, and incident management workflows described in its platform materials. That matters because the operational burden is often in the mechanics: collecting evidence, validating data, routing approvals, and generating technically acceptable outputs.
For broader context, readers may also find DORA Pillars Explained: Complete Breakdown (2026) and DORA European Commission Timeline and History (2026) helpful alongside this article.
Explore how DORApp can support your DORA compliance journey with a 14-day free trial at https://dorapp.eu/create-account/ or book a walkthrough at https://dorapp.eu/book-demo/ if you want to see how a structured reporting workflow may fit your institution.
Disclaimer: The information in this article is intended for general informational and educational purposes only. It does not constitute professional technical, legal, financial, or regulatory advice. Website performance outcomes, platform capabilities, and business results will vary depending on your specific circumstances, goals, and implementation. Always evaluate tools and platforms based on your own needs and, where relevant, seek professional guidance.
Regulatory note: This article is for informational purposes only and does not constitute financial, legal, or regulatory advice. DORA compliance requirements may vary based on your institution type, size, and national regulatory framework. Content referencing regulated industries is provided for general context only and should not be interpreted as legal, regulatory, compliance, or financial advice. If you operate in a regulated sector, always consult qualified financial, legal, and compliance professionals for guidance specific to your situation.
Frequently Asked Questions
What is DORA notification in simple terms?
DORA notification is the process by which an in-scope EU financial entity reports a major ICT-related incident to its competent authority under the Digital Operational Resilience Act. In simple terms, it means your institution may need to formally tell the regulator when a serious technology-related disruption or cyber event meets the major incident threshold. The process is staged, so you generally notify early with key facts, then provide updates, and later submit a final report once the situation is clearer and remediation work has progressed.
Does every ICT incident have to be reported under DORA?
No. DORA does not require every technical issue or service disruption to be reported externally. The key question is whether the incident qualifies as a major ICT-related incident based on the applicable classification criteria and thresholds. Your institution still needs internal incident management for smaller events, but external notification is usually reserved for incidents that meet the reportable threshold. That is why having a documented classification method matters so much. Without it, teams may either over-report minor issues or under-report incidents that should have been escalated.
What does the 24-hour DORA reporting reference usually mean?
The phrase usually refers to the short deadline associated with the initial stage of major incident reporting. In practice, teams often use “24-hour reporting” as shorthand for the expectation that authorities are notified quickly once a major incident has been identified, while also tracking awareness-related timing requirements. The exact legal interpretation should always be checked against the current technical standards and your jurisdictional setup. The important operational point is this: your institution should be ready to assemble and approve an initial report very quickly after classification.
What is typically included in the 72-hour update?
The 72-hour stage usually provides a more developed picture of the incident than the initial report. By then, institutions often include refined impact analysis, clearer containment status, better information on affected services or customers, known third-party involvement, and any updated risk to business continuity or data integrity. You still may not have every answer, especially if forensic work is ongoing. What matters is that the report reflects meaningful progress in the investigation and presents the best available information in a structured, traceable way.
When should the final report be submitted?
The final report is generally submitted after the incident has been stabilized and the institution has enough information to provide a reliable account of root cause, impact, recovery, and corrective actions. In many operational workflows, the final stage follows the intermediate reporting phase by a set period defined in the reporting framework. Because supervisory expectations and implementing standards can evolve, you should confirm the current timing and local interpretation with your legal and compliance teams. Operationally, the final report should not be rushed if key facts remain unclear.
How do you know when the reporting clock starts?
That depends on the relevant trigger in the reporting framework, which is why accurate timestamping is so important. Most institutions need to track at least the awareness time and the point of major incident classification. Problems often arise when different teams identify the event at different moments or when awareness is recognized informally before it is logged formally. A practical approach is to define awareness in internal policy using clear operational language and require teams to document it consistently. That reduces later disputes about whether a deadline was met.
What if a third-party provider causes the incident?
Your reporting obligations may still apply even if the incident originated with a third-party ICT provider. DORA places strong emphasis on third-party risk management and operational resilience across outsourced services, so institutions cannot assume vendor responsibility removes their own notification duties. In practice, this means you need fast access to supplier contacts, service mappings, contractual escalation points, and evidence from the provider. Many reporting delays happen because institutions are waiting on external confirmation, which is why supplier governance and incident reporting should work as one connected process.
Can a tool automate DORA incident notification completely?
Not completely, and it should not. Tools may help with structured data capture, workflow routing, validation, audit trails, and technical report generation, but classification judgments, legal interpretation, and final approvals still require human responsibility. A good system reduces administrative friction and gives teams clearer visibility into deadlines and missing information. It does not replace governance. That distinction matters because regulators are generally interested in whether your institution can demonstrate control, accountability, and sound decision-making, not whether you clicked a button in a software platform.
Why is incident classification so closely tied to notification timelines?
Because reporting is triggered by whether an incident is major, not simply by the fact that it exists. If classification is delayed, disputed, or poorly evidenced, your reporting timeline can become confused very quickly. Teams may spend valuable time debating severity instead of preparing a defensible initial report. A mature process links intake, triage, impact assessment, classification, and notification into one flow. That reduces duplication and helps management understand why a reporting decision was made, who approved it, and what facts supported it at that moment.
What should compliance teams improve first if they are new to DORA reporting?
Start with the fundamentals: clear ownership, a documented classification method, timestamp discipline, and a minimum required data set for major incident reporting. Many teams try to perfect templates before fixing operating basics. The better first move is to make sure people know who decides, who reviews, where the data comes from, and how deadlines are tracked outside normal business hours. Once that foundation is stable, templates and tools become much more effective. The goal is not elegance on paper. It is a reporting process that works under real incident pressure.
What does DORA stand for?
DORA stands for the Digital Operational Resilience Act. It is an EU regulation that sets requirements for how in-scope financial entities manage and test digital operational resilience, including ICT risk management, incident reporting, and oversight of certain third-party ICT arrangements.
What is reportable under DORA?
In most cases, reportable under DORA means a major ICT-related incident that meets the applicable classification criteria and thresholds in the reporting framework used by your competent authority. Not every ICT issue is reportable externally. Your institution typically needs to apply its documented classification method, make a timely and defensible decision based on available facts, and keep evidence of what was known at the time. Some frameworks also allow for voluntary notification of significant cyber threats, depending on supervisory expectations, so it is worth aligning your approach with your legal and compliance teams.
What are the 5 principles (or pillars) of DORA?
DORA is commonly explained through five core pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, management of ICT third-party risk, and information sharing arrangements. The exact phrasing can vary in summaries, but the core idea is consistent: DORA links governance, prevention, testing, supplier oversight, and reporting into one operational resilience framework.
What are DORA’s reporting requirements?
DORA’s incident reporting requirements typically focus on identifying and reporting major ICT-related incidents through a staged process. In practice, this usually involves an initial notification within short timelines after major classification and awareness triggers, an intermediate update within a defined window such as 72 hours in many operational interpretations, and a final report once root cause and remediation are sufficiently clear. Exact triggers, fields, and timelines can depend on the applicable technical standards and national supervisory approach, so institutions should confirm details with qualified legal and compliance professionals.
Key Takeaways
Conclusion
DORA notification timelines can feel deceptively simple on paper. A short deadline here, an update there, then a final report once the dust settles. In real institutions, though, those stages sit on top of incident triage, internal escalation, third-party coordination, legal interpretation, and management accountability. That is why the real task is not memorizing a deadline. It is building a process that can produce defensible decisions and reliable reporting under pressure.
If your team is still maturing its approach, focus first on awareness timing, classification discipline, ownership, and evidence quality. Those four areas usually make the biggest difference. If you want a practical way to explore the wider topic, browse the Dorapp blog for more DORA explainers, or see how DORApp approaches structured reporting workflows, XBRL-ready outputs, and audit-friendly process design at dorapp.eu. It is a useful next step if you want to turn reporting deadlines into something your team can manage with more confidence.
About the Author
Matevž Rostaher is Co-Founder and Product Owner of DORApp. He brings deep experience in building secure and compliant ICT solutions for the financial sector and is positioned by DORApp as an expert trusted by financial institutions on complex regulatory and operational challenges. DORApp’s own webinar materials list him as CEO and Co-Founder of Skupina Novum d.o.o. and CEO and Co-Founder of FJA OdaTeam d.o.o. His articles should carry the voice of someone who understands not just compliance requirements, but the systems and delivery realities behind them.