OperationalResilience.help
The Continuity Desk - important services, kept running
Home / Line 06 - Incident management and reporting / Guide

Minor Incidents and Near Misses

Why minor incidents and near misses deserve attention under DORA, how to record them without drowning the team in paperwork, and what patterns they reveal before a major incident.

Published 26 October 2026Checked against the regulation text on 26 October 2026European Union (financial entities in scope of DORA)

The short answer

Minor incidents and near misses are events that did not become major incidents, either because their service effect was limited or because a control, a workaround, or good fortune prevented a wider failure. They still deserve a proportionate record, because they are often the earliest sign of a weakness that will later cause a major incident. A short entry that captures what happened, what stopped it spreading, and whether any follow up is needed is usually enough. The aim is not to report every minor event to an authority, but to keep a record inside the firm that can be reviewed for patterns.

What is a near miss in this context?

A near miss is an event that could plausibly have become a major incident but did not, because of a safeguard or because of luck. Examples include a fault that was caught by monitoring just before it reached customers, a provider outage that coincided with low customer activity, or a change that was rolled back before it affected a live service. The distinction between a safeguard and luck matters, because a near miss stopped by a control is reassuring in a way that a near miss stopped by chance is not. Recording which of the two applied helps the firm judge whether its defences worked or whether it was fortunate, and fortune is not a control that can be relied on next time.

How much recording is proportionate?

Proportionate recording means a short, structured entry rather than a full incident report. The entry should name the service, the event, the effect, the reason it did not spread, and any action taken or proposed. It should be quick to write, or staff will stop writing it, and it should be stored where it can be searched later. A firm that demands a lengthy form for every minor event will get fewer records, not better ones, because the burden will discourage reporting. A firm that asks for a few lines, and shows that those lines are actually read, will usually get a steadier flow of useful information. The test of a minor incident system is not how many forms it generates, but whether anyone reviews them.

How do patterns emerge from minor events?

Patterns emerge when minor events are reviewed together, rather than one at a time. A single minor fault on a service may mean little, but repeated faults on the same service, the same component, or the same provider point to a weakness that deserves attention. A review that groups minor events by service, by cause, and by provider will often reveal a cluster that individual incident handlers missed, because each handler saw only their own event. That review does not need to be frequent to be useful, but it does need to be regular, owned by a named person, and followed by actions where a pattern is found. Without that review, minor incident records accumulate as an archive that nobody reads, which is little better than having no records at all.

Why does reporting culture matter here?

Minor incidents and near misses are only recorded if staff believe that reporting them is safe and useful. If staff fear blame for reporting a near miss, or if they believe their reports disappear into a system that never responds, they will stop reporting. Leaders can encourage reporting by thanking staff for near miss reports, by acting visibly on the patterns found, and by separating the discussion of what happened from any discussion of individual fault. That separation is easier to promise than to practise, especially when a near miss involved a mistake, but it is essential. A firm that punishes near miss reporting will learn about its weaknesses only when they become major incidents.

Primary sources on the record

Legal status: Regulation (EU) 2022/2554 in force; applies from 17 January 2025, with technical standards applying on the dates stated in each standard. Application position for this topic: Applies from 17 January 2025. Technical standards apply on their own stated dates.

Follow the service map

Line 06 - Incident management and reporting ICT Incident Classification and Reporting A plain guide to how DORA incident classification and reporting works: restoring the service, deciding what counts as major, and keeping a record that stands up later. Line 06 - Incident management and reporting Learning from Incidents Without Blame How to run an incident review that finds real causes and real fixes, without turning the review into a search for someone to blame, and why blame free review finds more. Line 06 - Incident management and reporting Incident Severity and Escalation How severity levels and escalation routes work together during an ICT incident, when an incident should move up a level, and who decides that it moves.