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.
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 . 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.
Sources (2)
Sets the initial-notification deadline by reference to classification as major and awareness of the ICT-related incident.
within four hours from the classification
Explains how incident duration and service downtime are measured for DORA classification evidence.
measure the duration of an incident
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 not covered by Article 9(5)(a) that may result in data losses applies, or whether at least two other 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.
Sources (2)
Defines the DORA classification criteria, Article 8 major-incident test, recurrence rule, and materiality thresholds.
Materiality thresholds for determining major incidents
Requires financial entities to report major ICT-related incidents to the relevant competent authority.
reporting of major ICT-related incidents
Once the incident is classified as a , 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.
Sources (1)
Provides the four-hour, 24-hour, 72-hour, one-month, late-classification, delay-notice, and weekend or bank-holiday timing rules.
Time limits for the initial notification
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.
Sources (2)
Sets the standard template, fields, update rules, estimate handling, combined-submission procedure, and final-report field structure.
standard forms, templates, and procedures
Specifies the information content for initial notifications, intermediate reports, final reports, and voluntary significant cyber-threat notifications.
General information to be provided
Sorena can convert this clock workflow into a live incident record with classification gates, deadline tracking, template fields, submission evidence, and closeout checks.
Ask questions tied to cited sources 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 , 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.
Sources (2)
Supports delay notices, intermediate updates after recovery, final report timing, and replacement of estimates with actual impact figures.
shall explain the reasons for the delay
Supports the reclassification notice and template-update evidence for incidents previously reported as major.
reclassified the ICT-related incident
"within four hours from the classification"
"Time limits for the initial notification"
"General information to be provided"
"shall explain the reasons for the delay"
"standard forms, templates, and procedures"
"secure electronic channels"
"reclassified the ICT-related incident"
"criteria for the classification of ICT-related incidents"
"measure the duration of an incident"
"Materiality thresholds for determining major incidents"
"reporting of major ICT-related incidents"
"acknowledge receipt"
"content and time limits"
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 guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
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.