ICT-related incident management process

ICT-related incident management process

Purpose and Placement within the ICT Risk Management Framework

The ICT-related incident management process is a mandatory core component of the ICT risk management framework under Article 6(1) DORA. Its purpose is to ensure:

  • Rapid and reliable detection, recording, handling, classification, escalation, mitigation, and resolution of ICT-related incidents
  • Integration with anomaly detection systems (Article 10 DORA, Article 23 RTS RMF)
  • Traceable documentation for supervisory reporting obligations (Article 19 DORA)
  • Prevention of recurrence through root-cause analysis, corrective measures, and continuous improvements

This process forms the operational backbone linking detection, response, recovery, continuity, and supervisory incident reporting.

Scope and Applicability

The process must cover all ICT-related incidents, including:

  • Cyber-attacks
  • System, network, or application failures
  • Data integrity, confidentiality, or availability issues
  • Third-party ICT service failures
  • Degraded performance of critical or important ICT assets
  • Potential or confirmed compromises
  • Significant cyber threats with potential impact

It applies across all business functions supported by ICT and includes internal systems, cloud environments, outsourced ICT services, and interconnections with financial infrastructures.

Mandatory Elements of the ICT-Related Incident Management Process

Establishment of an End-to-End Incident Process (Art. 17(1) DORA)

Financial entities must define, establish, and operate a structured and documented incident management process enabling:

  • Early detection of ICT-related incidents
  • Effective investigation and triage
  • Timely mitigation and response
  • Correct escalation to internal leadership and relevant functions
  • Preparation for supervisory reporting under Article 19
  • Documentation of causes, impacts, and lessons learned

Requirements for Monitoring, Handling and Tracking (Art. 17(2) DORA; Art. 23 RTS RMF)

Financial entities must establish procedures to ensure:

  • Coherent and integrated monitoring across ICT domains, logs, detection tools, and operational teams
  • Full visibility of internal and external factors (logs, threat intelligence, user reports, third-party notifications)
  • Continuous tracking of all incident lifecycle stages (detection → investigation → classification → response → closure)
  • Root-cause analysis and documentation of systemic weaknesses
  • Follow-up measures to prevent recurrence and strengthen controls

All incidents and significant cyber threats must be recorded comprehensively and protected against tampering.

Required Functional Components under Article 17(3) DORA

Early-Warning Indicators (Art. 17(3)(a))

The process must incorporate:

  • Automated alerts
  • Threshold-based triggers
  • Behavioural and anomaly detection mechanisms
  • Performance degradation indicators
  • Threat intelligence signals

These provide early visibility into activities that may evolve into ICT-related incidents.

Procedures for Detection, Tracking, Logging, Categorisation, and Classification (Art. 17(3)(b))

Procedures must define:

  • Detection rules, aligned with Article 10 DORA and Article 23 RTS RMF
  • Incident logging parameters capturing time of occurrence, detection, type, and severity
  • Categorisation based on predefined taxonomies
  • Classification and prioritisation according to:
    • Severity
    • Impact
    • Service criticality
    • Criteria in Article 18(1) DORA (materiality thresholds for reporting)

Classification must directly support incident reporting triggers under Article 19 DORA.

Assignment of Roles and Responsibilities (Art. 17(3)(c) DORA; Art. 23(1) RTS RMF)

The process must clearly define:

  • Detection responsibilities (SOC, NOC, monitoring teams)
  • Incident handling and triage roles
  • Escalation paths to senior leadership
  • Crisis management function (where relevant)
  • Legal, compliance, data protection and communications roles
  • Responsibilities for third-party incident notifications

Separation of duties and independence must be preserved (aligned with Article 6(4) and internal control models).

Communication, Escalation and Notification Procedures (Art. 17(3)(d) DORA)

Procedures must include:

  • Coordination with Article 14 crisis communication plans
  • Internal notifications to staff, senior management, and relevant teams
  • Escalation paths, including handling ICT-related customer complaints
  • Notifications to affected customers, where required
  • Information sharing with counterparties where services are impacted
  • Media and external stakeholder communication rules
  • Support for supervisory notification (Article 19)

All communication flows must be documented, secure, consistent, and time-sensitive.

Management and Leadership Reporting (Art. 17(3)(e) DORA)

Serious ICT-related incidents must:

  • Be reported to senior management without delay
  • Be escalated to the management body
  • Include details on:
    • Impact assessment
    • Containment measures
    • Additional controls required
    • Follow-up actions and risks

The management body has oversight duties under Article 5(2).

Response Procedures (Art. 17(3)(f) DORA)

The incident management process must define:

  • Immediate containment actions
  • Isolation of affected systems where necessary
  • Workarounds and fallback solutions
  • Restoration of services aligned with ICT BCP and response/recovery plans
  • Verification of service integrity before returning to normal operations
  • Documentation of all actions taken

Response must ensure timely, safe and resilient resumption of services.

Integration with Detection Mechanisms (Article 10 DORA; Article 23 RTS RMF)

Incident management must be fully integrated with anomaly detection mechanisms ensuring:

  • Continuous monitoring
  • Identification of anomalous behaviour
  • Automated alerting
  • Prioritisation according to severity and service criticality
  • Logging and forensic retention
  • Triggering of incident response workflows based on criteria defined in Article 23(5):
    • Malicious activity indicators
    • Data losses
    • Transaction or operations impact
    • ICT system/network unavailability

Documentation Requirements

Entities must document:

  • The overarching incident management policy and procedures
  • The taxonomy and criteria used for categorisation and classification
  • All incidents, investigations, communications, actions, and resolutions
  • Root-cause analyses and remediation measures
  • Evidence of escalation and reporting
  • Integration with ICT BCP, response and recovery plans
  • Incident-related logs and monitoring data, protected against tampering

Documentation must enable supervisory authorities to request and review incident records at any time.

Auditability and Governance

Internal audit must assess:

  • Adequacy and effectiveness of the incident management process
  • Compliance with Articles 17, 10, and 23 DORA
  • Integration with overall ICT risk management and operational resilience
  • Correct execution of escalation, classification, and notification procedures
  • Quality of root-cause analysis and remediation
  • Reliability of incident logging and monitoring

The management body must periodically review the process pursuant to Article 5(2).

Article 17 DORA

Article 17 DORA – ICT-related incident management process

Article 23 RTS RMF

RTS RMF