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.
Structured answer sets in this page tree.
Cited legal and guidance references.
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 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.
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.
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.
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.
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.
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 with possible 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.
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.
"estimate those numbers or amounts"
"Time limits for the initial notification"
"complete and accurate"
"reporting of major ICT-related incidents"