A practical form structure for classifying ICT-related incidents under DORA before deciding whether a major-incident report or voluntary significant cyber-threat notification is needed.
Use it to capture the classification criteria, materiality thresholds, reporting-stage fields, time-limit evidence, estimates, and reclassification notes that competent-authority submissions depend on.
DORA incident reporting has applied since 17 January 2025. From the first triage record, the classification form should show which Delegated Regulation (EU) 2024/1772 criteria were tested, whether Article 8 makes the event a , which Implementing Regulation (EU) 2025/302 fields are ready, and which reporting clock under Delegated Regulation (EU) 2025/301 is running.
The classification form should start with a structured yes/no assessment against the DORA criteria: clients, financial counterparts and transactions; reputational impact; duration and service downtime; geographical spread; data losses; criticality of services affected; and economic impact.
A is not triggered by every threshold in isolation. Under Delegated Regulation (EU) 2024/1772, the incident must affect critical services and either meet the data-loss threshold for successful malicious unauthorised access not covered by Article 9(5)(a) that may result in data losses, or meet two or more of the other materiality thresholds. Non-major recurring incidents become one major incident when they occur at least twice within six months, share the same apparent root cause, and collectively meet the major-incident test. Financial entities assess recurrence monthly, except microenterprises and the entities listed in DORA Article 16(1), for which that recurrence rule does not apply.
Sources (2)
Defines the DORA classification criteria, major-incident test, recurring-incident aggregation, and materiality thresholds.
criteria for the classification of ICT-related incidents
Establishes the Article 19 obligation to report major ICT-related incidents and the voluntary route for significant cyber threats.
reporting of major ICT-related incidents
The form should force the classifier to enter the threshold evidence that makes the incident reportable or not reportable. That means separating measurable thresholds from qualitative evidence, and recording estimates when exact values are not yet available.
The most useful form layout is one row per criterion: source of data, threshold tested, value observed or estimated, evidence link, owner, reviewer, and conclusion. This lets the team update the same record during the initial notification, intermediate report, and final report rather than rebuilding the classification from memory.
Count criteria rather than individual sub-thresholds: affected clients, financial counterparts, and transactions together form one criterion. Exceeding both a client threshold and a transaction threshold therefore counts once in the two-threshold test.
Sources (1)
Provides the numerical and qualitative materiality thresholds that should become rows in the classification form.
Materiality thresholds for determining major incidents
Once the incident is classified as major, Implementing Regulation (EU) 2025/302 requires financial entities to use the Annex I template for the initial notification, intermediate report, and final report. The same regulation allows fields required at a later stage to be supplied earlier when the information is already available.
The classification form should therefore mark each field as initial, intermediate, final, estimated, actual, not yet known, or not applicable. It should also preserve the incident reference code assigned by the financial entity and, when available, the reference code provided by the competent authority.
Sources (2)
Sets the standard forms, template fields, glossary, secure-channel procedure, reclassification field use, outsourced reporting notice, aggregated reporting conditions, and significant cyber-threat template.
standard forms, templates, and procedures
Specifies the content required in initial notifications, intermediate reports, final reports, and voluntary significant cyber-threat notifications.
content and time limits
The form should calculate deadlines from two timestamps: when the entity became aware of the ICT-related incident and when it classified the incident as a . These timestamps drive the initial-notification clock and help explain late classification.
Under Delegated Regulation (EU) 2025/301, the initial report is due as early as possible, within four hours from major classification, and no later than 24 hours from awareness. The intermediate report is due within 72 hours from the initial notification, with updates without undue delay and when regular activities recover. The final report is due no later than one month after the intermediate report or the latest updated intermediate report.
Sources (1)
Provides the four-hour, 24-hour, 72-hour, one-month, delay-notice, and weekend or bank-holiday timing rules for DORA major-incident reports.
Time limits for the initial notification
A significant cyber-threat notification is voluntary under DORA Article 19, and it is not the same record as a confirmed report. The form should keep a separate significant-threat tab for threats that have not materialised but may be relevant to the financial system, service users, or clients.
Delegated Regulation (EU) 2024/1772 treats a cyber threat as significant when all listed conditions are fulfilled: potential effect on critical or important functions or others in the ecosystem, high probability of materialisation based on available information, and potential to meet specified major-incident criteria or thresholds if materialised.
Sources (2)
Defines when a cyber threat is significant for DORA classification purposes.
High materiality thresholds for determining significant cyber threats
Sets the Annex III significant cyber-threat notification template and Annex IV instructions.
Notification of significant cyber threats
The classification decision should be reviewable after the incident. Keep the operational evidence beside the legal conclusion so a later reviewer can see why the incident was reported, not reported, updated, aggregated, or reclassified.
The strongest record is a single evidence pack that links the SOC timeline, service-management timestamps, business-impact evidence, customer and counterparty counts, transaction baselines, loss estimates, communications, recovery measures, and competent-authority submissions.
When the incident affects critical services and meets the Article 8 test in Delegated Regulation (EU) 2024/1772: either successful malicious unauthorised access not covered by Article 9(5)(a) that may result in data losses, or at least two other materiality thresholds. Recurring non-major incidents can also aggregate into one major incident when the regulation's recurrence conditions are met.
At minimum, the form should hold the entity and contact fields, incident reference code, detection time, classification time, incident description, triggered classification criteria, impacted Member States, discovery route, available origin information, business-continuity activation status, and any other relevant information.
Yes. Delegated Regulation (EU) 2024/1772 allows estimates from comparable reference periods when affected clients, financial counterparts, transactions, or amounts cannot be determined, and Implementing Regulation (EU) 2025/302 allows estimated values where accurate data are not available for initial or intermediate reporting.
Sources (2)
Supports evidence fields for estimates, template updates, secure channels, reclassification, outsourced reporting, and aggregated reporting.
complete and accurate
Supports the criterion-by-criterion evidence pack and recurring-incident assessment.
estimate those numbers or amounts
Sorena can help translate the DORA classification criteria, template fields, time limits, and evidence requirements on this page into a reusable incident intake and reporting workflow.
Ask questions tied to cited sources about DORA major-incident criteria, significant cyber-threat notifications, report fields, reporting clocks, and reclassification evidence.
Review your DORA incident intake form, major-incident classification matrix, reporting-template field map, and evidence pack.
"Materiality thresholds for determining major incidents"
"criteria for the classification of ICT-related incidents"
"High materiality thresholds for determining significant cyber threats"
"estimate those numbers or amounts"
"TEMPLATES FOR THE REPORTING OF MAJOR INCIDENTS"
"standard forms, templates, and procedures"
"Notification of significant cyber threats"
"complete and accurate"
"initial notification, the intermediate report, and the final report"
"content and time limits"
"Time limits for the initial notification"
"ICT-related incident management, classification and reporting"
"reporting of major ICT-related incidents"
How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
Track DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and critical-provider oversight milestones.
A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
Official source DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight.
Official source DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
Official source DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
Map DORA register fields to official templates for ICT contracts, provider chains, critical functions, dates, statuses, reporting, and evidence.
Compare binding DORA ICT third-party risk duties with the EBA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.
Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
Test DORA applicability against official sources for financial-entity scope, ICT services, critical or important functions, exclusions, proportionality, and evidence.
Check DORA operating evidence against official sources for ICT risk governance, major-incident reporting, resilience testing, TLPT, third-party contracts, and the register of information.
Map DORA obligations to official sources and operating evidence for ICT risk management, incident reporting, testing, third-party risk, registers, governance, and oversight.
Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.
An official source DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
Official source guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.
Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence.
An official source overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence.
Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
An official source DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.
What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs based on EU DORA RTS and ITS texts.
FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.
FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.
DORA proportionality explained from official sources: what can be scaled, simplified-framework eligibility, supporting evidence, and duties that remain mandatory.