---
title: "DORA incident classification forms: criteria, fields, and reporting clocks"
canonical_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/incident-classification-forms"
source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/incident-classification-forms"
author: "Sorena AI"
description: "Grounded guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "EU DORA"
  - "DORA incident classification"
  - "major ICT-related incidents"
  - "significant cyber threats"
  - "incident reporting templates"
  - "ICT incident evidence"
---
**[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 classification forms: criteria, fields, and reporting clocks

Grounded guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.

*Template Guide* *EU DORA*

## DORA incident classification forms

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 classification forms should be more than ordinary security tickets. They should show, from the first triage record, which Delegated Regulation (EU) 2024/1772 criteria were tested, whether Article 8 makes the incident reportable as a major ICT-related incident, which Implementing Regulation (EU) 2025/302 form fields are ready, and which reporting clock under Delegated Regulation (EU) 2025/301 is running.

## Classify the event before opening a major-incident report

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 major ICT-related incident is not triggered by every threshold in isolation. Under Delegated Regulation (EU) 2024/1772, the incident must affect critical services and either meet the malicious unauthorised-access data-loss threshold or meet two or more of the listed materiality thresholds. Non-major recurring incidents can also be treated as 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.

- Record affected service, critical or important function, authorisation or supervisory status, and whether there was successful malicious unauthorised access.
- Capture client, financial-counterparty, transaction-number, and transaction-value impacts, including whether values are actual or estimated from comparable reference periods.
- Measure duration from occurrence, detection, or log evidence as applicable; measure service downtime until regular service or delayed service is restored.
- Treat cross-Member-State impact, data availability, authenticity, integrity, confidentiality, and economic costs as separate evidence lines rather than a single severity label.

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, major-incident test, recurring-incident aggregation, and materiality thresholds.
- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Establishes the Article 19 obligation to report major ICT-related incidents and the voluntary route for significant cyber threats.

## Use the materiality thresholds as form fields, not prose

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.

- Clients: higher than 10 percent of all clients using the affected service, more than 100,000 affected clients, or relevant clients affected.
- Financial counterparts and transactions: more than 30 percent of relevant financial counterparts, more than 10 percent of daily average transaction count, or more than 10 percent of daily average transaction value.
- Duration, downtime, geography, data, and cost: more than 24 hours duration, more than 2 hours downtime for ICT services supporting critical or important functions, impact in at least two Member States, qualifying data-loss impact, or costs and losses exceeding or likely to exceed EUR 100,000.
- Reputation: media reflection, repetitive complaints, inability or likely inability to meet regulatory requirements, or likely material loss of clients or financial counterparts.

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) - Provides the numerical and qualitative materiality thresholds that should become rows in the classification form.

## Map classification output to the DORA reporting template

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.

- General fields: submission type, submitting entity, affected financial entity, LEI, financial-entity type, contact persons, parent undertaking where applicable, and reporting currency.
- Initial notification fields: detection date and time, classification date and time, incident description, triggered classification criteria, impacted Member States, discovery route, origin if available, business-continuity activation, and other relevant information.
- Intermediate-report fields: occurrence and recovery timestamps, client and counterparty impact, transaction impact, reputational impact, duration, downtime, Member-State impact, data-loss thresholds, critical-services assessment, incident type, threat techniques, affected functional areas, infrastructure components, client financial-interest impact, other-authority reporting, recovery measures, and indicators of compromise.
- Final-report fields: root-cause classifications, root-cause narrative, resolution summary, root-cause and resolution timestamps, resolution-authority relevance, gross costs and losses, recoveries, recurring-incident status, and recurring-incident occurrence times.

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 forms, template fields, glossary, secure-channel procedure, reclassification field use, outsourced reporting notice, aggregated reporting conditions, and significant cyber-threat template.
- [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 the content required in initial notifications, intermediate reports, final reports, and voluntary significant cyber-threat notifications.

## Add reporting clocks and delay evidence

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 major ICT-related incident. 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.

- Save awareness time, detection time, classification time, occurrence time, recovery time, root-cause-addressed time, and final resolution time as separate fields.
- If major classification happens after the first 24 hours from awareness, record why and submit the initial notification within four hours from classification.
- If a deadline cannot be met, record the notification to the competent authority, the reason for delay, and the time that notice was sent.
- Only apply the weekend or bank-holiday noon-next-working-day rule where the regulation allows it; the exception does not apply to the listed credit institutions, central counterparties, trading venues, and NIS2 essential or important entities for initial and intermediate reports.

Sources for this answer:

- [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) - Provides the four-hour, 24-hour, 72-hour, one-month, delay-notice, and weekend or bank-holiday timing rules for DORA major-incident reports.

## Handle significant cyber threats separately from incidents

A significant cyber-threat notification is voluntary under DORA Article 19, and it is not the same record as a confirmed major ICT-related incident 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.

- Capture the threat description, detection timestamp, threat status, changes in threat activity, and source of threat information.
- Record potential impact on the financial entity, clients, and financial counterparts, plus the major-incident criteria that would have been triggered if the threat materialised.
- Document vulnerabilities, threat-actor capability and intent where known, persistence, and knowledge from incidents affecting the entity, third-party providers, clients, or financial counterparts.
- When available, include indicators of compromise such as IP addresses, URLs, domains, file hashes, malware data, network activity, email headers, DNS requests, account activity, or database requests.

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 when a cyber threat is significant for DORA classification purposes.
- [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 Annex III significant cyber-threat notification template and Annex IV instructions.

## Evidence and decision record checklist

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.

- Keep the classification matrix showing every criterion tested, threshold result, data source, estimate method, owner, reviewer, and timestamp.
- Preserve raw or exportable evidence: monitoring alerts, incident tickets, logs, service-status records, BCP activation record, client-complaint evidence, media monitoring, transaction baselines, affected Member-State analysis, and cost or loss calculations.
- For outsourced or aggregated reporting, retain the competent-authority notice, third-party submitter identity and contact details, permission for aggregation where relevant, and the individual entity impact data if requested.
- If the incident is reclassified from major to non-major, record the further assessment, why the Article 8 criteria and thresholds were never fulfilled, the template fields used for the reclassification notice, and the date the competent authority was notified.

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) - Supports evidence fields for estimates, template updates, secure channels, reclassification, outsourced reporting, and aggregated reporting.
- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Supports the criterion-by-criterion evidence pack and recurring-incident assessment.

*Recommended next step*

*Placement: before sources*

## Build a classification record that supports DORA 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.

- [Open Research Copilot for EU DORA](/solutions/research-copilot.md): Ask source-linked questions about DORA major-incident criteria, significant cyber-threat notifications, report fields, reporting clocks, and reclassification evidence.
- [Talk through implementation](/contact.md): Review your DORA incident intake form, major-incident classification matrix, reporting-template field map, and evidence pack.

## 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, and use of templates.
  - Quote: "ICT-related incident management, classification and reporting"
- [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 classification criteria, materiality thresholds, the major-incident test, recurring incidents, significant cyber threats, and cross-border relevance details.
  - Quote: "Materiality thresholds for determining major 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 for initial notifications, intermediate reports, final reports, voluntary significant cyber-threat notifications, and reporting time limits.
  - Quote: "initial notification, the intermediate report, and the final report"
- [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 forms, Annex I major-incident fields, Annex III significant cyber-threat form, secure-channel rules, reclassification, outsourced reporting, and aggregated reporting procedure.
  - Quote: "TEMPLATES FOR THE REPORTING OF MAJOR INCIDENTS"

## 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 clock workflow: classification, reports, deadlines, and evidence](/artifacts/eu/digital-operational-resilience-act/incident-clock-workflow.md): Grounded DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
- [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-classification-forms