How to implement DORA incident reporting using AI

Overview

You'll learn how to implement DORA's ICT-related incident reporting requirements under Articles 17-23 using AI. This guide covers incident classification criteria, the mandatory 4-hour/72-hour/1-month reporting timelines, notification templates, root cause analysis procedures, and integration with your existing incident management processes, with specific ISMS Copilot prompts for generating each component.

Who this is for

This guide is for:

• Incident response managers and SOC leaders responsible for ICT incident detection and classification

• Compliance officers managing regulatory incident notifications

• CISOs overseeing incident management programs at financial entities

• Risk managers assessing incident impact and tracking remediation

• Consultants implementing DORA incident reporting for financial entity clients

Before you begin

You will need:

• An ISMS Copilot account (free trial available)

• Your ICT risk management framework established per How to build a DORA ICT risk management framework using AI

• Your ICT asset inventory with criticality classifications (needed for incident impact assessment)

• Your existing incident response procedures and any current regulatory reporting processes

• Understanding of your competent authority's reporting channels and formats

• Access to your incident response team, SOC, and compliance function

Understanding DORA's incident reporting requirements

Article-by-article breakdown

DORA Chapter III (Articles 17-23) establishes a comprehensive incident management and reporting regime. Each article addresses a specific aspect of the process:

Article

Title

Key requirements

Key deliverables

Art 17

ICT-related incident management process

Establish incident management process with early warning indicators, procedures, and roles

Incident management process document, roles matrix

Art 18

Classification of ICT-related incidents and cyber threats

Classify incidents using prescribed criteria (major vs non-major)

Classification matrix, severity criteria, decision flowchart

Art 19

Reporting of major ICT-related incidents

Three-stage reporting: initial (4h), intermediate (72h), final (1 month)

Report templates, escalation procedures, submission workflows

Art 20

Harmonisation of reporting content and templates

Standardized report formats per RTS

Completed report templates aligned with RTS formats

Art 21

Centralisation of reporting

Reporting through single EU Hub (future requirement)

Reporting channel procedures

Art 22

Supervisory feedback

Receive and act on supervisory feedback

Feedback integration process

Art 23

Notification of significant cyber threats

Voluntary notification of significant cyber threats

Threat notification procedures

The three-stage reporting timeline

Understanding DORA's reporting timeline is critical for building your procedures:

Report stage

Deadline

Trigger

Content required

Key challenge

Initial notification

Within 4 hours of classifying as major

Incident classified as major

Incident summary, classification rationale, initial impact assessment, affected services

Speed of classification and submission

Intermediate report

Within 72 hours of initial notification

Ongoing investigation

Updated impact, root cause analysis (initial), containment measures, recovery status

Providing meaningful analysis while incident may be ongoing

Final report

Within 1 month of initial notification

Incident resolution

Complete root cause, total impact (financial, operational, reputational), remediation actions, lessons learned

Comprehensive analysis and remediation evidence

Step 1: Establish your incident management process (Article 17)

Core incident management process

Article 17 requires a comprehensive ICT-related incident management process. This process must be integrated with your detection capabilities (Article 10) and your broader ICT risk management framework.

1. Open your DORA workspace in ISMS Copilot

2. Generate the incident management process:

   "Create a comprehensive ICT-related incident management process for a [entity type] satisfying DORA Article 17. Include: purpose, scope, and process objectives, incident lifecycle phases (detection, triage, classification, containment, eradication, recovery, post-incident review), roles and responsibilities (incident commander, technical lead, communications lead, compliance/regulatory reporting, management body liaison), early warning indicators and detection triggers (linking to Article 10 monitoring), escalation matrix by incident severity, communication protocols (internal teams, management body, clients, competent authority), integration with existing IT service management (ITSM) processes, documentation and evidence preservation requirements, process activation criteria and decision trees, and process performance metrics. Provide the process in flowchart-ready format with clear decision points."

3. Define the incident response team structure:

   "Define the ICT incident response team (IRT) structure for a [entity type] with [number] employees. Include: team composition (core team, extended team, on-call roster), team leader selection criteria and authority levels, activation procedures (business hours and after hours), communication channels and tools, team member contact directory template, training and exercise requirements, and integration with external parties (regulators, law enforcement, forensic providers, third-party ICT providers). Address 24/7 coverage requirements for meeting the 4-hour notification deadline."

Step 2: Build your incident classification matrix (Article 18)

Major incident classification criteria

Article 18 establishes criteria for classifying ICT-related incidents as major. The Regulatory Technical Standards (RTS) provide detailed materiality thresholds. Your classification matrix must operationalize these criteria for rapid decision-making during an incident.

1. Generate the classification matrix:

   "Create an ICT-related incident classification matrix for a [entity type] that satisfies DORA Article 18. Include the following classification criteria from the regulation and RTS: number of clients/financial counterparties affected (provide specific thresholds for our entity type), duration of the incident, geographical spread of the incident, data losses (confidentiality, integrity, availability), criticality of services affected (mapped to our ICT asset classification), economic impact (direct and indirect financial losses), reputational impact assessment. For each criterion, define: specific quantitative thresholds that trigger 'major' classification, measurement methodology, data sources for rapid assessment, and examples. Create a scoring matrix that allows classification within 1-2 hours of incident detection. Include a decision flowchart: if any single criterion meets the major threshold, the incident is classified as major."

2. Create the classification decision flowchart:

   "Design a step-by-step incident classification decision flowchart for DORA Article 18. The flowchart should be usable by on-call incident managers at 3 AM with limited information. Start with: initial incident details (what happened, when, what is affected). Then assess each major incident criterion sequentially: clients affected (threshold: [X]), duration (threshold: [X] hours), data impact (any confirmed data breach), critical services affected (any service on our critical list), economic impact (estimated above [X] EUR). If any criterion is met, classify as MAJOR and trigger 4-hour reporting. If borderline, escalate to [role] for classification decision. If no criteria met, classify as non-major and follow standard incident process. Provide guidance for situations with incomplete information."

Non-major incident tracking

While only major incidents require regulatory notification, DORA requires you to track and analyze all ICT-related incidents:

"Create a non-major ICT incident tracking and analysis procedure for DORA compliance. Include: recording requirements for all ICT incidents (incident register template), trend analysis methodology (identify patterns that could indicate systemic issues), escalation criteria (when accumulation of non-major incidents suggests a major issue), periodic reporting to management (frequency, format, content), and integration with the continuous improvement process under Article 13. Provide a quarterly incident trend report template."

Step 3: Create regulatory notification templates (Articles 19-20)

Initial notification template (4 hours)

The initial notification must be submitted to your competent authority within 4 hours of classifying an incident as major. Build pre-populated templates to meet this deadline:

1. Generate the initial notification template:

   "Create an initial incident notification template for DORA Article 19 (4-hour deadline). Pre-populate with standing organizational data. Include fields for: reporting entity identification (name, LEI, entity type, competent authority), incident identifier and classification date/time, incident description (what happened, initial timeline), classification rationale (which major criteria are met, with evidence), services affected and initial impact assessment, number of clients potentially affected (estimate if exact not known), geographical scope, initial containment actions taken, estimated duration if known, contact details for follow-up, and cross-border impact indicator. Design the template so it can be completed in under 60 minutes with the information available at classification time. Include guidance notes for each field."

2. Generate the intermediate report template (72 hours):

   "Create an intermediate incident report template for DORA Article 19 (72-hour deadline). Include fields for: reference to initial notification, updated incident timeline, updated impact assessment (clients affected, financial impact, data impact), root cause analysis (preliminary findings), containment and mitigation measures implemented, recovery status and estimated timeline, any changes to incident classification, communication actions taken (clients, counterparties, public), involvement of external parties (law enforcement, forensic providers), updated risk assessment, and any supervisory actions requested. Include guidance on providing meaningful root cause analysis even when investigation is ongoing."

3. Generate the final report template (1 month):

   "Create a final incident report template for DORA Article 19 (1-month deadline). Include comprehensive sections for: complete incident timeline (detection through resolution), confirmed root cause analysis (technical and organizational), total impact assessment (financial losses quantified, clients affected, services disrupted, data compromised), full description of containment, eradication, and recovery actions, effectiveness assessment of existing controls, remediation plan (actions, owners, deadlines, status), lessons learned and framework improvements, management body notification and decisions, regulatory reporting timeline compliance, and cross-references to any related incidents. This report should be suitable for supervisory review and serve as input to the post-incident review process under Article 13."

Submission procedures

Establish clear procedures for submitting reports to your competent authority:

"Create an incident report submission procedure for DORA regulatory notifications. Include: identification of our competent authority and their reporting channel (portal, email, API), submission authorization (who can authorize submission and at what time of day), quality review checklist before submission (completeness, accuracy, consistency with previous reports), submission confirmation and tracking, procedures for submitting outside business hours (for the 4-hour deadline), backup submission methods if primary channel is unavailable, record-keeping requirements (copies of all submissions with timestamps), and procedures for handling supervisory feedback under Article 22. Address the scenario where the incident itself affects our ability to submit reports."

Step 4: Build escalation and communication procedures

Internal escalation matrix

Effective escalation is critical for meeting DORA's tight timelines. Define clear escalation paths for every scenario:

1. Generate the escalation matrix:

   "Create an ICT incident escalation matrix for a [entity type] covering DORA reporting requirements. Define escalation levels: Level 1 (SOC/IT Operations): initial detection and triage, Level 2 (Incident Response Team): investigation and containment, Level 3 (CISO/CRO): major incident classification decision, Level 4 (Management Body): notification of major incidents, regulatory communication approval. For each level, specify: escalation criteria (what triggers escalation to next level), escalation timeline (maximum time at each level before escalation), notification method and contact details, information to provide when escalating, and decision authority at each level. Include after-hours escalation procedures and backup contacts. Design to ensure classification can occur within 2 hours of detection."

2. Create client notification procedures:

   "Develop client notification procedures for major ICT incidents under DORA. Include: criteria for when clients must be notified, notification timing relative to regulatory reporting, notification content (what to disclose, what to withhold during investigation), communication channels (email, portal, phone for critical clients), template client notifications for common incident types (service outage, data breach, system degradation), follow-up communication cadence, and record-keeping requirements. Address scenarios where the incident affects our ability to communicate with clients."

Management body notification

Article 5 requires the management body to be informed about ICT incidents. Define how this happens during incidents:

"Create a management body incident notification procedure for DORA Article 5 compliance. Include: notification triggers (all major incidents, significant non-major incidents), notification timeline (within [X] hours of classification), notification format (structured briefing template), content (incident summary, impact assessment, response actions, regulatory reporting status, client impact, media risk), decision points requiring management body input (public communications, client compensation, regulatory engagement), follow-up reporting cadence during ongoing incidents, and post-incident briefing and lessons learned presentation. Provide the management body incident briefing template."

Step 5: Integrate with existing incident management

Mapping DORA requirements to your current processes

Most financial entities already have incident management processes. Use ISMS Copilot to integrate DORA requirements into your existing framework rather than creating parallel processes:

"We currently use [ITIL/NIST/custom] incident management processes with [describe current tools: ServiceNow, Jira, PagerDuty, etc.]. Map DORA Article 17-23 requirements to our existing process. Identify: where our current process already satisfies DORA (detection, triage, containment, recovery), where we need to add DORA-specific steps (major incident classification, regulatory reporting, client notification), process modifications needed (timeline compression, escalation enhancements), tooling changes required (classification automation, report generation, submission tracking), and documentation updates needed. Provide a gap analysis with specific remediation actions."

Automating classification and reporting

Given the 4-hour timeline, consider automation opportunities:

"Identify opportunities to automate DORA incident classification and reporting for a [entity type]. Consider: automated collection of classification data points (number of affected clients from monitoring systems, service availability metrics, transaction volume impacts), automated pre-population of report templates from incident management tools, automated calculation of major incident criteria thresholds, workflow automation for escalation and notifications, integration between SIEM/incident platform and reporting workflow, automated deadline tracking and reminder alerts, and automated compilation of incident metrics for trend analysis. Provide implementation recommendations prioritized by impact on the 4-hour deadline."

Step 6: Root cause analysis procedures

Structured root cause analysis methodology

DORA requires root cause analysis as part of both intermediate (72-hour) and final (1-month) reports. Establish a standardized methodology:

1. Generate the RCA methodology:

   "Create a root cause analysis (RCA) methodology for DORA ICT incident reporting. Include: RCA initiation criteria and timing (start within 24 hours of major incident classification), investigation methods (5 Whys, fishbone/Ishikawa, fault tree analysis, timeline analysis), evidence collection and preservation procedures, technical investigation steps (log analysis, forensics, system examination), organizational investigation steps (process review, policy compliance, training adequacy), root cause categories (technical failure, human error, process gap, third-party failure, external attack, design flaw), preliminary RCA process for the 72-hour intermediate report (structured even with incomplete information), comprehensive RCA process for the 1-month final report, quality review of RCA findings before submission, and linkage between root causes and remediation actions. Provide an RCA report template with examples."

2. Create remediation tracking procedures:

   "Develop a post-incident remediation tracking procedure for DORA compliance. Include: how remediation actions are identified from RCA findings, action prioritization methodology (critical, high, medium based on risk), action assignment (owner, deadline, resources), progress tracking and reporting, management body oversight of remediation progress, verification of remediation effectiveness, closure criteria for remediation actions, and integration with the ICT risk register (updating risk assessments based on incident findings). Provide a remediation tracking register template."

Step 7: Cyber threat notification (Article 23)

Voluntary threat reporting

Article 23 encourages financial entities to notify competent authorities of significant cyber threats, even if they have not yet resulted in incidents. Establish procedures for this voluntary reporting:

"Create a significant cyber threat notification procedure for DORA Article 23. Include: criteria for what constitutes a 'significant cyber threat' warranting voluntary notification (targeted attacks detected but contained, intelligence on imminent threats, zero-day vulnerabilities affecting critical systems, threat patterns across the sector), internal assessment and decision process (who decides whether to notify), notification template for cyber threats (different from incident reports), timing expectations (not mandated but should be prompt), confidentiality considerations and information sharing limitations, and benefits of voluntary reporting (supervisory goodwill, sector-wide protection, intelligence sharing). Provide decision criteria and a notification template."

Step 8: Test your incident reporting capability

Tabletop exercises and simulations

Your incident classification and reporting procedures must be tested before a real incident occurs. Use ISMS Copilot to design realistic exercises:

1. Design tabletop exercise scenarios:

   "Design three tabletop exercise scenarios for testing our DORA incident classification and reporting procedures. Each scenario should: be realistic for a [entity type], unfold over multiple phases (initial detection, escalation, containment, reporting), test the major incident classification decision, test the 4-hour initial notification process end-to-end, include complications (incomplete information, after-hours detection, multiple simultaneous issues), test client communication triggers, and require management body notification. Scenarios should cover: (1) ransomware attack affecting critical banking/payment systems, (2) cloud provider outage affecting multiple services, (3) data breach discovered through external notification. For each scenario, provide an exercise facilitator guide with inject timeline, expected participant actions, and evaluation criteria."

2. Create exercise evaluation framework:

   "Create an evaluation framework for DORA incident reporting tabletop exercises. Evaluate: time from detection to classification (target under 2 hours), time from classification to initial notification submission (target under 4 hours), accuracy of classification decision, completeness of initial notification, quality of escalation and communication, management body notification effectiveness, client communication appropriateness, documentation quality, and team coordination. Provide a scoring rubric and post-exercise report template."

Next steps

You now have a comprehensive DORA incident reporting capability:

• Incident management process integrated with detection capabilities

• Classification matrix with quantitative thresholds for major incidents

• Three-stage regulatory notification templates (4-hour, 72-hour, 1-month)

• Escalation matrix with clear decision authorities and timelines

• Root cause analysis methodology with remediation tracking

• Cyber threat notification procedures

• Tested procedures through tabletop exercises

Continue with the next guides in this DORA series:

• How to plan DORA resilience testing using AI -- Design your testing program, including scenarios that validate your incident response and reporting capabilities

• How to manage DORA third-party ICT risk using AI -- Ensure your third-party providers can support your incident reporting obligations with adequate notification clauses and SLAs

For the foundational setup, see How to get started with DORA implementation using AI. For the ICT risk framework that underpins incident management, see How to build a DORA ICT risk management framework using AI.

For ready-to-use prompts, see the DORA Compliance Prompt Library. For the complete regulatory overview, refer to the DORA Compliance Guide for Financial Entities.

Getting help

For additional support implementing DORA incident reporting:

• Ask ISMS Copilot: Use your DORA workspace to generate scenario-specific classification guidance and customize report templates for your entity type

• Upload existing procedures: Get targeted gap analysis by uploading your current incident response plan for comparison against DORA Articles 17-23

• Simulate reporting: Use ISMS Copilot to walk through mock incident scenarios and practice completing notification templates under time pressure

• Validate outputs: Review all classification criteria and report templates against the DORA regulation text and relevant Regulatory Technical Standards before formal adoption