Module 5: ICT Incident Management, Classification and Reporting

Step 1 – Positioning DORA ICT Incident Management (2025 context)

Where does incident management fit in DORA?

The Digital Operational Resilience Act (DORA) is fully applicable in the EU from 17 January 2025 (i.e., earlier this year relative to today). Its ICT incident rules are now live obligations, not future requirements.

In the DORA structure, ICT incident management is mainly governed by:

• Articles 17–23 – ICT-related incident management, classification and reporting
• Annex I – Criteria for classifying major ICT-related incidents and significant cyber threats
• Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) adopted by the ESAs (EBA, ESMA, EIOPA) – these specify:
• Incident classification thresholds and scoring methodology
• Reporting templates, channels and timelines

You should connect this module to:

• Module 3 (Regulatory Landscape) – DORA vs. GDPR, NIS2, PSD2, sectoral rules
• Module 4 (Governance & ICT Risk Framework) – management body’s accountability and integration of incident management into the ICT risk management framework

Key high‑level ideas

1. Every ICT incident must be managed; only some must be reported as major incidents.
2. DORA seeks harmonised, EU‑wide incident classification and reporting for financial entities.
3. DORA does not replace GDPR or NIS2; instead, it adds a financial‑sector‑specific layer.
4. Incident management is not just technical response; it includes governance, documentation, communication, and learning.

> Challenge mindset: Throughout this module, always ask: “Would this process withstand scrutiny from a competent authority after a major incident?”

Step 2 – Defining ICT‑related Incidents and Major Incidents

2.1 Core DORA definitions (simplified)

DORA differentiates between ICT‑related incidents, major ICT‑related incidents, and significant cyber threats.

From DORA (paraphrased to keep it digestible):

• ICT‑related incident

Any single event or series of linked events compromising the availability, authenticity, integrity or confidentiality of data, or of ICT services, and which adversely affects the availability, authenticity, integrity or confidentiality of services provided by the financial entity.

• Major ICT‑related incident

An ICT‑related incident that has a high adverse impact on the network and information systems that support the provision of financial services.

• Significant cyber threat

A cyber threat that could have the potential to result in a major ICT‑related incident if materialised.

2.2 Practical distinctions

Think of a spectrum:

• Low‑impact incident – short internal system glitch, no client impact, quickly resolved
• Medium incident – affects some customers, limited duration or scope
• Major ICT‑related incident – crosses quantitative or qualitative thresholds defined in RTS/ITS (e.g., number of clients affected, duration, data loss, economic impact, critical services disrupted)

2.3 Why the definition matters

The definition determines:

• Which events must be logged internally
• Which must be escalated to management and the board
• Which must be reported to competent authorities (and possibly to customers and partners)

Your incident management process must:

1. Capture all ICT‑related incidents (broad net)
2. Filter and classify them against DORA criteria to identify major incidents and significant cyber threats

> Thought prompt: How would you draw the line between a “large but routine” outage and a major incident under DORA? What extra data would you need to decide?

Step 3 – The ICT Incident Lifecycle under DORA

3.1 Standard lifecycle (aligned with DORA expectations)

DORA does not prescribe a single lifecycle diagram, but it implicitly expects a mature, structured process. A robust lifecycle typically includes:

1. Detection & Reporting

• Monitoring, alerts, user reports, third‑party notifications
• Initial logging and first categorisation as ICT‑related incident or cyber threat

1. Triage & Initial Classification

• Assess scope, impact, affected services, data, geographies
• Decide if it is suspected major and trigger enhanced procedures

1. Containment

• Short‑term: isolate affected systems, block malicious traffic, disable compromised accounts
• Long‑term: more durable measures that minimise business disruption

1. Eradication

• Remove malware, close exploited vulnerabilities, clean affected systems

1. Recovery

• Restore systems and data from backups, verify integrity
• Gradually return services to normal operations

1. Post‑incident Review (PIR)

• Root cause analysis (technical + organisational)
• Lessons learned, control enhancements, update of risk assessments
• Management body oversight and approval of remediation plan

1. Documentation & Reporting

• Internal documentation (incident record, timeline, decisions)
• External reporting: DORA, GDPR, NIS2, sectoral rules
• Client and partner communication

3.2 DORA’s expectations around the lifecycle

DORA expects:

• A documented incident management process integrated in the ICT risk management framework
• Roles and responsibilities defined (1st line, 2nd line, 3rd line, management body)
• 24/7 capability or equivalent for detection and timely response, proportionate to the entity’s size and risk
• Testing and exercising of incident response (e.g., crisis simulations, cyber range exercises)

> Visual description: Imagine a circular diagram where each phase (Detection → Triage → Containment → Eradication → Recovery → PIR → Documentation) forms a loop. The PIR feeds back into risk management and controls, closing the learning cycle.

Step 4 – Applying the Lifecycle: A Ransomware Scenario

Scenario: Ransomware in a mid‑size EU bank (2025)

A mid‑size EU bank experiences a ransomware attack on its online banking platform. Let’s walk through the lifecycle with a DORA lens.

1. Detection & Reporting

• Monitoring detects unusual encryption activity and file renaming on application servers.
• Customers begin reporting that they cannot access online banking.
• Security Operations Centre (SOC) opens an incident ticket and flags it as high severity.

1. Triage & Initial Classification

• Online banking is a critical service under the bank’s DORA mapping.
• Outage affects >60% of active customers and is expected to last several hours.
• Early estimate suggests possible data exfiltration.
• Based on DORA RTS thresholds (e.g., % of customers affected, service downtime, data breach potential), the incident is classified as “suspected major ICT‑related incident”.

1. Containment

• Bank isolates infected servers from the network.
• Disables affected user accounts and admin credentials.
• Temporarily shuts down online banking front‑end to prevent further spread.

1. Eradication

• Forensic team identifies the initial infection vector (phishing email to admin with VPN access).
• Malware is removed, compromised accounts are reset, vulnerable remote access configuration is hardened.

1. Recovery

• Systems restored from clean backups.
• Integrity of transactional data is cross‑checked against core banking records.
• Online banking is gradually brought back, region by region, with enhanced monitoring.

1. Post‑incident Review

• Root cause: inadequate MFA enforcement on certain admin accounts, weak phishing awareness.
• Remediation: enforce MFA everywhere, accelerate privileged access management project, update phishing training.
• Board is briefed; risk appetite and controls for remote access are revisited.

1. Documentation & Reporting

• The bank concludes that DORA major incident thresholds are clearly met.
• It triggers DORA incident reporting (see Step 7 for timelines) and, because personal data is likely affected, GDPR breach notification.
• It also checks NIS2 applicability (if designated as an essential/important entity under national transposition) and any central bank or sectoral incident reporting obligations.
• Customers are informed via email, website banner, and mobile app notifications with plain‑language explanations and recommended protective steps.

> Reflection: In this scenario, which single factor most strongly drives the classification as major? Is it the number of customers, duration, data breach risk, or critical service? How might this change if the incident affected only internal HR systems?

Step 5 – DORA Classification Criteria and Thresholds

5.1 Core classification dimensions

DORA’s RTS on incident classification (adopted by the ESAs and in force in 2025) define criteria and scoring to decide whether an incident is major. While exact scoring tables are technical and detailed, the key dimensions are:

1. Number and type of clients affected

• Absolute number and proportion of total clients
• Whether retail, SME, corporate, or institutional clients are impacted

1. Service criticality and duration

• Whether the service is classified as critical or important under DORA
• Duration of the disruption (e.g., <1h, 1–4h, >4h, >1 day, etc.)

1. Geographical spread

• Number of Member States affected

1. Data impact

• Loss, theft, corruption, or unauthorised access to data, especially personal data or sensitive financial data

1. Economic impact

• Estimated direct and indirect financial losses (including fraud, remediation, compensation)

1. Reputational and systemic impact

• Intense media coverage, loss of market confidence, contagion risk to other financial entities

5.2 Scoring and thresholds (conceptual view)

The RTS typically work as follows (conceptual, not exact numbers):

• Each dimension is assigned a score based on defined bands (e.g., 0–3).
• Some dimensions may be mandatory triggers (e.g., any incident causing unavailability of a critical service above a given duration may automatically be considered major).
• A total score threshold or combination of conditions determines whether the incident is classified as major.

5.3 Internal implementation

A compliant financial entity in 2025 should:

• Translate the RTS into an internal incident classification matrix (often embedded in ticketing/SIEM tools).
• Ensure front‑line staff can quickly perform initial scoring, with second‑line risk/ICT security validating.
• Maintain evidence of classification decisions (why an incident was or was not deemed major).

> Edge case: Suppose a short‑lived outage (20 minutes) affects 100% of card payments in three Member States on a Saturday afternoon. The duration is small, but the criticality and systemic impact may still push it into major incident territory. Classification is rarely purely mechanical.

Step 6 – Classify Three Borderline Incidents

Read each mini‑scenario and decide whether it is likely to be a major ICT‑related incident under DORA. Justify your reasoning mentally or in writing.

Scenario A – Short‑term mobile app outage

A bank’s mobile app is unavailable for 45 minutes on a weekday morning due to a misconfigured deployment. Approx. 10% of active users attempt to log in during that period and fail. No data loss occurs; web banking and card payments work normally.

• Would you classify this as major? Why or why not?
• Which dimensions (duration, % of clients, criticality) are most relevant?

---

Scenario B – Limited but sensitive data leak

A small investment firm discovers that, due to a misconfigured S3 bucket, detailed portfolio statements (including names, holdings, and account numbers) of 200 high‑net‑worth clients were publicly accessible for 3 days. There is no evidence of mass downloading, but logs show at least two unknown IP addresses accessed the files.

• Does this qualify as major under DORA?
• How do data sensitivity, client profile, and reputational impact influence your decision, even if the absolute number of clients is modest?

---

Scenario C – Third‑party service disruption

A cloud‑based CRM provider used by a large insurer suffers an outage, making customer service agents unable to access policies or update claims for 6 hours. The insurer’s core policy administration system is unaffected, and customers can still file claims online, but follow‑up is delayed.

• How would you assess service criticality and impact on clients?
• Does the fact that this is a third‑party failure change your DORA obligations?

> Hint: Under DORA, outsourcing or using ICT third‑party providers does not transfer responsibility. The financial entity remains fully responsible for incident management and reporting.

Step 7 – DORA Incident Reporting Timelines and Content

7.1 Who must report and to whom?

Under DORA (as applicable in 2025):

• Financial entities (banks, payment institutions, investment firms, insurers, etc.) must report major ICT‑related incidents to their competent authority (e.g., national supervisory authority, central bank, or EU authority depending on the entity).
• In some cases, incidents may be centralised via a single EU hub (as specified in ITS) but supervised at national level.

ICT third‑party service providers do not report directly under DORA; instead, they must support the financial entity’s reporting.

7.2 Reporting phases and indicative timelines

The ITS specify a three‑stage reporting process for major incidents (exact hours may vary slightly by final national implementation, but conceptually):

1. Initial Notification – very soon after classification as major

• Often within hours of identifying the incident as major (e.g., 4 hours, or by end of next business day if discovered late).
• Contains basic facts: type of incident, affected services, initial impact assessment, immediate measures taken.

1. Intermediate / Update Reports – while incident is ongoing

• Provided at key milestones (e.g., significant change in impact, containment achieved, partial recovery).
• Update on root cause hypotheses, impact evolution, remediation steps.

1. Final Report – after resolution and analysis

• Submitted within a defined period after recovery (e.g., 20 business days after resolution, depending on ITS).
• Includes root cause, detailed timeline, final impact, measures taken to prevent recurrence.

7.3 Mandatory content elements (high‑level)

Reports must generally cover:

• Identification: entity, group, contact person, supervisory references
• Incident description: type (e.g., cyberattack, system failure), detection method, timeline
• Impact: affected services, clients, geographies, data, financial loss, operational impact
• Root cause (or hypotheses): technical and organisational
• Measures: containment, eradication, recovery, communication to clients/partners
• Lessons learned and remediation: control enhancements, governance changes

7.4 Client and partner communication

DORA expects financial entities to:

• Communicate promptly and in clear language with clients if the incident has or may have an impact on their financial interests.
• Avoid disclosing sensitive security information that could be exploited.
• Coordinate messaging across DORA, GDPR, NIS2 obligations to avoid inconsistent statements.

> Advanced consideration: Poorly handled client communication can transform a medium‑impact incident into a reputational crisis, which may retroactively influence how supervisors view your incident classification and governance maturity.

Step 8 – Quick Check: DORA Reporting Logic

Answer this question to test your understanding of DORA reporting triggers.

Step 9 – Coordinating DORA with GDPR, NIS2 and Other Regimes

9.1 Multiple regimes, overlapping incidents

In 2025, a single ICT incident in a financial entity can trigger three or more distinct reporting duties:

1. DORA – for major ICT‑related incidents and possibly significant cyber threats
2. GDPR – for personal data breaches (to supervisory authority within 72 hours of becoming aware, and to data subjects when high risk to rights and freedoms)
3. NIS2 – for incidents affecting entities designated as essential or important (e.g., some banks, market infrastructures), with early warning, incident notification and final report timelines
4. Sectoral / national rules – e.g., ECB/SSM, national central banks, payment system operators, card schemes

9.2 Practical coordination strategies

A mature organisation should:

• Implement a single integrated incident intake and assessment process that checks all regimes simultaneously (DORA, GDPR, NIS2, PSD2, etc.).
• Maintain a regulatory notification matrix summarising:
• Trigger conditions (e.g., data breach vs. service outage)
• Deadlines (hours/days)
• Recipients (DPA, NCA, CSIRT, central bank, etc.)
• Required content and templates
• Use one master timeline of the incident, re‑used across all reports (adapted to each regime’s focus).
• Coordinate with DPO, CISO, legal/compliance, and business owners to avoid contradictions.

9.3 Edge cases and conflicts

• Data breach without service disruption:
• Likely GDPR notification; may or may not be a DORA major incident, depending on scope and sensitivity.

• Service outage without data breach:
• May be DORA major (e.g., payment outage), but not a GDPR breach.

• Cross‑border incident:
• DORA reporting to home competent authority, GDPR to lead supervisory authority (if one‑stop‑shop applies), NIS2 to national CSIRT/competent authority where the entity is registered.

> Analytical question: How would you design a decision tree that, starting from a generic incident, guides the team through: “DORA major?” → “GDPR breach?” → “NIS2 incident?”? What information must be collected in the first 1–2 hours to feed this tree?

Step 10 – Design a DORA-Compliant Incident Process (Thought Exercise)

Imagine you are advising a large EU payment institution in late 2025. They already have a generic incident response plan but have not yet fully aligned it with DORA.

Outline, in bullet points, how you would adapt their process to ensure DORA compliance and alignment with GDPR/NIS2. Consider:

1. Governance & roles

• Who owns incident classification?
• How is the management body involved in major incidents?

1. Detection & logging

• How do you ensure all ICT-related incidents are logged in a central system?

1. Classification logic

• How will you embed the RTS thresholds (e.g., in a scoring sheet or tool)?
• How do you document why an incident is or is not major?

1. Reporting workflows

• How do you trigger DORA initial notification?
• How do you synchronise with GDPR (DPO) and NIS2 (if applicable)?

1. Client communication

• Who approves wording?
• How do you ensure consistency across email, app, website, and media?

1. Post‑incident review

• How do you formalise PIRs and ensure lessons learned feed into the ICT risk management framework?

> Activity: Draft a one‑page flow (on paper or a whiteboard) with swimlanes for IT/SOC, Risk/Compliance, DPO, and Management, showing how a suspected major incident flows from detection to final reporting and remediation under DORA.

Step 11 – Key Term Flashcards

Use these flashcards to reinforce core DORA incident management terminology.

Step 12 – Final Concept Integration Quiz

Test your integrated understanding of DORA incident management, classification, and reporting.