A practical workflow for deciding when the DORA reporting clock starts, which classification gates to run, and what evidence to keep for competent-authority submissions.
Use it during ICT incidents to separate awareness, detection, major-incident classification, initial notification, intermediate updates, final reporting, delay notices, and reclassification records.
Structured answer sets in this page tree.
Cited legal and guidance references.
DORA incident reporting depends on two clock-start facts: when the financial entity became aware of the ICT-related incident, and when it classified the incident as a major ICT-related incident. This workflow turns those facts into a record that supports classification, submission timing, authority evidence, delay handling, updates, and final closeout.
Open the incident clock record as soon as the entity becomes aware of an ICT-related incident. Awareness is not the same as classification: Delegated Regulation (EU) 2025/301 makes the initial-notification deadline depend on both awareness of the ICT-related incident and later classification as major.
Keep separate timestamps for awareness, detection, occurrence, service downtime, major-incident classification, initial notification submission, intermediate report submission, recovery of regular activities, root-cause completion, and final report submission. Mixing these timestamps makes it difficult to explain the reporting route later.
Before submitting a major-incident report, test the incident against Delegated Regulation (EU) 2024/1772. The workflow should first ask whether critical services are affected, then check whether successful malicious unauthorised access with possible data losses applies, or whether at least two materiality thresholds are met.
The classification record should not be a severity label. It should show the data source, value, estimate method, threshold result, owner, reviewer, and timestamp for each criterion.
Once the incident is classified as a major ICT-related incident, the initial notification is due as early as possible, within four hours from that classification, and no later than 24 hours from the moment the financial entity became aware of the ICT-related incident.
If the entity does not classify the incident as major within 24 hours from awareness but classifies it as major later, the initial notification is due within four hours from major classification. The workflow should therefore preserve both the awareness evidence and the classification evidence.
Implementing Regulation (EU) 2025/302 requires the Annex I template for initial notifications, intermediate reports, and final reports. The workflow should show which fields are required now, which fields can be supplied early, and which fields are estimated because accurate data is not yet available.
Do not wait for final impact numbers before making an initial notification. The implementing regulation allows estimated values based on available data where accurate data is not available for the initial notification or intermediate report.
Sorena can convert this clock workflow into a live incident record with classification gates, deadline tracking, template fields, submission evidence, and closeout checks.
Ask source-linked questions about DORA classification gates, report timing, authority routes, and evidence records.
Review your DORA incident reporting workflow, deadline evidence, and template readiness with Sorena.
The workflow should include explicit gates for problems that often happen during live response: a report cannot be submitted on time, an incident first reported as major is later assessed as non-major, or final impact figures differ from early estimates.
Closeout should not happen when the service is merely restored. It should happen when the reporting sequence, classification evidence, root-cause analysis, actual impact figures, authority submissions, updates, and management actions are all tied together.
For a major ICT-related incident, the initial notification is due as early as possible, within four hours from classification as major, and no later than 24 hours from awareness of the ICT-related incident. If classification as major happens only after the first 24 hours, the initial notification is due within four hours from that later classification.
No. Service restoration triggers an updated intermediate report without undue delay where regular activities have recovered, but the workflow continues until the final report is submitted after root-cause analysis is complete and actual impact figures are available.
Keep the secure-channel route, submitter identity, template used, submission timestamp, exported report, authority acknowledgement, any authority feedback, and any alternative-channel agreement or resubmission evidence if the standard secure channel was unavailable.
"Materiality thresholds for determining major incidents"
"shall explain the reasons for the delay"
"content and time limits"
"reclassified the ICT-related incident"
"acknowledge receipt"