---
title: "DORA incident clock workflow: classification, reports, deadlines, and evidence"
canonical_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/incident-clock-workflow"
source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/incident-clock-workflow"
author: "Sorena AI"
description: "Grounded DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "EU DORA"
  - "DORA incident clock"
  - "major ICT-related incident"
  - "initial notification"
  - "intermediate report"
  - "final report"
  - "incident classification"
  - "competent authority"
  - "DORA incident reporting"
  - "major ICT-related incidents"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# DORA incident clock workflow: classification, reports, deadlines, and evidence

Grounded DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.

*Workflow* *EU DORA*

## DORA incident clock workflow

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 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.

## Start the DORA clock record before deciding whether the incident is major

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.

- Record awareness time and source: monitoring alert, supplier notice, user report, service desk ticket, business line escalation, or authority contact.
- Record detection time separately because incident duration may be measured from occurrence, detection, logs, or other data sources when occurrence time is not known.
- Record classification time only after the DORA major-incident criteria and thresholds have been assessed.
- Assign one incident commander for operational response, one DORA classifier for threshold evidence, and one reporting owner for competent-authority submission evidence.

Sources for this answer:

- [Delegated Regulation (EU) 2025/301 on DORA incident notification content and time limits](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Sets the initial-notification deadline by reference to classification as major and awareness of the ICT-related incident.
- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Explains how incident duration and service downtime are measured for DORA classification evidence.

## Run the DORA major-incident classification gates

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.

- Critical services gate: decide whether ICT services supporting critical or important functions, authorised financial services, or malicious unauthorised access to supporting systems are involved.
- Impact gates: test clients, financial counterparts, affected transactions, reputational impact, incident duration, service downtime, geographical spread, data losses, and economic impact.
- Threshold examples to capture where applicable: more than 24 hours duration, more than 2 hours downtime for ICT services supporting critical or important functions, impact in two or more Member States, and costs or losses exceeding or likely to exceed EUR 100,000.
- Recurring incident gate: check whether non-major incidents occurred at least twice within six months, share the same apparent root cause, and collectively meet the major-incident test.

Sources for this answer:

- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Defines the DORA classification criteria, Article 8 major-incident test, recurrence rule, and materiality thresholds.
- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Requires financial entities to report major ICT-related incidents to the relevant competent authority.

## Apply the initial, intermediate, and final report time limits

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.

- Initial notification: submit as early as possible, within four hours from major classification, and no later than 24 hours from awareness unless the late-classification rule applies.
- Intermediate report: submit no later than 72 hours after the initial notification, even if status or handling has not changed.
- Intermediate updates: submit updated intermediate reports without undue delay, and in any case when regular activities have recovered.
- Final report: submit no later than one month after the intermediate report, or after the latest updated intermediate report where one was submitted.
- Deadline exception check: where a deadline falls on a weekend or bank holiday, use the noon-next-working-day rule only where Delegated Regulation (EU) 2025/301 allows it and preserve the reason.

Sources for this answer:

- [Delegated Regulation (EU) 2025/301 on DORA incident notification content and time limits](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Provides the four-hour, 24-hour, 72-hour, one-month, late-classification, delay-notice, and weekend or bank-holiday timing rules.

## Build the report package from the DORA templates

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.

- Initial package: submission type, submitting entity, affected financial entity, LEI or identification code, contacts, incident reference code, detection time, classification time, description, classification criteria triggered, impacted Member States, discovery route, known origin, and business-continuity activation.
- Intermediate package: update previously submitted data and add occurrence, recovery, client and counterparty impact, transaction impact, duration, downtime, data-loss, critical-service, threat, infrastructure, recovery-measure, and indicator evidence where available.
- Final package: root-cause classification and narrative, resolution summary, root-cause and resolution timestamps, actual impact figures replacing estimates, gross costs and losses, recoveries, recurrence status, and any resolution-authority relevance.
- Combined submission gate: combine two or all report stages only where regular activities have recovered or root-cause analysis is complete and the DORA time limits are still met.

Sources for this answer:

- [Implementing Regulation (EU) 2025/302 on DORA incident reporting templates](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Sets the standard template, fields, update rules, estimate handling, combined-submission procedure, and final-report field structure.
- [Delegated Regulation (EU) 2025/301 on DORA incident notification content and time limits](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Specifies the information content for initial notifications, intermediate reports, final reports, and voluntary significant cyber-threat notifications.

*Recommended next step*

*Placement: after report-package section*

## Build a cited incident clock record for DORA reporting

Sorena can convert this clock workflow into a live incident record with classification gates, deadline tracking, template fields, submission evidence, and closeout checks.

- [Open Research Copilot for EU DORA](/solutions/research-copilot.md): Ask source-linked questions about DORA classification gates, report timing, authority routes, and evidence records.
- [Talk through implementation](/contact.md): Review your DORA incident reporting workflow, deadline evidence, and template readiness with Sorena.

## Preserve competent-authority submission evidence

The reporting owner should preserve proof that the correct route was used. Implementing Regulation (EU) 2025/302 requires secure electronic channels made available by the competent authority, with other secure means agreed with the authority if those channels cannot be used.

DORA also provides that the competent authority acknowledges receipt of the initial notification and each report and may provide relevant feedback or high-level guidance. Keep those acknowledgements and any feedback with the incident record.

- Save the competent authority route, secure channel used, submitter identity, submission timestamp, template version, file hash or export identifier, and receipt acknowledgement.
- If the secure electronic channel was unavailable, save the agreed alternative secure means, the authority contact, the reason, and any later resubmission through the authority channel.
- If a third-party service provider submits reports for the financial entity, keep the prior outsourcing notice to the competent authority, third-party name, contact details, identification code, and scope of reporting authority.
- If a third party submits an aggregated report for multiple financial entities, keep the aggregation conditions, impacted-entity list, permission evidence where relevant, and individual impact data in case the competent authority requests it.

Sources for this answer:

- [Implementing Regulation (EU) 2025/302 on DORA incident reporting templates](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Requires secure electronic submission channels, alternative secure means where agreed, notices for outsourced reporting, and conditions for aggregated reporting.
- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Provides for competent-authority acknowledgement, feedback, and the continuing responsibility of financial entities for incident handling.

## Decision gates for delay notices, reclassification, and closeout

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.

- Delay gate: if an initial notification, intermediate report, or final report cannot be submitted within the relevant time limit, inform the competent authority without undue delay and no later than the missed reporting deadline, with reasons for the delay.
- Reclassification gate: if further assessment shows the reported incident never met the major-incident criteria and thresholds, notify the competent authority using the reclassification information in the reporting template.
- Estimate replacement gate: replace initial or intermediate estimates with actual impact figures in the final report once root-cause analysis is complete and actual figures are available.
- Records gate: keep the classification matrix, clock log, source citations, operational timeline, reporting templates, submitted files, acknowledgements, delay notices, authority feedback, recovery evidence, root-cause analysis, cost and loss calculations, and final approval.

Sources for this answer:

- [Delegated Regulation (EU) 2025/301 on DORA incident notification content and time limits](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Supports delay notices, intermediate updates after recovery, final report timing, and replacement of estimates with actual impact figures.
- [Implementing Regulation (EU) 2025/302 on DORA incident reporting templates](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Supports the reclassification notice and template-update evidence for incidents previously reported as major.

## Primary sources

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA text for Article 19 major ICT-related incident reporting, voluntary significant cyber-threat notification, competent-authority routing, acknowledgement, and supervisory feedback.
  - Quote: "reporting of major ICT-related incidents"
- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Defines DORA incident classification criteria, major-incident thresholds, recurring-incident treatment, significant cyber-threat criteria, and inter-authority information details.
  - Quote: "criteria for the classification of ICT-related incidents"
- [Delegated Regulation (EU) 2025/301 on incident notification content and time limits](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Specifies content and time limits for initial notifications, intermediate reports, final reports, delay notices, weekend or bank-holiday handling, and voluntary significant cyber-threat notifications.
  - Quote: "content and time limits"
- [Implementing Regulation (EU) 2025/302 on DORA incident reporting templates](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Sets standard forms, template fields, secure submission procedures, estimated-value handling, outsourced reporting notices, aggregated reporting conditions, and reclassification mechanics.
  - Quote: "standard forms, templates, and procedures"

## Related Topic Guides

- [DORA Critical or Important Functions: mapping ICT dependencies and evidence](/artifacts/eu/digital-operational-resilience-act/critical-and-important-functions.md): How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
- [DORA deadlines and compliance calendar for financial entities](/artifacts/eu/digital-operational-resilience-act/deadlines-and-compliance-calendar.md): Calendar the grounded DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and CTPP oversight milestones.
- [DORA ICT Third-Party Contract Remediation Workflow](/artifacts/eu/digital-operational-resilience-act/contract-remediation-workflow.md): A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
- [DORA ICT Third-Party Contracts FAQ](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md): What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
- [DORA ICT third-party risk and contract clauses guide](/artifacts/eu/digital-operational-resilience-act/third-party-risk-and-contract-clauses.md): Source-grounded DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight.
- [DORA incident classification forms: criteria, fields, and reporting clocks](/artifacts/eu/digital-operational-resilience-act/incident-classification-forms.md): Grounded guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
- [DORA major ICT incident reporting: classification, reports, and timing](/artifacts/eu/digital-operational-resilience-act/major-incident-reporting.md): Source-grounded DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
- [DORA major ICT incident thresholds: what triggers reporting?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md): FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs grounded in EU DORA RTS and ITS texts.
- [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md): 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.
- [DORA Register of Information Import and Build Workflow](/artifacts/eu/digital-operational-resilience-act/roi-import-and-build-workflow.md): Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
- [DORA Register of Information Template: ICT Provider Fields and Evidence](/artifacts/eu/digital-operational-resilience-act/dora-register-of-information-template.md): A grounded DORA register of information template for ICT third-party contracts, provider hierarchy, critical functions, dates, statuses, reporting, and evidence.
- [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md): 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 vs EBA outsourcing guidelines: ICT third-party risk comparison](/artifacts/eu/digital-operational-resilience-act/dora-vs-eba-outsourcing-guidelines.md): Compare binding DORA ICT third-party risk duties with the EBA/ESA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
- [DORA vs ISO 22301: ICT resilience and business continuity compared](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-22301.md): Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.
- [DORA vs ISO/IEC 27001: legal ICT resilience obligations and ISMS controls](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-27001.md): Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
- [DORA vs NIS2: financial-sector obligations, overlap, and evidence](/artifacts/eu/digital-operational-resilience-act/dora-vs-nis2.md): Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
- [DORA vs PSD2 incident reporting: major ICT and payment incidents](/artifacts/eu/digital-operational-resilience-act/dora-vs-psd2-incident-reporting.md): Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
- [EU DORA Applicability Test for Financial Entities and ICT Providers](/artifacts/eu/digital-operational-resilience-act/applicability-test.md): A source-grounded DORA applicability test for financial-entity scope, ICT third-party services, critical or important functions, exclusions, proportionality, and evidence.
- [EU DORA Compliance Checklist for Financial Entities](/artifacts/eu/digital-operational-resilience-act/checklist.md): A source-grounded DORA checklist covering ICT risk governance, major incident reporting, resilience testing, TLPT, ICT third-party contracts, register-of-information records, and audit evidence.
- [EU DORA Compliance Obligations and Evidence Guide](/artifacts/eu/digital-operational-resilience-act/compliance.md): A source-grounded DORA compliance guide covering ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, registers, governance, oversight, and evidence.
- [EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence](/artifacts/eu/digital-operational-resilience-act/faq.md): 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.
- [EU DORA ICT risk management control baseline](/artifacts/eu/digital-operational-resilience-act/ict-risk-management-control-baseline.md): A source-grounded DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
- [EU DORA ICT subcontracting chain controls for critical functions](/artifacts/eu/digital-operational-resilience-act/subcontracting-chain-controls.md): DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
- [EU DORA penalties and fines: enforcement powers and limits](/artifacts/eu/digital-operational-resilience-act/penalties-and-fines.md): Grounded guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.
- [EU DORA Register of Information Data Model: templates, fields, and evidence](/artifacts/eu/digital-operational-resilience-act/register-of-information-data-model.md): 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.
- [EU DORA Requirements Overview: ICT risk, incidents, testing, and third-party risk](/artifacts/eu/digital-operational-resilience-act/requirements.md): A grounded 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.
- [EU DORA Scope and Covered Entities: financial entities and ICT providers](/artifacts/eu/digital-operational-resilience-act/scope-and-covered-entities.md): Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
- [EU DORA Scope and Proportionality Workflow](/artifacts/eu/digital-operational-resilience-act/scope-and-proportionality-workflow.md): Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
- [EU DORA testing and TLPT readiness guide](/artifacts/eu/digital-operational-resilience-act/testing-and-tlpt-readiness.md): A grounded DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
- [EU DORA TLPT eligibility workflow for financial entities](/artifacts/eu/digital-operational-resilience-act/tlpt-eligibility-workflow.md): Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
- [EU DORA TLPT Runbook: scope, providers, reports, and remediation](/artifacts/eu/digital-operational-resilience-act/tlpt-runbook.md): Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
- [How does proportionality work under EU DORA?](/artifacts/eu/digital-operational-resilience-act/faq/proportionality.md): A grounded FAQ on DORA proportionality: what can be scaled, who may use the simplified ICT risk framework, what evidence supports the decision, and which duties cannot be waived.
- [How to build a DORA register of information](/artifacts/eu/digital-operational-resilience-act/register-of-information-how-to-build.md): Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/incident-clock-workflow