Skip to main content
Regulatory Council
green gradient background, "The Future of Application Security Is Already Here." and a read the report button.
Category: Business Continuity & Resilience

ICT-Related Incident

Also known as: ICT Incident
Simply put

An ICT-related incident is an event affecting an organization's information and communication technology systems, such as the networks and systems supporting its services. Under the EU's Digital Operational Resilience Act (DORA), financial entities must have a process to detect, manage, and notify such incidents. An incident may be classified as 'major' when it has a high adverse impact on the systems that support critical services.

Formal definition

Within the framework of the EU Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), an ICT-related incident is an event or series of events affecting the network and information systems of a financial entity. Article 17 of DORA requires financial entities to define, establish, and implement an ICT-related incident management process to detect, manage, and notify such incidents. A 'major' ICT-related incident is one determined to have a high adverse impact on the network and information systems supporting critical services; the source evidence indicates that classification turns on adverse impact to the criticality of services, though practitioners should verify the precise classification criteria against the binding DORA text rather than rely on any single secondary summary. The specific article numbers governing classification criteria and reporting obligations should be confirmed directly against the primary Regulation, as secondary sources in this evidence set differ on citation. Applicability is limited to financial entities within DORA's scope and does not extend to sectors or jurisdictions outside the EU regime; legal interpretation of scope and thresholds should be confirmed with qualified counsel.

Why it matters

For financial entities operating within the EU, the ICT-related incident concept sits at the heart of the Digital Operational Resilience Act's supervisory regime. DORA reflects a policy judgment that disruptions to the technology underpinning financial services, whether from cyberattacks, system failures, or operational errors, can threaten not only individual firms but the stability of the wider financial system. Treating such events as a defined, managed category rather than routine IT problems is what allows firms and supervisors to respond in a coordinated way and to build an evidence base about where operational fragility concentrates.

The distinction between an ordinary ICT-related incident and a 'major' one carries particular weight, because classification typically triggers escalation and notification obligations. Under DORA, a major incident is one determined to have a high adverse impact on the network and information systems that support critical services. That threshold matters practically: it determines when a firm must move from internal handling to formal reporting, and it shapes the aggregate picture that the European Supervisory Authorities compile from firm submissions. Getting classification wrong, either over- or under-reporting, can expose a firm to supervisory criticism.

Because the precise criteria, thresholds, and article references are set out in the binding Regulation and its accompanying technical standards, firms should treat any secondary summary, including this one, as a starting point rather than a substitute for the primary text. Applicability is confined to entities within DORA's scope in the EU regime; scope, thresholds, and their legal interpretation should be confirmed with qualified counsel.

Who it's relevant to

Operational resilience and ICT risk teams
Teams responsible for operational resilience own the incident management process DORA requires, detection, management, and notification. They must build the workflows and criteria that let the firm distinguish routine events from those meeting the 'major' threshold based on adverse impact to critical services.
Compliance officers and general counsel
Because classification triggers notification obligations under a binding EU Regulation, compliance and legal functions need to confirm the precise thresholds and reporting timelines against the primary DORA text and relevant technical standards. Scope questions and threshold interpretation for a specific entity should be confirmed with qualified counsel.
Risk managers at in-scope financial entities
Risk managers at financial entities within DORA's scope must integrate ICT-related incidents into the firm's broader risk framework, ensuring that events affecting network and information systems are assessed for their impact on critical services and escalated consistently.
Internal audit
Auditors assess whether the firm's ICT-related incident management process is defined, established, and operating as DORA's Article 17 obligation contemplates, and whether classification decisions and any resulting notifications are applied consistently and evidenced.

Inside ICT-Related Incident

ICT-Related Incident (concept)
Under DORA (Regulation (EU) 2022/2554), an ICT-related incident is generally understood as a single event or a series of linked events, unplanned by the financial entity, that compromises the security of network and information systems and has an adverse impact on the availability, authenticity, integrity, or confidentiality of data, or on the services the entity provides. Definitional specifics should be verified against the Regulation's definitions article.
Detection, Management, and Notification Obligation
DORA Article 17 establishes the obligation for financial entities to define, establish, and implement an ICT-related incident management process to detect, manage, and notify ICT-related incidents. This is a process requirement, not merely a reporting requirement, and forms part of the broader operational resilience framework.
Major Incident Threshold
A 'major ICT-related incident' is defined in DORA Article 3(10) and denotes an incident with a higher adverse impact, determined by reference to classification criteria. The 'major' designation is the trigger that distinguishes routine incidents from those subject to the escalation and reporting regime.
Classification Criteria
The criteria for classifying ICT-related incidents (and for determining what constitutes a 'major' incident) are laid down in DORA Article 18. These criteria are typically further specified through regulatory technical standards; practitioners should verify the applicable delegated acts and current thresholds against the primary sources.
Reporting Regime for Major Incidents
Where an incident is classified as major, DORA Article 19 sets out the requirement to report it to the relevant competent authority, typically involving initial, intermediate, and final notifications within specified timeframes. Exact timing and templates are elaborated in implementing measures and should be confirmed against the current text.
Relationship to GRC Pillars
The concept spans risk management (identifying and treating ICT-related uncertainty against operational objectives) and compliance (adhering to DORA's binding detection, management, and reporting duties), and connects to governance through the management body's oversight responsibilities for operational resilience.

Common questions

Answers to the questions practitioners most commonly ask about ICT-Related Incident.

Is every ICT-related incident subject to mandatory regulatory reporting?
No. Under DORA (Regulation (EU) 2022/2554), financial entities are generally required to detect, manage, and log all ICT-related incidents, but the specific obligation to report to competent authorities typically attaches only to incidents classified as 'major.' The classification exercise therefore acts as a threshold: many incidents are managed internally without triggering external notification, while those meeting the 'major' criteria fall within the reporting regime. Applicability, thresholds, and the treatment of significant cyber threats can vary, and the precise obligations should be verified against the current text of DORA and any related regulatory technical standards.
Does an ICT-related incident mean the same thing as a personal data breach?
Not necessarily. An ICT-related incident concerns an event affecting ICT systems, services, or the security of network and information systems, and its effect on an entity's operations. A personal data breach, by contrast, is a concept under data protection law such as the GDPR, concerning the compromise of personal data. The two can overlap, an ICT incident may also constitute a personal data breach, but they arise under different frameworks, carry distinct definitions, notification triggers, timelines, and recipients, and may need to be assessed separately. Legal interpretation of overlap in a specific case may require professional advice.
How do we determine whether an ICT-related incident qualifies as 'major'?
The term 'major' incident is defined in DORA (Article 3(10)), and the criteria for classifying ICT-related incidents are laid down in Article 18 of the Regulation, which is typically further specified through regulatory technical standards addressing factors and thresholds. In practice, entities generally establish an internal classification process that assesses relevant materiality factors against those criteria. Because the detailed parameters can be set out in delegated or implementing measures that evolve, the applicable thresholds should be verified against the current primary sources rather than relying on a fixed internal checklist alone.
What internal capabilities support detecting and managing ICT-related incidents?
DORA (notably Article 17) sets out the obligation for in-scope financial entities to detect, manage, and, where applicable, notify ICT-related incidents. Supporting this typically involves an ICT-related incident management process covering identification, logging, classification, response, and root-cause analysis, along with defined roles and escalation paths. These arrangements often sit within a broader ICT risk management framework. The specific design will depend on the entity's size, complexity, and risk profile, and should be aligned to the current requirements rather than to a generic template.
Who should be involved in classifying and escalating an incident once detected?
Classification and escalation generally benefit from involvement across functions, since determining whether an incident may meet 'major' criteria under Article 18 can require operational, technical, risk, compliance, and legal input. Many entities assign clear decision rights for classification and define escalation triggers so that potential 'major' incidents reach the responsible individuals promptly given the reporting regime under Article 19. The precise governance structure is a matter for each entity to define within its ICT risk management framework, and roles should be documented so classification decisions are defensible.
How should ICT-related incident records be documented and retained?
Consistent with the detect, manage, and notify obligation in Article 17, entities typically maintain records of ICT-related incidents, including how each was identified, classified, and handled, together with the rationale for any 'major' classification decision. Robust documentation supports internal review, root-cause analysis, and the ability to demonstrate the classification and reporting process to competent authorities. Specific retention periods and record content may be shaped by DORA, related technical standards, and other applicable requirements, and should be confirmed against the current primary sources for the relevant jurisdiction and sector.

Common misconceptions

Only 'major' ICT-related incidents need to be detected and managed.
The Article 17 obligation to detect, manage, and log ICT-related incidents typically applies to ICT-related incidents generally, not only major ones. The 'major' classification (Article 3(10), assessed against the criteria in Article 18) primarily governs whether the mandatory reporting regime in Article 19 is triggered, not whether the incident must be managed internally.
An ICT-related incident is the same as an ICT risk or a control failure.
An ICT-related incident is an event that has occurred and produced an adverse impact, whereas an ICT risk is a potential event and its possible effect on objectives, and a control is a measure intended to modify that risk. Conflating these obscures the distinction between prospective risk treatment and reactive incident handling.
The classification thresholds are a matter of internal judgment left to each firm.
The classification of incidents, including determining 'major' status, is governed by the criteria laid down in DORA Article 18 (typically supplemented by regulatory technical standards), rather than by discretionary internal definitions. Firms should map their internal criteria to the binding criteria and verify current specifics against the primary sources.

Best practices

Establish an ICT-related incident management process that supports detection, management, logging, and notification, consistent with the Article 17 obligation, rather than limiting the process to reportable events only.
Map internal incident classification criteria to the binding criteria in DORA Article 18 and the 'major' definition in Article 3(10), and verify thresholds against the current regulatory technical standards before relying on them.
Define escalation triggers and timelines that align with the Article 19 reporting regime for major incidents, including initial, intermediate, and final notifications, and confirm exact timeframes against the primary text.
Maintain a clear separation in documentation between ICT risks, controls, and actual incidents, so that risk registers, control frameworks, and incident logs remain distinct and defensible.
Assign governance responsibility so that the management body has oversight of the incident management framework and receives escalation of major incidents.
Confirm jurisdiction- and entity-specific applicability of DORA, including any proportionality provisions, with qualified legal or regulatory advisors, as scope and obligations vary by entity type and are subject to interpretation.
Application Security Isn’t Optional Anymore.