Major ICT-Related Incident

What Major ICT-Related Incident Means in Practice

A major ICT-related incident is not just a technical outage or a noisy alert. It is the point at which an ICT event crosses DORA’s reporting threshold, making the incident a regulatory matter as well as an operational one. That shift matters because classification drives timing, ownership, evidence handling and the need to reconstruct what happened with enough precision for supervisory reporting.

For financial entities, the practical question is whether the event is severe enough, across client impact, geography, downtime and financial effect, to become a reportable incident rather than an internal issue. That classification judgement is central to the term, and it is why incident managers, service owners and risk teams need a shared view of the threshold criteria.

How DORA Classifies the Incident

DORA does not treat every ICT disruption the same way. The classification process asks whether the event meets the regulatory severity thresholds and, if so, whether it should be handled as a major ICT-related incident with formal reporting obligations. In practice, that means severity is assessed against measurable indicators rather than intuition alone.

The important point is that the label is tied to impact, not just cause. A technical fault, provider issue, cyberattack or configuration error may all be relevant if they produce the kind of disruption DORA is designed to surface. That makes the definition useful for governance because it standardises when an organisation must escalate beyond ordinary incident handling.

For a deeper breakdown of the reporting thresholds and deadlines, DORA Major ICT Incident Reporting Guide explains the classification logic, timing and reporting stages in one place.

Why Accurate Reconstruction Matters

A major ICT-related incident is inseparable from the requirement to explain it clearly after the fact. Supervisory reporting depends on an accurate reconstruction of the timeline, the affected services, the scope of customer or market impact and the reason the event exceeded the threshold. Incomplete chronology or unclear root-cause analysis can turn an already serious incident into a reporting and governance problem.

This is why incident records, telemetry, change history, vendor communications and operational logs become part of the regulatory evidence base. The goal is not only to say that an incident happened, but to show how it developed, what was affected and why the organisation classified it as major.

For organisations aligning incident handling to formal response practice, ISO/IEC 27035 Incident Management Guide provides a useful incident-management model for evidence collection, analysis and lessons learned.

Reporting, Coordination and Recovery Expectations

Once an incident is classified as major, the work shifts from containment alone to coordinated reporting and recovery. That usually involves aligning the technical team, business owners, legal or compliance stakeholders and, where relevant, third parties that contributed to or were affected by the event. The operational burden is not only technical remediation, but also making sure the reporting sequence is timely and internally consistent.

Because the definition is tied to a regulatory framework, organisations should also be ready to compare DORA obligations with adjacent reporting regimes where the same event may trigger more than one notification path. That coordination problem is often as important as the incident itself, especially when service providers, outsourcing chains or multi-entity dependencies are involved.

NHIMG’s DORA Guide places major ICT incident reporting in the broader context of ICT risk management, resilience testing and third-party dependence.

Risk and Threat Considerations

The main risk in a major ICT-related incident is not only the outage itself, but the combination of operational disruption, reporting delay and weak reconstruction. If the organisation cannot determine scope quickly, it may miss the reporting threshold, understate customer impact or fail to preserve the evidence needed to justify its classification decision.

Failure mechanism: Poor logging, fragmented ownership, outsourced dependencies or unclear escalation paths can break the incident narrative, making it difficult to prove when the event became reportable and what consequences it caused.

Impact: That can lead to late or inaccurate reporting, supervisory scrutiny, weaker post-incident remediation and repeated exposure to the same failure pattern.

Practitioner Guidance

What to watch for: Treat threshold judgement as an incident discipline, not a postscript. Teams should know who owns classification, what evidence proves client impact or downtime, and how the reporting clock starts once an event crosses into major-incident territory.

Governance implication: The best-run programmes pre-align operations, risk and compliance on the same severity model so that technical responders are not forced to improvise the regulatory view during an active incident.

Related resources from NHI Mgmt Group

• What are the signs that an ICT-related incident management process is not ready for DORA reporting obligations?
• How does Major ICT Incident Reporting work?
• How do organisations implement Major ICT Incident Reporting?
• What are common mistakes with major ICT incident reporting?