DORA ICT Incident Management

Reporting is only one part: incident management also covers internal classification, containment, root cause analysis, and follow-up, regardless of whether an incident meets the reporting threshold. An incident that doesn't require reporting should still be handled through a structured process, since it can be an early indicator of larger problems.

A security event is initially just an observed anomaly that doesn't necessarily have a confirmed negative impact yet. An ICT incident under Article 17 exists once an actual impact on the availability, confidentiality, integrity, or authenticity of data or services is confirmed. That distinction determines whether the formal incident process gets triggered.

A documented process with clear ownership for detection, classification, containment, and reporting is required, including how communication with affected customers and relevant authorities is handled. A process that only exists on paper and hasn't been rehearsed tends to cause delays precisely when fast action matters most.

Structured logging of past incidents, including those below the reporting threshold, surfaces recurring vulnerabilities or attack patterns that would stay hidden if each incident were reviewed in isolation. This kind of analysis often yields more valuable insight for risk management than examining a single event on its own.

After the acute response, a structured review should assess not just the technical root cause but also organizational factors like response speed and communication paths. The resulting improvements should be documented and their implementation tracked, rather than just recorded in a closing report without follow-through.

This requires clearly assigned owners for initial event triage, an escalation path to the management body for severe incidents, and enough technical capacity for forensic analysis. Smaller companies often solve this through external incident response partners engaged on short notice when needed.