DORA Regulatory Technical Standards (RTS): ICT Incident Reporting

The Digital Operational Resilience Act (DORA) represents a landmark legislative stride by the European Union to fortify the ICT security and operational resilience of the financial sector. Moving beyond high-level principles, DORA's effectiveness hinges on the granular detail provided by its Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS). These standards, jointly developed by the European Supervisory Authorities (ESAs – EBA, EIOPA, and ESMA), translate DORA's mandates into actionable requirements, particularly in critical areas such as ICT incident reporting and third-party risk management. For B2B stakeholders in the financial industry, understanding these technical standards is paramount for achieving and demonstrating compliance.

The ESAs' Mandate and the Granularization of DORA

Under DORA, the ESAs were tasked with developing a comprehensive suite of RTS and ITS across various domains, including ICT risk management, incident reporting, digital operational resilience testing, managing ICT third-party risk, and information sharing. These standards are designed to ensure a harmonized and consistent application of DORA across all financial entities and member states, fostering a level playing field and reducing regulatory arbitrage.

The final draft RTS and ITS, submitted to the European Commission in January 2024, provide the concrete specifications for financial entities to build robust digital operational resilience frameworks. Our focus here will be on two critical aspects: the detailed criteria for classifying ICT-related incidents for reporting purposes, including their timelines, and the standardized approach to managing information on ICT third-party providers.

Operational Incident Classification Criteria Under the Final ESAs Draft

DORA mandates financial entities to establish and maintain a robust ICT-related incident management process, including the capability to classify, report, and analyze such incidents. The ESAs' final draft RTS on ICT incident reporting (mandated by Article 18(3) of DORA) provides the precise criteria for classifying a major ICT-related incident, triggering mandatory reporting obligations to competent authorities.

The classification framework is designed to ensure that only incidents reaching a certain severity threshold are reported, allowing supervisors to focus on events with significant impact while enabling financial entities to manage less severe incidents internally. The RTS outlines a multi-dimensional approach to assess the severity of an ICT-related incident, considering its impact on:

1. Critical Services and Functions: The extent to which critical functions (as defined under DORA, e.g., payment services, trading, customer account management) are disrupted, degraded, or compromised. This includes assessing the number of affected critical services and the dependency on the compromised ICT systems.
2. Number and Type of Users Affected: The number of internal and external users (customers, counterparties) impacted, with a higher severity attributed to incidents affecting a large customer base or critical internal staff. Specific thresholds are set for quantitative assessment.
3. Data Loss or Corruption: The extent of data compromise, including loss of confidentiality, integrity, or availability of data. Special emphasis is placed on sensitive data (e.g., personal data, proprietary information) and the volume of data affected.
4. Financial Impact: Direct and indirect financial losses incurred by the entity and its clients, including operational losses, fraud, and costs associated with recovery and remediation.
5. Reputational Impact: The potential for significant negative public perception, media attention, or loss of customer trust.
6. Duration and Recovery Time: The actual or estimated duration of the incident and the time needed to fully restore affected services and data. Prolonged disruptions or complex recovery efforts elevate severity.
7. Geographical Spread: Incidents affecting multiple jurisdictions or having a cross-border impact are typically classified as more severe due to their wider implications.
8. ICT Third-Party Involvement: Incidents originating from or significantly impacted by an ICT third-party provider often carry increased severity due to potential systemic risk and cascading effects across the financial sector.

Financial entities must implement a structured internal process to classify incidents against these criteria, ensuring timely and accurate assessment. This process should be dynamic, allowing for reclassification if the incident's impact or scope evolves.

Reporting Timelines for ICT Incidents

Once an ICT-related incident is classified as "major" according to the ESAs' criteria, financial entities are subject to strict reporting timelines to their respective competent authorities. The ESAs' RTS specifies a phased reporting approach to ensure supervisors receive critical information promptly while allowing entities to focus on incident resolution.

The reporting phases are:

1. Initial Notification:

   • Timeline: Without undue delay, and no later than 4 hours after the ICT-related incident is classified as major.
   • Content: This first report should contain high-level information necessary for supervisors to understand the nature and potential impact of the incident. This includes the date and time of discovery, the estimated start time of the incident, a brief description of the incident, its classification as major, the services affected, and an initial assessment of its impact on critical functions, clients, and financial stability. It should also indicate if an ICT third-party provider is involved.

2. Intermediate Report:

   • Timeline: No later than 72 hours after the ICT-related incident is classified as major.
   • Content: This report provides an update on the incident's status, including more detailed information on its root cause (if identified or initial assessment thereof), the impact assessment (e.g., number of affected customers, estimated financial losses), mitigation measures taken, and preliminary recovery actions. It should also update on any third-party involvement and estimated recovery timelines.

3. Final Report:

   • Timeline: No later than one month after the ICT-related incident is resolved and its impact fully contained. Competent authorities may grant extensions upon reasoned request.
   • Content: This comprehensive report details the incident from its detection to resolution. It includes a complete root cause analysis, a full impact assessment, a description of all remediation actions taken, the total number of affected customers, total financial losses, lessons learned, and any actions planned to prevent recurrence. If an ICT third-party was involved, the report must detail their role and any subsequent measures taken regarding the contractual arrangement.

In addition to these mandated reports, financial entities must proactively submit updates to their competent authorities if there are significant changes in the incident's status, impact, or remediation efforts.

Harmonized Templates for ICT Third-Party Registers of Information

DORA introduces a robust framework for managing ICT third-party risk, recognizing the systemic implications of over-reliance on a few critical providers. Article 28(10) mandates financial entities to maintain a register of information in relation to all contractual arrangements for the use of ICT services provided by ICT third-party providers.

The ESAs' final draft ITS on the register of information (mandated by Article 28(10) of DORA) specifies harmonized templates for these registers. The objective is to standardize the data collected, facilitating supervisory oversight, identifying potential concentrations of risk, and supporting the DORA oversight framework for critical ICT third-party providers.

The harmonized templates require financial entities to capture comprehensive information, including but not limited to:

• Identification Details: Legal name, LEI, country of establishment of the ICT third-party provider and the financial entity.
• Service Description: A clear description of the ICT service provided, including the specific functions supported and whether they are critical or important.
• Contractual Details: Start date, review dates, and termination clauses of the contractual arrangement.
• Location of Data/Service: The geographical location(s) where the ICT service is provided and where data is processed/stored.
• Criticality Assessment: Internal assessment of the criticality or importance of the ICT service to the financial entity's operations.
• Sub-contracting: Information on any sub-contracting arrangements involving critical or important ICT functions.
• Exit Strategy: Details of the exit strategy for the ICT service, including transition plans and data portability.
• Interdependencies: Identification of interdependencies with other ICT third-party providers or critical functions.

Maintaining an accurate and up-to-date register is not merely a compliance exercise; it is a critical tool for effective ICT third-party risk management, enabling financial entities to assess their exposure, conduct due diligence, and implement appropriate risk mitigation strategies. The harmonized templates ensure that supervisors receive consistent and comparable data across the EU financial sector.

ICT Incident Reporting: Classification Fields and Timelines Summary

The following table summarizes the key aspects of ICT incident reporting under DORA RTS, focusing on the classification fields and mandatory timelines:

| Reporting Stage | Timeline (from classification as "major") | Key Information & Classification Fields W |

JSON Template for Standardized DORA Incident Report Payload

The ESAs' RTS aims to standardize the information to be reported. Below is a conceptual JSON payload template for a DORA ICT incident report, reflecting the level of detail and structure envisioned by the technical standards. This structure enables both initial and subsequent reports to provide an evolving picture of the incident.

{
  "reportId": "FE-INC-20250315-001",
  "reportingEntity": {
    "name": "Financial Institution A GmbH",
    "lei": "XXXXXXXXXXXXX0000000000",
    "contactPerson": {
      "name": "Jane Doe",
      "email": "jane.doe@fina.com",
      "phone": "+49 123 4567890"
    }
  },
  "incidentType": "Major ICT Incident",
  "reportType": "Initial Notification",
  "submissionTimestamp": "2025-03-15T10:30:00Z",
  "incidentDetails": {
    "incidentIdentifier": "INC-PROD-OPS-2025-007",
    "detectionTimestamp": "2025-03-15T06:00:00Z",
    "startTimestamp": "2025-03-15T05:30:00Z",
    "endTimestamp": null,
    "incidentStatus": "Ongoing",
    "incidentCategory": "System Failure",
    "briefDescription": "Unauthorized access detected on production database, leading to service degradation for online banking.",
    "affectedICTServices": [
      {
        "serviceName": "Online Banking Platform",
        "serviceID": "SVC-OBP-001",
        "criticality": "Critical",
        "impactSeverity": "High",
        "descriptionOfImpact": "Customers unable to log in or perform transactions. Degradation of API response times."
      },
      {
        "serviceName": "Mobile Banking App",
        "serviceID": "SVC-MBA-002",
        "criticality": "Critical",
        "impactSeverity": "Medium",
        "descriptionOfImpact": "Intermittent connectivity issues and slow transaction processing."
      }
    ],
    "impactMetrics": {
      "affectedCriticalFunctions": ["Retail Banking", "Payment Processing"],
      "estimatedAffectedUsers": 50000,
      "estimatedFinancialImpactEUR": null,
      "dataCompromise": {
        "status": "Under Investigation",
        "dataType": ["Customer Login Credentials", "Transaction History"],
        "estimatedVolumeGB": null,
        "sensitivity": "High"
      },
      "reputationalImpact": "Potential High - Public disclosure likely if prolonged."
    },
    "ictThirdPartyInvolvement": {
      "involved": true,
      "providerName": "CloudHost Solutions Inc.",
      "providerLEI": "XXXXXXXXXXXXX1111111111",
      "serviceProvided": "Database Hosting and Management",
      "impactOnProviderServices": "Service degradation for other clients hosted on same infrastructure sector.",
      "contractualReference": "CLS-DBHOST-2023-01"
    },
    "geographicScope": ["Germany", "Austria"],
    "rootCauseAnalysisStatus": "Initial investigation points to a zero-day vulnerability in database software.",
    "remediationActionsTaken": [
      "Isolation of affected database servers.",
      "Implementation of temporary firewall rules.",
      "Initiation of forensics investigation.",
      "Communication with ICT third-party provider for immediate patch deployment."
    ],
    "recoveryStatus": "Partial service restoration in progress, full recovery estimated within 24-48 hours.",
    "lessonsLearned": null,
    "nextSteps": [
      "Continue forensic analysis.",
      "Monitor system health.",
      "Prepare intermediate report."
    ]
  }
}

Note: The specific field names and exact enumerations (e.g., incidentCategory, impactSeverity) may be further refined in the final published ITS. This template serves as a robust example reflecting the anticipated data requirements.

Implementation Guide for Financial Entities

Compliance with DORA's RTS and ITS on ICT incident reporting and third-party registers demands a proactive and integrated approach. Financial entities should consider the following implementation steps:

1. Review and Update ICT Risk Management Frameworks: Align existing ICT risk management policies, procedures, and controls with the granular requirements specified in DORA's RTS. This includes establishing clear roles and responsibilities for incident management and third-party risk.
2. Develop Robust Incident Response Plans (IRP) and Playbooks: Create or refine detailed IRPs that specifically incorporate the DORA incident classification criteria and reporting timelines. Develop playbooks for various incident scenarios to ensure a swift, consistent, and compliant response.
3. Invest in Monitoring and Detection Capabilities: Enhance ICT monitoring tools to rapidly detect and identify potential ICT-related incidents, supporting timely classification and reporting.
4. Establish Data Collection and Reporting Mechanisms: Implement systems and processes capable of collecting all required information for the ICT incident reports (initial, intermediate, final) and populating the harmonized templates for the ICT third-party register. Consider automation where feasible to ensure accuracy and timeliness.
5. Conduct Regular Testing and Training: Periodically test incident response plans through scenario-based exercises and penetration testing. Provide comprehensive training to all relevant staff, including IT, risk, compliance, and senior management, on DORA requirements, incident classification, and reporting procedures.
6. Enhance Third-Party Risk Management Programs: Integrate the harmonized register of information requirements into existing third-party risk management frameworks. Ensure contractual arrangements with ICT third-party providers include clauses aligned with DORA, particularly regarding incident notification and information sharing.
7. Foster a Culture of Resilience: Promote awareness of digital operational resilience across the organization. Encourage open communication and collaboration between business units, IT, and risk functions.
8. Engage with Competent Authorities: Maintain open lines of communication with relevant competent authorities to clarify interpretation of the RTS/ITS and understand specific supervisory expectations.

Conclusion

The DORA Regulatory and Implementing Technical Standards are the bedrock upon which the EU's digital operational resilience framework will be built. For financial entities, these detailed specifications are not merely regulatory hurdles but an opportunity to significantly enhance their ICT security posture and operational resilience. By meticulously implementing the incident classification criteria, adhering to stringent reporting timelines, and maintaining comprehensive ICT third-party registers, financial institutions can not only achieve DORA compliance but also strengthen their ability to withstand, respond to, and recover from ICT-related disruptions, ultimately contributing to the stability and integrity of the wider financial system. Proactive engagement with these standards, thorough preparation, and continuous refinement of internal processes will be key to navigating the new compliance landscape effectively.