Major ICT-Related Incident

Expanded Definition

A major ICT-related incident is not every outage or security event. Under DORA, the label applies only when an ICT disruption or breach crosses formal severity thresholds that regulators can assess consistently across firms. The classification looks at operational impact, number of affected clients, geographic spread, duration, and financial consequences, with an emphasis on whether the event materially disrupts critical services or business continuity. For financial entities, the term is therefore both technical and regulatory: teams must identify the incident, preserve evidence, and reconstruct the sequence of events well enough to support supervisory reporting. In practice, the concept sits between incident management and compliance response, because the quality of the record becomes part of the regulatory obligation. NHI Management Group treats this as a governance problem as much as a recovery problem, especially where privileged accounts, cloud services, or automated workflows are involved. The most common misapplication is treating any high-severity outage as a major ICT-related incident, which occurs when teams skip DORA threshold testing and assume operational pain automatically equals reportable status.

Examples and Use Cases

Implementing major ICT-related incident handling rigorously often introduces classification overhead, requiring organisations to weigh fast operational recovery against the need for defensible regulatory reporting.

• A core banking platform becomes unavailable across multiple regions, affecting customer access and transaction processing long enough to test DORA reporting thresholds.
• A cloud misconfiguration exposes sensitive records and forces service restrictions, prompting a review of client impact, scope, and whether the event meets major-incident criteria.
• A ransomware event interrupts payment processing and recovery requires coordinated evidence collection, timeline reconstruction, and management sign-off before notification.
• An automation failure in an identity or secrets workflow propagates across systems, and the organisation must determine whether the downstream service disruption is reportable.
• When AI agents or orchestrated automation are used in operational processes, incident teams may need to account for agent actions, tool access, and execution logs; the Anthropic — first AI-orchestrated cyber espionage campaign report is a useful reference point for understanding how autonomous activity can complicate incident reconstruction.

Why It Matters for Security Teams

Security teams need a precise definition because misclassification can create two equally serious failures: under-reporting a reportable incident or over-escalating an event that does not meet the threshold. Both outcomes weaken supervisory trust and can distort board-level risk reporting. For DORA-covered organisations, major ICT-related incident handling is also a test of operational resilience maturity: teams must be able to detect, scope, contain, and explain events quickly enough to meet timed notification obligations. That demands strong telemetry, clear ownership, and evidence retention across infrastructure, applications, cloud platforms, and identity systems. Where NHI, privileged access, or autonomous agents are part of the environment, incident responders must be able to separate legitimate automation from malicious activity and preserve the logs needed to explain each action. Organisations often discover the true cost of weak incident classification only after a disruption has already spread across services, at which point major ICT-related incident handling becomes operationally unavoidable.

Related resources from NHI Mgmt Group

• When does helpdesk social engineering become a major incident risk?
• Who is accountable when an AI-driven ICT incident triggers DORA reporting?
• What breaks when identity events are not visible during an ICT incident?
• Who is accountable when a manageable compromise becomes a major incident?