Workflow GuideEU

EU DORA Major Incident Reporting

Build an incident reporting workflow that works during outages and stands up to supervisory scrutiny.

Covers the process (Article 17), classification thresholds (RTS 2024/1772), and report content + time limits (RTS 2025/301).

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 23, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 23, 2026

Updated Feb 23, 2026

Overview

DORA incident reporting is not just "send an email to a regulator". It's a regulated workflow with classification logic, timed reporting outputs, and evidence requirements. The fastest path to compliance is to treat reporting as a product: a structured data model, a workflow engine, and a reporting pack generator that produces initial notification, intermediate updates, and a final root cause analysis report.

Section 1

What DORA requires (minimum viable compliant reporting system)

DORA requires financial entities to define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents (Article 17).

Financial entities must record all ICT-related incidents and significant cyber threats, classify incidents, and report major ICT-related incidents to competent authorities with specified report stages (Article 19).

Implement an incident management process with early warning indicators, tracking/logging/classification, roles and responsibilities, communications, and response procedures (Article 17).
Record all incidents and significant cyber threats; ensure consistent handling and root cause analysis and prevention improvements (Article 17(2)).
Report major ICT-related incidents: initial notification -> intermediate updates -> final report with RCA and actual impact figures (Article 19(4)).
Inform clients without undue delay where incidents impact clients' financial interests (Article 19(3)).

Section 2

Article 17 - Incident management process blueprint (control design)

Article 17 tells you what the process must contain. Build it as an operational workflow with measured outcomes.

The process must also support communications and management body reporting for major incidents.

Early warning indicators: define signals and thresholds for anomalous activities.
Tracking and logging: a single incident record with timestamps, severity, impacted services, and dependency links.
Classification: procedures to categorize and classify incidents by priority/severity and criticality of impacted services (ties to Article 18).
Roles and responsibilities: defined on-call and escalation model; crisis roles activated by scenario type.
Communications: staff + external stakeholder + media plan; internal escalation; customer complaint handling integration (Article 17(3)(d)).
Major incident reporting to management: structured briefings for senior management and management body (Article 17(3)(e)).

Recommended next step

Turn EU DORA Major Incident Reporting into an operational assessment

Assessment Autopilot can take EU DORA Major Incident Reporting from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Assessment workflow

Open Assessment Autopilot for EU DORA Major Incident Reporting

Start from EU DORA Major Incident Reporting and turn the guidance into owned tasks, evidence requests, and review checkpoints.

Explore next step

Talk to Sorena

Talk through EU DORA

Review your current process, evidence gaps, and next steps for EU DORA Major Incident Reporting.

Explore next step

Section 3

Classification and thresholds: Article 18 + RTS 2024/1772

Major incident reporting is triggered by classification. RTS 2024/1772 operationalizes the criteria and materiality thresholds for major incidents and cyber threats.

Implement classification as code + governance: thresholds, decision logs, and QA sampling.

Define classification inputs: services impacted, criticality, clients affected, transaction impact, geographic/cross-border impact, and economic impact (RTS context).
Implement threshold evaluation: deterministic rules where possible, with documented judgment where required.
Keep a "classification decision log": why it was (or wasn't) major, with evidence links and sign-off.
QA: sample classifications quarterly and compare decisions across teams to reduce arbitrariness.

Section 4

Reporting pipeline: Article 19, RTS 2025/301, and ITS 2025/302 (stages, content, time limits, templates)

Article 19 defines the reporting stages. RTS 2025/301 specifies the content and time limits, while ITS 2025/302 provides the standard forms, templates, and procedures used for actual submissions.

Design your pipeline to work during degraded operations (e.g., alternate submission paths).

Initial notification: generate quickly with known facts and classification basis; include cross-border impact indicators.
Intermediate reports/updates: trigger on significant status changes; support updated notifications on request of competent authority.
Final report: include root cause analysis and actual impact figures replacing estimates; record remediation actions.
Technical fallback: if a technical impossibility prevents submission using the template, notify via alternative means and preserve evidence of the fallback (Article 19).
Template discipline: map your incident object to the ITS 2025/302 standard fields so initial, intermediate, and final reports can be generated consistently even during degraded operations.

Section 5

Why the ITS 2025/302 templates change implementation quality

Many teams stop at classification and timing, but supervisors expect consistent use of the standard reporting forms and procedures. That is where the ITS matters.

If your reporting workflow cannot populate the standard template fields directly from incident records, the process will fail when speed and accuracy matter most.

Treat the ITS forms as a schema contract for incident reporting, not as a document to fill in manually at the end.
Map every required reporting field to a system of record, owner, and validation rule.
Test fallback paths and submission logistics so template-based reporting still works when primary systems are degraded.
Keep submission receipts and exact report versions because supervisors often ask for the timeline of what was reported and when.

Section 6

Voluntary significant cyber threat notifications (when to use them)

DORA allows financial entities to voluntarily notify significant cyber threats when relevant to the financial system, service users, or clients.

Treat this as a governance decision with clear triggers and a redaction approach.

Define trigger conditions: threat relevance, likelihood, sector contagion risk, and client impact.
Build a redaction and confidentiality model: share what's needed without leaking sensitive defensive details.
Evidence: keep the threat record, analysis, and rationale for notification vs non-notification.

Section 7

Reporting data model (recommended schema you can implement)

The easiest way to comply is to treat reporting outputs as structured objects generated from operational data.

This schema supports reporting, transparency, audits, and post-incident improvements.

Incident core: ID, timestamps, impacted services and criticality, root cause hypothesis, status timeline.
Impact metrics: clients affected, transaction and service disruption metrics, economic impact (costs/losses), geographic footprint.
Response and recovery: containment actions, recovery milestones, external dependency actions (third-party providers).
Communications: client notification decisions and timestamps, external stakeholder communications, regulator submissions.
Evidence links: logs, alerts, tickets, post-incident review, test results from remediation validation.

Section 8

Evidence pack checklist (what supervisors ask for first)

Reporting risk is usually evidence risk: you can't reproduce numbers or explain classification decisions later.

Build these artifacts as part of normal operations.

Incident management policy and runbook aligned to Article 17; on-call and escalation schedules.
Classification decision logs aligned to RTS 2024/1772; quarterly QA sampling results.
Copies of submitted reports (initial/intermediate/final) with timestamps and submission receipts.
Client communications templates and samples for major incidents impacting financial interests.
Post-incident review reports and improvement tracking to show learning and prevention.

Primary sources