Incident management is a critical pillar of DORA compliance. Financial institutions must establish robust procedures for detecting, classifying, and reporting ICT incidents.

DORA Incident Definition

An ICT incident is an event that has an actual adverse impact on the confidentiality, integrity, or availability (CIA) of ICT systems or data. Note: Unsuccessful or near-miss events are not incidents unless they have impact.

Key Characteristics of Reportable Incidents

  • Actual adverse impact (not potential)
  • Impact on ICT systems or data
  • Affects confidentiality, integrity, or availability
  • Impacts business continuity
  • Affects customer service delivery

Incident Severity Classification

Tier 1: Major Incidents (Must Report)

Major incidents require notification to supervisors within 72 hours.

Financial Impact Thresholds:

  • Direct financial loss exceeding €10,000
  • Customer funds potentially at risk
  • Regulatory fines or penalties
  • Significant reputational damage

Operational Impact Thresholds:

  • Unavailability of critical service > 15 minutes
  • Service degradation > 30% for > 30 minutes
  • Affecting > 1,000 customers
  • Unable to execute critical transactions

Data Impact Thresholds:

  • Breach of > 1,000 customer records
  • Unauthorized disclosure of sensitive data
  • Exposure of authentication credentials
  • Compromise of security controls

Tier 2: Significant Incidents (Document & Report)

Incidents with measurable impact but below major thresholds. Should be documented and reported periodically.

Tier 3: Minor Incidents (Log Only)

Low-impact incidents that don't meet reporting thresholds. Must still be logged for trend analysis.

Incident Classification Framework

Impact Dimensions

Confidentiality Incidents

  • Unauthorized Disclosure: Data access by unauthorized parties
  • Data Breach: Unauthorized transfer of data
  • Information Leakage: Unintended exposure of sensitive information

Integrity Incidents

  • Data Corruption: Unintended modification of data
  • Malicious Modification: Deliberate tampering with data
  • System Manipulation: Unauthorized system configuration changes

Availability Incidents

  • System Outages: Unavailability of critical systems
  • Service Degradation: Reduced performance or functionality
  • Denial of Service: Attacks preventing legitimate access

Incident Type Classification

Incident Type Definition Examples
Malware Infection Systems compromised by malicious software Ransomware, trojans, worms
Exploitation Attacks System vulnerabilities deliberately exploited SQL injection, buffer overflow
Cyber Attacks Deliberate attacks on ICT systems DDoS, hacking, credential theft
Data Breaches Unauthorized access to sensitive data Customer data theft, breach disclosure
System Failures Hardware or software malfunction Disk failure, application crash
Process Failures Failure of operational processes Misconfiguration, human error
Network Issues Network connectivity problems Connectivity loss, bandwidth exhaustion
Third-Party Incidents Issues caused by external service providers Cloud provider outage, vendor breach

Incident Reporting Procedures

Step 1: Incident Detection (0 hours)

  • Monitoring systems alert on anomalies
  • Staff report suspicious activities
  • Customer complaints indicate issues
  • Formal incident response activated

Step 2: Initial Assessment (< 6 hours)

  • Determine if event is actual incident
  • Assess initial impact scope
  • Classify severity level
  • Determine if major incident threshold met

Step 3: Early Notification (if Major)

  • Timeline: As soon as possible, within 72 hours
  • To: Competent authority and supervisory authority
  • Content: Basic facts and initial assessment
  • Format: Use EBA template

Step 4: Detailed Investigation (hours to days)

  • Root cause analysis
  • Impact assessment (financial, operational, reputational)
  • Affected parties identification
  • Scope confirmation

Step 5: Comprehensive Report (72 hours or sooner)

  • Detailed incident description
  • Complete impact quantification
  • Remediation measures
  • Future prevention steps

Step 6: Ongoing Communication

  • Regular updates to authorities
  • Final comprehensive report
  • Lessons learned documentation
  • Monitoring for related incidents

Reporting to Authorities

Who Must Be Notified

Banking Sector

  • Competent Authority: National banking supervisor (e.g., ECB, BaFin)
  • Supervisory Authority: Often same as competent authority
  • ESAs: European Banking Authority in some cases

Insurance Sector

  • Competent Authority: National insurance regulator
  • EIOPA: European Insurance and Occupational Pensions Authority

Documentation Requirements

For all incidents (major or not), maintain records of:

  • Incident detection method and timing
  • Initial classification and severity
  • Actions taken during response
  • Timeline of key events
  • Root cause findings
  • Impact on business operations
  • Notification dates and recipients
  • Remediation measures implemented
  • Lessons learned and improvements

Best Practices for Incident Management

Governance

  • Clear incident response policy
  • Defined roles and responsibilities
  • Regular training and awareness
  • Board-level oversight

Detection

  • 24/7 monitoring capabilities
  • Automated alerting systems
  • Security information and event management (SIEM)
  • Threat intelligence integration

Response

  • Documented playbooks for incident types
  • Incident response team trained and ready
  • Regular drills and simulations
  • Clear communication procedures

Recovery

  • Business continuity procedures
  • Tested backup and recovery systems
  • Vendor coordination procedures
  • Customer communication templates

Common Incident Reporting Mistakes

  • ❌ Delaying notification waiting for complete information
  • ❌ Underreporting impact to avoid scrutiny
  • ❌ Poor documentation of incident details
  • ❌ Inconsistent incident classification
  • ❌ Not involving legal/compliance early
  • ❌ Insufficient root cause analysis
  • ❌ No follow-up on remediation measures