Auditen
Home / Frameworks / DORA / ICT incident classification and reporting
DORA · Arts. 17–23

ICT incident classification and reporting

DORA requires financial entities to establish a robust framework for detecting, managing, and classifying ICT-related incidents based on their criticality. "Major" ICT incidents must be reported to the relevant competent authorities using standardized templates and within strict regulatory timelines.

What it means

The intent is to provide regulators with a systemic view of operational risks across the EU financial sector. Rather than reporting every minor technical glitch, organizations must apply a consistent taxonomy to distinguish between routine events and "major" incidents that threaten stability or impact critical functions.

In practice, this means your incident management process cannot be purely internal; it must be mapped directly to regulatory obligations. The scope extends beyond your own infrastructure to include ICT services provided by third-party vendors, meaning you are responsible for reporting major incidents even if the failure occurred at a cloud provider or software vendor.

How to meet it

Evidence an auditor asks for

  • The ICT Incident Management Policy, including the specific criteria used to classify an incident as "major."
  • An incident register/log showing all recorded events and the classification assigned to each.
  • Copies of reports submitted to regulators (or a log of submissions) along with timestamps proving adherence to deadlines.
  • Completed Root Cause Analysis (RCA) documents for previously identified major incidents.
  • Third-party contracts or addendums containing incident notification clauses.

Common pitfalls

  • Failing to distinguish between an "event" and an "incident," leading to either over-reporting noise or under-reporting critical failures.
  • Relying solely on third-party vendors to report incidents without having a verification mechanism, resulting in missed regulatory deadlines.
  • Using vague classification criteria (e.g., "high impact") without quantitative thresholds (e.g., "service unavailable for >2 hours").
  • Treating reporting as a one-time task rather than a lifecycle requiring initial, intermediate, and final reports.