DORA Near Miss Reporting (2026 Guide)
You investigate an ICT event on Monday morning. A core service slowed down, alerts fired, a provider was pulled into the call, and for a while it looked like you might have a reportable DORA incident on your hands. By the afternoon, the issue is contained. No customer harm is confirmed, no threshold is clearly crossed, and someone in the room asks the obvious question: do we log this as a near miss, a minor incident, or just move on?
That question matters more than many teams expect. Under DORA, institutions are not only judged by how they handle major ICT incidents, but also by whether their incident governance is disciplined, evidence-based, and consistent. In 2026, that matters even more because supervisors are looking for proof of compliance, not just policy documents.
DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, turning complex regulatory requirements into structured, manageable workflows with technically compliant reporting outputs. If you are still getting oriented, it helps to start with what is dora before narrowing in on near misses and incident thresholds.
What a near miss means under DORA
A dora near miss is not a formal incident category in the same way that a major ICT incident is. In practice, teams use the term for an event that could have become disruptive or reportable, but did not ultimately cross the relevant impact threshold. Think of a failed software deployment that briefly affects a production service but is rolled back before customers are harmed, or a third-party outage that creates a short exposure without causing material service disruption.
Here is the thing, near misses still matter because they tell you something important about your controls, dependencies, escalation speed, and operational resilience. A near miss may show that a weak point exists even if the final outcome was contained in time.
From a regulatory standpoint, DORA is centered on operational resilience, incident handling, and governance quality. That is why understanding the broader digital operational resilience act dora context helps. The legal obligation focuses on reportable incidents and resilience management, but prudent institutions also maintain structured records of lower-severity events and near misses.
How near misses connect to DORA’s five pillars
If you only look at near misses through the lens of external reporting, you miss most of their value. DORA is typically described through five core pillars, and near-miss tracking can support every one of them by strengthening your internal learning loop.
It also helps to be clear on terminology. “Near miss” is usually an internal governance label, not a formal DORA reporting category. DORA’s formal obligations concentrate on major ICT-related incidents and the surrounding processes: how you detect, classify, record, escalate, and report where required. Near misses are often the events that prove whether those processes work before a truly material disruption occurs.
Consider this practical mapping of near misses to the five pillars:
For most small business owners and entrepreneurs, “near miss” might feel like a safety mindset. For regulated institutions, it is also a governance mindset. You are showing that your organization is capable of learning and evolving based on evidence, not just reacting once something becomes major.
Near miss vs minor incident
This is where many teams get stuck. A near miss and a dora minor incident are not always the same thing.
A near miss usually means the impact stayed below incident significance
If the event was detected early, contained quickly, and produced no meaningful operational or customer impact, many institutions will classify it internally as a near miss. It is still logged, reviewed, and trended, but it may not be treated as an incident that activates external reporting obligations.
A minor incident usually means an incident happened, but below major reporting thresholds
A minor incident generally involves real disruption, degradation, or security impact, just not at a level that would trigger major ICT incident reporting. In practice, this means the event belongs in your incident inventory and governance process even if it never becomes externally reportable.
If your team is tightening its taxonomy, it helps to separate three questions: did something happen, how much impact did it create, and did it meet the threshold for a major incident? That is the same logic that underpins sound dora incident classification.
How incident thresholds work in practice
The phrase dora incident threshold often sounds more precise than it feels during a live event. Real cases are messy. Facts are incomplete, provider statements arrive late, and the business impact may change over several hours.
Under DORA, institutions need processes to identify, manage, classify, and where required report major ICT-related incidents. The detailed threshold logic sits in the broader incident framework and related technical standards, not in the shorthand language teams often use on calls. That means you should avoid treating thresholds like a simple yes or no checklist.
What teams typically assess
Think of it this way: a near miss may sit just below those impact markers, while a minor incident may show real but limited impact, and a major incident crosses the threshold that activates dora incident reporting obligations.
What many people overlook is that classification quality depends on your underlying data. If service mappings, entity ownership, and third-party dependencies are unclear, threshold decisions become subjective fast. That is also why incident management should connect back to what is ict risk and the wider control environment.
A practical classification workflow for the first 24 to 72 hours
When the classification is unclear early on, the worst move is often to lock yourself into a final label too quickly. DORA’s incident reporting approach relies on standardized classification criteria and defined reporting timelines set out through technical standards. You do not need to memorize every detail during an outage call, but you do need a repeatable workflow that makes your later decisions defensible.
0 to 4 hours: initial triage and provisional label
In the first hours, focus on what you can actually evidence. Capture the baseline facts, set a provisional classification, and assign a clear owner for updates. In most cases, a “provisional near miss” or “under assessment” status is more honest than a confident but premature “definitely minor” call.
4 to 24 hours: evidence capture and service impact mapping
This is typically where teams either build strong records or create future problems. You want to capture an incident timeline, map affected components to business services, and confirm whether any critical or important functions could be impacted. If an ICT third-party is involved, document what you requested, what they confirmed, and what remains unknown.
Now, when it comes to reporting readiness, early evidence matters because later reports and internal governance reviews tend to ask the same questions: when did you know, what did you know at the time, who made the call, and what supported it?
24 to 72 hours: reclassification triggers and decision sign-off
As facts firm up, you should have a structured moment to confirm or change classification, ideally with a documented decision and sign-off. Reclassification is not failure, it is normal incident management when impact evolves. The key is to record why the classification changed, and what new evidence drove it.
Common “reclassify to major” signals include:
Think of it this way: your record should show cautious reasoning without overcommitting early. “Based on current evidence” and “subject to confirmation” language is often more defensible than rewriting the narrative after the fact.
Why near misses still matter in 2026
In 2025, a lot of institutions were focused on getting across the line. Policies were finalized, the Register of Information was assembled, and teams worked to meet the first major deadlines. In 2026, the conversation has shifted. Supervisors are increasingly interested in whether your processes actually work in operation.
That is why near misses matter. They help demonstrate that you are not only responding to major events, but also learning from weak signals before they become serious failures. A bank, insurer, or investment firm that can show recurring near-miss analysis, remediation tracking, and governance follow-up is in a stronger position than one that only documents incidents after damage occurs.
From a practical standpoint, near misses are often where hidden patterns show up first:
If you need the wider legal framing, articles on dora regulation explained and the category pages for Incident Reporting and DORA Fundamentals are useful next reads.
RTS/ITS, templates, and what supervisors may ask to see
Most teams understand DORA at the headline level, but the operational detail often lives in the technical standards. DORA is supported by Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that translate the regulation into practical criteria, processes, and standardized reporting templates. You do not need to get overly legalistic to benefit from this, it mainly means your internal records should align with how you may later need to evidence decisions.
In practice, supervisors and auditors tend to care less about whether you used the perfect internal label on day one, and more about whether your decisions were consistent and traceable. That includes near misses, because near misses are often the events that show how your governance works when the outcome is not obvious.
What reviewers may ask for during a DORA review
An audit-ready near miss pack (simple checklist)
If you want a practical standard for “would this hold up later,” it helps to package near-miss evidence in a consistent way. A near miss pack often includes:
The difference often comes down to discipline. If near misses are recorded with the same care as incidents, you spend less time reconstructing evidence later, and you build a more credible operational resilience story over time.
How to manage near misses well
The reality is, most governance problems around near misses are not caused by bad intent. They come from inconsistency. One team logs everything, another logs only outages, and a third relies on email summaries that never make it into a central record.
Start with a clear internal definition
You should define what your institution considers a near miss, how that differs from a minor incident, and who makes the call. This may sit in your incident policy, classification standard, or operating procedures. The exact wording may vary by institution type and national supervisory expectations, but the internal rule needs to be clear enough that teams can apply it under pressure.
Capture the same core facts every time
Even if an event stays below reportable thresholds, the record should usually include detection time, awareness time, impacted service, third-party involvement, business effect, and why the event did not meet the major threshold. That creates defensible evidence later.
Review for patterns, not just isolated events
One near miss may be nothing more than a contained glitch. Five similar near misses over six months may point to a deeper control failure. In practice, this means your teams should review recurrence, concentrations by provider, and links to change events or control breakdowns.
For readers who want the bigger policy backdrop, the post DORA European Commission Timeline and History (2026) is a useful reminder that DORA is part of a broader EU resilience agenda, not a standalone reporting exercise.
Where tools and workflows can help
Near misses are easy to lose when your process depends on spreadsheets, inboxes, and memory. That is usually where friction starts. Teams know an event was important, but the record is incomplete, the classification rationale is missing, and nobody can show how the decision was reached.
Platforms like DORApp streamline the Register of Information process through a structured workflow that supports importing existing data, managing records through an intuitive interface, enriching data from public sources, validating against formal rules, and generating technically compliant outputs. While the Register of Information is a separate requirement from incident handling, the same principle applies: structured data makes compliance work more defensible.
With features such as modular workflows, audit-oriented records, XBRL conversion support for DORA reporting outputs, and connected compliance processes, DORApp can help teams spend less time reconstructing evidence after the fact. That is especially relevant for institutions moving from initial compliance to proof of compliance in 2026. If you want broader context, DORA Pillars Explained: Complete Breakdown (2026) is a good companion read.
You can also explore the platform directly through DORApp Modules, review DORApp Functions, or if you prefer a more hands-on next step, visit Book a Demo. For teams that want to test fit first, DORApp also offers a Free Trial – 14 Days.
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
Does DORA require formal reporting of every near miss?
No, not every near miss triggers formal external reporting. DORA is focused on major ICT-related incident reporting and broader resilience governance. A near miss is usually handled as an internal governance and risk management matter unless the facts show the event actually crossed a reportable threshold. The practical challenge is that events often look smaller at first and more serious later, so your team should still log and review them carefully. Good records help you defend your classification decision if a supervisor later asks why the event was not reported.
What is the difference between a near miss and a minor incident under DORA?
A near miss usually means an event could have caused material disruption but did not. A minor incident usually means disruption or security impact did occur, but it stayed below the threshold for a major reportable incident. The difference matters because it affects how you trend, escalate, and review the event. Many institutions use both categories internally, even if DORA itself focuses more directly on major ICT incidents and resilience processes. Your internal taxonomy should define both clearly so teams do not make inconsistent judgment calls.
Should we keep near misses in the same register as incidents?
In many cases, yes. Keeping near misses and incidents in one controlled system makes pattern analysis much easier. You can compare recurrence, affected services, third-party involvement, and remediation actions across the full event population. Some institutions use separate labels or statuses within the same workflow, while others maintain linked but distinct records. The best setup is usually the one that preserves traceability and supports board, audit, and supervisory review without creating duplicate records or fragmented evidence.
Can repeated near misses become a supervisory concern even if none were reportable?
Yes, they can. A single contained event may not draw much attention, but repeated near misses around the same provider, service, control, or change process could indicate a broader weakness in your ICT risk management framework. Supervisors increasingly care about patterns, governance response, and whether you learn from lower-impact events before they become major incidents. In 2026, that matters because institutions are being asked to demonstrate operational resilience in practice, not only through policy documents and one-time implementation evidence.
How detailed should a near-miss record be?
It should be detailed enough to support later review and consistent classification. That usually includes the timeline of detection and awareness, affected services or systems, known root cause or suspected cause, any third-party involvement, business effect, and a short rationale explaining why the event remained below major reporting thresholds. You do not need to over-engineer the record, but you do need enough structure that another reviewer could understand the decision later. Minimal records often become a problem during audits, control reviews, or supervisory follow-up.
Do third-party outages that recover quickly count as near misses?
They may. If a third-party outage created exposure or operational stress but did not materially disrupt your critical services, many institutions would treat that as a near miss or low-severity incident. The final classification depends on actual impact, not just the source of the event. Because DORA places strong emphasis on ICT third-party risk, these cases should still be logged carefully. Quick recovery does not make an event irrelevant, especially if the same provider appears repeatedly or supports critical or important functions.
How does near-miss tracking support DORA compliance more broadly?
Near-miss tracking supports DORA by strengthening evidence, governance, and learning loops. It helps you show that your institution detects weak signals, classifies events consistently, investigates root causes, and feeds lessons back into controls and third-party oversight. While DORA does not treat every near miss as externally reportable, supervisors may still expect a mature institution to understand the difference between lucky escapes and stable resilience. Tracking near misses well can also improve your future incident classification accuracy and reduce debate during time-sensitive escalation calls.
What should compliance teams do if the classification is unclear at the start?
Start by recording the facts you do know and avoid locking in a final classification too early. In practice, the first hours of an event are often messy. Impact may still be unfolding, provider input may be missing, and business teams may not yet know the customer effect. A staged process works best: log the event, capture minimum facts, assign ownership, and reassess as evidence improves. This is usually more defensible than making a rushed classification decision and then trying to rewrite the record later.
Is there a benefit to using specialized tooling for near misses and incident governance?
Usually, yes, especially for institutions dealing with multiple legal entities, providers, and reporting obligations. Specialized tooling can help centralize evidence, track deadlines, preserve audit trails, and connect incidents to services, contracts, and third-party records. That does not replace policy judgment or legal review, but it may reduce operational friction and improve consistency. As DORA oversight matures, the ability to show why a decision was made, who approved it, and what data supported it becomes more valuable than simply having a policy document on file.
What are the 5 principles of DORA?
DORA is commonly explained through five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing arrangements. The “principles” are essentially that resilience should be governed, tested, monitored, and evidenced, not assumed. Near-miss tracking supports those pillars by strengthening your internal records and showing that you learn from events that could have become major.
What are the requirements for DORA?
DORA’s requirements typically include having an ICT risk management framework, clear incident handling and reporting processes for major ICT-related incidents, resilience testing proportional to your risk profile, strong oversight of ICT third-party providers, and governance and documentation that can stand up to audit and supervisory review. Exact expectations can vary by institution type and jurisdiction, so your compliance and legal teams should confirm what applies to your organization.
What is the DORA incident classification system?
DORA incident classification is the structured way institutions determine whether an ICT event is major and therefore potentially reportable, based on standardized criteria such as impact on services and clients, duration, critical function relevance, and confidentiality, integrity, or availability implications. In real operations, classification is often staged: you make a provisional call early, gather evidence, and then confirm or reclassify as impact becomes clearer. Keeping a clear rationale and timeline is usually as important as the final label.
What is DORA’s disorder?
In a DORA compliance context, “DORA” refers to the Digital Operational Resilience Act, not a medical term. If you are seeing “DORA’s disorder” in search results, it is likely mixing unrelated meanings of the acronym. For ICT and financial services compliance teams, the relevant topic is how DORA strengthens operational resilience through governance, incident handling, testing, and third-party oversight.
Key Takeaways
Conclusion
Near misses sit in an awkward but important space. They are easy to dismiss because they did not become major incidents, yet they often reveal the exact control weaknesses that later create major reporting events. If your institution treats them as noise, you may miss the patterns that matter. If you treat them as part of a disciplined governance process, they become one of the most useful early-warning signals in your resilience framework.
The practical goal is not to over-report everything. It is to build a clear internal logic for how events are logged, classified, reviewed, and learned from. That is what makes your incident framework more credible to management, audit, and supervisors.
If you want a more structured way to approach DORA workflows, evidence handling, and reporting-ready data, explore how DORApp can support your DORA compliance journey with a 14-day free trial or request a personalized walkthrough at dorapp.eu. You can also keep learning through the Dorapp blog if you are building out your incident management approach step by step.
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.